Yéndome de snaps y distribuyendo Typus Pocus

Cuando me fui de Canonical seguí trabajando en un entorno informático muy parecido al que tenia mientras trabajaba allí. Obvio que borré y desinstalé cosas que no iba a usar en el corto plazo (o nunca más) como microk8s, pero en realidad yo usaba Ubuntu antes de entrar en Canonical y seguí usando Ubuntu después de ese período de catorce años y medio (aunque me pasé de Ubuntu normal a Kubuntu en algún momento del viaje).

Dicho eso, con el tiempo algo me empezó a hacer ruido y molestar más y más: que la máquina se vaya actualizando sola todo el tiempo. Sospecho fuertemente que algunas inestabilidades vienen de ahí ya que luego de actualizaciones yo no reiniciaba los programas (o la computadora entera) aunque saliera el cartel de "es necesario reiniciar".

Charlando de eso con unas y otras personas, eventualmente llegué a la conclusión de que aunque quería seguir con Ubuntu, lo quería levemente modificado. Particularmente sin snaps. Pero es más fácil decirlo que hacerlo, porque algunas cosas sólo se distribuyen en Ubuntu via snaps... por ejemplo, si hacés sudo apt install firefox eso te instala un snap!

Pero claro, siempre se puede instalar las cosas desde otro lado. Bajar algún .deb a mano, correr algún script, etc. Para Firefox puntualmente hay instrucciones específicas, por ejemplo. Con Chromium se me complicó parecido, tuve que usar lo que armó gente de Mint. Y para Skype no encontré alternativa, pero no me jode porque casi no lo uso (solamente cuando tengo que llamar a un teléfono fijo en otro país) así que lo utiizaré via web y ya.

Por otro lado, uno de los programas que tenía instalado como snap era Typus Pocus, el juego donde un mago tiene que tipear hechizos para atravesar su particular aventura :)

El juego del mago

Este juego me puso en una disyuntiva: si yo mismo no lo queria más como snap, ¿en qué forma lo iba a ofrecer al mundo para que sea fácilmente instalable?

Que interesante sería tener un sistema que permita instalar paquetes Python y que te resuelvan todo el tema de la distribución e instalación de dependencias, ¿no? Bueno, claro que existe, lo hice yo porque soy previsor de formas que sólo el universo conoce (?): aquí entra PyEmpaq.

PyEmpaq es un simple pero poderoso empaquetador de Python para correr cualquier proyecto en cualquier lado con las dependencias que necesite mientras sean instalables en un entorno virtual.

¡Empaquétalo!

Entonces, si quieren jugar a Typus Pocus lo único que tienen que hacer es bajarse este archivo y correrlo con Python (python3 TypusPocus-2.0.pyz).

Anecdóticamente, me pasó que algo había cambiado en pygame (el framework para juegos que usa Typus Pocus) y todos los textos se veían feos, por suerte Dave pudo encontrar qué era y lo fixeamos. Y yo de paso le arreglé el sistema de cómo se calcula el puntaje, que siempre estuvo medio roto.

Disfruten.

Comentarios Imprimir

Mi experiencia con VSCode

El disparador

Con motivo del cambio de laburo hace unos meses arranqué con una máquina limpia de cero. Parte de la instalación de siempre es armar mi entorno de desarrollo, particularmente instalar Vim, aunque no sólo lo uso para desarrollar sino que también es mi editor de cabecera para todo lo que necesite (por ejemplo, escribir los posts de este blog).

Como venía haciendo hace un par de años, instalé Neovim (el Vim más moderno y piola para usar, aunque es sólo de terminal) y Neovim Qt, una interfaz gráfica para Neovim (no la única, pero la que mejor me funcionó de las que exploré y evalué en su momento).

¿Por qué una interfaz gráfica? Mucha gente me "plantea" que usar el editor de la terminal es suficiente, pero yo prefiero otra cosa.

Estoy muy acostumbrado a trabajar todo desde la terminal, disparar procesos, moverme por los directorios, etc., y cuando quiero editar algo no quiero que el editor se me abra en esa terminal, ocupándomela, sino que quiero que se levante como una ventana independiente y me deje seguir trabajando en la terminal que estaba. Además me gusta poder abrir varios editores en distintas ventanas para poder trabajarlas en paralelo (¡y todavía mantener la terminal aparte!).

Volviendo a Neovim Qt. En su momento la versión estable tenía algunos problemitas, y empecé a usar directamente las releases "nocturnas". Y ahora, que instalé la máquina de cero, también instalé Neovim y Neovim Qt. Tristemente vi que era prácticamente inusable, porque tiraba unos mensajes por cada tecla que apretaba, lo que luego de investigar un poco aprendí que se debía a un detalle de la adaptación entre el programa en sí (Neovim) y la parte gráfica (Neovim Qt).

