flix (@ home 🏡)

[Rafael Casuso @Rafael_Casuso]

Por si nunca os habéis enfrentado a hacer uno ya os lo digo yo: hacer un buen CLI es probablemente más difícil que una aplicación web tradicional.

[Jerónimo López @jerolba]

@ilopmar FYI, sobre git en repositorios grandes que comentabas el otro día

[Noa Gresiva @NoaGresiva]

Creadores, trabajadores y CEOs de empresas relacionadas con las redes sociales:

1Mark Zuckerberg (CEO de Meta/Facebook): Ha declarado que no permite que sus hijas usen sus propios dispositivos de la forma en que lo hace el público general debido a los riesgos de los algoritmos y la monetización del "engagement".

2Evan Spiegel (Cofundador de Snapchat): Limita el tiempo de pantalla de su hijo a solo 1.5 horas por semana. Argumenta que el no ver televisión de niño lo obligó a leer y construir cosas por sí mismo.

3Neal Mohan (CEO de YouTube): Reconoce restringir activamente el uso de redes sociales y YouTube en sus tres hijos. Aplica límites estrictos los días de semana.

4Chamath Palihapitiya (Ex-vicepresidente de Facebook): Afirma que sus hijos no tienen permitido usar "esa m****a". Ha expresado que las redes sociales están destruyendo el tejido funcional de la sociedad.

5Sean Parker (Ex-presidente de Facebook): Admitió que Facebook fue diseñado para explotar una vulnerabilidad en la psicología humana y ha expresado temor por lo que hace al cerebro de los niños.

6 Paul Stovell (Cofundador de Octopus Deploy): Ha prohibido a sus tres hijos tener cuentas en redes sociales porque crean "impresiones poco saludables e irreales de otras personas y estilos de vida".

7Joe Gagliese (CEO de Viral Nation - Agencia de Social Media): A pesar de construir su carrera en redes sociales, prohíbe que sus hijos las usen libremente, afirmando que no son un lugar para que los niños anden solos.

8Arturo Bejar (Ex-empleado y denunciante de Meta): Ha declarado públicamente que "los niños no están seguros en Instagram" y sugiere que la edad mínima debería ser de al menos 16 años. 

9Steve Jobs (Cofundador de Apple): No permitía que sus hijos usaran el iPad. "Limitamos la cantidad de tecnología que nuestros hijos usan en casa", declaró a The New York Times.

10Bill Gates (Cofundador de Microsoft): No permitió que sus hijos tuvieran teléfonos móviles hasta los 14 años. También prohibió los dispositivos en la mesa a la hora de comer.

11Tim Cook (CEO de Apple): Aunque no tiene hijos, impone límites estrictos a su sobrino. "No quiero que estén en una red social", ha dicho.

12Sundar Pichai (CEO de Google): Ha mencionado que intenta limitar el tiempo de pantalla de sus hijos y que estos no tienen acceso libre a dispositivos a pesar de su cargo.

13Susan Hobbs (Ex-directora en Cloudflare): Prohibió completamente a su hija el uso de redes sociales basándose en su conocimiento del sector.

14Vijay Koduri (Ex-empleado de Google): Prolonga el acceso de sus hijos a los teléfonos lo más posible para evitar que se convierta en un "hábito de por vida" impulsado por las empresas.

15Taewoo Kim (Ingeniero Jefe de AI en One Smart Lab): Prohíbe dispositivos a sus sobrinos para que no pierdan la capacidad de atención a largo plazo.

16Petra Griffith (Fundadora de Wedbush Ventures): Bloquea los teléfonos de sus hijos de 13 y 15 años para evitar el uso excesivo.

17Chris Anderson (Ex-editor de Wired y CEO de 3D Robotics): Ha establecido límites de tiempo y controles parentales estrictos en cada dispositivo de su casa.

18Alex Roetter (Ex-vicepresidente de Ingeniería en Twitter): Apareció en el documental The Social Dilemma afirmando que no permite que sus hijos usen las redes sociales que él mismo ayudó a construir.

19Justin Rosenstein (Creador del botón "Like" de Facebook): Ha eliminado sus propias aplicaciones de redes sociales y limita su uso personal, advirtiendo sobre el daño psicológico que causan.

20Loren Brichter (Creador de la función "tirar para refrescar" en Twitter): Ha expresado arrepentimiento por haber creado funciones tan adictivas y limita el acceso de su familia a ellas.

[Uncle Bob Martin @unclebobmartin]

One of the big problems with Cucumber, over the years, was the fact that the programmers wrote the fixtures, and so there was a perverse incentive for the programmers to tune the GWT syntax in a way that made the fixtures easier to write. This led to lots of nasty implementation complexity leaking into the GWT statements.

CLAUDE feels the same perverse incentive. It tries to fill the GWT statements with implementation details. However, this is easy to countermand. When I see implementation details leaking into the GWT statements, I fire up an agent to remove them and return the statements to natural language that describes only external observables.

You've got to stay on top of these lazy junior developers. They'll make a horrible mess if you take the leash off them.

[David Pardo @dei_biz]

Una de las cosas que más han cambiado en mi manera de trabajar en las últimas semanas es que ahora creo muchas más herramientas de un solo uso.

Revisar la transcripción de un video? Creo un visor web que me permite reproducir cada frase. Unificar nodos en neo4j? herramienta!

[Yuval Avrahami @yuvalavra]

We hacked the AWS JavaScript SDK, a core library powering the entire @AWScloud ecosystem - including the AWS Console itself 🤯

How did we do it? Just two missing characters was all it took.

This is the story of #CodeBreach 🧵👇

[Miguel Carranza @elwatto]

Another year goes by with no hexagonal architecture implemented

[Bernardo Quintero @bquintero]

33 años después, el enigma del virus Málaga por fin tiene respuesta.

