Como se sostiene en este artículo, la capacidad de "documentar" es realmente importante.
No solo sirve para destacar tus propias fortalezas y demostrar resultados, sino que también ayuda a hacer el trabajo más llevadero y a dar instrucciones a otras personas.
No hace falta crear desde el principio materiales o documentos impresionantes. Lo importante es adquirir el hábito de organizar la información y escribirla, aunque sea de forma simple.
Yo también lo sé en teoría, pero no lo pongo mucho en práctica... De verdad es un tema muy difícil.
No conoceré los fundamentos a un nivel profundo, pero he visto que no conocerlos produce resultados realmente absurdos e inimaginables.
Por ejemplo, implementar algo de forma que primero cargue todos los registros de la BD en memoria y luego busque en memoria.
Cuando hay pocos registros funciona bien, pero cuando aumentan, la memoria revienta.
Lo programan así porque no entienden en absoluto la diferencia entre la memoria y la BD.
Este es solo un ejemplo; cada vez implementan las cosas en direcciones realmente impensables.
Un programador común(?) de verdad no puede ni imaginárselo.
Yo también estoy de acuerdo con este artículo.
Creo que definir los problemas con valores de estado abstraídos es útil para descubrir problemas, y estoy intentando crear herramientas de gestión de estados que sean claras de forma visual y explícita, como la visualización de estados con diagramas, Unreal Blueprint o los flujos de trabajo.
Supongo que primero tendré que fijarme en el lenguaje.
De todos modos, el trabajo práctico de la ingeniería de software va a cambiar mucho. Las máquinas de código perderán competitividad, pero yo apostaría a que los ingenieros que realmente pueden crear un producto end-to-end sobrevivirán.
Mientras trabajaba en desarrollo, hubo una época en la que por unos años hice trabajo de planificación, y el mensaje del texto sobre tener que "vender" realmente me llegó.
Por más que un producto esté muy bien preparado y planificado, si no puedes persuadir y venderlo eficazmente a tus colegas, no podrás obtener su apoyo,
y al final será difícil que el proyecto avance con fluidez.
Si tienes una idea, aprendí que también es indispensable hacer cosas como comunicarla eficazmente a las personas de tu entorno para conseguir su apoyo.
Ah, esto lo corregiré más adelante.
Entonces, ¿eso significa que
<selectlist>ya no será necesario?Show GN: Webjuego de batallas/ránkings de configuración de personajes
Es otro tema, pero parece que en el bot de Slack no se muestra el
<select>del título jajaAyer cuando lo vi no me di cuenta, pero es de Microsoft, wow. Voy a tener que probarlo.
Parece que a los blogueros que predecían nuevas funciones vigilando los nuevos commits les va a dar pena.
¡Totalmente de acuerdo..!
Como se sostiene en este artículo, la capacidad de "documentar" es realmente importante.
No solo sirve para destacar tus propias fortalezas y demostrar resultados, sino que también ayuda a hacer el trabajo más llevadero y a dar instrucciones a otras personas.
No hace falta crear desde el principio materiales o documentos impresionantes. Lo importante es adquirir el hábito de organizar la información y escribirla, aunque sea de forma simple.
Yo también lo sé en teoría, pero no lo pongo mucho en práctica... De verdad es un tema muy difícil.
No conoceré los fundamentos a un nivel profundo, pero he visto que no conocerlos produce resultados realmente absurdos e inimaginables.
Por ejemplo, implementar algo de forma que primero cargue todos los registros de la BD en memoria y luego busque en memoria.
Cuando hay pocos registros funciona bien, pero cuando aumentan, la memoria revienta.
Lo programan así porque no entienden en absoluto la diferencia entre la memoria y la BD.
Este es solo un ejemplo; cada vez implementan las cosas en direcciones realmente impensables.
Un programador común(?) de verdad no puede ni imaginárselo.
https://es.news.hada.io/topic?id=4138
También está Coolify.
Yo también estoy de acuerdo con este artículo.
Creo que definir los problemas con valores de estado abstraídos es útil para descubrir problemas, y estoy intentando crear herramientas de gestión de estados que sean claras de forma visual y explícita, como la visualización de estados con diagramas, Unreal Blueprint o los flujos de trabajo.
Supongo que primero tendré que fijarme en el lenguaje.
¡Es un texto que me recuerda a las clases de teoría de la computación! Se lo recomiendo a quienes programan para que lo estudien.
¿Está buenísimo, no? Increíble que hasta algo así exista como código abierto jaja
¡Peor es mejor!
De todos modos, el trabajo práctico de la ingeniería de software va a cambiar mucho. Las máquinas de código perderán competitividad, pero yo apostaría a que los ingenieros que realmente pueden crear un producto end-to-end sobrevivirán.
Yo también pienso que OpenAPI function calling no será mejor. Volver a hacer esto con el protocolo MCP también da trabajo.
Mientras trabajaba en desarrollo, hubo una época en la que por unos años hice trabajo de planificación, y el mensaje del texto sobre tener que "vender" realmente me llegó.
Por más que un producto esté muy bien preparado y planificado, si no puedes persuadir y venderlo eficazmente a tus colegas, no podrás obtener su apoyo,
y al final será difícil que el proyecto avance con fluidez.
Si tienes una idea, aprendí que también es indispensable hacer cosas como comunicarla eficazmente a las personas de tu entorno para conseguir su apoyo.
En una época en la que hasta Docker Desktop usa Kubernetes, es una pena que solo sea compatible con Docker Swarm.
> ERROR: Unsupported distribution 'manjaro'
Quise probarlo, pero parece que Manjaro no es compatible. Es una pequeña lástima, la verdad.
Anthropic publica como código abierto Model Context Protocol
Cómo desarrollar con Model Context Protocol (MCP)
Explicación comparativa entre MCP y API
Awesome MCP Servers - Lista de servidores compatibles con Model Context Protocol