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