https://cyb3rh4ck.github.io/post/Recent content in Posts on Cyb3rh4ck D3v L1f3HugoesSat, 03 Oct 2026 09:00:00 -0600https://cyb3rh4ck.github.io/post/physiqueos-architecture-case-study/Sat, 03 Oct 2026 09:00:00 -0600https://cyb3rh4ck.github.io/post/physiqueos-architecture-case-study/Cómo diseñé PhysiqueOS, una app para registrar entrenamientos de fuerza: modular monolith, límites por módulo de negocio, concurrencia optimista, snapshots inmutables y una estrategia de pruebas con PostgreSQL real.https://cyb3rh4ck.github.io/post/vertical-horizontal-scaling/Mon, 06 Apr 2026 11:10:00 -0600https://cyb3rh4ck.github.io/post/vertical-horizontal-scaling/Una guía técnica para entender cuándo hacer scaling up (mejorar hardware) o scaling out (agregar servidores), preparando el camino hacia la arquitectura monolítica y distribuida.https://cyb3rh4ck.github.io/post/overview-of-architectural-styles/Mon, 06 Apr 2026 10:52:20 -0600https://cyb3rh4ck.github.io/post/overview-of-architectural-styles/<p>En el <em>software development</em> (desarrollo de software), los <em>architectural styles</em> (estilos arquitectónicos) son cruciales para determinar cómo se estructuran y cómo funcionarán los sistemas. Cada <em>architectural style</em> tiene su propio conjunto de principios y patrones que abordan problemas y requisitos específicos. Seleccionar un <em>software architectural style</em> es una decisión crítica en el proceso de desarrollo de software, ya que impacta el <em>performance</em> (rendimiento), la <em>maintainability</em> (mantenibilidad), la <em>scalability</em> (escalabilidad) y el éxito general de la aplicación.</p>https://cyb3rh4ck.github.io/post/implementing-solid-principles/Tue, 31 Mar 2026 12:55:00 -0600https://cyb3rh4ck.github.io/post/implementing-solid-principles/Explora uno a uno los 5 principios SOLID y otras reglas fundamentales de la comunidad para construir software limpio, mantenible y verdaderamente flexible.https://cyb3rh4ck.github.io/post/cohesion-and-separation-of-concerns/Tue, 31 Mar 2026 11:58:00 -0600https://cyb3rh4ck.github.io/post/cohesion-and-separation-of-concerns/Aprende qué es la Cohesion en el desarrollo de software, por qué es crucial, y cómo el principio SoC te ayuda a construir componentes más robustos.https://cyb3rh4ck.github.io/post/principles-of-software-architecture/Tue, 31 Mar 2026 10:30:00 -0600https://cyb3rh4ck.github.io/post/principles-of-software-architecture/Aprende qué es el coupling, por qué es crucial mantenerlo bajo y cómo implementarlo utilizando interfaces en Java para mejorar el diseño de tu sistema.https://cyb3rh4ck.github.io/post/solid-relevance/Sat, 28 Mar 2026 21:42:00 -0600https://cyb3rh4ck.github.io/post/solid-relevance/<blockquote> <p><strong>Nota:</strong> Esta es una traducción fiel al español (latino) del artículo original <a href="https://blog.cleancoder.com/uncle-bob/2020/10/18/Solid-Relevance.html">&ldquo;Solid Relevance&rdquo;</a> escrito por Robert C. Martin (Uncle Bob).</p> </blockquote> <p>Recientemente recibí una carta de alguien con una inquietud. Decía lo siguiente:</p> <blockquote> <p>Durante años, el conocimiento de los principios SOLID ha sido una parte estándar de nuestro procedimiento de contratación. Se esperaba que los candidatos tuvieran un buen conocimiento práctico de estos principios. Sin embargo, últimamente, uno de nuestros gerentes, que ya no programa mucho, ha cuestionado si eso es sensato. Sus puntos fueron que el principio Abierto-Cerrado (Open-Closed) ya no es muy importante porque la mayor parte del código que escribimos no está contenido en grandes monolitos y hacer cambios en pequeños microservicios es seguro y fácil. El Principio de Sustitución de Liskov está muy desactualizado porque ya no nos enfocamos tanto en la herencia como lo hacíamos hace 20 años. Creo que deberíamos considerar <a href="https://speakerdeck.com/tastapod/why-every-element-of-solid-is-wrong">la postura de Dan North sobre SOLID</a>: &ldquo;Simplemente escribe código simple&rdquo;.</p> </blockquote>