Semana ganada

General — Sábado 15 de Junio de 2013, 10:06


Yo sé que mucha gente lo dice del deporte en general, pero a mí me pasa con el tenis: es un vicio.

Al contrario de lo que me pasa con la heroína, cuyo consumo mantengo estable [0], juego muchas veces tenis una vez por semana, a veces no juego, y otras semanas juego dos veces. Cuando me pasa que juego dos veces, el segundo día estoy mucho más afilado, estable, dinámico... juego mejor, bah. Y cuando termina el segundo día, quiero tener tenis al otro día también!

En fin, ¿por qué lo de semana ganada? Este jueves jugué un partido "de entrenamiento" contra un rival que normalmente me gana, ya que tiene un nivel superior al mío. Pero ayer le gané (6-4, 1-6, 10-8), aplicando varias cosas que aprendí en las clases en las últimas semanas.

Y ayer viernes, repetí tenis. Tenía la final de la ronda perdedores del torneo del club. Esta es mi segunda final en un torneo (sin contar los de pool en Las Vegas [1]), y la primera vez la perdí en dos sets.

Pero esta vez jugué bárbaro, y no le dí chance al rival: 6-2 6-3.

Estoy chocho :)


[0] No probé heroína jamás, así que el consumo es estable en cero
[1] Contando los torneos de pool en Las Vegas también, porque nunca jugué ninguno (es más, no conozco Las Vegas)


CDPedia al cubo

Python — Jueves 13 de Junio de 2013, 23:42


Tres cositas tres, sobre CDPedia, en orden cronológico.

El once de Mayo pasado salió al aire por CN23 la emisión de Geekye en la que Irina Sternik me entrevista, justamente, sobre la CDPedia. El programa entero está subido acá en iutúb (arranca desde la parte que nos compete).

CDPedia en Geekye

Además, el martes que viene, a la mañana, es la presentación de Huayra Linux, el sistema operativo libre del Programa Conectar Igualdad (el logo y el motto es genial, "el día en el que las vacas vuelan ha llegado", :p). Esto es relevante acá porque Huayra sale de entrada con CDPedia instalada... o sea que todos los chicos que reciban una compu de Conectar Igualdad van a usar y disfrutar CDPedia! Están todos invitados al acto, es en Tecnópolis, 10:30hs.

Finalmente, les cuento que la semana que viene tenemos PyCamp 2013. Entre los proyectos que voy a empujar está obviamente CDPedia (acá están todos los proyectos, un lujo!), y en particular quiero ver si logramos dos cosas: por un lado un sistema de generación continua (algo que esté armando todo el tiempo CDPedias en distintos idiomas) y por otro lado que esta aplicación funcione en Android (con lo que se tendría todo el contenido de Wikipedia, offline, en los teléfonos y tablets).


Cenas de cumpleaños

Comidas — Jueves 06 de Junio de 2013, 19:07


Moni hizo un par de cenas con motivo de su onomástico que sucediose el mes pasado, y yo, a modo de agasajo, cociné para todos algunas cosas que normalmente preparo.

La primer cena armé unas bruschetas de entrada. Todas con una base de rodajas de pan de campo, tostadas luego de ponerles un poco de aceite de oliva. Hice de champignones y cebolla de verdeo, de sardinas sobre un colchón de tomate, y de jamón crudo y rúcula.

Bruschetas

Luego, para la cena, hice una tortilla española de 10 huevos (nunca había hecho una tortilla española, ni una tortilla taaaan grande, pero tenía ganas de estrenar mi sartén nuevo :p).

Tortilla

La cena no era sólo eso: también había colita de cuadril al horno, con cebollas, morrón y tomates, lo cual fue lo más sencillo de preparar (lejos) de toda la noche.

Para la segunda cena amasé pizzas. Me encanta prepararlas con harina de trigo 000, y ponerle un poco de harina integral y un poco de harina de salvado... en conjunto, hace que salgan bastante livianas.

Hice pizzas de cuatro quesos: mozzarella, parmesano, queso azul, y queso fresco...

Pizza cuatro quesos

, ...de berenjena rehogada con provenzal casero, con queso...

Pizza de berenjenas

, ...de panceta, tomate fresco y cebolla de verdeo...

Pizza de panceta

, ...y de rúcula y jamón crudo.

Pizza de rúcula y jamón crudo

Me encanta preparar cosas que no cocino siempre, especialmente cuando viene gente invitada, y tiene más adrenalina que prepararlo cuando estamos sólos en casa...

Todas las fotos de estas comidas (y otras), acá.


Un largo camino al .exe

Software — Miércoles 29 de Mayo de 2013, 12:43


Algunas versiones de Encuentro (si no recuerdo mal la 0.5 y 0.6) estaban empaquetadas para Windows (con instalador y todo).

