¿Por qué FreeBSD y no (x)BSD?

Minientrada

Por eliminación.

Elegí FreeBSD porque NVIDIA publica drivers para la ABI de FreeBSD. Lo que significa que puedo tener aceleración gráfica y tener mis pantallas con la resolución correcta en vez de usar el driver genérico xorg-vesa. No sirve de nada más porque NVENC no está disponible fuera de Windows y porque no uso FreeBSD para jugar.

Eso es todo. No soy un fanboy de FreeBSD y si mis casos de uso hubiesen sido otros tal vez hubiese ganado otro sistema operativo. Pero ganó este. Los tres sistemas son muy similares entre sí de todos modos.


Otros candidatos:

  • NetBSD: me gusta por su extremada simpleza, hecha para darle una perfecta portabilidad. El lema de NetBSD es “por supuesto que corre NetBSD”, haciendo referencia al hecho de que es posible instalarlo en muchísimas arquitecturas (incluso en Macs de principios de los años 90 o en Play Stations).
  • OpenBSD: lo admiro por su extrema seguridad, pero mis casos de uso con mi ordenador me llevan a admirarlo de lejos. OpenBSD es tan seguro que hace unos años eliminaron el soporte para Bluetooth porque es un protocolo inseguro y su driver no estaba bien mantenido.

Primera dosis

Imagen

Un cartel señala la dirección del punto de vacunación del Zendal
La única foto que he tomado, en parte porque me prometí a mi mismo que no haría la cutrez de tomarme un selfie.

Primera dosis puesta. Ha tocado Pfizer. En tres semanas a regresar, y en cinco semanas esto definitivamente se acaba.

Ha sido un año muy largo.

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;

GitLab vs Gitea

Minientrada

No entiendo por qué GitLab se ha convertido en la implementación de referencia para alojar repositorios con funciones extras como tareas, peticiones de integración o cuentas de usuario. Es lento, dificil de utilizar, dificil de instalar… y además, es un software que se sigue llamando «libre» porque tiene una versión comunitaria, pero que vista la capa de marketing que tiene como producto, no se siente tan libre.

Y sin embargo es lo que plataformas como GNOME, Xfce o Free Desktop han instalado en los últimos años como alternativa a los clientes más duros pero simples como cgit. Una alternativa mucho más ligera que dispone de funciones web es Gitea. Una de las cosas buenas de las aplicaciones web hechas en Go es que igualmente se distribuyen como un binario que se puede arrancar de la forma que haga falta. Configurar un GitLab es absurdamente complicado.

Sobre el Copilot y lo de repetir código

Minientrada

No estoy siguiendo mucho el tema de GitHub Copilot más allá sobre los memes que ya se han hecho, así que tampoco puedo contar nada innovador.

A los programadores nos encanta soltar siglas para todo. Una de ellas es DRY: do not repeat yourself. Resolver continuamente los mismos problemas y reescribir el mismo código es absurdo porque provoca código complicado de mantener. El código debería ser reusable.

Excepto que no todo el código acaba siendo fácil de reutilizar. O, al menos, puede ser bastante excéntrico tratar de reutilizar cierto código. Crear librerías de funciones útiles que hagan las cosas sencillas pero que la librería estandar de nuestro lenguaje de programación no nos proporcione, o marcarse un Node.js y tener un ecosistema lleno de paquetes monofuncionales (en el sentido más literal de la palabra) para hacer cosas como comprobar si un array está vacío, si un número es par, o para introducir espacios en una palabra.

«¿Un paquete para crear un array de N posiciones en JavaScript? Eso es absurdo». Posiblemente. El zero-dependency es un estilo de vida, y en el caso de lenguajes como JavaScript, reducir el número de dependencias en el package.json no le viene nada mal a la mayoría de paquetes. Pero probablemente para la mayoría de estas funciones, no puedas escribirlas de tirón sin tener que entrar en Google a buscar en Stack Overflow, y a veces no tenemos tiempo ni de buscar en Stack Overflow.

Es aquí donde creo que las IAs de este estilo podrían tener potencial. No me hagas cambiar de ventana para buscar en internet cómo hacer X en Y, perder tiempo consultando la segunda respuesta porque la primera no aplica, luego la segunda pregunta porque la primera no contiene las respuesta que me interesa… En su lugar, deja que le diga al ordenador en palabras propias qué pretendo hacer y que me genere código sin levantar los dedos del teclado. O deja que automatice el código más aburrido y repetitivo de escribir para ahorrarme tiempo.

Existen razones por las cuales ni quiero pedir acceso a la beta de GitHub Copilot, pero de usarlo, se me ocurrirían casos de uso interesantes que de otro modo tendría que resolver perdiendo tiempo para escribir la función o buscando en internet, como por ejemplo:

  • Dado este array asociativo de objetos ({item1: { k1: v1, k2: v2 }, item2: { k1: v3, k2: v4 }}), fabrica un índice inverso a partir del campo k2 de cada item del array asociativo.
  • Fabrica un array con integers monotónicamente crecientes ([0, 1, 2, 3, 4...]). La IA generaría algo como Array(40).fill(0).map((_, i) => i).
  • Haz una función que valide un e-mail (¿te sabes la regex de memoria sin buscar en internet? ¿te sabes los mil millones de casos edge que tiene el RFC de las direcciones de e-mail?).

Parafraseándome a mí mismo en Twitter hace unos días,

Si programas en Java llevas pudiendo hacer clic para que el ordenador te genere los getters y los setters de tus clases desde hace décadas. Esto podría revalorizar el análisis y el diseño y dejar al ordenador que rellene specs. Imagina escribir un TDD y que el IDE lo rellene.

Trabajar en los procedimientos más complejos y reales y en la lógica de negocio que requiere intervención humana con el tiempo que gano cuando al pulsar un botón me rellena los métodos chorra tipo «buscar X en este array»? Lo compro. Y eso que no espero usar este producto.

@makigas

App Nap en Mojave vs Big Sur

Minientrada

El otro día enchufé mi ordenador portátil después de tenerlo dos días desconectado de la corriente pero encendido y en modo suspensión. La batería estaba al 95% de carga. Es curioso porque antes del downgrade, durante los meses en los que usé Big Sur, la batería se me descargaba más rápido en este tipo de casos. Hablamos de una pérdida del 30% o del 40% de la batería en ese mismo intervalo de tiempo.

Me pregunto si habría algún tipo de cambio en App Nap o en algún componente del sistema operativo responsable de esto, que haga que consuma más batería en Big Sur. O si fue algún tipo de bug temporal que ha quedado resuelto en sucesivos parches del sistema operativo. (Sigo sin plantearme actualizar, de todos modos.)