jueves, 6 de junio de 2013

El pequeño imcomprendido

Este post podría hablar de mi mismo, de los problemas que creo que tengo para lograr que otras personas me entiendan, pero no, eso lo dejo para otro día, o mejor para el diván.

Hoy revisar un poco sobre otro pequeño incomprendido, que comparte mis iniciales: JavaScript

Un poquito de historia

JavaScript fué creado en Netscape por Brendan Eich. Querían un  lenguaje interpretado fácil de aprender, en cierta forma, como Visual Basic. El nombre en clave era "Moca", pero como en ese momento estába de moda Java, le pusieron JavaScript. Esa fué, en mi opinión  uno de los principales vectores de la confusión e incomprensión que sufre el lenguaje. Si querés aprender y no sabes la diferencia, podes llegar a seguir un tutorial complejo de Java por error, y los lenguajes, en si, solo comparten cierta sintaxis heredada de C.

Según cuenta la leyenda, a javascript lo crearon entre gallos y madrugada, y como estaba aparentemente listo y completo, lo metieron en Netscape, así como estaba. No es que JavaScript no sea un lenguaje de programación "turing completo", es que hay algunos comportamientos que son distintos de lo que un programador con cierta experiencia podría esperar.

Como lo viví yo.

Si bien mi primer lenguaje fue Logo, allá por 1994, y tuve pasos fugaces por Visual Basic y C++, mi romance mas fuerte fue con python. Python es un lenguaje lindo, es  como una chica linda, inteligente y comprensiva, que te ayuda a que programar, te avisa cuando estas haciendo burradas, y por lo general es sincera con vos. Esas "bondades" hacen que uno analice muchos aspectos de otros lenguajes de programación. Desde ese punto de vista, JavaScript es horrible, criptico, e impredecible. 
Pero siempre en la vida de un programador, por necesidad, o eventualidad tenes que escribir código PHP
(que tire la primera piedra quien esté libre de PHP...) y ahí la visión cambia. PHP es como el estereotipo de minita, es lo que quiere el mercado, cuando las cosas no andan bien no te dice nada, cuanto mas lo conoces mas de mentira te das cuenta que es, y termina siendo una relación dolorosa (Por ahí para PHP no porque es bien minita). Desde esa comparación, JavaScript queda bien parado. Vendría a ser el lenguaje mas humano posible, con sus idas y vueltas, pero real, sin mentiras. Los lenguajes de programación, son en cierta forma como las personas, si te dejas llevar por la primera impresión, te podes equivocar, y tienen imperfecciones, como todos, si, hasta Python tiene sus grises.

Por donde arrancar

Al menos para mi, es importante estar motivado para hacer algo, las cosas que  mas me motivan de JavaScript, es que esta cada vez en mas lugares, o mejor dicho, hay cada vez en mas dispositivos que tienen browsers. Por otra parte, existe node.js, que nos permite escribir servidores asincronos usando el lenguaje, e incluso hay robots que usan JavaScript.
Lo que considero clave para aprender y querer al lenguaje, es aceptar que es distinto. No tiene clases "per se", y los ciudadanos de primer nivel son las funciones. Es un lenguaje funcional. 
Muchas veces me paso de encontrarme con código en el lenguaje "X" como si fuese el lenguaje "Y". (Python como si fuese java, ultimamente). Es algo muy normal cuando trabajamos con una mezcla de tecnologías (en el caso de que desarrollemos web), pero lentamente, es importante profundizar en las diferencias, para escribir mejor JavaScript.

Los materiales que mas me sirvieron

Mi heroe personal en materia de Javascript es Douglas Crockford, autor de el ya mítico "The World's Most Misunderstood Programming Language", lamentablemente, no puedo recomendar traducciones, porque... no me gustan las traducciones.
Para seguir avanzando, y entendiendo el lenguaje, el elegido es "JavaScript the good parts".
Paul Irish, también es un crack, el screencast de "10 cosas que aprendí mirando el código fuente de JQuery", es un material tremendo.

miércoles, 5 de junio de 2013

Zafá del xml con Tryton Builder!

Hay cosas que no me gustan, y hay cosas que detesto. En esa escala de valores, en el primer lugar está PHP y en el segundo los XMLs. Como conté en el post anterior, estoy desarrollando algunos módulos para Tryton, que define sus vistas, y elementos de interacción usando ese lenguaje de markup.

Hay varios artículos que hablan que uno tiene que ser un programador vago, yo estoy totalmente de acuerdo con que hay que ser un programador que automatiza al máximo el trabajo que no le gusta hacer, para poder dedicar el tiempo a problemas mas complicados o atractivos, o a mirar por la ventana.

En mi intento por zafar de escribir varios cientos de  '<',' /', y '>' a mano nació Tryton Builder (Que tiene logo y todo!)


Por el momento, para generar un módulo, hay que escribir un pequeño archivo de código (Si, es código python, porque me gusta programar, no parametrizar, yamls, csv, y ese tipo de cosas) de este estilo:



En el ejemplo, estoy realizando todos los pasos para generar el modulo de ejemplo del wiki de tryton

Solo para comparar la diferencia de caracteres escritos versus generados:

El proximo paso, es armar una interfaz de consola como la de los scaffolders de Ruby On Rails




martes, 4 de junio de 2013

Monkey Patcheando Element tree para soportar cdata

Hace un tiempo que estoy trabajando con Tryton, el ERP libre, escrito en python, y como me gustan los scaffolders de Rails, decidí escribir uno para armar los esqueletos de los módulos. Tryton, no se bien por que motivo, utiliza mucho xml, para definir vistas, y fixtures de datos. Como me gusta programar en python, me empezé a escribir una especie de DSL para definirlos de una manera mas amigable:
https://github.com/joac/tryton_builder

Python permite trabajar con xml con un montón de bibliotecas distintas, pero las mas amigable de usar, para mi es ElementTree

Cuando empece a escribir el codigo, y hacer pruebas, me encontré con varios problemas, el primero, ElementTree no tiene "Pritty Print"
para que el xml generado sea mas cómodo de leer, por suerte encontré esta receta:


en http://effbot.org/zone/element-lib.htm#prettyprint que resolvió correctamente el problema

Avanzando en el diseño de los scaffolders me encontré con otra limitación  ElementTree no soporta el tag CDATA. Usted podria preguntarse "¿Que es el tag CDATA?", Básicamente un tag que le dice al parser "Lo que esta aca adentro es un conjunto de caracteres, no lo parsees"
Si bien se puede evitar el uso del tag, ingresando el texto escapado (por ejemplo, en lugar de '>' escribir '&gt' ) el objetivo es que el XML no deje de ser legible, encontré otras recetas en StackOverflow:
http://stackoverflow.com/questions/174890/how-to-output-cdata-using-elementtree

Pero finalmente, decidí escribir mi propia versión basada en algunos de los comentarios (la receta con mas votos no funciona en python 2.7+)