Pero hacer ese trabajo era un perno. En este caso lo hacía un muchacho que se llama Javier Andalia, pero después no lo continuó. El drama es básicamente que GTK, la biblioteca que se usaba para la interfaz gráfica es muy poco amigable para hacerla andar en Windows. Siempre fue un dolor de muelas, lo sigue siendo, y no creo que cambie.

Todo empeoró cuando del lado del server cambiaron todo obligándome a cambiar un montón de cosas de mi lado. Ahí salió la versión 0.7, que funcionaba correctamente con el estado actual de situación, pero dejaba a los usuarios de Windows sin tener algo que les funcione.

Y la verdad es que el contenido de Encuentro, Conectate, BACUA, etc, está buenísimo y da para que lo disfruten todos, aunque el usuario tenga un sistema operativo de mierda.

Entonces, encaré el laburo de migrar de GTK a Qt. Y una vez estuvo eso, empaqueté nuevamente para Windows y armé el instalador.

Luego de un par de semanas de "beta", tengo el orgullo de presentarles Encuentro 1.0, :D

Es una release rara porque a nivel funcionalidad real no hay mucho impacto, pero internamente cambió todo.  Igual, lo importante acá es el nuevo público al que puede llegar.

Ah, y mañana jueves con Diego Mascialino (el otro gran desarrollador de Encuentro) hacemos la release party de esta versión... o sea, nos juntamos a tomar algo y jugar unos pooles en Wrangler's... el que quiere venir que venga, están todos invitados! (pero cada uno se paga lo suyo :p).


La estructura de un proyecto: ejemplo Encuentro

Python — Jueves 23 de Mayo de 2013, 18:43


Un tema que se ha visto varias veces, tanto en la lista de PyAr como en la vida real, es que los desarrolladores que no estuvieron involucrados en proyectos grandes, o que sólo estuvieron metidos en uno o dos sistemas (más allá el tamaño), no saben muy bien qué estructura, o qué forma, darle a un proyecto nuevo.

Es totalmente comprensible. La estructura a tener depende de muchos factores: de la complejidad del proyecto, de cuan listo lo deja uno para empaquetarlo, de la prolijidad del desarrollador, etc.

Lo notable es que (en mi experiencia) el proyecto aunque nazca pequeño, siempre conviene que esté ordenado. Y que la forma de ordenarlo, qué estructura darle, cambia en función de las necesidades (como decía arriba) pero que siempre es bueno tener alguna.

En función de todo esto es que paso a contarles qué estructura tiene hoy Encuentro. No es la mejor del mundo, pero es la que a mí me funciona en este y otros proyectos. Y es una buena base como para que alguien que no tiene idea sepa para qué lado ir ordenando los tantos.

El código en sí lo pueden ver acá o si tienen instalado bazaar pueden hacer bzr branch lp:encuentro y exploran el código de forma local.

Bueno, a los bifes.


El código "útil" en sí

Tenemos dos archivos y varios directorios...

- test: Este es un script que básicamente ejecuta todas las comprobaciones que necesitamos para asegurarnos que el proyecto está "verde". En el caso de encuentro, corre las pruebas de unidad (las que están en el directorio tests, ver abajo), luego corre un verificador estático de código genérico (pylint) y finalmente otro verificador puntual para pep 8.

- version.txt: La versión del programa. La tengo separada sólo por consistencia: me gusta que esté en un sólo lado así es la misma para todos los que la necesitan (setup.py, para mostrarlo al arrancar, o cuando el usuario pide info del programa, etc).

- bin/: Aquí (normalmente) hay un sólo archivo, con el nombre del proyecto: encuentro. Este es el script de inicio, el que arranca todo el sistema ya sea cuando lo ejecutamos desde el proyecto mismo, desde un tarball descomprimido, e incluso es el que va a parar a /usr/bin cuando se instala. Este es el único que es ejecutable, el resto del sistema son sólo módulos.

- encuentro/: Es el directorio principal del proyecto (por eso el nombre). Acá tenemos todo el código "de producción" del proyecto, con su estructura interna. Por lo pronto, en este mismo directorio están todos los módulos que tienen que ver con el funcionamiento interno de Encuentro.

- encuentro/ui/: Aquí tenemos todo el código que necesitamos para armar la Interfaz del Usuario del programa. También tiene que ver con el funcionamiento interno de Encuentro, pero es sólo el manejo de la interfaz. La separación de qué va aquí o qué va directamente en encuentro/ a veces es complicada.

- encuentro/ui/media/: Todas las imágenes, audios, etc, que necesitamos para que funcione la UI en sí.

- encuentro/logos/: También imágenes, pero que se usan como identificación del programa en sí. Aunque algunas se usan en la parte de UI, están todas acá porque también se usan en otros contextos (por ejemplo, en la instalación del paquete).

- tests/: Los tests de unidad del proyecto, normalmente un montón de archivos cuyo nombre arranca con "test_" pero también pueden haber otros (módulos o no) para dar soporte a las pruebas.


Otros directorios

Estos son directorios puntuales que tengo para Encuentro. Algunos se repiten con otros proyectos, otros no.

