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

En defensa de SQLite

Minientrada

Recientemente en Ruby on Rails incorporaron un cambio que genera un aviso al arrancar la aplicación en modo producción si el driver de base de datos que está configurado es el de SQLite. El aviso se puede desactivar cambiando un flag de configuración en el production.rb para confirmar que no es un accidente, sino una decisión.

You are running SQLite in production, this is generally not recommended.

Debo romper una lanza a favor de SQLite. Tiene sus issues, claro está, pero muchos de ellos pueden entenderse si se lee la documentación técnica.

Por ejemplo, si nunca te has leído su guía sobre tipos de datos y afinidad de columnas probablemente te sorprenda lo blando que es para validar los tipos de datos durante el INSERT (puedes guardar enteros en columnas creadas como VARCHAR, y viceversa).

No vale para todo, pero lo he visto muchas veces en producción en circunstancias en las que tiene sentido que esté en producción, y si está justificado, seguiré defendiéndolo con fuerza como alternativa ligera.

¿Alguna vez dejamos de estar en guerra con el Excel?

Estado

¿Alguna vez dejamos de estar en guerra con el Excel? Piénsalo. En muchas ocasiones, tu trabajo como desarrollador consiste en crear software que resuelva problemas mejor que lo que puede hacerlo una hoja llena de fórmulas en Microsoft Excel.

(Corolario: un sistema informático nunca está completo hasta que no tiene un botón para descargar una snapshot de los datos cargados en él como CSV.)