Canonical Voices

What Bitácora de Vuelo talks about

facundo

Curso de Python confirmado


Estoy muy contento porque el primer Curso Abierto de Python que armé ya está 100% confirmado, :).

El curso es de 18 horas en total, de 19 a 22, los días Miércoles 25 de Septiembre, 2 y 9 de Octubre, saltamos un miércoles, 23 y 30 de Octubre y 6 de Noviembre.

Quedan sólo un par de plazas disponibles, si quieren anotarse tienen todos los datos en la paginita que armé. Una novedad es que ahora también se puede pagar por DineroMail: no me conviene demasiado, pero permite pagar con tarjeta de crédito, RapiPago, PagoFácil, etc., así que supongo que podría ser cómodo para alguien en algunos casos...

Read more
facundo

PyDay en Junín 2013


Este fin de semana se sucedió otro evento en Junín. Organizado por Juan Rodriguez Monti, con la colaboración de varios de los chicos de siempre, y con el apoyo indiscutible de la facultad, armaron otro PyDay que salió muy muy bien.

No estuve en todas las charlas, pero fui a varias; las que más me gustaron fueron la de Alecu "Controlando Python desde Arduino", la de Juanjo Ciarlante "Software Libre en las nubes", y la de Daniel Coletti "Ser emprendedor con Software Libre".

Alecu en su charla

Yo dí una charla nueva, "Emulando paralelismo de forma asincrónica", una charla bastante complicada pero que salió bastante bien. Eso sí, tardé una hora en darla, así que le tengo que pegar una revisada para ajustarla y simplificarla un poco.