- qtreactor: El módulo de integración entre Qt (el framework de interfaz gráfica que estoy usando) y Twisted (una biblioteca asincrónica que uso para trabajar con la red).

- server: Cuando le decimos al programa "local" de Encuentro que actualice los episodios, se baja algunos archivos comprimidos de mi server, con toda la metadata. Estos archivos comprimidos se generan una vez al día a partir de los sitios webs de Encuentro, Conectate, BACUA, etc. El código para realizar todo esto está en este directorio.

- web: Todos los archivos necesarios para montar el sitio web del proyecto.

- windows: Imágenes, configuraciones, y explicaciones necesarias para armar el .exe en Windows y luego armar con eso el instalador final que se distribuye.


Otros archivos

Estos son otros archivos que no tienen demasiada relación entre sí, pero que son importantes en distintos momentos de la vida del proyecto:

- AUTHORS, COPYING: Info legal: cuales son las personas que participaron del proyecto, y la licencia del mismo.

- LEEME.txt, README.txt, AYUDA.txt: Textos de ayuda para la persona que llega por primera vez al proyecto (viéndolo desde los archivos fuente). Está en dos idiomas, pero como Encuentro es inherentemente para personas que hablan castellano, el LEEME es el que tiene la info posta.

- anuncio.txt, pasos_release.txt: Recordatorios y textos preparados para mí (o para el que haga la release del proyecto... que vengo siendo siempre yo, :p).

- pylintrc: Un archivo de configuración para el verificador estático de código que mencionaba arriba.

- setup.py, MANIFEST.in: Script principal de empaquetamiento e instalación, más un archivo que podríamos decir de configuración del mismo.

- encuentro.desktop, source_encuentro.py: Dos archivitos necesarios en sistemas Debian/Ubuntu (al menos). El primero le pasa al sistema info para poner el programa en el menú del usuario, y el otro es usado en caso de que el programa crashee, para informar automáticamente del problema.


Malena, un mes

General — Jueves 09 de Mayo de 2013, 18:20


Hoy Male cumpre un mes, y para festejar (?!) subo cuatro fotitos de la pequeña en distintos momentos.

La primera es con Felipe, en un momento de cariño:

Malena y Felipe


Acá están en pleno baño, con cara de circunstancias:

Malena en pleno baño


Al final de dicho baño, con Moni:

Luego del baño reparador (?)


Y apoliyando, que de eso sabe un montón...

Durmiendo


Kilink, el pastebin útil

Software — Domingo 05 de Mayo de 2013, 22:03


Con el gran Nico César hace tiempo definimos lo que serían los términos de un servicio que queríamos ofrecer. Por cuestiones varias de la vida, al final nunca terminamos armando algo que cumpla con todos estos requisitos, aunque arrancamos con el proyecto. Pero lo arrancamos en un repo privado.

Muchos meses después, viendo que jamás vamos a seguir eso, le pedí permiso para liberar el código y las especificaciones que armamos. Entonces, subí el código del proyecto a GitHub, y tengo reservado el dominio kilink.com.ar para ofrecer el servicio ahí.

Este proyecto, entonces, lo declaro abierto a la comunidad, para el que quiera participar, participe. Yo lo voy a empujar en el PyCamp de este año!


Descripción general

La idea es ofrecer un "espacio de colaboración de corta vida".  Algo así como un pastebin dinámico, pero que al mismo tiempo sea fácil de usar. En definitiva, algo útil.

Los kilinks van a poder ser editables, y cada nueva edición será hija del kilink editado (cada "submit" es un commit en un virtual versionado de código). Aclaración importante de terminología: el kilink es *uno solo*, que tiene distintas versiones; este kilink único tiene siempre la misma URL, el mismo "kilink id".

Habrá tener coloreado de código, como todos los pastebines, pero con dos grandes diferencias: detección y coloreado automático de tipo de texto, y edición coloreada.

La autenticación será lo más sencilla posible para que un visitante pueda decir "soy Fulano" en la menor cantidad de clicks posibles. La idea es ofrecer de esas autenticaciones que son tan automágicas ahora: openid, via twitter, o facebook, etc, o de última un "usuario/clave" por si la persona no tiene ninguno de los otros mecanismos fáciles.

No hay mecanismos de "compartición" de los kilinks: cualquiera puede acceder a cualquier kilink (en general por la URL que se comparte, pero también buscando, ver abajo).

La autoría del kilink y la responsabilidad sobre ese texto es del usuario que lo pegó ahí. Hay que declinar explícitamente responsabilidad.  El texto incluido en el mismo es de "dominio público" y puede ser mostrado/usado indiscriminadamente.

¿Por qué usar kilink?

  • Se puede usar anonimamente...
  • ...pero recuerda quien sos
  • Permite compartir un texto en pocos clicks
  • Se da cuenta del lenguaje
  • Es amigable a nivel de interfaz
  • Copia el texto directamente a tu clipboard
  • Se puede integrar el texto en donde quieras, por versión o siempre actualizado!


