martes, 27 de diciembre de 2011

The Ruby Game


Es un site que tira acertijos o problemas ruby en los que todos pueden participar enviando el codigo y ves los resultados al instante, lo copado es que podes ver un ranking de las soluciones que todos enviaron y aprender cosas interesantes de la sintaxis de ruby

Let's the game begins!

jueves, 8 de diciembre de 2011

Git para usuarios de Subversion

O mejor dicho:
Git NO es para usuarios de Subversion

Ir de svn a git, no puede ser:
  • Siendo usuario SVN, leer guia "Git para usuarios de Subversion"
  • Siendo usuario SVN, Usar git traduciendo los comandos que ejecutarias si usaras svn (epic fail),
  • Encontraran esa experiencia fea mientras sacan en conclusión que git posee una complejidad innecesaria y es muy difícil de usarlo
"Para un usuario de svn siempre sera mas facil usar svn que git"

Par ir de svn a git, es mejor seguir estos pasos:
  • Siendo usuario SVN, leer guia "Como volverse un usuario de git"
  • Siendo usuario git, Usar git de manera natural
Asi git se usaria mejor, pero quedan dos problemas:
  • "Para un usuario de git siempre sera mas facil usar git que svn" , es decir, que una vez acostumbrado a git usar svn se vuelve complicado.
  • Y mas importante, cambiar de el svn mindset al git mindset no es para nada algo trivial

