El Blog de Marcelo!

Me gustaría hacer un post bien largo acerca de todo lo que me dejó personalmente la última PyCon Argentina, pero lamentablemente estoy complicado con el tiempo, ya que no sólo quiero leer y escribir acerca de todo el “bombardeo” de información que te deja cada charla, sino que también quisiera investigar un poco cada cosa y dejar acá algo más que solamente los links. Pero bueno, vamos a hacer el intento de resaltar lo primero que me viene a la mente.

Cappuccino y la Web que se viene

Uno de los muy interesantes punteros que me dejó la conferencia tiene que ver con las keynotes[1][2], y la existencia por un lado de la aplicación web 280Slides y por el otro del framework en el cual se basa, Cappuccino. Sugiero pegarle una mirada, más que nada a las demos (para los faltos de tiempo como yo); me parece que es sencillamente genial, hay mucha influencia del OS X acá, y se nota. Es una aplicación donde la línea entre lo desktop y web se esfuma, literal y definitivamente. Lástima que hay que aprender oootro lenguaje nuevo, Objective-J.

Y esto parece que no se va a detener, tal como dijo Jacob. Más si nos enteramos que hay desarrollos bastante avanzados para integrar contextos canvas 3D en los navegadores, y leemos algunas características futuras de HTML5. En resumen, él plantea que toda la toolchain web actualmente apesta, incluso Python, y propone algunas líneas de solución para que Python sea el lenguaje web del 2020, cuando HTML 5 sea el estándar y el navegador web sea el nuevo Sistema Operativo. Ya había escrito algo de esto.

Código más rápido, código más optimizado: LLVM

De la segunda plenaria, me quedó claro que al fin surgió un contendiente de relativa importancia al venerable GCC, y se llama LLVM. Acá tengo más todavía para investigar, pero básicamente el branch performante de Python llamado Unladen Swallow implementará (entre varias cosas más) un JIT para CPython implementado por medio de LLVM; algo así como V8 o TraceMonkey son para Javascript. Una de las cosas en las que Collin afirmó varias veces fue que “no pretendemos ser originales, queremos robar ideas de cualquier paper, de donde sea, con tal de hacer Python más rápido” . Lo malo es que al parecer, y si bien era una de las ideas iniciales del proyecto, eliminar el GIL no será tan fácil (de paso y relacionado, ¡excelente charla la de Multiprocesamiento en Python!).

LLVM está haciendo muchos méritos para ser considerado, como por ejemplo que Apple está apostando muy fuertemente por él, incluso tiene la idea de reemplazarlo definitivamente dejando atrás a GCC. En Snow Leopard (OS X 10.6), ya mismo se ofrece una interfaz compatible con GCC para LLVM además de toda la toolchain para compilar software desde los fuentes con él. FreeBSD también está trabajando para migrar a él. Y si bien todavía le falta bastante camino por recorrer (tiene escaso soporte para C++, o que no compila el kernel de Linux, por ejemplo), ya se pueden ver algunas muestras de su potencial, y personalmente encontré varios comentarios de que es mucho más sencillo contribuir y entender el código del proyecto comparado con GCC.

En fin, repetí en ambos párrafos, en asuntos totalmente diferentes, la palabra toolchain, que significa literalmente “cadena de herramientas”, y está relacionado generalmente al uso de varias herramientas como un conjunto en las diferentes etapas de la creación de aplicaciones. Evidentemente, tanto en el mundo de las aplicaciones web, como en el de los lenguajes de programación, se está yendo hacia la optimización de los recursos que tenemos. ¡Buenísimo!

[1] Snakes on the Web – Jacob Kaplan-Moss
[2] Unladen Swallow – Collin Winter

¡Gracias a PyAr por una excelente PyCon!
Saludos

Mucho no me gusta hacer posts con casi nada de aporte propio, pero en este caso se lo merece. Este post sólo va a referenciar al excelente sitio de Doug Hellman, PyMOTW (Python Module of the Week). Básicamente el autor presenta una vez por semana un módulo de la biblioteca estándar de Python, realizando un análisis del mismo y mostrando ejemplos de uso.

En particular, esta semana hizo una introducción al módulo dis, que desensambla código Python mostrando el bytecode respectivo. Lo bueno es que muestra varios usos para el mismo (nuevos para mí), como en el caso de un debug o en el de optimizar el funcionamiento ahorrando bytecodes.

En fin, preparándome para la inminente PyCon Argentina, me entusiasmé leyendo y probando los ejemplos de este post. No puede haber programador python que no esté subscripto a su feed.

Saludos!

Sólo me voy a limitar a copiar el texto de la invitación… de más está decir que espero ansioso los días para ir, y creo que va a estar buenísima. Si sos programador o estás haciendo tus primeras armas en la programación, ¡no podés faltar!

