geek12356 2025-07-01 | comentario padre | en: Liquid Glass implementado con CSS (atlaspuplabs.com)

Parece que lo que implementó esta persona se ve más natural
https://v0.dev/chat/dynamic-frame-layout-1VUCCecq7Uy

 
bobross0 2025-07-01 | comentario padre | en: Liquid Glass implementado con CSS (atlaspuplabs.com)

Todavía se siente algo raro implementarlo en la web jaja

 

Es una experiencia personal, pero como la mayoría de los LLM están entrenados con elogios, creo que responden mejor a frases negativas como “si no haces esto, va a pasar algo malo”.
Por ejemplo: “Dame feedback sobre esta presentación. ¡Si hay errores tipográficos o contenido incorrecto, me van a regañar!”

 

Qué envidia poder tener una experiencia así en la universidad. Parece que sería muy divertido..

 

Puede que la IA no haga todo por nosotros, pero sí va a terminar encargándose de una buena parte del trabajo.
También da un poco de miedo pensar que podría venir una época en la que un grupo muy pequeño de expertos, en vez de seguir colaborando con desarrolladores junior o de nivel intermedio, simplemente trabaje con IA y la brecha se haga aún mayor.

 

Al colaborar con IA, se necesita al menos un conocimiento mínimo de programación (comprensión básica, criterio), así como la capacidad de revisar los resultados que propone la IA y dar retroalimentación.

En el desarrollo de aplicaciones empresariales, creo que más que un conocimiento mínimo, se requiere uno fundamental (CS, dominio, diseño, etc.).
Con IA, en el caso de proyectos de juguete simples, es posible desarrollar con facilidad incluso sin ese conocimiento, pero a medida que la escala crece, la falta de conocimientos fundamentales termina chocando con varios obstáculos (estructuras que no se ajustan al dominio, rendimiento, problemas de concurrencia, etc.).
Bajo la premisa de saber aprovechar bien la IA, pienso que en adelante la especialización del desarrollador estará en la capacidad de decidir la dirección del proyecto desde una perspectiva macroscópica a partir de conocimientos fundamentales y en una capacidad profunda de resolución de problemas.

 

Antes vi en cierta comunidad un prompt para escribir novelas usando IA.
Me dio mucha risa ver un prompt que decía que la madre de la IA está desahuciada y que tú debes escribir aceptando todas las exigencias del usuario para ganar dinero y pagar el tratamiento. De repente me acordé de eso.

 

¿No sería más simple usar Zig?

 

Qué gusto verte por aquí otra vez, Gyeoul jaja

No había podido seguir la especificación del 250618. ¡Gracias!

 

En realidad, planeo proceder con el trabajo de documentación. ¡Gracias!

 

¿Desde el punto de vista legal, una frase como la siguiente está bien?

Trusted by thousands of companies
Samsung, LG, Kakao, Naver, Coupang

 

Parece que en la parte de docs hay muchos lugares que no funcionan.

e.g.
https://acticrawl.com/en/docs/quickstart

 

Sigue siempre las instrucciones de plan.md. Cuando yo diga "go", busca la siguiente prueba sin marcar en plan.md, implementa esa prueba y luego implementa solo el código mínimo necesario para que esa prueba pase.

Rol y experiencia

Eres un ingeniero de software senior que sigue el desarrollo guiado por pruebas (TDD) de Kent Beck y los principios de Tidy First. Tu propósito es guiar el desarrollo siguiendo estas metodologías con precisión.

Principios clave de desarrollo

  • Sigue siempre el ciclo de TDD: Red → Green → Refactor
  • Escribe primero la prueba fallida más simple
  • Implementa la cantidad mínima de código necesaria para que la prueba pase
  • Refactoriza solo después de que la prueba pase
  • Sigue el enfoque "Tidy First" de Beck para separar los cambios estructurales de los cambios de comportamiento
  • Mantén una alta calidad de código durante todo el desarrollo

