MetsuOS

Construyendo la plena inclusión a través del videojuego

Curso sobre Spec Driven Development 🟡③

SDD Today 000

KB

OJO WIP

Este programa formativo profundiza en la metodología que sitúa a la especificación técnica como el motor central del ciclo de vida del software, garantizando la coherencia entre el diseño y la implementación final.

Módulo 1: Fundamentos y Filosofía del SDD

Módulo 2: Estándares de Especificación y Protocolos Modernos

Módulo 3: Diseño de Contratos de API de Alto Nivel

Módulo 4: Ecosistema de Herramientas y Colaboración

Módulo 5: Automatización de Código y Artefactos

Módulo 6: Garantía de Calidad Basada en la Especificación

Módulo 7: "Integración y Despliegue Continuo (CI/CD)

Módulo 8: SDD en Entornos Distribuidos y de Eventos

Módulo 9: Innovación, Estrategia y Futuro del SDD

Referencias Bibliográficas

Fuentes que apoyan y fundamentan el SDD

  1. Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures. Disertación doctoral, UC Irvine. Fundamentos de REST que exigen contratos claros. 🟡③🌐 .- Disertación doctoral de Roy T. Fielding (2000, UC Irvine) que define estilos arquitectónicos para software basado en red e introduce REST con énfasis en interfaces uniformes y contratos claros entre componentes.
  2. Stoplight. The API Design-First Guide. Guía práctica sobre el enfoque de diseño primero. Documentación esencial sobre el flujo de trabajo SDD. 🟡③🌐 .- Guía práctica de Stoplight sobre diseño de APIs con enfoque design-first, que utiliza OpenAPI como contrato único de verdad para colaboración temprana, mock servers y flujos de trabajo SDD.
  3. Geewax, J. J. (2021). API Design Patterns. Manning Publications. Referencia en Google Books. Detalla la importancia de las especificaciones rigurosas. 🟡③🌐 .- Libro de J.J. Geewax (2021, Manning) que recopila patrones de diseño para APIs web e internas, destacando principios y especificaciones rigurosas para consistencia, escalabilidad y comunicación fiable entre servicios.
  4. Postman Engineering. Building an API-First World. Canal de YouTube de Postman. Vídeos técnicos sobre la implementación de especificaciones OpenAPI en el ciclo de vida. 🟡③🌐 .- Graphic novel oficial de Postman sobre el mundo API-First, que presenta estrategias para adoptar el enfoque API-first y recursos relacionados con la implementación de especificaciones OpenAPI en el ciclo de vida de desarrollo.
  5. AsyncAPI Initiative. AsyncAPI Specification Documentation. Documentación oficial. El estándar para aplicar SDD en mensajería. 🟡③🌐 .- Documentación oficial de la especificación AsyncAPI (versión 3.1.0) del AsyncAPI Initiative, estándar protocol-agnóstico para describir APIs orientadas a eventos y mensajería con contratos claros, canales, mensajes y bindings.

Fuentes que cuestionan o matizan el SDD (Refutación y Crítica)

  1. Fowler, M. (2012). Consumer-Driven Contracts: A Service Evolution Pattern. Artículo en martinfowler.com. Argumenta que el diseño debe nacer de la necesidad del consumidor, no solo de una especificación centralizada (Producer-Driven), lo cual a veces choca con el SDD puro. 🟡③🌐 .- Artículo de Martin Fowler (coescrito con Ian Robinson) que describe el patrón Consumer-Driven Contracts para evolución de servicios, destacando cómo los contratos impulsados por consumidores reducen acoplamiento y permiten cambios independientes.
  2. Thoughtworks. Technology Radar: Over-ambitious API gateway logic. Referencia técnica. Advierte sobre el peligro de automatizar demasiada lógica de negocio basándose solo en especificaciones y Gateways. 🟡③🌐 .- Entrada del Technology Radar de Thoughtworks que advierte contra gateways API excesivamente ambiciosos que implementan lógica de negocio y orquestación en middleware, recomendando mantener la lógica de dominio en aplicaciones o servicios.
  3. Continuum (2020). The overhead of Design-First. Artículo técnico. Discute cómo el SDD puede ralentizar equipos pequeños o proyectos en fase de prototipado rápido donde la especificación cambia cada hora. 🟡③🌐 .- Artículo técnico que discute el overhead del enfoque design-first en entornos de APIs pequeñas, internas o de evolución rápida donde las especificaciones cambian frecuentemente.
  4. Humble, J., & Farley, D. (2010). Continuous Delivery. Addison-Wesley. Aunque apoyan la automatización, advierten sobre sistemas de generación de código que crean "código muerto" o difícil de mantener si la herramienta de SDD no es madura. 🟡③🌐 .- Libro clásico de Jez Humble y David Farley (Addison-Wesley) sobre prácticas de Continuous Delivery, que apoya automatización pero advierte sobre riesgos de generación de código y mantenimiento en herramientas inmaduras.
  5. InfoQ (2022). Challenges of Spec-Driven Development in Microservices. Presentación técnica en YouTube. Debate sobre la complejidad añadida de mantener la Verdad Única en sistemas altamente distribuidos. 🟡③🌐 .- Presentación técnica que discute desafíos del Spec-Driven Development como complejidad añadida del código y menor comprensión del desarrollador en mantenimiento y sistemas distribuidos.