Además, fueeeeeeeera de programa, dí un tallercito de "Introducción a Python" el día anterior en la Universidad, pero la asistencia fue muy baja, :(. Por otro lado, estuve jugando un poco al tenis el domingo a la mañana, así que eso compensó, :D.

En fin. Ir a los eventos de Junín siempre está bueno, y los disfruto bastante.

Read more
facundo

Vacaciones serranas


Los últimos días de Julio y primeros de Agosto nos fuimos de vacaciones con la familia.

La mayoría de los días los pasamos en Merlo, donde hicimos base para (además de conocer la ciudad en sí y sus atractivos turísticos) pasear por San Javier, Yacanto, Nono, Mina Clavero, etc.

Las montañas, desde la cabaña

Luego, cruzamos las "altas cumbres" y nos quedamos un par de días en La Bolsa, una ciudad cerquita de Alta Gracia. De ahí paseamos a Villa General Belgrano, visitamos amigos en Córdoba Capital y también en José de la Quintana.

Pasendo por la ciudad de Alta Gracia

En general, paseamos bastante pero no demasiado, ya que para los chicos en algún momento se ponía pesado el tanto movernos. Pero conocimos lugares hermosos, compramos cosas ricas, y disfrutamos mucho todo.

Destaco un reloj de sol que está buenísimo, hecho por Pérez Celis. Bah, son dos relojes, uno horizontal, y otro vertical (y este de dos caras), que no sólo te daba la hora, sino también el mes. En las fotos hay una en particular que explica en detalle cómo leerlo e interpretarlo.

Reloj de sol

También visitamos un algarrobo de más de 1200 años de viejo, y como atracción está bueno destacar el Camino de las Altas Cumbres, hermoso para hacerlo en velocidad de paseo, ya que sube y baja toda la montaña.

De Merlo me llamó la atención que muchos semáforos tenían un contador de segundos que indicaban cuanto faltaba para que cambie de rojo a verde o viceversa (lo cual estaba buenísimo), pero no encontramos ni un semáforo para peatones :(. Otro detalle que noté es que no había nada de wifi público en ningún lado, lo cual me sorprendió porque escuché mucho del "wifi en San Luis" y esperaba que funcione en uno de sus principales puntos turísticos...

Todas las fotos, acá.

Read more
facundo


Finalmente me decidí, y armé un curso grupal para aquellos que quieren aprender Python, no como parte de un grupo cerrado para una empresa o institución, sino abierto al público en general.

Será un Curso Introductorio a Python, apuntado a aquellos que no saben nada de este lenguaje, o saben algo pero quieren profundizar o formalizar conocimientos.

El nivel es introductorio, lo que significa que se van a ver muchos conceptos del lenguaje de manera profunda, pero no se tocarán temas avanzados ni satélites a lo que es Python en sí, con la intención que el asistente gane sólidos conocimientos que luego le permitan explorar el resto a su gusto.  Se necesita tener conocimientos previos de programación (pero no hace falta ser un programador avanzado).  En detalle, el contenido del curso versará sobre los siguientes ítems:

  • Introducción: ¿Qué es Python?; Primeros pasos; Recursos
  • Tipos de Datos: Haciendo números, y más números; Cadenas de texto; Tuplas y listas; Conjuntos; Diccionarios
  • Controles de flujo: if/elif/else; loops while y for; Excepciones
  • Encapsulando código: Funciones; Clases; Módulos; Espacios de nombres
  • Otros temas: Archivos; Trabajando en Red; Conexión con Bases de Datos

El formato del curso será presencial, en un ambiente "tipo aula" con pizarrón y proyector, pero no basado en filminas, sino totalmente dinámico y adaptativo.  Se hace un foco especial en la interacción profesor-asistente, de forma de ir resolviendo las dudas de todos y lograr un aprendizaje más profundo en el mismo tiempo.  En función de esto también se limita el cupo, con una cantidad máxima de asistentes de alrededor de diez personas.

Como parte del curso se entregará un certificado de asistencia al mismo, basado en una evaluación sobre un proyecto personal o grupal, totalmente a decisión de el/la/los/las participante(s).  Este proyecto se arranca durante el curso, pero puede continuar después del mismo, bajo mi supervisión/tutoría (sin costo extra).  También se entregará documentación de forma digital.  No se necesita asistir al curso con computadoras, pero pueden traer laptops/netbooks si lo desean (van a disponer de conexión a internet via wifi y conexión eléctrica).

El curso es de 18 horas en total (tres horas por clase, un día a la semana, seis semanas), de 19 a 22.  En esta primera oportunidad se hará el curso en un lugar céntrico de la Ciudad de Buenos Aires, los días Miércoles 25 de Septiembre, 2 y 9 de Octubre, saltamos un miércoles, 23 y 30 de Octubre y 6 de Noviembre.

El costo total del curso será de $920; es necesario abonar al menos el 50% para reservar la posición (recuerden que, como indicaba arriba, hay un máximo de lugares disponibles), abonando el saldo restante el primer día de clases.  El curso comienza con un cupo mínimo de 4 alumnos, a confirmar como máximo los primeros días de Septiembre. En el caso de no formarse el grupo, se postergará el inicio o se reintegrará el dinero completo de la seña.

Para reservar, entonces, deberán depositar o transferir el dinero a mi cuenta del banco, para lo cual coordinamos por mail. Si se les complica esta manera de pago, lo charlamos.

Bueno, creo que cubrí la mayoría de los puntos.  Si tienen alguna duda, pueden preguntar por acá, o en privado al mail, sin ningún problema.

Read more
facundo

Mil grullas


Esta foto la saqué durante el evento 1000 Grullas que se hizo en el Teatro de la Ribera, al que fuí con la familia y donde todos aprendimos a hacer grullas con papel.

La idea era, obviamente hacer entre todos mil grullas, en función de la leyenda japonesa.

No sé cuantas se hicieron, pero al menos yo aprendí a hacerlas :)

Grullas

Todas las fotos de ese día, acá.

Read more
facundo


Bueno, todos los saben, porque no sólo tenemos una página de los proyectos que íbamos a encarar, sino que también armamos un video el último día con todo lo que se hizo durante el PyCamp!




Para completar el ciclo, pueden ver fotos del evento acá, acá, acá y acá.

Read more
facundo

Mondongo


Para el día del padre pasado quería invitar a mi viejo a casa, pero no me decidía qué comida hacer; había pensado en algún pescado, pero no me convencía la idea. Y a mi viejo se le ocurrió la idea de hacer algún guiso, y enseguida me entusiasmé con hacer un mondongo.

Nunca había hecho, pero de algo estaba seguro: no tenía una olla lo suficientemente grande :D. Así que me hice una listita de todas las cosas que necesitaba comprar, y entre ellas incluí una nueva olla para el hogar :)