En otro momento me hubiese puesto a ver cómo se podía solucionar, o qué versión "no tan reciente" instalar para intentar que el problema desaparezca. Pero como tambien tenía otros detalles que venía arrastrando (quizás el que más me molestaba era la imposibilidad de abrir un editor tomando la entrada de stdin, e.g. ./algo | nvim-qt), decidí salir un poco de la zona de confort y probar algo por otro lado.

Vamos a explorar

¿Qué alternativa?

Seguro que no quería cambiar solamente la forma en que programaba. Yo uso al editor de texto para mil cosas, no sólo para trabajar con un lenguaje de programación, así que estaba decidido a encontrar algo que no sirviese solamente para programar (como por ejemplo PyCharm).

Al mismo tiempo estaba con ganas de probar "algo bien moderno", para poder descubrir o encontrar funcionalidades o formas de trabajar a las que no estaba acostumbrado.

Luego de ver algunas opciones, terminé eligiendo Visual Studio Code, un editor para texto puro o cualquier lenguaje de programación, del cual me habían hablado bien en más de una ocasión.

Igual, antes de "pegar el salto" probé que algunas cosas básicas que necesitaba que funcionen sí o sí. Por ejemplo poder abrir un archivo lanzándolo desde la terminal, o tener muchas ventanitas sueltas y no todo apretado/junto en una sola gran ventana.

Probando cosas por primera vez

Impresiones luego de algunas semanas

VSCode es muy flexible. Es básicamente un editor genérico con un amplio esquema de extensiones y una buena gestión de la configuración.

Particularment me encanta como está manejada la configuración. La misma se puede trabajar a través de la interfaz gráfica (incluyendo la posibilidad de buscar), y te indica si las opciones corresponden al editor en sí o alguna extensión, se pueden cambiar cosas a nivel global o por proyecto, todo tiene un título, una explicación, e incluso una indicación de si fue modificado el valor original (como el segundo item de la siguiente captura).

Captura de un pedacito de la config

Además, todo eso termina siendo escrito en un archivo de texto relativamente fácil de editar a mano (es un JSON), con lo que si hay alguna configuración muy oscura que todavía no está representada en la parte gráfica, se puede agregar a ese archivo y listo!

Con lo que son las extensiones (o "plugins" o "add-ons") no estoy tan contento. El editor descansa en este código de terceros para funcionalidades muy básicas, con lo cual todo termina siendo una extensión que hay que elegir e instalar aparte. Y las extensiones, en algún punto, compiten entre si porque no todo puede estar 100% coordinado (por ejemplo, atajos de teclado).

Al final, todo anda casi bien, pero nunca termina de funcionar del todo bien y es bastante molesto. Particularmente, estoy bastante frustrado con el autocompletado. Es básico, no puede no funcionar. Ya probé un par de extensiones y ninguna encaja bien. :(

Creo que derivado de tener muchas extensiones, un efecto secundario bastante molesto es que tarda en arrancar. Y no maneja bien el levantar las extensiones de forma asincrónica. Por ejemplo si abro un editor limpio (cosa que yo hago muy seguido, tengo mapeado el ctrl-alt-g a nivel de sistema) y me pongo a escribir rápido, parte de lo que tecleo VSCode lo toma antes de cargar la extensión de Vim. Entonces eso que escribí no se deshace si apreto u, o si puse / me escribe la barra en vez de ir abajo y empezar a buscar...

Situación donde importa muy poco si tarda en arrancar

¿Qué cosas "modernas" encontré?

Disclaimer: no son modernas per se, son cosas que Vim básico no trae, y yo por H o por B nunca habilité/agregué a mi setup de trabajo.

Me está gustando el modelo de, cuando estoy trabajando en un proyecto grande (y no editando archivos o código suelto por ahí), tener las distintas ventanas como pestañas de una gran ventana, con la flexibilidad de poder "separarla" y ponerla a un costado para poder trabajar viendo dos archivos al mismo tiempo.

Eso se complementa muy bien con tener de forma gráfica el árbol de directorios y archivos del proyecto, y la habilidad del editor de mostrarme "dónde esto que estoy marcando está usado en el resto del proyecto" o "dónde está eso definido". Me permite explorar y entender código un poco más rápido de la técnica que usaba antes. Dicho eso, obvio que sigo usando lo de "disparar abrir la ventana desde una terminal" en casi todos los casos fuera de trabajar en un proyecto, o búsquedas más avanzadas desde la línea de comando (la combinación de find y grep es muy poderosa).

Tengo que darle alguna segunda oportunidad a que me muestre atributos de objetos o parámetros de una función. Siempre que lo tuve me resultó muy intrusivo... entiendo que hay gente que va codeando haciendo click en opciones, pero me resulta muy molesto que se me abran ventanas todo el tiempo sobre el cursor cuando voy tecleando. Tengo que ver a más gente usarlo en vivo y aprender de esa experiencia.

Moderno :)

