Enrique Soria

Hola github.com/rsinger86/djan…

a massive loss of signal. some of us have worried about this for awhile as one of the (countless) second-order effects of vibe coding + crowd-hype. i'm a huge advocate of well-done, ai-assisted coding. but there were always going to be downsides to the proliferation of llms writing code in the large. we need to see these effects and work through them. just a few simple examples on the loss of signal. - design signal. a reasonably well-designed website took effort and signaled depth of thought that probably generalized to product, to security, etc. that's very much gone, unless you're crafting something *extremely* unique (maybe you should) - documentation signal. the very *existence* of docs implied thought and effort. that signal is mostly gone now since it's trivial to prompt "look at the codebase and write some docs". very few people read docs closely enough to discern accuracy. traditionally you just trusted them: the kind of person who would go through the effort to write docs in the first place would usually write accurate ones! - ecosystem signal. generally a vibrant ecosystem suggested a mature, good project. that a "hub" existed signaled something. but now you've got 15 different random hubs for, say, clawdbot/moltbot, some with weird incentives, and it is extremely difficult for developers to develop correct intuitions about what's what. (see also: the security vulns from @theonejvo) the upshot here is something even more subtle and possibly dangerous, or at least exhausting. the explosion of vibe-coded software has *shifted* the burden of analysis to end-user developers; but we haven't updated on that fact. we still assume, e.g., that a big project is just going to be good, or that we can trust it based on other signals. that's really no longer true. the cognitive burden of needing to constantly evaluate what you use is real, and we'll need new frameworks asap.

Exigir la presencialidad en un sector como el informático no es ni malo ni bueno, sino asumir un sobrecoste en salarios para seguir siendo competitivos como marca empleadora (igual que si pides ir en traje). El FMI pone un número a ese sobrecoste: 8% imf.org/es/publication…

GREEN FLAGS IN SOFTWARE ENGINEERS: 1. Can explain complex stuff in simple words (if a new joiner gets it, they actually understand it) 2. Writes readable code, not clever code (good names, small functions, boring patterns) 3. Thinks in tradeoffs, not absolutes (they will say “depends” and then tell you exactly what it depends on) 4. Cares about testing and observability (logs, metrics, traces, alerts… they want to debug fast at 3am) 5. Treats performance like a product feature (measures first, optimizes second, knows where latency actually comes from) 6. Owns failures without ego (postmortems, root cause, prevention, no blame games) 7. Communicates early and clearly (good PR descriptions, clear docs, good async updates) 8. Respects the user and the business (edge cases, data loss, migrations, backwards compatibility… they think beyond “it works on my machine”) 9. Keeps learning but stays practical (reads docs, ships small experiments, upgrades mental models over chasing hype) Are there any other points I should add?

After a long time without a release, django-lifecycle v1.2.6 is finally out 🎉 It adds Django 6 support and a context manager to bypass hooks. Big thanks to 7 first-time contributors who made this release possible ♥️ github.com/rsinger86/djan…

¡Volvemos con la primera charla del 2026! 🎆 En esta ocasión Héctor Chuliá nos contará cómo desplegar modelos de machine learning en producción 🗓 Martes 27 de enero, 18:30 en las oficinas de GuruSup Regístrate ahora en: meetup.com/es-ES/python-v…

i am convinced that software devs have a speed problem they think the #1 issues is writing code faster... its not. its fixing the code that is already there to stop being utter garbage (as a garbage code connoisseur) quality is really lacking these days, yet quantity has never been higher

¡Empezamos la semana con noticias frescas! Ya es oficial, la PyConEs tendrá lugar en Barcelona los días 06, 07 y 08 de Noviembre. 📢 ¡Estate atentx a nuestras redes para no perderte ninguna novedad! (Català a continuació/English below) #PyConES #PyConBarcelona2026