Les decía, nunca había hecho mondongo. Entonces, necesitaba saber qué ponerle. Busqué un rato en la web, y me quedé con cuatro recetas que me gustaron. Entendí qué hacía cada una, y luego armé una mezcla, en función de lo que quería yo.

A nivel cantidad, éramos cinco o seis adultos (porque también venía mi amigo Diego con la familia) más dos chicos, por lo que calculé los ingredientes como para unas 10 a 12 personas. Compré todo, y el sábado me puse manos a la obra.

Tempranito le saqué los sobrantes de grasa al mondongo (2 kg) y lo puse a hervir en abundante agua con un poco de sal, pimienta en grano y laurel. Mientras esto hervía fui preparando un poco todo el resto; en particular puse los porotos (250g de un tipo y 250 de otro) y los garbanzos (500g) en unos tupper con agua fría y los mandé a la heladera.

Luego de dos horas de hervor, saqué el mondongo del fuego, descarté el agua, y lo dejé enfriar. Cuando estuvo a temperatura manejable, lo corté en pedacitos pequeños o tiritas cortas, y lo dejé para la noche.

A la tardecita arranqué con la cocción del todo, un poco en paralelo con dos cosas. Por un lado, puse a hervir los dos tipos de poroto y el garbanzo, en tres recipientes separados, con casi nada de sal. Y los iba supervisando de a ratitos, viendo si ya estaban blandos (pero no demasiado). Al momento de sacarlos, hay que descartar el agua y cortar la cocción con agua fría, lavándolos de paso.

Y en simultaneo a todo esto, preparé la olla principal. Corté chiquito cebolla (3 grandes), morrón (3 grandes) y ajo (8 dientes), y los puse a rehogar. Cuando estaba todo entre transparente y doradito, agregué la panceta (400g) y el chorizo colorado (3 medianos), todo cortado en pedacitos ni muy muy ni tan tan.

Cuando estos dos últimos ingredientes largaron su grasa y aceite y estuvo todo impregnado bien, levanté todo con un poco menos de media botella de vino tinto. Dejé que vuelva a tomar temperatura, y agregué 2 latas de puré de tomate, apio y puerro (un par de ramitas de cada uno), 4 tomates cortados en cubitos, y un par de zanahorias que justo tenía en la heladera (cortadas bien chiquitas).

Esto ya tenía forma de guiso, así que condimenté: sal y pimienta a gusto, tres o cuatro hojas de laurel, bastante ají molido, orégano, pimentón, y un manojo de perejil cortado groseramente.

Luego los garbanzos, porotos, y el mondongo. Y finalmente agregué caldo de verdura suficiente como para que quedara la proporción de líquido correcta y un poco más, hasta que me dió la olla.

Entre una cosa y la otra se hicieron las diez de la noche, así que dejé hervir todo dos horitas, apagué el fuego, y tapé. El domingo a la mañana, a eso de las once, lo puse a calentar de nuevo, dejando hervir lentamente la mezcla.

Comimos a las dos de la tarde, estaba en su punto.

Mondongo

Si lo hacen, me cuentan como les fue!

Read more
facundo

Enjuewemela modo PyAr


No es la primera vez que les comento algo sobre Enjuewemela, mi jueguito similar a los populares Bejeweled o Diamond Mine, que se basa en alinear 3 o más gemas, tanto verticalmente como horizontalmente, intercambiando gemas adyacentes.

Pero quizás este post sea el último que hago sobre el juego. Y es que me aburrí de pulirle detalles, tratar de hacerlo lindo, jugable, divertido... son cosas que llevan mucho tiempo, no tan evidentes al usarlo... y nada, me aburrió.

