SQL: Suma acumulativa

Minientrada

Tengo una tabla como la siguiente:

datetime               points
2021-07-05 10:00:00    1
2021-07-05 10:05:00    1
2021-07-05 10:08:00    -1
2021-07-05 10:10:00    1
2021-07-05 10:11:00    -1

Y quiero sacar las sumas acumulativas. Es decir, no quiero sacar simplemente un SUM(points) y que me devuelva 1, sino que quiero ir viendo, para cada fila, la suma parcial de todas las filas que hay hasta llegar a esa desde el principio.

Por lo que veo en Stack Overflow, una forma universal de hacerlo aunque poco eficiente con tablas muy grandes, es utilizar INNER JOINs aplicados sobre la misma tabla que parcialmente vayan agrupando los resultados por fecha. Me hice algo como lo siguiente en mi caso usando un WITH para filtrar sólo aquellos resultados que realmente quiero sumar y así tratar de hacerlo más eficiente.

WITH points AS (
  SELECT datetime, points
    FROM data
   WHERE target_id = 12345
)
SELECT a.datetime, a.points, SUM(b.points)
  FROM points a
       INNER JOIN points b
               ON b.datetime <= a.datetime;

Listar paquetes instalados no automáticamente con pkg

Minientrada

pkg es el gestor de paquetes de FreeBSD. Es una alternativa a ports que permite instalar paquetes adicionales en el sistema que no vienen con el sistema base.

Es posible listar los paquetes instalados utilizando pkg-info(8). Sin embargo, mi principal problema con casi todos los gestores de paquetes es lo mal que diferencian entre paquetes instalados por mi y paquetes instalados como dependencia.

Me interesa sacar una lista de los paquetes verdaderamente instalados por mi. Esos paquetes que puse explícitamente en mi terminal al escribir algún comando pkg install. Por supuesto es importante saber la lista de dependencias que hay instaladas en mi sistema, pero si estoy fabricando una copia de seguridad con el listado de paquetes que he instalado en mi máquina, me parece importante ocultar las dependencias que no haya pedido, porque puede ocurrir que en el futuro esa dependencia también cambie con respecto a mis programas y deje de ser necesaria (o aparezcan otras nuevas).

pkg-query(8) es el front-end para la base de datos en la que pkg guarda su configuración y estado de los distintos paquetes. Lo bonito es que cuando se instala un paquete, sí recuerda si se ha hecho a consecuencia de ser una dependencia, o porque se haya pedido explícitamente. Así que se le puede pedir un filtro que deje fuera los paquetes que se han instalado automáticamente para listar sólo los que sí se han instalado intencionalmente con el siguiente comando: pkg query -e '%a = 0' '%n'.

danirod@beastie:~ % pkg query -e '%a = 0' '%n' | head
ImageMagick7
alacritty
base64
claws-mail
compton
doas
dsbmixer
en-freebsd-doc
feh
firefox

jq: filtrar índice inverso por valor de un subcampo

Minientrada

Amo jq, pero a la vez daría lo que fuera por poder aprender del todo su lenguaje de consulta porque a veces se me atraganta.

Sería muy fácil con jq hacer una búsqueda en un array de objetos en función de lo que vale uno de los campos de cada objeto, ¿verdad? Hablo de un array como este:

[
  {
    "nombre": "Carmen",
    "departamento": "Ventas",
    "superior": "Ana"
  }
]

Pero ¿qué pasa si en vez de un array tengo un objeto a modo de índice inverso? Me refiero a la clásica de fabricar con este array un objeto donde como valores tengo cada uno de los valores del array, pero como clave tengo algún identificador concreto de cada objeto. Al fin y al cabo, buscar items en una lista tiene complejidad O(n), pero hacerlo en un mapa tiene complejidad O(1). Es más rápido hacer lista["Ana"] que hacer lista.find(i => i.name == "Ana").

{
  "Carmen": {
    "nombre": "Carmen",
    "departamento": "Ventas",
    "superior": "Ana"
  }
}

El secreto está en usar to_entries y from_entries para convertir entre objeto y array de entries. jq 'to_entries | from_entries' < input.json se anula entre sí. Entre ambas sentencias podemos plantar un select para hacer un filtro de aquellos elementos del nuevo array generado por to_entries que filtre por una condición concreta para .[].value.whatever.

jq 'to_entries | select(.[].value.superior == "Ana") | from_entries' < empleados.json

La salida de to_entries es un array, por lo que cuando se hace el select para filtrar elementos que cumplan un criterio, hay que empezar la query con un .[], para poder hacer introspección sobre cada elemento del array. Realmente no es muy complejo, pero me lo apunto porque me ha costado un poco de ensayo y error dar con el orden correcto en el que tengo que poner los puntos y los corchetes.

Ordenar archivos por una columna específica en Bash

Minientrada

Es posible especificarle al comando sort la columna por la que se quiere ordenar un archivo, en vez de utilizar el criterio por defecto, el de ordenar al fabéticamente por el contenido de toda la fila. Esto resulta útil, por ejemplo, para ordenar archivos de log tabulares por una columna concreta que no sea la primera. Hay que usar la opción -k, que tiene un comportamiento similar a la opción -f de cut cuando se delimita por espacio.

cat prueba.txt
3 miércoles
1 lunes
2 martes
4 jueves

sort prueba.txt
1 lunes
2 martes
3 miércoles
4 jueves

sort -k2 prueba.txt
4 jueves
1 lunes
2 martes
3 miércoles

Acentos en la consola de FreeBSD

Minientrada