Facilidad de uso / primera impresión

El diseño tiene que ser simple y efectivo, orientado a bajar la barrera de entrada del visitante, el "costo" que el usuario tiene que pagar desde que llega a la página hasta que tiene el kilink en su portapapeles para pegarlo en otro lado. Esto se ve en varios detalles, por ejemplo:

  • que el cursor por default esté en el textarea destino
  • que el textarea, en lugar de estar 100% vacío, tenga adentro un "pegar acá" o algo similar en gris, suavecito, que desaparezca al pegarle algo.
  • que entre el textarea y el botón de submit no haya nada que distraiga
  • que el botón de submit se llame "crear kilink" o lo que corresponda
  • que pueda llevar la url del kilink creado sin tener que seleccionar un texto
  • que se pueda crear un kilink sin registrarse ni loguearse
  • botones para copiar automaticamente al clipboard: URL y texto del kilink
  • download as file
  • botón de imprimir, y CSS especial para que quede linda la impresión
  • etc

Visualmente, la página tiene que ser lo menos intrusiva posible, hay que minimizar la "polución visual", pero sin dejar de ofrecer la información necesaria (al hacer hover con el mouse, o en colores que no llamen demasiado la atención).

Otras características:

  • una URL o kilink ID que casi funciona como  URL corta, ej: kilink.com.ar/4g3jxd
  • el contenido del kilink debería ser indexado por google y otros buscadores


Contribución anónima

Se va a poder crear o editar un kilink sin tener que registrarse ni loguearse, pero va a aparecer "Anonymous" como autor (o algo más divertido).

Dicho esto, al usuario le conviene autenticarse, ya que de esta manera puede tener distintas ventajas:

  • Es autor de los tuits que cree (figura su nombre, digamos)
  • Como es autor, puede borrar sus tuits
  • Tiene en su perfil preferencias para adaptar mejor kilink a sus necesidades (habría que ver cuales :p )


Edición, versionado, diffs

Un gran detalle con respecto a la edición es que va a ser "in place". En otras palabras, en lugar de ofrecer un texto estático y un área nueva (como la mayoría de los pastebines), queremos mostrar el texto del kilink, y que el usuario lo pueda editar ahí mismo.

Obviamente, poder editar nos va a generar una estructura de árbol para las versiones. Este árbol será mostrado de forma explícita en la interfaz web, pudiendo el usuario hacer click en cualquiera de los nodos, viendo las distintas versiones del mismo kilink. Al mostrar las distintas versiones como nodos de un árbol se evita confundir al usuario con cosas como versiones "hermanas", "padres" o "hijas". El usuario ve la versión que tiene elegida, y si la edita aparecerá un nuevo nodo hijo del que estaba viendo.

También, se podrá elegir dos versiones, y pedir un "diff" entre las mismas.


Coloreado del texto y tipo del mismo

¿Qué es la autodetección? En lugar del funcionamiento "pastebin clásico" (de pegar un texto y elegir qué tipo de texto es), cuando el usuario pegue el texto se debe autodetectar qué tipo de texto y colorearlo en el momento según el tipo detectado. Obviamente, va a haber un combobox con todos los tipos, que cambia automáticamente al tipo autodetectado, pero que el usuario puede modificar para rectificar una autodetección erronea (obviamente, si el usuario cambia a mano el tipo de texto, el coloreado cambiará correspondientemente).

La "edición coloreada" es la habilidad de poder editar el kilink y que se vaya coloreando mientras se edita (recordemos que vamos a mostrar un sólo texto y el usuario podrá editar directamente allí).

Ambos comportamientos no son fáciles de lograr, pero facilitaría mucho la interacción del usuario, y quizás con herramientas como google-code-prettify no sea tan complicado.


Caducidad de los kilinks

Los kilinks serán permanentes, nunca vencen y siempre estarán online, a menos que el autor del mismo los borre explícitamente. Esta no-caducidad hay que comunicarla explícitamente, pero aclarando que no nos hacemos cargo si un kilink desaparece por problemas ajenos o propios, o por la baja del servicio.

Con respecto a que los usuarios puedan borrar kilinks, sólo será posible si el usuario es el autor del mismo.

Como esta es una acción poco probable (nadie borra un paste, a menos que se de cuenta que metió info muy sensible o demasiado privada), la idea es que sólo se pueda hacer desde la página de perfil del usuario, para no ensuciar la interfaz de uso "normal".


Herramientas

Hay que tener una colección de herramientas, entre ellas:

  • plugin para editores (seleccioná el texto → kilink, salta a la pag web con el kilink ya creado)
  • plugin para navegador (seleccioná el texto → kilink, idem)
  • linea de comando ("grep ERROR *.log | kilink" y este escupe la url de un kilink nuevo)
  • applet que permita meter una "ventanita para rápidamente crear kilinks" en cualquier lado
  • applet que permita meter un "visualizador de un kilink particular" en cualquier lado
  • applet que permita meter "mis últimos kilinks" en cualquier lado