Ha sido muy emocionante cerrar el círculo.

Gracias por acompañarme en esta historia.

https://t.co/BJH4Y73CYy

[Arpit Bhayani @arpit_bhayani]

SQLite has about 155,800 lines of code, and its test suite has roughly 92 million lines. That is ~590x more test code than actual code 🤯

This is the level of testing you need for a real production database. Here are some types of tests they run.

Out-of-memory tests - SQLite cannot just crash when memory runs out. On embedded devices, OOM errors are common. They simulate malloc failures at every possible point and verify that the database handles them gracefully.

I/O error tests - Disks fail. Networks drop. Permissions change mid-operation. SQLite inserts a custom file system layer that can simulate failures after N operations, then verifies that no corruption occurs.

Crash tests - What happens if power cuts out mid-write? They simulate crashes at random points during writes, corrupt the unsynchronized data to mimic real filesystem behavior, then verify the database either completed the transaction or rolled it back cleanly. No corruption allowed.

Fuzz testing - They throw malformed SQL, corrupted database files, and random garbage at SQLite. The dbsqlfuzz tool runs about 500 million test mutations every day across 16 cores.

100% branch coverage - Every single branch instruction in SQLite's core is tested in both directions. Not just 'did this line run', but 'did this condition evaluate to both true AND false'.

Databases are really unforgiving :)

By the way, if you want to go deeper, I recommend reading the official SQLite documentation on their testing strategy. The doc is pretty practical and deep.

Have linked it below.

[DHH @dhh]

Microservices is the software industry’s most successful confidence scam. It convinces small teams that they are “thinking big” while systematically destroying their ability to move at all. It flatters ambition by weaponizing insecurity: if you’re not running a constellation of services, are you even a real company? Never mind that this architecture was invented to cope with organizational dysfunction at planetary scale. Now it’s being prescribed to teams that still share a Slack channel and a lunch table.

Small teams run on shared context. That is their superpower. Everyone can reason end-to-end. Everyone can change anything. Microservices vaporize that advantage on contact. They replace shared understanding with distributed ignorance. No one owns the whole anymore. Everyone owns a shard. The system becomes something that merely happens to the team, rather than something the team actively understands. This isn’t sophistication. It’s abdication.

Then comes the operational farce. Each service demands its own pipeline, secrets, alerts, metrics, dashboards, permissions, backups, and rituals of appeasement. You don’t “deploy” anymore—you synchronize a fleet. One bug now requires a multi-service autopsy. A feature release becomes a coordination exercise across artificial borders you invented for no reason. You didn’t simplify your system. You shattered it and called the debris “architecture.”

Microservices also lock incompetence in amber. You are forced to define APIs before you understand your own business. Guesses become contracts. Bad ideas become permanent dependencies. Every early mistake metastasizes through the network. In a monolith, wrong thinking is corrected with a refactor. In microservices, wrong thinking becomes infrastructure. You don’t just regret it—you host it, version it, and monitor it.

The claim that monoliths don’t scale is one of the dumbest lies in modern engineering folklore. What doesn’t scale is chaos. What doesn’t scale is process cosplay. What doesn’t scale is pretending you’re Netflix while shipping a glorified CRUD app. Monoliths scale just fine when teams have discipline, tests, and restraint. But restraint isn’t fashionable, and boring doesn’t make conference talks.

Microservices for small teams is not a technical mistake—it is a philosophical failure. It announces, loudly, that the team does not trust itself to understand its own system. It replaces accountability with protocol and momentum with middleware. You don’t get “future proofing.” You get permanent drag. And by the time you finally earn the scale that might justify this circus, your speed, your clarity, and your product instincts will already be gone.

[Simon Martinelli @simas_ch]

In many cases YAML makes the Spring configuration files much longer than properties files.
Additionally you cannot copy a single configuration line.
I’ll be team properties file forever ✊

[Will McGugan @willmcgugan]

I consider myself a "just in time" developer.

Like I have no idea how to work with sqlite databases in Python. At least not without an ORM. By the end of the day I will.

Let me tell you the secret of how I do that...

I read docs and play with code until it works. 🤫

[TRGCON @tarugoconf]

Ya tenéis disponible la primera charla publicada de la #TRGx.

«Open Source que salva vidas» por Pablo Sánchez.
https://t.co/88LCuQPRGD

[Javier Pastor @javipas]

Me encanta esto. En un mundo de webs enormes y pesadas, una lista de páginas de menos de 100KB (plumitas) y hasta <512KB (que dan para mucho).

512KB Club | A showcase of lightweight websites. https://t.co/Nz7TATPiWq

[Pablo Grueso @PabloGrueso]

"La IA no elimina la complejidad, la esconde"
Muy del gusto de @Recuenco 😀
#TRGx

[Pablo Peñalver | Innovación con sistema @ppenalvera]

@flixStuff #TRGx

[flix (@ home 🏡) @flixStuff]

La banda al escenario principal de la fiesta. Temazos q toca. #TRGx

[flix (@ home 🏡) @flixStuff]

@david_bonilla para q no sobre comida poned un mini tupper a la salida y q cada uno se lleve al menos un pan para las tostadas de mañana. #TRGx

[flix (@ home 🏡) @flixStuff]

Rumiando ideas del taller de @recena “Herramientas y procesos para equipos de desarrollo de alto rendimiento” #TRGx

[javi santana @javisantana]

I value your opinions a lot but TBH being up or down in this incident was *also* a matter of luck. Engineering is important but if for some reason you relied on getting new instances running, dynamodb or other stuff, you are done. Other AWS regions were being affected by the incident, so again, you can have the perfect multiregion setup and going [partially] down.

The incident happened during traffic valley so database services like us didn't need to get extra capacity (on avg) so we were "fine"