Próximos pasos

Creo que puedo declarar como exitosa la fase primera del experimento. Momento de pasar a la segunda etapa.

Básicamente ahora el plan es volver a arrancar desde cero. Con un VSCode "de fábrica", todo limpio, ir agregando las configuraciones de nuevo, ahora que entiendo todo mejor, con la idea de eliminar todas las mugres que indefectiblemente se van amontonando por ir explorando e ir probando cosas que realmente no eran las correctas o no tenían sentido.

Habiendo dicho eso, sí hay un cambio "fuerte" que voy a incorporar en esta fase, que es la de cambiar el plugin para Vim. Hoy estoy usando el que creo que es el oficial pero tiene algunos mocos bastante molestos, y quiero probar el de Neovim.

Y también aprovechar para darle un segundo empuje al intentar arreglar algunos detalles que todavía no tengo funcionando de forma correcta, principalmente el corrector ortográfico (no puedo cambiar fácil entre idiomas) y el autocompletado.

Veremos como evoluciona. Stay tuned.

Comentarios Imprimir

Resaltando cosas en pantalla

Esta historia es un caso de éxito del modelo de código abierto.

Para unos videos que al final no se terminaron, necesitaba una herramienta que me permitiese "resaltar" determinadas cosas en la pantalla. Parecido a lo que hace un puntero durante una presentación, y justamente muchas herramientas para armar presentaciones tienen algo similar a la hora de mostrar esas presentaciones.

Pero yo necesitaba que también sucediera en la pantalla, sobre cualquier programa, para poder resaltar algo en un navegador, en la terminal, en un editor, etc.

Busqué varias alternativas, y no encontré nada. Lo más cercano que encontré es Gromit-MPX, una herramienta que permite realizar anotaciones directamente sobre cualquier escritorio (tanto X11 como Wayland).

Lo probé y efectivamente me dejaba dibujar y escribir sobre la pantalla, pero no tenía esa capacidad de "resaltar" con el puntero del mouse, que es lo que yo quería. Ahí me di cuenta que si yo pudiese reemplazar el puntero del mouse que ponía al estar activa la herramienta (una cruz de tamaño mediano) con un círculo pintado de amarillo con determinada transparencia, eso iba a ser suficiente para mis necesidades.

Y acá está la magia del open source. Yo tenía acceso al código fuente de esa herramienta (hecha en C, usando el framework Gtk/Gdk), entonces sólo ("sólo") era necesario entender cómo funcionaba y luego toquetearlo hasta lograr lo que quería. ¡Todo un desafío!

Hice un fork de ese proyecto. Estudié un poco el código, encontré donde cargaba el "puntero cruz", un archivo en formato XPM; ya fue divertido estudiar ese formato, entenderlo, y ver si me servía para dibujar un círculo amarillo con transparencia. No, no se puede. Ok, metamos una imagen posta, un PNG. Pero ahí ya tuvo que tocar el código en sí para cambiar el archivo de referencia (incluso cuando el proyecto se instala) y especialmente al momento de cargar el cursor en sí:

GError *error = NULL;
GdkPixbuf* paint_cursor_pixbuf = gdk_pixbuf_new_from_file("/usr/local/share/paint_cursor.png", &error);
data->paint_cursor = gdk_cursor_new_from_pixbuf(data->display, paint_cursor_pixbuf, 64, 64);

El resultado fue muy satisfactorio:

El resaltado en acción

Si lo quieren probar, clonan mi repo y luego siguen las instrucciones del README para compilar/instalar:

mkdir build
cd build
cmake ..
make
make install

Después lo ejecutan:

gromit-mpx

Y les va a aparecer una ventanita con un par de pantallas de información e instrucciones. Con F9 (o desde el ícono en la barrita de íconos) lo activan y desactivan.

¡Cuenten si lo usan!

Comentarios Imprimir

Bailando por un subtítulo