Tags

Los kilinks tendrán tags asociados, los cuales se crearán de forma semimanual, y servirán como filtros.

Habrá un área cerca del texto donde haya una colección de tags. Al crear un kilink, al momento de pegar el texto, en esa zona aparecerán N tags sugeridos por el sistema (luego de analizar el texto), el usuario puede borrar alguno de esos tags, o agregar más.

Mecanismos para autosugerir tags:

  • lenguaje de programación usado (if any)
  • bibliotecas específicas usadas en el código


API

Se debe implementar una API HTTP sobre la cual se podrá hacer todo lo que se pueda hacer, al punto que la interfaz web usará esa misma API para trabajar contra el backend.

La API tendrá dos modos: autenticado y público. Para el modo público no se necesita nada en particular, pero no se puede hacer todo desde ahí (por ejemplo, borrar kilinks).

Idea: Debemos revisar las APIs de pastebin, snip y tinypaste, que son las más piolas que vimos, para diseñar de entrada algo que tenga sentido. También hay que ver cómo autenticar.

Idea: Ofrecer en el sitio bindings para distintos lenguajes de programación.


Estructura de costos de tener un auto

General — Miércoles 01 de Mayo de 2013, 22:09


El siguiente es el análisis de todos los gastos durante el primer año al auto que compramos con Moni el año pasado, un Sandero Stepway 1.6.

La idea es poder ver cuanto cuesta tener y mantener un auto mediano, y cuales son los rubros que más impactan en ese valor.

Los gastos están separados en distintos rubros, algunos fijos y otros variables (en función del kilometraje). Estos rubros son los que yo uso para llevar mi contabilidad casera, por eso los tengo separado así.

Los rubros son:

  • Estacionamiento: no pago cochera fija por mes (ni en casa (y yo laburo en casa), ni cuando Moni va a trabajar), así que este gasto es el estacionamiento cada vez que voy a Capital o parecido, más alguna que otra fichita de parquímetro.
  • Seguro: el auto tiene seguro contra terceros completo en La Caja a través del Automóvil Club Argentino (ACA), pero aparte de ese costo, acá incluyo el mismo valor que yo guardo como "autoaseguro" (que es un yeite que me rinde más que pagar directamente un seguro más caro). En otras palabras, el valor este es mitad para "el seguro", mitad para un "sobre" en el que guardo plata para gastos que el seguro cubriría si fuese más alto.
  • Patente: eso, la patente, tener en cuenta que el auto está anotado en Provincia de Bs As.
  • Mantenimiento: principalmente el ACA por mes y algún que otro lavado del auto, ya que como el auto es nuevo y está en garantía no tengo gastos de mecánico (pero justamente por esto, acá están incluidos los gastos de los dos servicios, de 10 y 20 mil kilómetros); un detalle es que los primeros tres meses del auto no pagué el servicio ACA porque me los bonificaron al tomar el seguro.
  • Nafta: más claro echale nafta: los gastos de ídem; ojo con sacar algún rendimiento a partir de este valor, ya que el gasto de nafta está afectado muchas veces por el descuento del ACA o de pagar con la tarjeta el domingo.
  • Peajes: los gastos de peajes automáticos en Capital y Gran Buenos Aires, pero no los correspondientes a los peajes en ruta (porque esos los pago en efectivo y los considero como gastos de los viajes mismos, casi siempre vacaciones).

Autito

A esos rubros, le agrego lo que es la amortización de la compra del auto en sí, considerando el valor que pagué en su momento, y que el auto se amortizaría en cinco años (teniendo en cuenta un valor residual chico).

En este año, que al auto le hicimos 23742 km, los gastos fueron:

  Estacionamiento: $ 3761.25
  Seguro:          $ 4457.00
  Patente:         $ 2545.20
  Mantenimiento:   $ 3539.00
  Nafta:           $11641.92
  Peajes:          $ 1281.69
  Amortización:    $14300.00

El gasto total en este año (considerando gastos fijos y variables) es de $41526, lo cual da $3461 por mes: $2070 de gastos fijos ($878 sin contar la amortización), y $1390 de gastos variables.

El costo total por kilómetro es de $1.76. Este valor es interesante porque toma en cuenta todos los gastos fijos, más variables, más el costo de comprar el auto (teniéndolo cinco años y luego vendiéndolo), y me da la pauta que (en mi caso!) conviene tener auto que moverme en remis.

Otra conclusión interesante es que la nafta representa el 28% del costo total total del auto, ¡nada despreciable!

Pueden ver los cálculos en este PDF, pero si quieren les dejo el notebook ipython que armé, para que jueguen con él (lo bajan y hacen ipython notebook costoauto1.ipynb).