Hoy os voy a hablar de la paradoja de la post-escasez Cuando tenía 10 años, mi hermano y yo conseguimos una Nintendo DS. Al principio solo teníamos un par de juegos: Metroid Prime Hunters (que venía con la consola, juegazo) y un remake de Mario 64. Como eran los únicos dos juegos que teníamos, los aprovechamos al máximo. Por Navidad o por mi cumpleaños, podía pedir solo un (1) juego. Investigaba durante semanas: leía reseñas, comparaba opiniones en foros y veía gameplays. Si iba a tener únicamente un juego durante meses, más valía que fuera bueno. Todo ese proceso generaba anticipación y, incluso antes de tenerlo, ya estaba disfrutándolo. Cuando por fin lo conseguía, como era lo único a lo que podía jugar, lo exprimía hasta la última gota. Me lo pasaba pipa. Un par de años después descubrí algo: la flashcard R4. Básicamente, era una tarjeta que permitía cargar juegos pirata en la consola. Como friki de 12 años, sin dinero y sin preocupaciones éticas, ahorré durante unos meses y me la compré. De repente tenía acceso inmediato a todos los juegos que quisiera, gratis. Sin embargo, no fue tan satisfactorio como había imaginado. Ahora que podía conseguir cualquier juego al instante, descargaba uno, jugaba un rato y luego pasaba a otro. La escasez había desaparecido, pero con ella también la anticipación, el compromiso y, en gran medida, el disfrute. Era raro: objetivamente tenía más, pero subjetivamente sentía menos. Al final: dejé de jugar. No creo que esta experiencia sea universal, pero sospecho que muchos reconoceréis la sensación (quizá los zoomers no). Los humanos tendemos a valorar más lo limitado, sobre todo si implica espera, esfuerzo o renuncia. Desde un punto de vista evolutivo, esto tiene sentido. Y es que no podemos olvidar que somos monos. Nuestra especie ha evolucionado durante millones de años en entornos donde los recursos eran escasos e impredecibles. Como resultado, nuestro cerebro presta más atención, genera mayor anticipación y extrae más valor de aquello que no está siempre disponible. De forma similar, la capacidad de retrasar la gratificación y de generar anticipación por recompensas futuras es parte del propósito de nuestro sistema dopaminérgico. Esto influye directamente en nuestra satisfacción y felicidad. La anticipación es un mecanismo donde el cerebro aumenta la señal de valor asociada a estímulos futuros. Es un mecanismo evolutivo: nos empuja a invertir energía, atención y esfuerzo en objetivos distantes en el tiempo que no están garantizados. Por eso, cuando hay anticipación, las cosas saben mejor. Estos mecanismos siguen activos hoy y, de hecho, son explotados de forma consciente por empresas que crean escasez artificial para aumentar el valor percibido de sus productos: bolsos Birkin, skins en videojuegos, relojes de Rolex o los Labubu de POP MART. Aquí es donde entra la era actual. La inteligencia artificial y la automatización nos acercan a un mundo donde muchos bienes, contenido, imágenes, textos, entretenimiento, incluso relaciones, pueden generarse de forma casi instantánea y en cantidades virtualmente infinitas. En cierto sentido, estamos entrando en una era de post-escasez. Y, como me ocurrió con la R4, la abundancia tiene un efecto paradójico. Cuando cualquier cosa puede crearse al momento, tendemos a invertir menos atención en cada unidad individual. No porque sea peor, sino porque es reemplazable. Por ejemplo, yo no creo que los ensayos generados por modelos de IA como Claude Opus sean malos; de hecho, probablemente son mejores que los que escribe la mayoría de personas. Sin embargo, me cuesta valorarlos. Solo necesito un click para generarlos. Esto a su vez, hace que valore también menos lo que escriben otros humanos. Y así no solo con los ensayos, sino con todo lo demás. Esta es la paradoja de la post-escasez: al crear un mundo donde todo está disponible, corremos el riesgo de crear un mundo donde la propia abundancia genera un tipo extraño de pobreza, no de recursos ni de experiencias, sino de significado y satisfacción. La cuestión ahora no es sobre si debemos frenar la abundancia, eso es estúpido, imposible e indeseable, sino sobre cómo vamos a aprender a vivir con ella. Si el entorno ya no nos impone límites, quizá tengamos que empezar a imponérnoslos nosotros: elegir con más intención, reducir opciones, comprometer más tiempo con menos cosas. En un futuro infinito, lo verdaderamente escaso no van a ser los recursos, sino la atención y la capacidad de valorar algo el tiempo suficiente como para que nos importe.

Esta comparación entre AIs está genial "Codex, Claude Opus y Google Gemini tratan de construir Counter Strike" Al fin un test que no se trata de hacer un snake o un buscaminas instantdb.com/essays/agents_…

[Articles] How to display a JSON value in Django admin (when using MySQL) Show how to extract and cast a JSON value in MySQL-backed Django models to annotate and sort datetime fields in the admin list view. #djangonews blog.enriquesoria.com/display-json-v…

Los SSD pierden datos a largo plazo sin energía La mayoría de SSD (TLC/QLC) no garantizan la integridad de los datos más de 1 o 2 años apagados Estimaciones de retención sin energía, según tipo de NAND,ñ QLC aprox de 1 año TLC: hasta 3 años MLC: unos 5 años SLC hasta 10 años

another win for the EU 🇪🇺

Una buena práctica al encontrar un bug es escribir primero un test que lo reproduzca y después arreglarlo. Así te aseguras de que no vuelva a aparecer.

khé github.com/FarhanAliRaza/…

@Scienceseur @iamdevloper Can you delete it permanently? Can you un-hide it? If not, I would design it as a DELETE.

@esoria_dev @iamdevloper Is it though? Why is it not a “hide/soft delete” operation from the API users POV. The API simply doesn't expose a DELETE operation.

Are we all pretending we don't just "soft delete" each time?

@snellchapo @iamdevloper Yeah, it could be an email too, but from a API design perspective it makes more sense to be a DELETE.

@Scienceseur @iamdevloper Maybe I'm missing something, but it doesn't makes sense to expose an internal field that's being used to hide information to the API. From the API user POV, it's a delete.

@esoria_dev @iamdevloper Transparency is not a bad thing.

@ajrgd @iamdevloper

@esoria_dev @iamdevloper maybe it's a real delete but appears externally like a soft delete