Hace muchos años que me nutro de Liberarte (guiño a les que escuchamos Algo Prestado para ver películas y series, más conocido como "me bajo lo que quiero ver de donde puedo".

Cuando Argenteam estaba vivo y tenía justo lo que necesitábamos estaba buenísimo porque coincidía el video/audio con el subtítulo que ofrecían. ¿Pero en el resto de los casos? subdivx es un gran recurso y casi siempre se encuentra lo que se necesita.

Pero no siempre.

A veces hay que hacerle ajustes a los subtítulos que uno baja para ver la peli o serie que descargó. E incluso en los casos donde la sincronía es correcta, hay algún spam, algún subtítulo en particular puede tener error de tiempos, y varios detalles más.

Fuí lidiando con eso primero a mano, luego medio automatizando algunas cosas, y finalmente me creció una herramienta.

Esta que encontré en Bilbao no lleva subtítulos

En estos días finalmente liberé esa herramienta cuyo propósito final es ayudar a procesar subtítulos. Pueden instalarla y usarla con pip o cualquiera de sus similares. Yo uso fades:

$ fades -d substool -x substool -h
Usage:
    substool [help] <command>
...

Tiene varios comandos. El más usado es el check, que realiza un montón de laburo sobre el (los) archivo(s) que indiquemos:

  • si es un .rar o un .zip lo va a descomprimir y extraer su contenido, y luego lo procesa

  • si es directamente un subtítulo (srt, ssa, vtt, tt, sub, o xml), procesa eso

  • lo carga, corrigiendo cualquier encoding bizarro que tenga a UTF-8, si es necesario

  • corrige los tiempos de cada frase si están claramente mal (por ejemplo si arranca y termina al mismo tiempo, o si los tiempos están invertidos)

  • separa en partes lineas que sean extremadamente largas, o frases que tengan demasiadas lineas

  • saca algo de spam

Este comando check es lo primero y básico que le corro al subtítulo que bajo. Siempre.

Los otros comandos ya son más específicos, para cuando la sincronía está mal y hay que ajustarla:

  • shift: para cuando los tiempos están sólo desfasados y hay que subirlos o bajarlos una cantidad de segundos

  • rescale-params: si además hay una diferencia de velocidad, con este comando se pueden especificar un delta de posición y un delta de velocidad

  • rescale-points: también re-escala, pero indicando en qué momento deberían mostrarse dos puntos del subtítulo, y el sistema calcula todo (también muestra como resultado el delta de posición y velocidad que se obtuvo, con lo cual se puede usar el comando anterior sobre otros subtítulos similares)

  • rescale-mimic: si tenemos un subtítulo que calza perfecto pero en otro idioma, este comando nos permite re-escalar usando ese subtítulo correcto como fuente de verdad

  • adjust: para ajustar cada uno de los tiempos si tenemos el subtítulo correcto en el mismo idioma pero en otro formato

Si usan esto me cuentan :)

Comentarios Imprimir

Catando vinos

Para mi último cumpleaños Moni me regaló una cata de vinos.

Fue en el Mercado Gourmet Amparo, sucursal de la zona de Cañitas, donde tienen un primer piso hermoso para tal fin.

La presentación para cada persona

La cata fue comandada por Claudia Piedrabuena, docente de la Escuela Argentina de Vinos y de la Escuela Argentina Sommeliers, y para este caso puntual embajadora de marca de Pernord Ricard, empresa internacional que compró hace unos 20 años a Etchart, marca/bodega argentina bastante conocida.

Etchart es una bodega fundada a mitad del siglo XIX, en Cafayate (Salta), a más de 1600 metros de altura sobre el nivel del mar. Esa altura es clave para lograr los vinos que logran, y aunque no es algo tan tradicional como "Mendoza", bien los valen.

Disclaimer: no voy a "evaluar" los vinos (no soy quién) más que agregar algún detalle puntual, todos eran muy muy ricos (y muy muy caros para el nivel de vinos que manejo).

La cata arrancó con los blancos. El primero era un torrontés (del que cuento más abajo), el otro un Viognier 2022. Los tintos fueron tres, un Cabernet Franc 2022, un Etchart Arnaldo B. Gran Reserva 2020 (blend) y un Assemblage 2022 (Malbec Malbec).

Los vinos, en orden

Vuelvo al primer vino porque resultó que tiene toda una anécdota atrás. Resultó de un hallazgo fortuito, un vino que encontraron en unos depósitos de cemento de antes de que Pernord Ricard comprara la bodega a sus dueños originales. O sea, dijeron "che, qué les parece si aprovechamos esos depósitos de cemento que están ahí desde que compramos esto", fueron, y resultó que uno tenía contenido. ¡Y el vino estaba bueno! Es más, luego de embotellarlo y esperarlo un poco más, mejor. Y es así que terminé probando un torrontés de 32 años. Increíble la consistencia que tenía, era más denso que un vino común... se movía como un whisky bueno en la copa, supongo que es el añejamiento.

En fin, una experiencia muy interesante, da para repetir :)

Comentarios Imprimir