Es interesante por si quieren ver por ejemplo el costo total por kilómetro si le hacen mucho menos recorrido (por ejemplo, porque viven en Capital y se moverían en subte), y de ahí comparar si les conviene tener el auto o usar remises; o agarrar las cuentas y sumarle un valor de estacionamiento fijo, etc. Y obvio, para actualizar el precio de compra que hoy es más que el año pasado...


LocoLander

Software — Viernes 26 de Abril de 2013, 19:31


En el último sprint internacional que fui en el laburo se me ocurrió una idea a la que le fui dando forma. Se la he contado a varias personas, y la encontraron interesante.

Es un proyecto donde la idea es dar un servicio gratis a la comunidad de software libre. Esto va más allá que Python, pero si lo podemos hacer desde PyAr para toda la comunidad, no estaría nada mal.

Estoy contando acá entonces de qué va el proyecto, y también voy a poner algo de esto en la página del PyCamp, a ver si genera tracción para ser laburado este Junio.


Contexto

La idea surge de una necesidad en particular. Una gran idea dentro de un proyecto de software es "la revisión por pares" (peer review). En ese contexto, cuando uno escribe el código de un cambio, ese código no va directamente al trunk (main, o head, o lo que sea) del proyecto, sino que uno termina el branch, y lo propone a revisión.

Entonces vienen los "pares" y revisan el código, a veces sugieren mejoras (a veces desaprueban totalmente los cambios, puede pasar) y uno tiene que hacer cambios posteriores, a veces lo aprueban sin más trámite, etc. El punto es que en determinado momento el cambio está listo para ser integrado a trunk (main, head, etc.). La acción de "meter el cambio en trunk" se la denomina muchas veces como landear (el código aterriza en el branch principal del proyecto).

¿Cómo se landea un branch? Bueno, hay formas y formas. Pero la más correcta, o completa, o la que está realmente buena hacer es....

  1. agarrar el trunk más reciente, y mergear los cambios del branch en cuestión
  2. si no hubo conflicto, correr los tests de integración del proyecto, y cualquier serie de pruebas (por ejemplo, verificadores de código como lint o pychecker).
  3. si todo estuvo bien, landear el código (esto es, commitear los cambios al trunk)


¿Cual es el problema de esta secuencia? Uno solo: es mucho trabajo. Entonces, o nadie lo hace, o el que lo hace termina tardando mucho en hacerlo. Y ambas situaciones son malas.

¿Por qué malas? En el primer caso, donde no se hace toda la secuencia, se corre el riesgo de meter en trunk código que rompe el mismo, o que no cumple con los estándares de calidad del proyecto. En el segundo caso, el tardar es malo para la colaboración: (me ha pasado que) a veces alguien externo al proyecto sugiere un cambio y escribe el código, y los desarrolladores del proyecto ven que está todo bien, pero demoran todos estos pasos, y finalmente el resultado es que los cambios propuestos tardan semanas en entrar a trunk, lo cual sólo sirve como desmoralizador de la gente que quiere ayudar.

Ahora, imagínense que uno, como desarrollador del proyecto, pudiera decir "este branch está aprobado, está listo para entrar en trunk", y viniera un bot al ratito, y ejecutase todos esos pasos que indiqué yo antes.

LocoLander


El proyecto

En detalle, lo que LocoLander haría es armar un entorno donde uno luego registraría su proyecto, el cual sería revisado de tanto en tanto, y si hay un branch para landear, se realizarían todos estos pasos automáticamente.

Para lograrlo, se levantaría una máquina virtual con un determinado sistema operativo instalado, se instalarían las dependencias que el proyecto necesite (y declare), se copiaría trunk y se le incorporaría los cambios del branch a probar, se correrían luego todos los tests y verificaciones, y finalmente si todo está como corresponde, se meterían esos cambios en trunk.

Algunas consideraciones:

- Configuración para el uso: Cuando se quiera usar LocoLander, se deberá dar de alta el proyecto en la página de LocoLander, autenticando de alguna manera para luego poder ver los resultados de cada intento de merge, etc., indicando qué otras personas pueden ver esa información, e ingresando algunos datos del proyecto en sí.

- Entorno para el proyecto: La idea es que el proyecto lo declare y que el entorno se arme solo en función de las necesidades de cada proyecto. Por ejemplo, que instale un Ubuntu Precise, más estos cuatro paquetes con apt-get, más estos dos con easy_install. Esta información viviría en un archivo especial del proyecto, que LocoLander leería en el momento del armado del entorno. Toda la salida a stdout/stderr de esta etapa quedaría logueada para poder revisarse.

- Ejecución de las pruebas: LocoLander, una vez armado el entorno y con el código brancheado, ejecutaría un archivo puntual (que también está indicado en el archivo de configuración antedicho). Ese archivo puede correr las pruebas unitarias y cualquier control sobre el proyecto, pero la idea es que termina con el resultado en ok o en error, y esto determina si el branch está listo para mergearse a trunk o no. Como en el caso anterior, toda la salida de stdout/stderr estaría disponible para el usuario.