Para "despedirme", le implementé algo que tenía en mente hace rato y que quería que esté: un "modo Python Argentina", donde en vez de las piezas usuales, hay personajes de juegos hechos por el grupo.

Enjuewemela modo PyAr

Lo consiguen en el lugar de siempre :)

Read more
facundo

PyCamp 2013


El viaje

Moni me dejó en Retiro a eso de las 20:35, cerquita de las 20:45 que era la hora que tenía mi micro. No sabía si viajaba con alguien, pero me encontré con Ricardo Kirkner en la terminal, que viajaba en mi mismo micro. También nos cruzamos a Felipe Lerena, pero tenía otro viaje, y supimos que estaba más gente por ahí que iba a Villa Giardino al PyCamp, pero no nos las cruzamos.

Yo tenía un boleto electrónico (había comprado los pasajes por internet e impreso un PDF que te dan), y no estaba seguro que eso sirviera para subirme directamente al micro, así que pregunté por ventanilla que onda. Me enteré que con eso era suficiente, y también que el micro venía con retraso. Bueno a esperar.

Esperamos, esperamos, y esperamos. Al final, llegó el momento de subirnos al micro, con dos horas de demora, :(. En fin, ya estábamos arriba y moviéndonos, era cuestión sólo de llegar, ¿no? No.

A eso de medianoche me despierto y veo que el micro está en la terminal de Campana. Pasa un rato, y el bondi no se movía. Tenía el motor prendido, pero no nos íbamos nunca. Veinte minutos después, nada. Bajo a preguntar (la mayoría de la gente dornmía), y el chofer me dice que el micro estaba roto (luego me enteré que "no aceleraba"), que estábamos esperando un reemplazo. Uff.

Como media hora después llega otro micro, el chofer nos dice que nos cambiemos de coche, la gente se despierta, nos movemos, etc. Arranca el nuevo vehículo y abandonamos Campana. Ahora sí el viaje arrancaba, y era sólo cuestión de llegar, ¿no? No.

Ya de día, y saliendo de Córdoba Capital, me parece que el micro va sospechosamente lento por la ruta. Antes de llegar al primer peaje, se tira a un costado y viene el chofer y dice que el micro estaba roto (en esta oportunidad: se había roto la manguera del hidráulico que movía el ventilador del radiador, y el motor calentaba demasiado).

Not angry

La gente re molesta, se baja del micro, unas señoras llamaron a un remis para volver a Córdoba y ahí tomar otro micro de corta distancia, otros sólo protestaban, nadie sabía mucho qué hacer. Yo quería llegar pronto a Villa Giardino para no perderme mucho PyCamp, así que no quería esperar indefinidamente hasta que viniera otro micro.

Charlando, me doy cuenta que una pareja de chicos iban hasta La Falda, que queda muy cerquita de Villa Giardino, y les digo: ¿por qué no nos tomamos los cuatro un remis? Yo tenía en los contactos el número de un remis de córdoba, llamé, me dijeron que el viaje salía alrededor de $300, y le dije que se viniera.

Un rato después nos pasó a buscar el auto, nos subimos los cuatro, y ahí si ya pudimos hacer el último trecho que nos separaba de PyCamp. Llegamos quince minutos antes del almuerzo, con cinco horas de retraso del plan original. Pero llegamos.

Y en la vida me vuelvo a tomar un micro de Mercobus/PlusUltra.


El resto del Jueves

Al llegar fueron todos saludos, presentaciones con varias personas a las que no conocía personalmente, el almuerzo, más saludos y presentaciones, y el arranque con el PyCamp propiamente dicho.

Schedule

Esa tarde laburé con TOMy, un cliente lindo y útil de consola para conectarse a muchas bases de datos (MySQL, Postgresql, etc), mejorando por mucho los clientes que trae cada motor. Le refactoreé un par de cosas a la hora de importar unos plugins, aunque lo que quería realmente hacer era otra cosa (que finalmente pude hacer luego, ver abajo).

No pude seguir con TOMy porque llegó la hora asignada de empezar con LocoLander, un proyecto idea mía. Se armó un grupito, pero la verdad los que siguieron prendidos al proyecto (durante una buena parte del resto del PyCamp, y que trabajaron mucho mucho) fueron Ricardo, Nati Bidart, y Matías Bordese. Yo hice un par de cosas, charlé mucho del diseño, pero no estuve echando tanto código con esto.

Lo groso es que se logró muchísimo. Pueden ver acá el código, ya con mucho hecho de la interfaz de registro de proyectos y de seguimiento del proceso, así como también toda la infraestructura para armar imágenes de distintos linuxes y configurarlos con las dependencias necesarias para correr los tests necesarios sobre los branches de los proyectos registrados.

Luego de la cena, y para cerrar el día, jugamos una partida de Belfort, un juego muy muy divertido que tiene Alecu. Los jugamos de a tres parejas: él y Matías, Nati y yo, y Elvio y Gisele, una pareja que yo no conocía hasta el PyCamp. Estuvo muy bueno, y con Nati lo ganamos en una serie de movimientos maestros cerca del final, sorprendiendo incluso a Alecu porque logramos el máximo de puntos del juego.


Segundo día, el viernes

Este fue el último día que me levanté temprano, con bastante frio porque el radiador de la pieza no andaba!. Desayuné y luego me puse cerca del gran Hugo Ruscitti que le contó a mucha gente sobre Pilas y su proyecto para que los chicos en las escuelas aprendan a programar usando el editor web. Yo ya había charlado mucho con Hugo sobre esto, así qu eno participé demasiado, pero estaba con la oreja parada mientras seguía laburando un poquito en LocoLander y TOMy.

Y seguí con eso incluso después del almuerzo, hasta que llegó la hora de Kilink, el otro proyecto nuevo que llevaba al PyCamp. Se me juntaron varios chicos para arrancar... y cuando les quise mostrar como estaba lo que ya estaba, no andaba en mi máquina, :(.

Ahí me puse a ver por qué, tratar de configurarlo, pregunté, no lo pudimos hacer andar como estaba, y decidí cambiar el approach. Instalé Apache, lo empecé a configurar, y luego de varias chanchadas y cosas de apuro, hice que pudiera correr.

Ya a esa altura había perdido la mitad de la gente, pero los que quedaron les gustó mucho. Les mostré lo que había a nivel de código... y llegamos a la conclusión que era todo viejo y complicado, :/ (tener en cuenta que en este proyecto Nico César y yo laburamos algunas horas a las apuradas hace dos años!).

El problema estaba en tres niveles. Primero, la forma de servir los datos... usaba flup y con José Massón pasamos a usar Flask: mucho más fácil, directo, sacamos magia del medio, y hasta los tests quedaron más sencillos. Segundo, la interfaz a nivel de html/css/js... estaba todo mezclado, desordenado, y hasta yo había hecho la chanchada de meter algo de javascript en el template para poder renderizar el árbol de versiones directamente. Acá estuvieron trabajando muchísimo Miss Filly y Juan Carizza, por muchas, muchas horas. Y lo tercero a corregir, que todavía no se hizo, es reemplazar SQLObject por SAW, un wrapper a SQLAlchemy que hizo Emiliano Dalla Verde Marcozzi.

El hotel

No todo terminó ahí con Kilink, especialmente los dos días siguientes. Filly y Juan estuvieron trabajando bastante para tratar de reemplazar el javascript que arma el árbol, y aunque todavía no lo terminaron parece que estaría sirviendo D3 para esto. Y José implementó toda la API, para poder usar Kilink programáticamente, porque se necesitaba para que el editor web de Pilas pudiera usarlo para guardar los scripts que se escriben.

El jueves también lo cerramos con un juego: el Galaxy Trucker, que yo ya había jugado una vez en un PyDay en Córdoba, pero no me acordaba mucho. Igual, lo jugué bastante bien y gané por UN puntito, muy muy justo.


Sábado

Habiéndome acostado la noche anterior a las tres de la mañana, era obvio que no me iba a levantar demasiado temprano. Pero nueve y media ya estaba bañadito y listo para comenzar a trabajar.

Luego de un viajecito al pueblo a llevar al hospital a un chico que se sentía mal y comprar algunas cosas en el almacén para tener a la muchachada engordando mientras programaban, sí me puse a trabajar.

Seguí con Kilink y Locolander, hasta que se hizo hora de arrancar con la CDPedia. Habían dos cosas que quería empujar con respecto a este proyecto. El primer punto era que CDPedia pudiera correr en Android (para tenerla en teléfonos y tablets); Diego Mascialino y Manu Quiñones se pusieron con esto, pero se les complicó bastante porque el Python que corre en Android se ve que está un poco recortado, y justo en donde lo necesitábamos, :(. Tenemos que seguir explorando a ver qué opciones hay para hacerla andar.

El segundo punto era lograr un sistema de generación continua de CDPedias. O sea, un sistema que de forma autónoma vaya generando CDPedias en distintos lenguajes, uno atrás del otro, y que luego vuelva a arrancar con el primero, como para garantizar tener algo siempre más o menos actualizado. Con esto nos pusimos Emiliano, en la parte de montar un buildbot para que ejecute, supervise y muestre los resultados de la ejecución, y yo, para armar un único script que realice la cantidad de pasos manuales que se hacen hoy en día. ¡Y casi casi lo tenemos listo!

El cierre del día lo dió la reunión número 61 de PyAr, pegadita a la cena. Los dos temas principales de la reunión fueron las cosas buenas y malas del PyCamp actual, qué cosas deberíamos cambiar para la próxima, etc, y charlamos también sobre la próxima PyCon, qué hacía falta, etc. Claro, satélites a estos temas se tocaron muchos otros, por ejemplo la interacción entre los eventos y las empresas, o también una idea de Nico Echaniz de construir algo en Quintana para que pueda usarse por las distintas comunidades libres para ir a trabajar, hacer sprints, etc.

Reunión de PyAr

Cuando volvimos a buscar las cosas al salón era como la una de la mañana. Yo estaba listo para irme a dormir, pero salió la idea de jugar nuevamente al Belfort... en esta oportunidad jugamos individualmente Nati, Matías, Ricardo, Lucio, y yo. Sorprendentemente volví a ganar, por unos buenos tres puntos.


Último día

Obviamente, luego de haberme acostado a las cuatro y media, no iba a levantarme temprano. Pero no fue tan tarde, nueve y media me desperté solito, y a las diez ya estaba bañado y en el salón para trabajar.

Hice alguna que otra cosa, pero lo importante de la mañana fue la presentación que hicieron las distintas personas de todas las cosas que se hicieron durante los días del PyCamp. La verdad es que estuvo genial, ¡tantas cosas en tan poco tiempo! Se filmó un video, yo tengo que editarlo y sacarle los espacios muertos, así es más dinámico para ver. Luego se los paso.

Mientras almorzábamos surgió el tema de que en este PyCamp no habíamos ido a hacer ninguna actividad física grupal. Y así medio de golpe decidimos salir a pegar una vuelta. Avisé, la gente se enganchó, y finalmente cambiamos una "reunión para charlar de cómo ayudar a organizar PyCon" por una "caminata para charlar de...". No fuimos demasiado lejos: caminamos hasta un dique cercano, nos quedamos un rato y volvimos; no más de una hora en total, pero estuvo bueno. Charlamos de PyCon, pero también nos despejamos bastante y nos sacamos de encima ese cansancio crónico que teníamos, lo que nos permitió encarar distinto la tarde que nos quedaba.

Luego del dique

Bah, que nos quedaba a algunos que nos volvíamos ya de noche. La mayoría que vivía en Córdoba Capital se fue durante la tarde, para llegar a sus hogares más o menos temprano.Yo dentro de todo me fui bastante temprano, a las siete de la tarde, porque mi plan fue llegar lo suficientemente temprano a casa como para llevar a Felu al jardín.

Y bueno, es por eso que luego de ir despidiendo gente durante la tarde un grupito reducido de nueve personas fuimos acomodando y limpiando todo al final, nos tomamos unas cervezas antes de partir, y dimos por finiquitado el sexto PyCamp de Python Argentina.  Acá están todas las fotos.

Read more
facundo

Vamos con las pelis


Varias vistas, pero no tantas, :/. Vamos a ver si le podemos poner ritmo...

  • Battle LA: -0. Una peli de acción pasable, pero ya no me banco más al concepto de "hay que mantener militares yanquis porque van a salvar al mundo algún día".
  • Casino Jack: -0. Aristas interesantes, muestra un poco lo que es el juego del "lobby" en EEUU, pero después no tiene mucho.
  • Fair game: +1. Muy buena película sobre construcción de la verdad desde el gobierno sobre la misma gente...
  • Freakonomics: -0. Conceptualmente interesante, pasa mucho tiempo con boludeces; no vale la pena.
  • Les misérables: +1. Nunca pensé que un musical me fuera a gustar tanto. Los actores están bárbaros, la música perfecta... la historia es conocida, pero igual no le resta.
  • Malice in Wonderland: -1. Demasiado loca y volada, no me gustó.
  • Middle men: +0. Más allá del nudo de la historia, que es interesante, se mezcla todo y se desenlaza todo de una forma interesante. Las actuaciones podrían ser mejores, pero está bien (o quizás es que Luke Wilson no me gusta nada nada).
  • Resident evil: After life: -0. Estúpida y sensual Milla Jovovich. Pero ya está, no veo ni una más.
  • Seres: genesis: ??. No la pude ver... no la conseguí bajar por ningún lado, :/
  • South of the border: +1. Genial serie de entrevistas de Oliver Stone a presidentes latinoamericanos, dejándolos hablar pero también repreguntando, todo mezclado con el punto de vista de USA sobre estos mandatarios, con lo que se generan opiniones y puntos de vista que normalmente no se conocen.
  • Super 8: +0. Un tanto trillada y "peli de adolescentes", pero más allá de eso, muy buena peli.
  • The freebie: +0. Muy interesante como plantean el tema y cómo lo desarrollan, especialmente al momento de hilvanar la historia. Pero tampoco es nada del otro mundo. Y no conseguí subtítulos en castellano.
  • The good heart: +0. Muy buena visión sobre dos personalidades complejas y atípicas; hay un concepto para desarrollar y está muy bien, pero la peli es oscura, enrevesada, y el punto álgido muy previsible...
  • The tourist: +1. Acción, mistero, Johnny Depp y Angelina Jolie. Say no more.
  • Transformers: Dark of the moon: -1. Mucha acción, no te aburrís, pero que película de mierda, toda una propaganda de los milicos yanquis. Es para perderle el respeto a Spielberg por ser productor ejecutivo de esta cagada.
  • Unknown: -0. Muy buen giro, pero no llega a hacer valer la peli.


Y todas estas nuevas. Me estoy quedando atrás...


Finalmente, el conteo de pendientes por fecha:

(24-Sep-2008)   15   6
(21-Ene-2009)   18  18  12   1   1
(09-May-2009)   13  11  10   5
(15-Oct-2009)   17  16  15  14
(01-Mar-2010)   18  18  18  18  16   4
(12-Sep-2010)   19  18  18  18  18  18   9   2
(14-Dic-2010)   13  13  13  13  12  12  12   5
(13-Abr-2011)       23  23  23  23  23  23  22
(09-Ago-2011)           12  12  11  11  11  11
(06-Ene-2012)               21  21  18  17  17
(27-Jul-2012)                   15  15  15  15
(26-Nov-2012)                       12  12  11
(09-Feb-2013)                           19  19
(19-Jun-2013)                               19
Total:         113 123 121 125 117 113 118 121

Read more
facundo

Semana ganada


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)

Read more
facundo

CDPedia al cubo


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

Read more
facundo

Cenas de cumpleaños


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

Read more
facundo

Un largo camino al .exe


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

Read more
facundo


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.

Read more
facundo

Malena, un mes


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

Read more
facundo


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.

Read more
facundo


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

Read more
facundo

LocoLander


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.

Read more
facundo

Actualizaciones


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.

Read more