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

Comentarios Imprimir

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