- Repositorios: Aunque tenemos mucha variabilidad en el cómo usarlos, la intención es que LocoLander sea multi-repositorio. O sea que trabaje con Launchpad, GitHub, BitBucket, etc. El trabajo de soportar varios varía más que nada en función de las determinades capacidades que tiene cada repositorio y qué API presenta para no tener que andar scrapeando HTML o haciendo cosas locas para laburar autenticado.

- Autenticación de LocoLander: Esto depende del repositorio en sí, pero en general sería así: LocoLander tendría un usuario en cada repositorio, y si uno quiere usarlo todo lo que tiene que hacer a nivel autenticación es "incorporarlo como colaborador", o "darle permisos de commit en el proyecto", o lo que corresponda en cada repositorio. Lo que no se haría de ninguna manera es poner en el sitio de LocoLander tokens de autenticación de los distintos repositorios. De esta forma, los riesgos de seguridad son mínimos: LocoLander no posee datos críticos de nadie, y el dueño de cualquier proyecto puede en cualquier momento sacarle los permisos de commit a LocoLander.

- Elección de qué branch está listo para intentar mergear: Este punto también depende de cada repositorio. Por ejemplo, en Launchpad, cuando se hace un "merge proposal", el mismo tiene un "estado" que cualquiera con derecho de commit puede poner como "Aprobado", entonces LocoLander revisaría eso. Hay otros repositorios que no son tan completos, pero siempre se puede solucionar con algún texto especial en los comentarios que se dejan. Creo que este es el punto de más variabilidad.

- Previniendo abusos del código que se ejecuta: Un detalle importante en el funcionamiento de LocoLander es que hace muchas cosas él mismo (levantar una VM en particular, instalarle paquetes, etc), pero en algún momento ejecuta código que está en el branch. O sea, le está dando el control a alguien más. ¿Qué podemos hacer para evitar abusos (que la máquina no se ponga a mandar spam, o que no sea un nodo de seti@home...) Creo que el punto crítico acá es que en el momento de tomar el control el proceso potencialmente maligno no pueda acceder a internet para nada, ni a ningún recurso fuera de la máquina virtual en sí. Después se pueden poner condiciones de uso, cortar los procesos que están corriendo más de N minutos, o revisar periódicamente lo que parezca raro, pero creo que ya cortando la posibilidad de conectarse a cualquier lado se está restringiendo bastante la posibilidad de mal uso.

- Recursos necesarios: ¿Qué máquina se necesita para que esto corra? Mi idea es que no mucha. Quizás el más crítico es la memoria: hay que levantar una VM y ejecutar un proceso adentro que debería disponer de al menos unos centenares de megas para correr. Y también se necesita bastante disco (para guardar snapshots de muchas VMs, principalmente), pero cualquier VPS medio pelo da mucho disco. A nivel de velocidad de la máquina en sí, no me jode mucho: si los tests tardan en correr, alpiste.

Creo que cubrí todos los puntos importantes a la hora de definir el proyecto, pero si alguien tiene una duda, es bienvenido a preguntar.


Actualizaciones

Python — Martes 23 de Abril de 2013, 11:37


Estos días hice dos releases rápidos.

El primero fue de LauncherPosta, porque resulta que en Ubuntu Raring crasheaba mal. O sea, no tiraba un traceback: crasheaba.

¿Lo peor? Es un problema de la librería PyGtk, de cómo está implementado para Gtk 3. ¿Lo peor más peor de todos los peores? Es por diseño, y les parece bien que crashee a la mierda en lugar de tirar un traceback decente (miren el bug que abrí y lo que me respondieron).

En fin, esto refuerza lo que les decía que Gtk3 me gustaba menos y menos y me estoy pasando a Qt.

BTW, de LauncherPosta liberé la versión 1.0, con el casi único cambio de soportar mejor el toqueteo de la configuración del systray bajo Unity (un pedazo de código que luego les compartiré más separadamente).

El segundo release fue de Enjuewemela.

Hace rato que no sacaba una versión del jueguito. Es que aunque le había hecho un montón de correcciones, había un gran feature que estaba esperando: el replayer.

¿Qué es el replayer? Es un modo de ejecución de Enjuewemela que le decís que te reproduzca un juego anterior (le tenés que pasar el log que generó la jugada), y podés ir viendo exactamente el juego que hiciste, avanzando y retrocediendo con las flechas. Esto más que nada lo hice porque era necesario para poder detectar algunos crashes raros, y porque era divertido de hacer, :)

Los cambios más interesantes para esta versión 0.5, aparte de la habilidad de "re-jugar un log", son:

- Alienta cuando hay múltiples coincidencias
- Cambia el tablero cuando cambia de nivel
- Múltiple fondos
- Correcto manejo de los highscores
- Otras pequeñas mejoras y un montón de correcciones.