One More Thing

Un escenario de retrocomputación del siglo 24

¡Desbloquea el poder de MetsuOS y descubre que la privacidad y la seguridad son la clave para desencadenar tu verdadero potencial en línea!

Contenido registrado en Safe Creative

Logo Safe Creative
¡Usa el código de promocional 7ZYM4Z y ahorrate unos eurillos en tu suscripcion de Safe Creative!

MetsuOS Needs You!

Apoyanos en este proyecto difundiendolo en tus redes, o mejor, haznos una donación a la cuenta paypal para poder dedicar más tiempo y recursos a el. No olvides comentarnos que parete te interesa más junto con tu donación.

En este momento, además de mantener los servicios, estoy centrado en crear la siguiente iteración del software que me permite hacer todo esto y creando una biblioteca personal física para poder contrastar contenido.

Sobre el sistema de validez de un contenido en MetsuOS

Empezando a incorporar los niveles de validación de un contenido (también llamada sabiduría o niveles de conocimiento) ⚫🔴 🟡 🟢 🔵⚪ ¿Qué són?

Sobre la categorización de los tipos de conocimiento

La Metsukeología (de Metsuke vision global y logos conocimiento) es la ciencia que estudia el conocimiento como un conjunto potencial de conocimiento del que podemos obtener, procesar o percibir partes concretas dentro de un marco contextual específico, y cuyo contexto general real está muy por encima de lo que somos capaces, como especie, de percibir, procesar e integrar de forma completa (definición en progreso).

La Metsucología (de Metsu aniquilación - en este contexto en forma de colapso - , logos conocimiento) es la ciencia que estudia como extraemos verdades percibidas - colapsadas - como conocimiento desde nuestra perspectiva real (tanto epistemológico como gnoseológico) al tomar una parte específica del conocimiento metsukeológico potencial enmarcado en un contexto concreto, obligando a colapsar el conocimiento potencial en conocimiento específico (definición en progreso).

Mas sobre el contexto

DISCLAIMER: Mi consideración de anticientífico respecto al consenso científico es una hipotesis de trabajo propia, que supone que toda asignación de validez, incluso aquella derivada de la conclusión por acumulación de evidencia NO debe ser supeditada a debate, ni acuerdo, debe ser algo probabilistico sin intervención del ego humano. Podría estar equivocado y, en este punto, es donde se aplicaría entonces ese mismo consenso que ahora considero no valido (incluso dañino)

Existen indicadores para algunas cuestiones adicoinales como los siguientes:

Cuando hablamos de un contenido que incluye un texto que hace referencia a otro.

También aplicaremos el Sistema de fiabilidad de fuentes y credibilidad de contenidos de la OTAN 🔴②, este sistema incluye una valoración de la fiabilidad de la fuente de A a F (siendo A la de mayor fiabilidad) y una varloración de credibilidad del contenido de 1 a 6 (siendo 1 la mayor credibilidad).

En MetsuOS la agregaremos al final uniendo amos valores como si fuera una coordenada. Por ejemplo: ⚫①-D4 o 🟡③-B2. Esto ayudarña a contextualizar la información sobre la solidez del conocimiento al que se hace referencia en cada momento.

Hay que tener en cuenta que, cuando hay elementos subjetivos o parcialmente subjetivos, el punto de referencia seré yo mismo. Quizá más adelante pueda objetivizar esto más (seria lo deseable), pero en tanto no tenga herramientas que me lo permitan, debo ceñirme al principio de honestidar intelectual, y esperar que mis sesgos dañen lo menos posible la información (en parte este es el nudo gordiano que pretendo resolver, y por ello es dificil resolverlo a priori).

Así de forma resumida, podríamos decir que esta definición es nivel 🔴② (Rojo2 xD) ¿Crees que me dejo algo? Si es así por favor ayudame a mejorarlo contactándome a través de X (Twitter) en mi cuenta, @metsuke 🌐

Consulta la versión completa de la descripcion en ⚫🔴🟡🟢🔵⚪ (🔴②) Un poco más de detalle