Status update

GObject library for Instapaper

I have been working in a GObject library for Instapaper API for a while, just for take some experience with librest. At the moment, you can only retrieve your bookmarks list and get the text content (parsed by Instapaper from the original URL). You can check it in my GitHub. The plans it’s to build a simple read-it-later like (I really like Words for Mac, here a review) application for GNOME 3, but without a clear roadmap or any deadline.

Almanah

After releasing three new versions for Almanah, 0.10.8 with tag support for test purpose; 0.9.1 and 0.10.1 with a critical bug fixed affecting the database encryption, it’s time to return the proposed roadmap and start to work in the SQLite VFS for a better diary database security. I’m very exciting about this work, because I have never work in something like that, something that this kind of “low-level” work. I hope to have something visible in one week.

Advertisements

Almanah tagging support

I have been working for a while in a new feature for Almanah, tagging support. And is ready for user testing, so feedback is welcome.

At the moment there is no great functionality, just tag the diary entries, but is the first step to allow the user make searches based in tags, print just entries with some tag, and so on.

This new feature has required some design modifications to the main window, including a new header in the diary entry view, where the tags are placed. Take a look.

I have used the EggWrapBox for this header, so the widgets wraps along the space with something similar to a responsive design 🙂 As you see, the space between the tag bar and the entry is some ugly, I have thinking to place something like a thin line…

The tag widgets have been written from scratch with Cairo and fixed colors, so remains a lot of work in accessibility and the use of theme colors. The little “x” in the right allow the user to remove the tag for this entry, but I think it’s small and dificult to press, so need some work.

I have make a screencast to show you all the flow:

Of course, you can get the code and test it. Get it from Git git://git.gnome.org/almanah.

Aprender de las cosas más pequeñas

Estoy trabajando en el etiquetado de entradas para Almanah y por pequeña que pueda parecer implementar esta mejora, he aprendido algo sobre cuestiones que uno da por supuesto durante el desarrollo y he disfrutado con ello.

Lo primero al comenzar esta mejora fue plantear el esquema de la base de datos. Para Almanah empleamos una base de datos SQLite muy sencilla, con una única tabla para guardar las entradas, la cual tiene una clave primaria formada por tres campos: año, mes y día.

Sin muchas vueltas la primera solución que me vino a la cabeza es crear dos nuevas tablas, una para las etiquetas (con dos campos, etiqueta y un entero como clave primaria) y otra para la relación entre entrada y etiqueta (los tres enteros de clave de la entrada y al clave de la etiqueta). Sencillo, ¿no? Siempre he trabajado de esta manera de forma automática. Pues resulta que al compartir con Philip (el creador de Almanah) algunas cuestiones sobre lo que estaba realizando, entre ellas el esquema, me planteó porqué no usar una única tabla, con las claves de la entrada y un campo más de tipo texto para la etiqueta.

Pensé, “eso debe ser muy ineficiente porque buscar por una cadena en lugar de por un entero para buscar las entradas de una etiqueta dada debe costar mucho”, pero ¿porqué? ¿cuáles eran las ventajas reales y los inconvenientes de emplear una u otra forma? Así que nos pusimos a investigar un poco.

Después de las primeras búsquedas en StackOverflow mi propuesta de dos tablas parecía que se llevaba la palma, pero un poco más de indagación y empezamos a ver pruebas de carga con búsquedas en campos de tipo entero y tipo texto y las diferencias eran minúsculas para un volumen de datos medio, al rededor de un millón. Y por último encontré esta respuesta en StackOverflow que me pareció condensaba lo que yo estaba planteando y me hacía cambiar el punto de vista: lo importante no es el tipo, sino el volumen de lo que almacenas y el patrón de acceso. ¿Alguien más no está cansado de oír que una llave principal es mejor y más rápida siendo un entero? Pues desacte de esa idea, porque hay factores que influyen, la respuesta correcta a que tipo de clave primaria usar es: depende. Lo primero es tener claro su uso, su tamaño (de longitud), si se querrá modificar, …

Para confirmar todo esto realicé mis propias pruebas con los dos esquemas empleando unas 3000 entradas y 3 etiquetas por entrada. Pensé que estos datos serían reales y permitirían conocer el comportamiento para una situación posible, es decir, un usuario que emplease Almanah de manera intensiva y tras varios años. Los resultados fueron indiferentes, la velocidad de acceso era inferior a 0.06 segundos.

Por último, me pregunté si SQLite ofrecía algo de material al respecto. Pese a que la web da una sensación de anticuada, cuenta con documentación técnica muy completa y encontré muy interesante el siguiente enlace sobre planificación de queries porque me dí cuenta de como maneja SQLite las entradas, las claves y la importancia de los indices (siempre teniendo en cuanta las queries que se emplearán). También me resultó de mucha utilidad el documento sobre los tipos de datos, sobre todo el punto 3 sobre comparación porque la comparación entre enteros se realiza antes con una llamada a atof (convirtiéndolo en un número de coma flotante). Interesante, ¿verdad

La conclusión de todo esto es que siempre hay que ser crítico y poner en duda todo lo que te llevas entre manos, todas tus ideas dadas por supuestas y analizar hasta el fondo el porqué de las ideas. La recompensa por ello es muy gratificante y siempre sales ganando.

Finalizada la primera fase del nuevo diseño de Almanah

Tras muchos meses de trabajo, aunque sin mucho tiempo que poder dedicar, por fin está finalizado el nuevo diseño de la ventana principal de Almanah. Aquí la captura de rigor.

El principal objetivo con el nuevo diseño es, principalmente, adaptar Almanah a GNOME 3 aprovechando la ocasión para buscar una mejor experiencia en la redacción de la entrada en el diario por parte del usuario. Está claro que habrá mucho que mejorar, por ahora la ventana principal es muy rudimentaria y no cuenta con muchas opciones, pero este ahora es el reto y el comienzo.

Las principales mejoras son:

  • Barra de tareas más sencilla, con sólo cuatro botones: estilo de fuentes, selección de fecha, marcar como importante y un botón de menú a la derecha del todo para realizar acciones sobre la entrada (insertar fecha, enlaza, cortar, etc.). Aquí un captura del selector de fecha, del cual estoy orgulloso, si bien tiene algunos defectos por pulir.
  • Integración con GMenu. Eso ha permitido eliminar la barra de menús de la aplicación y ganar en claridad. Aquí captura.
  • Nueva zona de “eventos”, que permite ver los eventos del día (tareas creadas o concluidas y eventos del calendario). Espero que pronto se muestren los eventos ocurridos desde la última vez que el usuario escribió en el diario. Captura también.

Estos cambios sólo están disponibles en el repositorio, puesto que no se tiene pensado realizar una versión nueva de manera inmediata, si bien, mi compromiso es realizar una hoja de ruta para una próxima versión, incluyendo, al diseño ya comentado, la gestión de etiquetado, permitir al usuario introducir más de una entrada al día y dos tareas de fondo sin mucha visibilidad: realizar un añadido a SQLite para trabajar con los datos encriptados de manera directa ganando en seguridad (ahora se desencripta el fichero y queda expuesto) y centralizar la gestión del diario en una librería para poder realizar añadidos externos, como una extensión para GNOME Shell.