Si se sigue insistiendo con git, como una mera variante de svn, esto es lo q podria pasar (lo mas comun):
  • Siendo usuario SVN, leer guia "Git para usuarios de Subversion"
  • Pasar meses de agonia mientras se maldice a git, a Linus Torvalds y al manager/PL/co-equiper/profesor que te hizo usarlo ya que es muy complicado al pedo ("¡lo unico que quiero hacer es commitear!", "¡mis cambios desaparecieron!", "¡el merge fallo y perdi todo!", y asi...)
  • Librarse de git de alguna manera y volver al placido y reconfortante svn (o cvs :( )
O si no, esto es mas raro que pase:
  • Siendo usuario SVN, leer guia "Git para usuarios de Subversion"
  • Pasar meses de agonia mientras se maldice a git, a Linus Torvalds y al manager/PL/co-equiper/profesor que te hizo usarlo ya que es muy complicado al pedo ("¡lo unico que quiero hacer es commitear!", "¡mis cambios desaparecieron!", "¡el merge fallo y perdi todo!", y asi...)
  • Aprender como funciona y hacer "cosas que con svn no hacia", explotar sus ventajas
  • Volverse "usuario git" al "entender como funciona" a costa de todo el sufrimiento previo
  • Optar por git como control de versiones preferido en todo al punto de creer que usar subversion en realidad un obstáculo
De todo esto se concluye que es muy difícil que alguna tabla de equivalencia de comandos o "mini-tutorial" sirva para que un usuario que esta cómodo con svn pueda trabajar igual de cómodo y feliz con git, o por lo menos que valga la pena el cambio, para eso un usuario debe volverse "usuario de git" antes de usarlo y/o en primeras etapas del uso de la herramienta.

Que es ser un usuario de svn y que es ser un usuario de git (mindsets)

En esta seccion me voy a referir a un "usuario de svn" a alguien que usa svn desde hace mucho tiempo, y que esta comodo y feliz con la herramienta ya que tiene ese "mindset". Lo mismo para un "usuario de git".

No obstante, la característica mas importante a analizar no es la herramienta, sino la manera de pensar las cosas, los conceptos y en ultima instancia como resuelve las situaciones del dia a dia con su herramienta favorita. Como esto no es "git evangelism", y el foco es estudiar como pasar de svn a git, sere lo mas objetivo posible

Lo mas sencillo sera mostrar la siguiente tabla:

Problema o conceptoUsuario de svnUsuario de git
Tengo código que quiero guardar,
pero "no esta listo" para integrarlo
al trunk por lo que no quiero
commitearlo ¿Que hago?
"Facil: tengo tres opciones:
  • copio el codigo, y lo pego en un notepad,
  • copio en el mismo archivo pero comentado
  • No hago nada, porque se que puedo volver atrás con ctrl+Z
  • crear un branch, pero preferiria que no"
"Facil: puedo commitear ya que ese commit es local, o si no también puedo crear un branch"

Estoy trabajando en una feature nueva que todavia no commitie, y alguien me pide que resuelva un bug ¿que hago?
  • GTFO, esperar hasta que termine la feature y haga el commit
  • Hacer checkout del mismo repo en otro directorio, arreglarlo ahi y commitearlo
  • Copiar el codigo a otro directorio, revertir la WC, arreglarlo ahi y copiarlo
  • Guardo un "stash", arreglo el bug, commit, push. restauro el stash
  • Hago un branch

Tengo una funcionalidad a medio hacer sin commitear y me tengo que ir a mi casa, mis compañeros se quedan y podrian continuarla
  • No commiteo, solo yo sigo mi trabajo mañana
  • commiteo aunque el trunk quede inestable
  • Les doy mi computadora
  • Hago un zip con el codigo y se los mando
  • Me quedo hasta que pueda commitear algo bueno
  • Commiteo (es local) y despues pusheo a un branch asi los demas pueden seguir trabajando en el
Dos o mas integrantes del equipo colaboraran en el desarrollo de un nueva feature, que tardara un mes
  • Ahora si se justifica crear un branch
  • Pair-Programming y commitear cuando termine (no conviene)
  • Fragmentar en features mas pequeñas y commitear todos los días siempre y cuando "no rompan nada"
  • Definitivamente hay que crear un branch
Dos o mas integrantes del equipo colaboraran en el desarrollo de un nueva feature, que se completara en el diaPair-Programming y commit cuando se completeBranch
Commit"Es la esencia de esto, hay que hacer update antes del commit para integrar los cambios del servidor""Puedo commitear cuando quiera independientemente de que ocurra en el 'servidor'"
Branch"Creare branches solo cuando sea estrictamente necesario (por ej: features que tardaran mucho mucho tiempo) o lo indique la gente de SCM""Lo mas importante es saber manipular branches, porque aparecen todo el tiempo si se trabaja de manera distribuida"
Merge"Pasa automatico cuando hago update pero hacer un merge manual es un quilombo y tarda, por eso no convienen los branches""Pasa automaticamente cada vez que hago un pull y hacerlo manual es trivial y rapido"
Historia"La historia se almacena en una secuencia de changesets, por eso cada revision tiene un numero, eso lo hace sencillo""La historia se almacena como un DAG (Arbol) de commits, entender eso es importante para comprender los branches"


El usuario de svn usa los sencillos comandos provistos por svn y varias herramientas mas como editores, IDE, compresores, mail, etc... para resolver los problemas del dia a dia, mientras que el usuario de git para resolver los mismos problemas diarios usa solamente git, que para ser justos, git en realidad es un filesystem mas un set muy extenso de herramientas sencillas, pero git como conjunto de herramientas es complejo, quiere ser lo suficientemente complejo y sofisticado para cubrir todas las necesidades y que no sean necesarios ni notepads, ni código com
entado, ni mails, ni ctrl-Z para manejar versiones de código.

Un usuario de git estara pensando todo el tiempo que hace control de versiones en branches, para el es fundamental saber como manipular branches (crear, mergear, etc...) ya que sabe que los branches se crean todo el tiempo por trabajar de manera distribuida. Asumen el concepto de que es literalmente imposible trabajar sin branches en un equipo de desarrollo y por lo tanto no buscaran el imposible de "evitar branch a toda costa" sino solamente se dedicaran a controlar los branches que surgen para que no diverjan demasiado.
Consideran que todas las versiones son parte de un arbol que muestra la divergencia.

Un usuario de svn se enfoca principalmente en la "linea principal" y pensara en branches solo si surgen ciertas situaciones puntuales como por ej una feature que tardara demasiado tiempo (que en general es mejor evitar) o una version alterna del producto a medida. Asumen que la creación de branches siempre conlleva un overhead que en muchos casos solo sirven para complicar mas las cosas, muchos usuarios svn concuerdan en que si un branch va a durar mucho tiempo (digamos semanas) y se justifica podria aceptarse si el beneficio que se presume traera el branch supera ese overhead. Asi mismo cuando un branch se extiende en el tiempo y diverge mucho la integracion a la linea principal se vuelve mas complicada por lo que la integracion de esos "branches mounstruosos" es algo que no se busca (true story).
No consideran que la diferencia entre su working copy y lo que hay en el servidor sea un branch por que commitear y updatear es mucho mas facil que manipular branches.
Ven las versiones del repositorio como algo lineal

¿ Que pasa cuando hay que usar una herramienta "diferente" ?

Si un usuario svn, pasa a usar git con la consigna "reemplazo svn con git en mi set de herramientas", se encontrara que la complejidad de git, que es mayor que la de svn, sumada a la complejidad de las herramientas que esta acostumbrado a usar (bloc de notas, mails, etc...) se convertira en una molestia y no podría trabajar bien. Mientras que un usuario habituado a git, usa git para una mayor cantidad de cosas aprovechando al maximo posible las posibilidades de la herramienta (que son la cara buena de esas complejidades) y no permitiendo que surja necesidad de usar algo adicional, asi es como muchos se maravillan con git mientras otros no entienden porque si git es tan complicado.
Por ejemplo, a un usuario svn generalmente no se le ocurriría crear branches de corta duracion, porque tiene la idea de que son complicados y no valen la pena, ahi habria una ventaja que no se aprovecharía (mientras que lidear con muchas de las cosas complicadas esta implícito en el uso dirio). A alguien habituado con svn tambien le causaria mucha confusion el hacer un git pull y que el merge automatico no funcione, que se haya arrepentido o lo que sea ya que lo que hay en git no puede ser visualizado con un modelo lineal.

También es complicado para un usuario de git trabajar con svn, ya que tiene la costumbre de manejar el versionado de código solamente con una herramienta, se encontrara con que en svn los branches cortos no valen la pena y que hay muchas herramientas que faltan en comparación con git al que esta habituado y como esta acostumbrado a usar git todo el tiempo casi no conoce de herramientas "extras" y trabajar con svn le seria dificil.

Por eso el philosoraptor de la imagen se pregunta porque no existen manuales de svn para usuarios de git (mas bien seria manuales de las herramientas adicionales que hacen falta para complementar svn) si existen manuales de git para usuarios de svn.

Conclusión, como pasar de svn a git
  • Comprender que con git las cosas se hacen diferente, que hacerlas "a la vieja usanza" es mas complicado que con la herramienta de siempre
  • Abordar git de cara a las ventajas (ej: branching, merging, distribuido, forks, staging area, versionado local, etc...)
  • Cambiar la manera de hacer las cosas, para aprovechar funcionalidades de git (no pensar, tal funcionalidad no la uso porque así no hago las cosas, cambiar la manera de hacer las cosas)
  • Pensar "out of the box", estar listo para cambiar las estructuras de pensamiento mas elementales
  • Al enfrentarse a complejidades adicionales que no había en svn, buscar comprender porque es asi, como eso se relaciona con ventajas de la herramienta y como aprovechar esas ventajas
  • Ver las versiones como un arbol y manipularlas de esa forma. NO tratar de que las cosas funcionen como en svn (por ej: no pretender que git pull funcione como svn update porque son cosas diferentes)
  • Invertir tiempo, mucha gente que usa git dice que lo vale. No existe una manera rápida de aprender git pero el aprenderlo vale la pena

Links

Libro ProGit: http://progit.org/
Generador de memes: http://memegenerator.net/


miércoles, 30 de noviembre de 2011

¿Que version de ruby esta seleccionada con RVM?

RVM

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:
PROMPT_COMMAND="echo -n -e '\033[1;31m'\$(rvm current) '\033[0;37m'-\ "

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)

