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

Comentarios Imprimir

La estructura de un proyecto: ejemplo Encuentro

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

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
Comentarios Imprimir

Kilink, el pastebin útil

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 errónea (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.

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.

Comentarios Imprimir

Estructura de costos de tener un auto

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

Comentarios Imprimir