Tenía problemas para escribir acentos y eñes una vez enciendo mi ordenador en FreeBSD. Tengo configurado mi ordenador para arrancar manualmente el entorno gráfico, por lo que cuando enciendo el sistema lo primero que veo es una consola de vt pidiéndome el usuario y la contraseña. En este punto, todavía puedo teclear la letra ñ en el campo de nombre de usuario, pero después de hacer login, soy incapaz. Tampoco logro hacerlo si arranco X11 y abro terminales.

La razón de esto parece estar en que no se activa el soporte para caracteres extranjeros si no está establecida la variable de entorno $LANG. Aquí un hilo en el foro donde dicen que la solución es esa. Si tal cual en tcsh ejecuto setenv LANG es_ES.UTF-8, a partir de ese momento puedo escribir caracteres españoles en la consola.

Para persistirlo entre sesión y sesión, dentro del archivo ~/.login_conf introduje lo siguiente:

me:\
	:charset=UTF-8:\
	:lang=en_US.UTF-8:

Con esto queda establecido el charset a UTF-8 y la variable de entorno LANG la dejo preparada con el valor en_US.UTF-8. Si quisiese que mi ordenador estuviese en español podría utilizar es_ES.UTF-8 en su lugar, pero considero que es más valioso poder buscar el mensaje exacto en inglés que una traducción.

Por cierto, el archivo .login_conf no puede ser un enlace simbólico. Tuve la genial idea de tratar de mover ese archivo a mi repositorio de dotfiles una vez lo dejé funcionando para poder incluirlo en mi copia de seguridad, pero se conoce que, por cuestiones de seguridad, este es uno de esos archivos en el que el sistema no resuelve los enlaces simbólicos cuando se pretende utilizar a través de la API del sistema operativo, para evitar posibles problemas de seguridad. Por eso también lo subo íntegro a este post: aparte de para ayudar a posibles almas perdidas desorientadas con esto, para hacer backup en alguna parte, visto que no se integra bien con el resto de mi repo de dotfiles todavía.

Borrando ramas locales de Git que ya no existen en remoto

Minientrada

En la mayoría de mis repositorios Git, correr git branch suele suponer abrir un cubo de basura bien grande. Cuando una rama de Git desaparece en el remoto (por ejemplo, en GitHub cuando se borra desde la interfaz web automáticamente), luego te tienes que acordar en local de borrar también tu rama. De lo contrario, vas a acabar con ramas stale que son aquellas de las que se hizo git push para abrir PR y que quedan ahí.

Una forma de identificar estas ramas es hacer un git fetch --prune, manteniendo ese prune para que se ocupe de detectar qué ramas han desaparecido del remoto, seguido de git branch -vv | grep gone. En el modo verbose de branch, las ramas locales que hacen tracking de un remoto que ya no está se identifican porque aparece [gone] en su línea de terminal. Por lo que esta pipeline lista únicamente esas ramas locales que han desaparecido del repositorio remoto.

Cortando la primera columna (mejor con awk '{ print $1 }' aunque con cut también se pueda hacer), puedes listar únicamente los nombres de las ramas. Y si estás de acuerdo con la salida de git branch -vv | grep gone | awk '{ print $1 }', (y sólo si estás de acuerdo, porque ya sabes, no refunds), entonces puedes envolver todo en un git branch -D $(git branch -vv | grep gone | awk '{ print $1 }') para cargarte todas esas ramas de un plumazo.

Follow-up sobre el portapapeles de Vim

Minientrada

Compartí por el Discord de mi comunidad de YouTube mi post del otro día en el que compartía un atajo para copiar y pegar de Vim al portapapeles. Aparentemente no a todo el mundo le funcionó a la primera.

Para poder utilizar compartir el portapapeles, Vim tiene que haber sido compilado con soporte para el mismo. Esto se puede saber ejecutando vim --version y comprobando que en la salida del comando aparece la opción +clipboard (tiene que ser un +, porque un -clipoboard precisamente avisa que no). Las versiones de Vim que trae Homebrew en macOS lo suelen tener. En otros UNIX y en GNU/Linux, es posible que haya que cambiar el paquete vim por vim-x11 o por una versión de Vim más completa.

Probando en mi instalación de FreeBSD con X11, funciona tanto para el portapapeles CLIPBOARD ("+) como para el portapapeles PRIMARY (el del botón central del ratón, "*).

¿Qué hacemos cuando hay conflicto en el Gemfile.lock?

Minientrada

Pues esta es fácil pero como todo en Git nunca aparente. Va a pasar cuando haga cambios al Gemfile en dos ramas a la vez.

git checkout HEAD -- Gemfile.lock

Esto es para traerme el Gemfile.lock que había antes de obtener mi conflicto. Lo importante es que podemos confirmar con un git status que se preserva el Gemfile, así que los cambios en las versiones o librerías siguen ahí.

Si he metido o quitado una dependencia del Gemfile, ahora ejecuto bundle para que se descargue o se retire del lock por encima de la última versión que había en la rama en la que estoy intentando hacer el merge.

Si he actualizado la versión de una dependencia del Gemfile, ahora ejecuto bundle update para que se vuelva a reflejar ese cambio en el lock por encima de la última versión que había en la rama en la que estoy intentando hacer el merge.

Portapapeles del sistema y VIM

Minientrada

El registro de Vim + (PLUS) interactúa con el portapapeles del sistema operativo (el que te permite luego hacer Ctrl-V en otra aplicación).

Si hago un yank en Vim poniendo "+ primero (por ejemplo, "+yy para copiar una línea o una selección visual), luego puedo pegarlo en otra aplicación gráfica de macOS con Cmd+V. Es bidireccional, así que puedo pegar del portapapeles del sistema si he copiado de otra app con "+p.

Hasta ahora utilizaba el modo selección y luego ejecutaba !pbcopy para enviarle mi buffer a pbcopy (un comando de terminal de macOS que envía su stdin al portapapeles), pero esto es más cómodo y no me borra el buffer.