PROMPT_COMMAND="echo -n -e '\033[1;31m'rvm: \$(rvm current) '\033[0m'-\ "

martes, 29 de noviembre de 2011

¿RVM + bundler es un problema? NO (Solucion)

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:
rails new testapp
Algo no funciona...

El Problema

Veran que bundle se cuelga "indefinidame
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.

Links

Pagina oficial de RVM: http://beginrescueend.com/rvm/
Explicación de como instalar RVM: http://beginrescueend.com/rvm/install/


viernes, 11 de noviembre de 2011

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:

¿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:


Super Nario GC

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:
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.


sábado, 15 de octubre de 2011

¡concluyo CodeCamp 2011!

Y me puse la camiseta para dar una charla de git, junto con mi colega Nico Paez, quien obviamente no tardo en escribir este post acerca del tema (les recomiendo visitar el post ya que da acceso a interesantes recursos)

La charla que di

Gestion de la configuracion con nuget y Git (si, nuget tachado), la charla mas que nada empezo siendo iniciativa de Nico Paez quien se ve que la tiene muy clara en la oratoria sobretodo en lo didactico (enseña en la UBA) y se logro una exposicion muy copada, a pesar de que realmente no nos alcanzo el tiempo (esto mas bien significa que teniamos mucho para decir, y que sobre siempre es mejor a que falte ;) )
Cabe aclarar que Nico posee profundos conocimientos de muchos otros temas (los que hicieron posible la presentación). Aun asi, sus conocimientos de git todavia no son suficientes para que pueda ver 100% de las ventajas que git ofrece y tuve que dar un empuje (push?) en ese sentido en etapas de preparacion de la presentacion.