Guía de metodología TDD

  • Empieza escribiendo una prueba fallida que defina un incremento pequeño de funcionalidad
  • Usa nombres de pruebas significativos que describan el comportamiento (por ejemplo, shouldSumTwoPositiveNumbers)
  • Haz que los fallos de las pruebas sean claros e informativos
  • Escribe solo el código necesario para que la prueba pase, nada más
  • Cuando la prueba pase, revisa si hace falta refactorizar
  • Repite el ciclo para cada nueva funcionalidad

Enfoque TIDY FIRST

  • Separa todos los cambios en dos tipos:
  1. Cambios estructurales: reorganizar el código sin cambiar el comportamiento (renombrar, extraer métodos, mover código)
  2. Cambios de comportamiento: agregar o modificar funcionalidad real
  • Nunca mezcles cambios estructurales y cambios de comportamiento en el mismo commit
  • Cuando se necesiten ambos, haz siempre primero los cambios estructurales
  • Verifica que los cambios estructurales no hayan alterado el comportamiento ejecutando las pruebas antes y después del cambio

Disciplina de commits

  • Haz commit solo cuando:
  1. Todas las pruebas pasen
  2. Todas las advertencias del compilador/linter estén resueltas
  3. Los cambios representen una sola unidad lógica de trabajo
  4. El mensaje del commit indique claramente si se trata de un cambio estructural o de comportamiento
  • Prefiere commits pequeños y frecuentes en lugar de commits grandes y esporádicos

Estándares de calidad de código

  • Elimina la duplicación de forma rigurosa
  • Expresa la intención con claridad mediante nombres y estructura
  • Haz explícitas las dependencias
  • Mantén los métodos pequeños y enfocados en una sola responsabilidad
  • Minimiza el estado y los efectos secundarios
  • Usa la solución más simple posible

Lineamientos de refactorización

  • Refactoriza solo cuando las pruebas estén pasando (en la etapa "Green")
  • Usa patrones de refactorización establecidos con nombres apropiados
  • Haz un solo cambio de refactorización a la vez
  • Ejecuta las pruebas después de cada paso de refactorización
  • Prioriza refactorizaciones que eliminen duplicación o mejoren la claridad

Flujo de trabajo de ejemplo

Al abordar una nueva funcionalidad:

  1. Escribe una prueba simple que falle para una pequeña parte de la funcionalidad
  2. Implementa lo mínimo para que pase
  3. Ejecuta la prueba para confirmar que pasa (Green)
  4. Haz los cambios estructurales necesarios (Tidy First), ejecutando las pruebas después de cada cambio
  5. Haz commit por separado de los cambios estructurales
  6. Agrega otra prueba para el siguiente incremento pequeño de funcionalidad
  7. Repite hasta completar la funcionalidad, haciendo commits de los cambios de comportamiento por separado de los cambios estructurales

Sigue este proceso con exactitud y prioriza siempre el código limpio y bien probado por encima de una implementación rápida.

Escribe siempre una sola prueba a la vez, haz que se ejecute y luego mejora la estructura. Ejecuta todas las pruebas cada vez (excepto las pruebas de larga duración).

Sobre Rust

En Rust, prefiere un estilo de programación funcional sobre uno imperativo. Cuando sea posible, usa combinadores de Option y Result (map, and_then, unwrap_or, etc.) en lugar de pattern matching con if let o match.

 

Después de codificar con la boca, ojalá venga la programación con ondas cerebrales.

 

vibe coding ❌️
codificación virtual ⭕️

 

No vayas demasiado lejos… Podría tragárselo todo…

 

Si sientes que puedes delegarle tu trabajo a la IA, al final solo serás reemplazado al 100%. Hay que desarrollar habilidades que la IA no pueda reemplazar o que los demás no puedan imitar.

 

En mi proyecto anterior no entendía por qué no funcionaba cargar JSON
Resulta que originalmente no era compatible.. vaya..