Me parece que la analogía es apropiada. Mi proyecto también está compuesto, en esencia, solo por dos cosas: la intención de la persona y el snapshot.
Al final, pensaba que el camino que debe seguir mi proyecto es cómo calcular la intención humana (p. ej., pulsaciones de teclas, clics del mouse) y cómo hacer que adquiera un determinado significado.
El concepto es atractivo, pero por experiencia casi nunca he visto que este tipo de intentos idealistas haya tenido éxito..
Por ahora, me parece que Feedly sigue siendo la opción más segura, y además sus funciones de IA están bastante bien.
Es algo que aparece básicamente en la mayoría de los libros sobre métodos ágiles, como Extreme Programming de Kent Beck y Scrum de Jeff Sutherland, entre otros. También pueden fijarse en las historias de usuario. Por lo visto, la mayoría de la gente no sabe bien que la base del ágil son los sprints cortos y las demos para adaptarse rápidamente a los requerimientos del cliente.
Sí, comparto la opinión que mencionaste.
Definitivamente hay partes que no se pueden reemplazar con código.
En ese sentido, si lo explico de una manera un poco distinta, quería decir que un código con alta legibilidad hace que no sea necesario producir documentación.
La documentación que se va acumulando a medida que el software se prolonga también genera carga cognitiva para los desarrolladores. La clave está en reducir el trabajo de estar alternando entre el código y la documentación.
No creo que sea posible dejar únicamente el código.
Creo que puede variar según el contexto y la situación en la que uno se encuentre.
Gracias por tu comentario.
Si expreso mi objeción con cautela, yo creo que el código no puede sustituir a la documentación. Los lenguajes de programación todavía no tienen la riqueza expresiva ni la capacidad de transmisión del lenguaje natural y, en la práctica, ¿cuándo va uno a leer todo ese código?
Tener código que pueda sustituir a la documentación es una esperanza y un deseo, pero es una Torre de Babel a la que no se puede llegar.
Más bien, parece mejor dedicarse a fondo a OOAD.
¿Qué significa exactamente escribir la spec de forma ágil?
Escribir la spec por encima.
Escribir la spec tal como la va dictando el cliente.
Si cambian los requisitos del cliente, mantenerla con ayuda de herramientas para poder modificar la spec rápidamente.
Escribir la spec de forma ágil.
El punto central de ese texto es que, para empezar, ni siquiera queda claro qué es ágil. Se la pasan diciendo que ágil tiene estas características y que hay que hacerlo de tal o cual manera, pero hasta ahora no he visto un texto que realmente muestre: este es un producto hecho con una metodología ágil. Incluso viendo el manifiesto, sigue siendo confuso. ¿Qué tal si muestran un ejemplo?
No sé por qué tratan las metodologías como si fueran escrituras sagradas. Creo que el autor original también era igual de dogmático, solo que iba en otra dirección.
Desde el momento en que eliges SQLite para un servidor de producción, tienes que estar pensando constantemente en cuándo migrar a otra cosa.
Antes valía la pena pensarlo porque el costo del DB en sí (compra de servidores, IDC, licencias, etc.) era alto,
pero hoy en día supuestamente se puede montar con un simple clic, así que ¿de verdad hace falta pensarlo tanto?
Tan solo con romper la toma de decisiones vertical y la mejora iterativa en ciclos cortos, el mensaje que nos deja es enorme (por supuesto, lo mismo aplica a las técnicas/herramientas de gestión de proyectos).
La conclusión de que 'el agile en sí no aportó nuevas perspectivas y se caricaturiza a todos los que lo defienden como fanáticos ciegos del agile' me parece excesiva.
Me parece que la analogía es apropiada. Mi proyecto también está compuesto, en esencia, solo por dos cosas: la intención de la persona y el snapshot.
Al final, pensaba que el camino que debe seguir mi proyecto es cómo calcular la intención humana (p. ej., pulsaciones de teclas, clics del mouse) y cómo hacer que adquiera un determinado significado.
Vi que lo lanzaron y quería venir a escribir un post, pero ya lo habían publicado.
Tengo curiosidad por ver qué tanto rendimiento tendrá.
Como queda código existente, es posible verificar directamente qué implementación es.
https://gitlab.com/sebuls/libhwp
El concepto es atractivo, pero por experiencia casi nunca he visto que este tipo de intentos idealistas haya tenido éxito..
Por ahora, me parece que Feedly sigue siendo la opción más segura, y además sus funciones de IA están bastante bien.
rip
Es algo que aparece básicamente en la mayoría de los libros sobre métodos ágiles, como Extreme Programming de Kent Beck y Scrum de Jeff Sutherland, entre otros. También pueden fijarse en las historias de usuario. Por lo visto, la mayoría de la gente no sabe bien que la base del ágil son los sprints cortos y las demos para adaptarse rápidamente a los requerimientos del cliente.
Sí, comparto la opinión que mencionaste.
Definitivamente hay partes que no se pueden reemplazar con código.
En ese sentido, si lo explico de una manera un poco distinta, quería decir que un código con alta legibilidad hace que no sea necesario producir documentación.
La documentación que se va acumulando a medida que el software se prolonga también genera carga cognitiva para los desarrolladores. La clave está en reducir el trabajo de estar alternando entre el código y la documentación.
No creo que sea posible dejar únicamente el código.
Creo que puede variar según el contexto y la situación en la que uno se encuentre.
Gracias por tu comentario.
Solo se siente como un cambio de perspectiva, pero todos están muy sensibles.
Yo también debería intentarlo una vez.
Gracias por la buena información.
Si expreso mi objeción con cautela, yo creo que el código no puede sustituir a la documentación. Los lenguajes de programación todavía no tienen la riqueza expresiva ni la capacidad de transmisión del lenguaje natural y, en la práctica, ¿cuándo va uno a leer todo ese código?
Tener código que pueda sustituir a la documentación es una esperanza y un deseo, pero es una Torre de Babel a la que no se puede llegar.
Más bien, parece mejor dedicarse a fondo a OOAD.
¿Qué significa exactamente escribir la
specde forma ágil?specpor encima.spectal como la va dictando el cliente.specrápidamente.specde forma ágil.El punto central de ese texto es que, para empezar, ni siquiera queda claro qué es ágil. Se la pasan diciendo que ágil tiene estas características y que hay que hacerlo de tal o cual manera, pero hasta ahora no he visto un texto que realmente muestre: este es un producto hecho con una metodología ágil. Incluso viendo el manifiesto, sigue siendo confuso. ¿Qué tal si muestran un ejemplo?
BckHWP. Automatización de Excel VBA
https://m.blog.naver.com/husky81/222045248589
Estaría bueno que Gemini CLI al menos funcionara bien, pero siempre se anda colgando.
Últimamente veo este tipo de casos con más frecuencia.
No lo entiendo con exactitud, pero creo que capto más o menos la idea.
Gracias.
No sé por qué tratan las metodologías como si fueran escrituras sagradas. Creo que el autor original también era igual de dogmático, solo que iba en otra dirección.
Desde el momento en que eliges SQLite para un servidor de producción, tienes que estar pensando constantemente en cuándo migrar a otra cosa.
Antes valía la pena pensarlo porque el costo del DB en sí (compra de servidores, IDC, licencias, etc.) era alto,
pero hoy en día supuestamente se puede montar con un simple clic, así que ¿de verdad hace falta pensarlo tanto?
¡Este artículo en sí no es ágil!
Coincido.
Tan solo con romper la toma de decisiones vertical y la mejora iterativa en ciclos cortos, el mensaje que nos deja es enorme (por supuesto, lo mismo aplica a las técnicas/herramientas de gestión de proyectos).
La conclusión de que 'el agile en sí no aportó nuevas perspectivas y se caricaturiza a todos los que lo defienden como fanáticos ciegos del agile' me parece excesiva.
Ojalá que codex también soporte tokens OAuth como Claude.