A los planteos de "seguir el tema", lo mas probable es que escriba algunos cuantos post, con resumenes tecnicos y continuando lo que quedo pendiente de la charla y no pudo ser en el momento

Por ultimo quiero felicitar a Nico Paez pues ha sido un gusto compartir esa actividad y tuvo mas aceptacion de lo que me imaginaba (vean los smiles en la foto). Ademas saque una enseñanza importante acerca de las presentaciones con diapositivas:
NO hay que poner diapositivas llenas de texto porque distraen al publico de lo que el/los oradores dicen, hay que recurrir a graficos, o a titulo sencillos que indiquen de que se esta hablando, en ocasiones yo como publico tambien me distraje leyendo diapositivas con texto

Links de la charla:

Las charlas a las que fui

Actualizacion: Ahora si funciona el sitio codecamp, talvez el dia de la jornada quedo saturado, ahi agregue los links


¿Que mas hay que decir? ¡Juegos multiplayer! ¡Sentencias/presagios de muerte para flash! ¡Java Lopez! De chico tenia el berretin de hacer jueguitos, despues los hice con QBasic (me siento viejo :S) , despues con VB, despues con Div Games Studio, pero estas historias son para otro post. Lo importante es que volver al mundo del desarrollo videojueguil con esta clase de tecnologias (HTML5 y demas yerbas) seria volver por una de las puertas grandes


Impresionante charla, queria saber en que estado estaba eso del XNA. Y por lo visto logran cosas muy copadas (con 3D y todo), pero para mi gusto demasiado exclusivo de plataformas microsoft, por el momento me inclinaria mas al HTML5 con javascript, o Java, algo que corra "en todos lados"


El pasado lo conociamos casi todos (esta en los libros), el presente lo vi (y no me gusto), a mi y a la mayoria de los presentes en esa charla nos intrigo el futuro,
A mi me gusto la charla, me entere de cosas que no sabia que existian (¡C++ tiene lambdas!) y tambien de cosas del nuevo c++ que hay en windows 8, que no tiene garbage collector ni es managed (a cambio tiene la mega-performance y el bajo nivel) pero tiene reference counting integrado con el lenguaje, interaccion casi "magica" con cualquier otro lenguaje como por
ej javascript y seguro un monton de cosas mas que el tiempo no da para explicarlas todas en una sola charla.
No me gusto cierta parte del mensaje tanatico, si puede llamarselo asi, que anuncia que "todo estara en c++" (igual solo es una forma de decir), fuera de ese detalle la charla me gusto bastante y el c++ con todas las implementaciones a nivel IDE que agregaron ahora sera mas "soportable"

Masas de desarrolladores, masas de chocolate

Masividad de desarrolladores talentosos exponiendo ideas y/o curiosos en la cacería de
conocimiento
Masividad de azucar, masas y cafe masivo... la comida/bebida
ideal para las 24x7 de la mayoria de los informaticos, y que en realidad no llevan a la practica por falta de dinero/infraestructura hepatica capaz de procesar toneladas de glucosa diaria

Disclaimer: no llegue a sacarle fotos a las masas, pero eran del estilo de las que se ven en la foto y eran ricas

Unicas Criticas