La verdad es que estoy un poco harto de Enjuewemela. Hay que ponerle un montón de laburo para "hacerlo más lindo" al juego, y la verdad es que "hacerlo lindo" no es algo que me divierta.

Así que creo que sacaré un gran último feature, y luego creo que lo paso a mantenimiento, porque tengo otros proyectos bastante más interesantes para empujar.

Ya los comentaré por este mismo canal. Stay tuned.


Vela

Fotos — Sábado 20 de Abril de 2013, 19:56


Esta foto la saqué en un monasterio tibetano, en un viaje que hice con motivo de una capacitación de Python para un programa que necesitaban para calcular un nombre.

Vela

O quizás la saqué en un patio de Paternal, en un cumpleaños. Ponele.


Migrando Encuentro a PyQt

Python — Miércoles 17 de Abril de 2013, 17:59


Este no es un post sobre Encuentro precisamente, sino sobre la experiencia de migrar Encuentro a Qt.

O, mejor dicho, a PyQt. ¿Qué es PyQt? Sencillo: una capa de unión para poder usar Qt desde Python. ¿Y qué es Qt? Qt es una biblioteca multiplataforma para desarrollar aplicaciones con interfaz gráfica. En otras palabras, una biblioteca para hacer las ventanas, botones, y todo eso que arma la interfaz gráfica de un programa de escritorio.

Con esa descripciones no tendríamos diferencia entre PyQt/Qt y PyGtk/Gtk, que es lo que usaba Encuentro hasta ahora. Entonces, ¿por qué migrar?

Son varias las razones... pero principalmente porque empaquetar PyGtk en un .exe es un dolor de muelas, y eso llevó a que la última versión que corre en windows es la que no funciona porque cambió todo el backend web (cuando los videos pasaron de ser hosteados por Encuentro a estar en Conectate). En otras palabras: la última versión de Encuentro que corre en windows no sirve para nada, y básicamente es culpa de Gtk.

Otras razón de menor importancia es que no me gustó como Gtk evoluciona. El futuro del framework es Gtk3, y ya estuve tirando código para usarlo, y lo que usé me gustó menos que Gtk2, así que me pareció un buen momento de cambiar. Finalmente, es una buena excusa para aprender Qt, ;)

Qt

En fin. La migración ya está terminada, pude hacer en Qt todo lo que tenía que hacer en función de la interfaz de Encuentro. ¿Qué me pareció? Bueno, las sensaciones son varias.

Me gustó Qt, mucho más cuadradito, más pytónico especialmente en la versión 4 que es la que yo estoy usando. Aunque la mayoría del código es muy similar, hay varias cosas que son más sencillas que en Gtk, aunque no todas, y hay bordes que limar.

(En este punto quiero aclarar que en ningún punto usé Qt Creator, el constructor gráfico de interfaces, sino que hice todo todo a mano, lo cual me permitió meterme bien adentro del framework y aprender mucho de su estructura subyacente.)

Un ejemplo de borde sencillo: no se puede saber si una señal está conectada o no. Entonces, por ejemplo, yo tengo un botón que muta de función, y a veces tiene que tener una señal conectada, y a veces otra (para que al hacer click haga una cosa u otra; en particular en el contexto de Encuentro: que el botón dispare la descarga del episodio, o la reproducción). Cuando el contexto cambia y se hace la revisión del estado del botón, no puedo decirle que desconecte cualquier señal que tenga, o preguntar qué señal tiene y desconectarla, tengo que (a mano) guardar en algún lado la señal que había conectado antes para desconectarla y conectar la nueva que corresponda.

Un ejemplo de algo complicado de hacer en Qt (que en Gtk es trivial): QTreeWidget no soporta HTML en el texto. Esto es, la habilidad de insertar tags para cambiar el tipo de texto (en el caso de Encuentro, yo lo necesito para resaltar en amarillo el fondo de las letras que coinciden con lo que el usuario ingresó en el campo de filtrar). Finalmente lo pude hacer, adaptando un ejemplo que Roberto Alsina encontró en la web, pero lo hace más lento, le agrega pequeños glitches que aunque no me joden, no deberían estar, y me mete a mí código oscurísimo que no es ni cerca de fácil de debuguear.

Por último, la integración con Twisted no es trivial. Hay cosas que en Encuentro están hechas con Twisted que podrían hacerse con herramientas más propias de Qt, sí, pero en este caso de migración, ya estaban hechas en Twisted y mi idea era aprovecharlas. Pero tuve que meter en el proyecto todo un módulo de integración y levantar la aplicación y cerrarla de una manera no trivial (y que me costó tiempo y sudor hacer que funcione correctamente, especialmente la parte de cerrar la aplicación, porque tuve que apagar los hilos de Twisted a mano).

La conclusión es que Qt me gustó bastante, y aunque extraño algunas cositas de Gtk, seguramente mis nuevos proyectos estarán usando PyQt.


«Anterior   1 2 3 4 5 6 7 8 9 10 11 ... 54 55 56  Siguiente»

Powered by LifeType