Está abierta la inscripción para participar de PyCon Argentina 2009, la primera conferencia en castellano sobre el lenguaje de programación Python, a realizarse los días 4 y 5 de septiembre en la sede de la Universidad de Belgrano, Zabala 1837, en la Ciudad de Buenos Aires.

En esta primera edición contaremos con la participación de Jacob Kaplan-Moss (creador de Django) y Collin Winter (core developer de Python) como invitados especiales del evento, y con más de 30 charlas sobre Python y temas relacionados, desde tutoriales para principiantes hasta charlas de nivel avanzado.

Cronograma de charlas:
http://ar.pycon.org/2009/conference/schedule/

La entrada es libre y gratuita. Para evitar contratiempos, confirmar su asistencia y recibir credencial y demás materiales de la conferencia, se recomienda realizar inscripción previa en el sitio web.

Inscripción y más información:
http://ar.pycon.org/2009/registration/

Espero conocer gente ahí… ¡nos vemos!

Dando vueltas por ahí, me entero que es muy sencillo utilizar localmente versionado de código fuente (gracias a los sistemas de control de versiones distribuidos, como por ejemplo Mercurial, GIT y Bazaar) para luego subir/actualizar los cambios a un repositorio Subversion principal. Es decir, en vez de usar los comandos svn como clientes de un servidor Subversion, es posible utilizar alguno de estos sistemas distribuidos como clientes “consumidores” del repositorio principal, para luego aprovechar sus importantes ventajas en forma local.

En principio, admito que no conozco ningún VCS distribuido, más que nada por vagancia (je), pero esto en particular sí lo necesito de vez en cuando, principalmente cuando no estoy conectado, y/o cuando los cambios que hago con respecto a trunk son profundos, llevan tiempo y quiero tener un control más “fino” en lo que hago.

A ver, habiendo nombrado primero los sistemas más conocidos (por mí), se desprende que tenemos:

• Mercurial-Svn: Si bien el autor del artículo que me inspiró a escribir esto (Vadim Zeitlin, desarrollador de wxWidgets) comentaba que le gusta muchísimo Mercurial por su fácil uso, al momento de probar esta extensión para subir los cambios al servidor SVN de wxWidgets tuvo problemas de performance, uso de memoria, etc. De todas maneras, el código fuente en el repositorio de wxWidgets es bastante grandote (~330MB), así que quizás funcione bien para proyectos chicos/medianos, y más si uno ya conoce Mercurial.

• Git-Svn: Bueno, citando nuevamente a Vadim, parece que critica un poco lo complicado de los comandos Git, sin embargo termina recomendándolo en forma rotunda por su velocidad y poca utilización de espacio extra en el disco*. Acá parece haber un tutorial cortito para utilizarlo (Google me devuelve muchísimos enlaces más por si es poco).

• Bazaar-Svn: A Bazaar lo conozco por su relación estrecha con Launchpad y Ubuntu, por lo tanto yo probaría a este primero… ah, y ellos mismos elaboraron una comparativa (imparcial) entre Bazaar y Git por un lado, y entre Bazaar y Mercurial por el otro.

En fin, recién me sumerjo en la lectura y experimentación de todo esto, pero para aquellos que trabajan contra un servidor SVN** y suben sus cambios con poca frecuencia al repositorio principal, “rompiendo todo” cada vez que lo hacen (guiño, guiño), me parece que esto les viene perfecto.

Además, tengo entendido que no es difícil usar Bazaar (por poner uno de ejemplo), y realmente está muy cool poder volver atrás en los cambios que uno hizo desde que hizo el checkout/update del SVN, mientras desarrolla, y sin tener que conectarse a Internet (VPN/SSH/etc.).

(*) Cuando el cliente de control de versiones distribuido hace un checkout del repositorio Subversion, no sólo descarga la última versión de trunk, sino que descarga todas las versiones pasadas de todas las ramas existentes, con lo cual el consumo de espacio en disco local pasa a ser un asunto importante. Git, según Vadim, parece tener poco overhead en este sentido comparado con la extensión de Mercurial.

(**) Una de las cuestiones que no le hacen perder valor e importancia a SVN es que, al ser centralizado, sigue siendo relevante en empresas que quieren tener un control más o menos estricto de su código; por lo tanto, la migración a sistemas distribuidos no siempre estará bajo su radar. Es por eso que hablo de “diferencias” en el título del post y no de una “futura migración”, es decir, que los distribuidos sean los “nuevos vecinos de la cuadra” no quiere decir que vengan a reemplazar a los viejos y conocidos.

¡Saludos!

Bueno, este es el primer post de mi blog sobre WordPress en dominio propio, marcelofernandez.info.

No hace falta cambiar el Feed RSS, ya que al hacerlo yo en FeedBurner, directamente va a levantar los nuevos posts del dominio nuevo.

El cambio lo hice estrictamente porque me cansé de esperar que Blogger avance… es demasiado básico para un montón de cosas. Vamos a ver cómo nos va, por ahora me enamoré de WordPress.

Saludos