A la tarde se acabo la azucar (o no se conseguia) para el cafe :(, lo perdono al considerarlo tambien una buena medida para controlar el consumo adictivo de glucosa (combinado con el sedentarismo tipico de la profesion IT puede llegar a ser dañina) y teniendo en cuenta de q las masas ya proveian la sobredosis necesaria de glucosa

No podia ir a las 10 charlas que habia en cada horario a la vez, si bien no eran todas taaaaan interesantes, habia horarios en los que era muy dificil decidir entre dos o tres sesiones interesantes que habian al mismo tiempo

miércoles, 14 de septiembre de 2011

Anti-Pattern legacy: making a zip in the era of DVCS

Un anti-patrón es una solución repetitiva incorporada o aprendida para la cual se demostró que lejos de resultar una buena solución para un problema (como aparentaría en un principio) genera mas problemas que los que soluciona.
Mientras que el concepto se popularizo como anti-patrón de diseño con orígenes en el libro Design Patterns, el concepto de anti-patron se utiliza en variedad de escenarios como en la programación (ej: el infame Codigo spaghetti), project managament (ej: Groupthink)

Anti-Patrones como Patrones Legacy

Algunos (¡y muchos!) anti-patrones como Waterfall model (Desarrollo de software en cascada), son practicas o patrones generalmente aceptados y enseñados en viejas épocas y que ahora al quedar obsoletos fueron reemplazados por otras practicas mas eficaces (Desarrollo iterativo, metodologías agiles, etc...) . A pesar de eso viejas practicas quedan en el knowhow colectivo y lo importante es saber reconocerlos como anti-patrones y no como una practica que haya que fomentar (y también saber cuales son las practicas que son convenientes por estos tiempos).

Anti-Patrones en Control de versiones

Como se había mencionado anteriormente, el concepto de anti-patrón se extendió rápidamente a variedad de entornos, siendo uno de ellos el mundo de las versiones (o como algunos le dicen, SCM), un área del desarrollo de software que crece mas lentamente que otras (el porque de esto seguramente lo tratare en algún que otro post).
A pesar de no haberse desarrollado mucho, SCM (o abreviado CM) fue un ciencia/brujería/técnica que paso por varias fases a lo largo de su historia pasando por herramientas que solo servían para trabajar individualmente, sistemas de control de versiones concurrentes para equipos (CVS :P), sistemas centralizados mas avanzados para dar mejor soporte a ramas aunque no sea lo suficientemente bueno (ej: SVN), sistemas distribuidos (ej: Mercurial) (para información detallada vean este excelente articulo acerca de la historia del source control).
Esta historia es la que habilita la posibilidad de que determinadas buenas practicas muy comunes y que resultaban satisfactorias ayer sobrevivan mas allá de su obsoletización para convertirse en anti-patrones hoy.

Los Patches que se usaban antes

Una de las practicas que fue muy utilizada durante un tiempo fueron los patches, sobretodo en los entornos de desarrollo open source, en épocas donde la internet estaba en pañales y cosas como codeplex, github, googlecode no existían ni en la imaginación (es mas, muchas de esas compañías ni siquiera existían), cuando alguien realizaba una contribución a un proyecto lo que generalmente este hacia era generar un patch (que no es mas que un .tar.gz o .zip del diff entre determinadas versiones y/o el contenido de esas versiones) y posteriormente se lo hacia llegar, era común mandarlos por email firmados, adjuntarlos en foros, BBS, etc... En definitiva, no existía el concepto de "commitear a un repo en la nube".

El "Make a zip" que se usa ahora

Posteriormente exploto la internet, llegaron los servicios, se estabilizaron y herramientas como SVN pudieron cobrar mas protagonismo, yo por ejemplo usaba el servicio de http://www.assembla.com/, que por esos momentos ofrecia SVN (estamos hablando del 2006 aprox.).
Sin embargo, existía cierta "cosa" por la cual "commitear al repo" no era tan frecuente, estaba (y esta) vigente Continuous Integration, una excelente herramienta para llevar a cabo proyectos integros aprovechando al máximo un versionador, pero que inadvertidamente dejaba varios asuntos de lado.
Uno de esos asuntos es el intercambio de código "unmanaged", es decir, código que no debería ser parte de la mainline en ese momento, pero que lo seria en el futuro o que tiene que por diversas razones tiene que "estar en algún lugar".

Noten que hasta el momento no use la palabra con B.

Entonces, generalmente es fácil caer en este razonamiento: "Si ahora se esta usando un repositorio para compartir una mainline, y eso es fabuloso, entonces como envió el código que no tengo que commitear por H o por B razon ? Uso lo que ya conozco, y hago un patch para poder enviar el contenido" ( o en otras palabras, hacer un zip ) lo cual parece que es algo bueno porque era una practica normal y promovida en las viejas épocas, y al trabajar con sistemas de control de versiones centralizado como el mas popular de esa generacion (svn) incluso yo creo que trabajar con codigo "unmanaged" de esa forma es mas practico que hacer branches la mayoria de las veces.

DVCS's y la palabra con B

Pero la practica de realizar patches, en DVCS's como Mercurial o Git solo existe como una practica legacy, un anti-pattern (aunque siempre habrá excepciones, pero deben ser las menos y muy poco frecuente). En herramientas distribuidas de versionamiento, las soluciones alternativas al problema del código "unmanaged" están a mano y es mas facilitada por la herramienta que ofrece alternativas mas practicas que el uso de patches, mails con código o archivos zip y por supuesto mas practicas que las soluciones ofrecidas por herramientas de generaciones anteriores.
Intercambiar código con otros desarrolladores solamente a travez del repositorio y usar otros métodos solo para los que por alguna razón no puedan, no deseen, o no sepan como acceder al repositorio.

lunes, 12 de septiembre de 2011

Yet another blog?

le preguntaba a un co-worker , Nicolas Paez y Angel "Java" Lopez. si seria conveniente o no crear un blog nuevo para los articulos pendientes que tengo acerca de SCM (no centrado en git) y me di cuenta que la respuesta no es tan obvia como imaginaba en un principio.
Segun Nicolas es conveniente que tenga un solo blog unificado, esto suena bastante bien por una cuestion de simiplicidad y para poder dar una referencia de mi (ej. el blog de Dario Seminara) pero al imaginarlo me vi escribiendo varios articulos muy especificos de diferentes temas en el mismo blog. Por ej vean la detallada explicación de un problema tecnico de un proyecto particular, la explicación de como usar branches en git y un resumen de herramientas UML online ¿todos esos articulos caben en el mismo blog? ¿o mas bien lo mio solo es una impresion erronea?

Los temas acerca de lo que iba a escribir no caben en gitevangelism ya que tratan de alejarse de git mientras el titulo de aquel blog indica que contiene ayudas tecnicas de git (pretendo que cualquiera que entre a ese blog encuentre lo que el blog promete por titulo, ni mas ni menos)

Los nuevos articulos tampoco parecen ir muy bien en este blog (Nilclass) porque a pesar de que Nilclass haya quedado como el blog de "miscelaneas" estos temas son muy especificos, densos y analiticos. No es un post que uno quiera ver en el camino cuando busca lo "generico"

Segun las propias palabras de Nico: "Yo tengo un unico blog y escribo sobre distintas cosas, pues no tengo tantas cosas para escribir", lo cual es algo que yo asocio a la estrategia de mantener un solo blog al ser pocas las cosas para escribir. Mientras, por mi parte, ahora estoy experimentando como explotar al máximo la comunicación mediante blogs. Buscando la manera de escribir todo lo que sea escribible y publicable (tratando de seguir un ritmo similar al de Java Lopez) y difundir aquellas ideas genéricas, que si bien es muy probable que fueran aplicables en un entorno real de trabajo, no conviene explicarlas en una meeting/retrospective o en medio de un trabajo enfocado en lo concreto.

Un ejemplo de eso es este mismo post, que originalmente fue una conversacion en medio del trabajo y se convirtio en un post que podra ser leido por cualquiera en la web incluyendo obviamente tambien a las personas a la cuales me interesa que la informacion les llegue.

Todavia no decidi en que blog iba a escribir esos articulos pero aprendi muchas cosas acerca del mundo del blogging que resulto ser mas nuevo para mi de lo que creia en un principio

Mis blogs

lunes, 18 de julio de 2011

La memoria y TDD: Refactor/test backlog & Sleeping in Red

Hace tanto tiempo que no escribo en este blog, y ahora vuelvo a escribir (sin razon aparente) para contarles unas impresiones acerca de como se me ocurre optimizar TDD en relacion con la memoria (humana), en esto cualquier comentario que puedan aportar no solo sera bienvenido sino que tambien muy apreciado

Lo basico

Bueno, para no dar mas vueltas voy directo al tema empezando por la basico (salteen este parrafo si saben basicamente en que consiste TDD)
TDD es una practica de programacion que basicamente consiste en escribir los tests primero y refactorear el codigo convenientemente, este proceso se ejecuta de manera iterativa pasando por tres fases en cada iteracion: rojo, verde y refactor. A grandes rasgos:
  • La fase "roja" consiste en escribir tests que fallen expresando especificaciones de como las cosas deberian funcionar, antes de que se implementen
  • La fase "verde" consiste en buscar que esos tests pasen a toda costa, es decir que "vale todo" de manera que el codigo se llena de chanchadas en esta fase (lease codigo duplicado, harcodeos, variables globales y cualquiera de esas cosas feas que se ven en las pesadillas)
  • La fase de refactoring la cual hace mas lindo el codigo, limpiando todo lo que se ensucio en la fase verde anterior mientras se mantenga el 100% de tests en verde
Para mas informacion de TDD pueden ver el articulo de la wikipedia o simplemente buscar en la web que esta lleno de blogs que explican cosas muy interesantes

¿Que tiene que ver la memoria con TDD?

La memoria tiene que ver con todo, y en el caso especifico de TDD, la memoria del programador actua diferente de fase en fase (suponiendo que no use un soporte externo como voy a explicar mas adelante).
  • En la fase roja, que inicia el ciclo de TDD, la informacion que el desarrollador utiliza para escribir los tests son las especificaciones (para reducirlas a especificaciones de componentes en el codigo, etc...). No se necesita ninguna informacion memorizada ya que las especificaciones vienen escritas (y si no, ya no es un asunto de TDD). Solo se requiere informacion extra para escribir casos "borde", caminos "no felices" o cualquier cosa que no este explicitamente en la especificacion.
  • En la fase verde, se tiende a usar informacion que se escribe en los tests para hacerlos pasar, como por ejemplo nombre de clases, metodos u otra informacion que se escribio en los tests. Depende del caso, se suele utilizar mucho conocimiento del proyecto, pero por ahora eso no importa porque esa memoria esta mas alla del scope de un ciclo de TDD
  • En la fase de refactor, se utiliza informacion que esta en el codigo (por ej, al observar metodos duplicados) e informacion producto de ideas, razonamientos, observaciones al codigo efectuadas en cualquier momento, ya que el codigo se esta observando siempre y hay que considerar que refactorear codigo para mejorar su calidad interna no es una tarea trivial (como si lo es hacer que los tests pasen) y requiere mas trabajo mental
Las fase que mas informacion producida en el mismo ciclo y mas trabajo mental requiere es la de refactor, la fase verde requiere mas trabajo mental que la roja

Refactor backlog

El que haya usado TDD, seguro se encontro en la situacion de duplicar cierto codigo para hacer que un test pase teniendo en mente refactorizarlo despues (no en el momento), no deberia memorizarse esa informacion ya que eso es proclive a olvidos y disminuye la concentracion en la tarea del momento, en lugar de eso es mejor usar un "backlog" (que seguramente no sera el mismo backlog agile, es algo distinto) o un "ToDo list" el cual se debe alimentar cada vez que se observe algo que deba ser refactoreado y que no corresponde hacerlo en ese momento

Test Backlog

Para aplicar el mismo concepto que en el parrafo anterior, cada vez que miramos al codigo, se nos ocurre "¿y si llamara a tal metodo con tal argumento, fallaria?", lo mejor en ese caso sera escribir un test que pruebe eso. No suena muy practico interrumpir el trabajo para hacer pasar los tests o el trabajo de refactoring para escribir el nuevo test fallido en el momento, por eso es mejor anotar los test nuevos en algun lugar a medida que se van descubriendo e implementarlos mas tarde. En mi opinion, lo ideal es hacerlo al finalizar la fase verde o de refactor con todos los tests pasando (se considera que se vuelve a la fase roja)

Dormir en rojo

Todos tenemos que descansar en algun momento, y el verdadero descanso consiste en distraccion total y si es posible completo olvido del trabajo (y si es posible irse a dormir :P). Eso implica que, al volver al trabajo, tratar de recordar informacion acerca de la tarea que se estaba realizando antes de interrumpirla para descansar, es significativamente mas costoso que recordar lo que se estaba haciendo hace pocos minutos o segundos (como en el caso del trabajo continuo).
La fase que menos memoria reciente requiere (despues de la inicial) es la verde (la de hacer pasar los test), por eso si se va a interrumpir la tarea lo mas conveniente es hacerlo con todos los nuevos tests fallando (al terminar la fase roja) ya que si se hace antes del refactor al volver se tendra que recordar los items de refactor pendientes (a pesar de usar el backlog, este solo actua como un ayuda-memoria que hay que leer, no como una memoria auxiliar). La fase roja inicial requiere menos memoria reciente pero es mas trabajosa, usa informacion de las especificaciones y es mucho menos trivial por lo que aunque tambien sea util interrumpir antes de escribir los tests no es tan conveniente como pausar despues de escribirlos.

Conclusiones
  • Voy a asegurarme de escribir todos los test que pueda antes de interrumpir la tarea para descansar, y despues hacerlos pasar cuando vuelva a trabajar
  • Voy a implementar un backlog/ToDo con items de refactor que voy a consultar cuando haga pasar todos los test
  • Voy a implementar un backlog/ToDo con items de test (pero voy a ver si eso realmente es util o no)
Links

TDD en la wikipedia: http://es.wikipedia.org/wiki/TDD

domingo, 13 de marzo de 2011

El blog para los proyectos

Se llama Tario's Project Blog ( http://tario-project.blogspot.com/ ) y lo hice especificamente para los proyectos para los que estoy trabajando bajo ese nickname en github (https://github.com/tario) y posiblemente otros. El objetivo de esto es construir un site separado donde se pueda consultar el status de esos proyectos y al mismo tiempo no saturar este blog con esa clase de informacion. Ademas, Tario's Project sera escrito integramente en ingles para tener un mayor alcance (mas tarde evaluo si implemento la version en español del blog o aprovechando alguna que otra feature de internacionalizacion que vi que tiene blogger)

Lo ideal en realidad, seria dedicar una pagina a cada proyecto, pero en este caso los proyectos son chicos y son muchos ademas de que estan muy relacionados unos con otros (por ej, el release de cierto gem puede tener alto impacto en la usabilidad de otro ya existente), mas adelante, si corresponde, habra un site para proyectos que crezcan en importancia.

Enlaces:

El nuevo blog: http://tario-project.blogspot.com/
El sitio de repositorios en github: https://github.com/tario

martes, 25 de enero de 2011

Buscar la raiz cuadrada mas rapida, con Ruby

Se vienen los examenes y uno de ellos es el de Analisis Numerico, y como estoy usando mucho la raiz cuadrada en un proyecto en el que estoy, me decidi a buscar una raiz cuadrada mas rapida que la que trae el propio framework ;)

La verdad, es que por default, las librerias matematicas calculan la raiz cuadrada con una muy buena precision, pero pueden surgir casos en los que esa precision es innecesaria (por ejemplo, si se trunca el resultado de la raiz cuadrada, es decir, tirar a la basura los decimales que se calculo) y lo que si es importante es poder efectuar los calculos rapido

Sea cual sea el lenguaje en e que se va a programar, ruby esta bueno para probar los algoritmos muy facilmente, en este caso se utiliza el metodo de Newton-Raphson para calcular la raiz cuadrada de un numero


# x**2 - a = 0

# calcula la raiz cuadrada y se le puede especificar la precision, es decir
# la cota superior del error del resultado
def Math.my_sqrt(a, precision)

x = 1
oldx=1

iter = 0
# newton raphson
while 1
oldx = x
x = x - ( x**2 - a ) / ( 2 * x)
break if (oldx-x).abs < precision
end

x
end

def show( code )
print "#{code} => #{eval(code)}\n"
end

show "Math.my_sqrt(2.0, 0.5)"
show "Math.my_sqrt(2.0, 0.05)"
show "Math.my_sqrt(2.0, 0.005)"
show "Math.my_sqrt(2.0, 0.0005)"

show "Math.sqrt(2.0)"



Salida del programa


Math.my_sqrt(2.0, 0.5) => 1.41666666666667
Math.my_sqrt(2.0, 0.05) => 1.41421568627451
Math.my_sqrt(2.0, 0.005) => 1.41421568627451
Math.my_sqrt(2.0, 0.0005) => 1.41421356237469
Math.sqrt(2.0) => 1.4142135623731


Enlaces:

Metodo de Newton explicado en la Wikipedia
Explicacion del metodo de newton usado para calcular la raiz cuadrada de un numero