Herramientas de desarrollo on KnightLi Blog

Graphify resuelve la mayor limitación de Claude Code: convertir un codebase en un grafo consultable por IA

Thu, 21 May 2026 08:02:32 +0800

safishamsi/graphify es una herramienta de grafo de conocimiento para asistentes de programación con IA. Su objetivo es directo: tomar el código, documentación, SQL schemas, scripts, papers, imágenes, video y audio dentro de una carpeta de proyecto, convertirlos en un grafo consultable y evitar que los asistentes de IA dependan solo de grep, lectura completa de archivos o búsquedas improvisadas para entender el proyecto.

Proyecto: safishamsi/graphify

En el momento de preparar este artículo, la página de GitHub muestra unas 50.2k stars y 5.4k forks, con licencia MIT. El README lo describe así: escribe /graphify en tu asistente de programación con IA y mapeará todo el proyecto como un grafo de conocimiento consultable.

El problema central que resuelve

Los asistentes de programación con IA son cada vez más potentes, pero en codebases reales todavía encuentran varios problemas:

No saben cómo se conectan los módulos clave.
Leen muchos archivos, pero no forman un mapa general de arquitectura.
La búsqueda encuentra texto, pero no dependencias aguas arriba y aguas abajo.
Código, database schema, documentación e infraestructura están dispersos.
En colaboración de equipo, cada persona puede tener un modelo mental distinto de la estructura del proyecto.

Graphify intenta añadir una “capa de memoria” al proyecto. Conecta entidades de código, conceptos documentales, tablas de base de datos, configuración, notas de diseño y relaciones entre archivos para que el asistente de IA pueda consultar el grafo en lugar de escanear archivos desde cero cada vez.

Uso mínimo

El uso mínimo de Graphify es muy simple. Tras instalarlo, escribe esto en tu asistente de programación con IA:

`1`	`/graphify .`

En PowerShell, el / inicial se interpreta como separador de ruta, así que en Windows PowerShell usa:

`1`	`graphify .`

Después de ejecutarlo, genera el directorio graphify-out/ con tres archivos principales:

graphify-out/
├── graph.html
├── GRAPH_REPORT.md
└── graph.json

Cada archivo cumple una función:

graph.html: grafo interactivo que se abre en el navegador, con nodos clicables, filtros y búsqueda.
GRAPH_REPORT.md: puntos destacados del proyecto, conceptos clave, conexiones inesperadas y preguntas sugeridas.
graph.json: grafo completo, consultable después sin volver a leer todos los archivos.

Para generar una página de arquitectura más legible con diagramas Mermaid de flujo de llamadas, ejecuta:

`1`	`graphify export callflow-html`

Instalación y soporte de plataformas

El paquete de Graphify en PyPI se llama graphifyy, con doble y. El README advierte que otros paquetes graphify* en PyPI no están afiliados al proyecto, aunque el comando CLI sigue siendo graphify.

La instalación recomendada es:

`1`	`uv tool install graphifyy`

También puedes usar:

1
2

pipx install graphifyy
pip install graphifyy

Después, regístralo con tu asistente de IA:

`1`	`graphify install`

El proyecto soporta muchas plataformas, incluidas Claude Code, Codex, OpenCode, GitHub Copilot CLI, VS Code Copilot Chat, Aider, Cursor, Gemini CLI, Kimi Code, Kiro y Google Antigravity. Cada plataforma puede usar comandos distintos, por ejemplo:

graphify install --platform codex
graphify install --platform gemini
graphify cursor install
graphify antigravity install

Los usuarios de Codex también deben añadir esto bajo [features] en ~/.codex/config.toml:

`1`	`multi_agent = true`

El README también indica que Codex usa $graphify, no /graphify.

Qué archivos puede procesar

Graphify cubre muchos tipos de entrada.

En código, soporta 31 lenguajes, incluidos Python, TypeScript, JavaScript, Go, Rust, Java, C/C++, Ruby, C#, Kotlin, Scala, PHP, Swift, Lua, Zig, PowerShell, SQL, Shell, JSON y más.

En documentación, soporta:

.md
.mdx
.qmd
.html
.txt
.rst
.yaml
.yml

También puede ampliarse con dependencias opcionales:

pip install "graphifyy[pdf]"
pip install "graphifyy[office]"
pip install "graphifyy[video]"
pip install "graphifyy[mcp]"
pip install "graphifyy[neo4j]"
pip install "graphifyy[sql]"
pip install "graphifyy[all]"

pdf sirve para extracción PDF, office para .docx y .xlsx, video para transcripción de video y audio, mcp para MCP stdio server, neo4j para enviar a Neo4j, y sql para extracción de SQL schema.

Qué valor tiene el informe generado

GRAPH_REPORT.md no es un resumen normal. Selecciona relaciones del proyecto que son especialmente útiles para asistentes de IA.

El README menciona contenidos como:

God nodes: los conceptos centrales más conectados del proyecto.
Surprising connections: enlaces inesperados entre archivos o módulos.
The why: razones de diseño extraídas de comentarios, docstrings y documentos de diseño.
Suggested questions: preguntas que el grafo está especialmente preparado para responder.
Confidence tags: cada relación se marca como EXTRACTED, INFERRED o AMBIGUOUS.

Esto es importante. Una búsqueda normal solo dice “dónde aparece esta palabra”. Un grafo puede responder “con qué módulos, configuraciones, tablas y documentos se conecta este concepto”. En codebases grandes, eso se acerca más a entender la arquitectura que una simple búsqueda de texto completo.

Comandos comunes

Comandos comunes de Graphify:

/graphify .
/graphify ./docs --update
/graphify . --cluster-only
/graphify . --no-viz
/graphify . --wiki
graphify export callflow-html
/graphify query "what connects auth to the database?"
/graphify path "UserService" "DatabasePool"
/graphify explain "RateLimiter"

También puedes añadir un paper o video al grafo:

1
2

/graphify add https://arxiv.org/abs/1706.03762
/graphify add <youtube-url>

Para análisis asistido de PR:

graphify prs
graphify prs 42
graphify prs --triage
graphify prs --conflicts

Estos comandos encajan con revisiones de código: ver qué comunidades del grafo afecta un PR, si hay riesgo de conflicto con otros PRs y qué review queue conviene priorizar.

Relación con MCP, Neo4j y CI

Graphify no solo genera un grafo HTML. También puede exponer el grafo a asistentes de IA para uso repetido.

Por ejemplo, puedes iniciar un MCP server:

`1`	`python -m graphify.serve graphify-out/graph.json`

El MCP server ofrece capacidades como query_graph, get_node, get_neighbors, shortest_path, list_prs, get_pr_impact y triage_prs.

También soporta exportación o push a Neo4j:

1
2

/graphify ./raw --neo4j
/graphify ./raw --neo4j-push bolt://localhost:7687

Para trabajo en equipo, el README recomienda poder commitear graphify-out/, de modo que todos empiecen con el mismo mapa del proyecto. También puedes ejecutar:

`1`	`graphify hook install`

Así el grafo se reconstruye automáticamente después de cada git commit y se configura un merge driver para evitar que graph.json quede con marcadores de conflicto cuando varias personas commitean en paralelo.

Privacidad y coste

El README de Graphify explica bastante bien los límites de privacidad.

Los archivos de código se parsean localmente con tree-sitter y no generan llamadas API. Video y audio pueden transcribirse localmente con faster-whisper. Docs, PDFs e imágenes para extracción semántica pasan por la API del modelo usado por tu asistente de IA.

Si usas headless graphify extract, puede que necesites estas variables de entorno:

ANTHROPIC_API_KEY
GEMINI_API_KEY
GOOGLE_API_KEY
OPENAI_API_KEY
DEEPSEEK_API_KEY
MOONSHOT_API_KEY
OLLAMA_BASE_URL

También pueden usarse backends como Ollama local, AWS Bedrock o Claude Code CLI. El README indica además que el proyecto no tiene telemetry, usage tracking ni analytics.

En la práctica, conviene recordar que parsear código localmente no significa que todo se quede offline. Si intervienen docs, PDFs, imágenes o modelos cloud, hay que revisar backend, API keys, cumplimiento empresarial y límites de datos.

Escenarios adecuados

Graphify encaja con varios tipos de usuarios:

Desarrolladores que quieren que Claude Code, Codex, Cursor y Gemini CLI entiendan mejor la estructura del proyecto.
Personas que necesitan comprender rápido un codebase grande y desconocido.
Equipos que quieren analizar juntos código, SQL schema, documentación y configuración.
Personas que hacen revisión de arquitectura, PR review o análisis de impacto de refactors.
Equipos que quieren exponer conocimiento del proyecto como herramienta MCP para Agents.
Líderes técnicos que quieren conservar un “mapa del proyecto” para el equipo.

No es necesario para todos los proyectos. En scripts pequeños, demos puntuales o repositorios muy simples, una búsqueda normal y el README quizá basten. El valor de Graphify aparece con más claridad en proyectos con muchos módulos, mucha documentación, mucha colaboración y uso frecuente de asistentes de IA.

Resumen

Graphify importa porque mueve el contexto de los asistentes de programación con IA desde “leer archivos temporalmente” hacia “un grafo de conocimiento del proyecto consultable y persistente”.

Para desarrolladores, no reemplaza el IDE, la búsqueda o el LSP. Añade una capa de memoria estructurada para asistentes de IA: qué módulos importan, qué conceptos están muy conectados, qué documentos explican decisiones de diseño y qué comunidades puede afectar un PR. A medida que herramientas Agent como Codex, Claude Code, Gemini CLI y Antigravity se vuelvan más comunes, esta capa de grafo del proyecto será cada vez más útil.

Referencias:

GitHub: safishamsi/graphify

Qué es Vercel AI SDK: un toolkit unificado para desarrolladores TypeScript que crean apps de IA

Sun, 17 May 2026 23:07:38 +0800

vercel/ai es el AI SDK open source mantenido por Vercel.

Su posicionamiento es claro: ofrece a los desarrolladores TypeScript un conjunto de herramientas unificado para crear aplicaciones de IA y AI Agents. Viene del equipo detrás de Next.js, pero no se limita a Next.js. También soporta React, Svelte, Vue, Angular y runtimes como Node.js.

Repositorio del proyecto: https://github.com/vercel/ai

Si estás creando una app de chat, una herramienta de escritura con IA, una aplicación RAG, un Agent con tool calling, una interfaz con salida en streaming, o un producto que debe conectar varios proveedores de modelos en la misma aplicación, Vercel AI SDK merece atención.

El problema central que resuelve

Hoy, al crear aplicaciones de IA, uno de los mayores problemas no es “si se puede llamar a un modelo”, sino que cada proveedor tiene APIs, formatos de streaming, convenciones de tool calling, manejo de errores y necesidades de estado en frontend distintas.

Por ejemplo:

OpenAI tiene su propio SDK y formatos de respuesta.
Anthropic tiene su propia estructura de mensajes.
Google, xAI, Mistral, DeepSeek, Groq y otros también difieren.
La salida en streaming requiere manejar chunks.
El tool calling requiere procesar solicitudes estructuradas iniciadas por el modelo.
La UI de chat también debe gestionar mensajes, estados de carga, cancelación, reintentos y errores.

Si escribes un adaptador manual para cada proveedor, el proyecto se vuelve complejo muy rápido.

La idea de Vercel AI SDK es reunir esas diferencias detrás de una API unificada. El desarrollador escribe la aplicación contra una sola interfaz y conecta distintos modelos mediante Providers.

Arquitectura unificada de Providers

Una característica clave de Vercel AI SDK es que es provider-agnostic, es decir, no está atado a un único proveedor de modelos.

Puede acceder a OpenAI, Anthropic, Google y otros proveedores mediante una API unificada. El README del proyecto también indica que AI SDK usa Vercel AI Gateway de forma predeterminada, lo que facilita acceder a varios providers principales.

Esto es útil en proyectos reales.

Muchos productos de IA terminan usando más de un modelo:

Algunas tareas necesitan modelos de razonamiento fuerte.
Algunas tareas necesitan modelos rápidos y baratos.
Algunas tareas requieren multimodalidad.
Algunas tareas requieren contexto largo.
Algunas tareas necesitan modelos locales o privados.

Una arquitectura unificada de Providers facilita el cambio de modelo, las pruebas graduales, el control de costos y las estrategias de fallback.

El streaming es clave para la experiencia frontend

Una gran diferencia entre las apps de IA y las APIs tradicionales es que las respuestas pueden ser largas.

Si el usuario debe esperar a que vuelva toda la respuesta, las herramientas de chat, escritura y programación se sienten lentas. La salida en streaming permite mostrar texto de forma progresiva, para que el usuario vea avance antes.

Vercel AI SDK encapsula bastante bien la generación en streaming. El desarrollador no necesita manejar desde cero eventos de bajo nivel, sino usar las APIs de generación y streaming del SDK para conectar la salida del modelo con la UI.

Esto resulta especialmente cómodo en aplicaciones Next.js / React.

Una interfaz de chat con IA parece simple, pero en realidad debe manejar:

Lista de mensajes.
Entrada del usuario.
Solicitudes al servidor.
Visualización de tokens en streaming.
Estado de carga.
Estado de error.
Cancelación de generación.
Regeneración.

Estas son las tareas repetitivas que AI SDK intenta reducir.

Tool calling y escenarios de Agent

A medida que las aplicaciones de IA pasan de “chatear” a “hacer cosas”, el tool calling se vuelve cada vez más importante.

El modelo no solo devuelve lenguaje natural; también puede necesitar llamar funciones externas:

Consultar una base de datos.
Buscar documentos.
Llamar APIs de negocio.
Leer el estado de un pedido.
Generar gráficos.
Crear eventos de calendario.
Modificar archivos de proyecto.

Vercel AI SDK soporta capacidades de tool calling, para que el desarrollador defina herramientas, parámetros y lógica de ejecución, y el modelo pueda solicitar esas herramientas cuando corresponda.

Esta es una de las razones por las que pasó de ser un “SDK de UI de chat” a un toolkit más amplio para aplicaciones de IA y Agents.

Pero añadir tool calling no lo resuelve todo. En proyectos reales también hay que considerar:

Validación de parámetros.
Límites de permisos.
Logs de llamadas a herramientas.
Idempotencia.
Timeouts y reintentos.
Confirmación humana.
Restricciones para acciones sensibles.

AI SDK puede ayudar con interfaces y flujo, pero los límites de seguridad los debe diseñar el desarrollador.

Integración de UI

Vercel AI SDK es amigable con frameworks frontend.

No solo ofrece APIs centrales de generación; también abstrae chat, completions, estado de mensajes y UI en streaming. Para equipos que usan Next.js y React, esto puede reducir mucho código repetitivo.

Pero no sirve únicamente para despliegues en Vercel.

Si tu proyecto usa TypeScript, o tu backend corre en Node.js, AI SDK puede funcionar como capa de llamada a modelos y procesamiento de streaming. Desplegar o no en Vercel depende de la arquitectura, hábitos del equipo e infraestructura.

Skill for Coding Agents

El README de vercel/ai incluye una sugerencia interesante: si usas coding agents como Claude Code o Cursor, puedes añadir el skill de AI SDK al repositorio.

El comando de ejemplo es:

`1`	`npx skills add vercel/ai`

Esto muestra que Vercel entiende que los usuarios de AI SDK no son solo desarrolladores humanos, sino también coding agents.

Cuando un agent modifica un proyecto que usa AI SDK, un skill dedicado en el repositorio puede ayudarle a entender convenciones del SDK, APIs frecuentes, estructura del proyecto y buenas prácticas, reduciendo la probabilidad de cambios desordenados.

Esta dirección merece seguimiento.

En el futuro, los proyectos open source quizá no solo ofrezcan README y documentación, sino también instrucciones estructuradas para AI coding agents. En SDKs complejos, eso puede convertirse en una nueva puerta de entrada a la experiencia de desarrollo.

Proyectos para los que encaja

Vercel AI SDK encaja en estos escenarios:

Apps de chat con IA basadas en Next.js / React.
Herramientas de escritura, preguntas y respuestas, soporte y asistentes de código que necesitan streaming.
Productos de IA que deben conectar varios model providers.
Equipos que quieren crear prototipos RAG o de preguntas sobre documentos rápidamente.
Apps que necesitan tool calling, function calling o capacidades ligeras de Agent.
Equipos que ya usan TypeScript / Node.js.

Es especialmente útil para desarrolladores frontend y full-stack. En muchas apps de IA, la dificultad no es solo llamar al modelo, sino convertir la salida del modelo en una experiencia estable, fluida e interactiva.

Para qué no encaja tanto

Si tu proyecto es principalmente un backend Python, entrenamiento de deep learning, fine-tuning de modelos o servicio de inferencia de bajo nivel, Vercel AI SDK quizá no sea la herramienta central.

Está más cerca de la capa de aplicación que de un framework de entrenamiento.

Si necesitas:

Entrenar tu propio modelo.
Gestionar clusters de inferencia con GPU.
Hacer batch inference de bajo nivel.
Controlar profundamente tokenizer, KV cache, cuantización y motores de inferencia.

Conviene mirar PyTorch, vLLM, SGLang, TensorRT-LLM, llama.cpp o servicios cloud de inferencia.

Vercel AI SDK se parece más a la capa que conecta capacidades de modelos con productos.

Qué tener en cuenta al usarlo

Primero, no interpretes una API unificada como ausencia total de diferencias.

Los distintos model providers siguen variando en capacidades, longitud de contexto, formatos de tool calling, detalles de streaming, tipos de error y precios. Un SDK unificado reduce fricción de ingeniería, pero no elimina las diferencias entre modelos.

Segundo, controla costos.

Cuando una app de IA sale a producción, el chat en streaming, los reintentos, tool calls, recuperación RAG y fallbacks multi-modelo pueden aumentar costos. Hace falta rate limiting, caché, logs y monitoreo de presupuesto.

Tercero, diseña límites de seguridad.

Si el modelo puede llamar herramientas, debes limitar qué pueden hacer esas herramientas. No dejes que el modelo ejecute directamente acciones de alto riesgo, ni expongas secretos, permisos de escritura en bases de datos u operaciones de producción sin controles.

Cuarto, conserva observabilidad.

Cuando una app de IA falla, no basta con mirar el error del frontend. Necesitas saber entrada del usuario, modelo elegido, llamadas a herramientas, tiempo de respuesta, consumo de tokens, tipo de error y salida final.

Resumen

vercel/ai no es un modelo nuevo, ni solo un componente de chat.

Se parece más a infraestructura para desarrollar aplicaciones de IA con TypeScript: Providers unificados, salida en streaming, tool calling, gestión de estado frontend y escenarios de Agent dentro de un SDK open source.

Para equipos que ya usan Next.js, React, TypeScript y Node.js, puede reducir mucho el costo de ingeniería entre “la API del modelo funciona” y “la experiencia de producto es usable”.

Pero no es una capa universal. La elección de modelos, permisos, control de costos, logs, monitoreo y seguridad de negocio siguen siendo responsabilidad del desarrollador.

Si quieres crear aplicaciones de IA, no entrenar modelos, Vercel AI SDK es un toolkit que vale la pena probar temprano.

Referencias

Bun: runtime, gestor de paquetes, pruebas y bundler de JavaScript en una sola herramienta

Sun, 17 May 2026 17:42:25 +0800

Bun es una toolchain open source todo en uno para JavaScript / TypeScript creada por oven-sh.

No quiere ser solo un reemplazo más rápido de Node.js. Reúne runtime, gestor de paquetes, runner de scripts, test runner y bundler bajo el mismo comando bun. Para desarrolladores frontend y Node.js, su atractivo es claro: menos herramientas, menos espera en instalación y build, y muchas tareas comunes con un solo comando.

Proyecto: https://github.com/oven-sh/bun

Conclusión rápida

Bun encaja mejor con quienes quieren simplificar la toolchain JavaScript.

Puede:

Ejecutar JavaScript, TypeScript, JSX y TSX.
Funcionar como runtime compatible con Node.js.
Reemplazar npm / yarn / pnpm para gestionar paquetes.
Ejecutar scripts de package.json.
Ejecutar pruebas.
Empaquetar código frontend o backend.
Usar bunx para ejecutar comandos de paquetes npm.
Ofrecer API integradas como Bun.serve, bun:sqlite, Bun.sql, Bun.redis y Bun.s3.

Su valor más visible es la experiencia de desarrollo: instalaciones rápidas, arranque rápido, comandos unificados y TypeScript / JSX listos para usar.

Pero Bun no es algo que todos los proyectos deban adoptar de inmediato. Aplicaciones Node.js grandes, proyectos con muchas extensiones nativas y servicios de producción con requisitos altos de estabilidad necesitan validar compatibilidad, build, pruebas y despliegue.

Qué es Bun

Según el README oficial, Bun es un toolkit todo en uno para aplicaciones JavaScript y TypeScript. Se distribuye como un único ejecutable llamado bun.

Su núcleo es Bun runtime: un runtime JavaScript rápido que busca actuar como drop-in replacement de Node.js. Bun está escrito en Zig, se basa en JavaScriptCore y optimiza arranque y uso de memoria.

Puedes ejecutar directamente:

`1`	`bun run index.tsx`

TypeScript y JSX funcionan sin configuración adicional.

El mismo comando bun incluye test runner, script runner, gestor de paquetes compatible con Node.js, bundler y package runner.

Comandos frecuentes:

bun test
bun run start
bun install <pkg>
bunx cowsay 'Hello, world!'

Un proyecto típico puede acabar con node, npm, pnpm, tsx, jest, vitest, webpack, esbuild y ts-node. Bun intenta absorber muchas rutas frecuentes en una sola herramienta.

Instalación

Bun soporta Linux, macOS y Windows en x64 y arm64.

Script oficial:

`1`	`curl -fsSL https://bun.com/install \| bash`

Windows:

`1`	`powershell -c "irm bun.sh/install.ps1 \| iex"`

También se puede instalar con npm:

`1`	`npm install -g bun`

macOS Homebrew:

1
2

brew tap oven-sh/bun
brew install bun

Docker:

1
2

docker pull oven/bun
docker run --rm --init --ulimit memlock=-1:-1 oven/bun

En Linux hay que mirar la versión del kernel. El README recomienda Linux kernel 5.6 o superior, con 5.1 como mínimo.

Actualizar:

`1`	`bun upgrade`

Actualizar a canary:

`1`	`bun upgrade --canary`

Canary no suele ser buena opción para producción salvo que estés validando una función nueva o investigando un bug concreto.

Por qué Bun es rápido

La velocidad de Bun viene de varias capas.

Primero, el arranque del runtime es rápido. Muchas herramientas CLI y scripts de desarrollo no están limitados por CPU sostenida, sino por arranque de proceso, carga de módulos, transpilación TypeScript y resolución de dependencias. Bun optimiza esas rutas.

Segundo, la gestión de paquetes es rápida. bun install busca reemplazar los flujos de instalación de npm / yarn / pnpm. Usa caché global y su propio lockfile, lo que puede reducir mucho la espera con muchas dependencias.

Tercero, TypeScript / JSX funcionan sin configuración. Muchos proyectos solo quieren ejecutar un .ts o .tsx; con Node.js tradicional se añaden tsx, ts-node, Babel o un build. Bun puede ejecutarlos directamente.

Cuarto, las herramientas integradas reducen cambios de proceso y configuración. Pruebas, scripts, bundling y ejecución viven en la misma herramienta.

Aun así, “Bun es rápido” no significa que todo proyecto vaya a ser más rápido. Depende de dependencias, lógica de scripts, framework de pruebas, build, uso de API Node.js y caché de CI.

Gestión de paquetes: reemplazar npm / yarn / pnpm

Bun instala dependencias directamente:

`1`	`bun install`

Añadir dependencia:

`1`	`bun add react`

Añadir dependencia de desarrollo:

`1`	`bun add -d typescript`

Eliminar dependencia:

`1`	`bun remove react`

Ver por qué existe una dependencia:

`1`	`bun why react`

Auditoría de seguridad:

`1`	`bun audit`

Si migras desde npm o pnpm, revisa si bun.lock entra en control de versiones, si CI usa bun install --frozen-lockfile, si private registries y .npmrc son compatibles, si workspace se comporta como esperas, si lifecycle scripts introducen riesgo y si un monorepo dependiente de pnpm puede migrar sin fricción.

Los proyectos pequeños pueden probarlo directamente. En monorepos grandes, empieza por un package o un job de CI no bloqueante.

Ejecutar scripts y TypeScript

Bun ejecuta scripts de package.json:

`1`	`bun run start`

También ejecuta archivos directamente:

1
2

bun run index.ts
bun run index.tsx

Es útil para scripts como:

scripts/build.ts
scripts/seed.ts
scripts/migrate.ts
scripts/check.ts

Con Node.js, muchas veces hay que resolver loader TypeScript o precompilación. Bun reduce ese pegamento.

Si un script depende de detalles de Node.js, como loaders, frontera ESM/CJS, módulos nativos, child process, file watching o API de borde, sigue necesitando pruebas.

Test runner

Bun incluye test runner:

`1`	`bun test`

Encaja en proyectos pequeños que quieren menos configuración Jest / Vitest, y también para mover algunas pruebas unitarias, de herramientas o de librerías a un runner más ligero.

Al migrar pruebas, mira diferencias en expect, mock API, snapshots, entorno DOM, reglas de descubrimiento, cobertura y reportes de CI.

Si el proyecto depende profundamente de Jest, con matchers propios, mocks complejos, jsdom, babel-jest o ts-jest, no conviene migrar deprisa. Puedes usar bun test en módulos nuevos y conservar el framework anterior para lo existente.

Bundling y build

Bun ofrece bundler:

`1`	`bun build ./src/index.ts --outdir ./dist`

Puede usarse para bundles frontend, scripts backend, CLI y librerías. La documentación cubre loaders, plugins, macros, CSS, HTML, HMR, minifier y single-file executable.

Buenos candidatos iniciales:

Herramientas frontend pequeñas.
CLI Node.js.
Scripts internos.
Servicios de un solo archivo.
Proyectos sin loaders webpack complejos.

Ten cuidado con cadenas webpack complejas, muchos plugins Vite, transformaciones Babel profundas, pipelines CSS / assets especiales, micro-frontends, module federation y proyectos con requisitos finos de hash, chunks y compatibilidad.

El bundler de Bun es atractivo, pero migrar build suele ser más arriesgado que cambiar el gestor de paquetes. Valídalo por separado.

Ejecutar servicios HTTP

Bun ofrece Bun.serve:

Bun.serve({
  port: 3000,
  fetch(req) {
    return new Response("Hello from Bun")
  },
})

Es práctico para API pequeñas, servicios internos, webhook receivers y servicios con estilo edge. Bun también incluye WebSockets, Workers, Streams, SQLite, PostgreSQL, Redis, S3 y TCP/UDP sockets.

Si ya usas Express, Fastify, NestJS, Next.js, Hono, Elysia u otro framework, revisa primero su compatibilidad con Bun. No hace falta reescribir un servicio solo para usar Bun.

Una ruta realista es usar Bun primero para scripts y paquetes, después para pruebas, y al final evaluar si el runtime de producción debe cambiar. La migración del runtime exige más cuidado porque afecta directamente el comportamiento en producción.

Relación con Node.js

Uno de los objetivos de Bun es ser un drop-in replacement de Node.js, pero compatibilidad no significa equivalencia completa.

El ecosistema Node.js acumula muchos detalles: interoperabilidad CJS / ESM, módulos internos, extensiones nativas, lifecycle scripts de npm, comportamiento de filesystem, stream y Buffer, worker / child_process, debugging y profiling.

Bun mejora rápido, pero la migración a producción debe juzgarse por pruebas.

Preguntas prácticas:

¿Tus pruebas pasan con Bun?
¿Las dependencias clave soportan Bun?
¿Los artefactos de build son equivalentes?
¿CI y local se comportan igual?
¿Hay monitorización y rollback en producción?
¿Docker y despliegue son estables?

Cambiar solo el gestor de paquetes tiene menos riesgo. Cambiar el runtime de producción tiene mucho más.

Proyectos adecuados

Bun encaja bien con proyectos pequeños nuevos en JavaScript / TypeScript, herramientas internas, CLI, CI que necesita instalaciones rápidas, frontend que quiere reducir complejidad, scripts o servicios sensibles al arranque y desarrolladores que quieren TypeScript listo para ejecutar.

Conviene ir con más cautela en monorepos enormes, proyectos atados a pnpm workspace, servicios con muchas extensiones nativas Node.js, builds frontend muy personalizados, backends con exigencias fuertes de consistencia en runtime y suites de pruebas muy dependientes de Jest.

Una estrategia conservadora y útil es usar Bun primero como herramienta de desarrollo, no como sustituto inmediato de todos los runtimes de producción.

Consejos de migración

Para probar Bun en un proyecto existente:

Instala Bun localmente.
Ejecuta bun install y revisa el resultado.
Conserva o commitea bun.lock para evitar confusión con lockfiles.
Prueba bun run <script> con scripts comunes.
Migra pocas pruebas con bun test.
Añade un job Bun no bloqueante en CI.
Si no hay problemas, evalúa cambiar el flujo principal de instalación.
Evalúa la migración del runtime de producción al final.

En equipos, conserva una ruta de rollback. Mantén el flujo npm / pnpm / yarn durante la migración, ejecuta ambos en CI un tiempo, no cambies runtime, gestor, framework de pruebas y bundler en la misma modificación, y divide el proceso en pasos pequeños verificables.

Comandos frecuentes

Instalar:

`1`	`curl -fsSL https://bun.com/install \| bash`

Actualizar:

`1`	`bun upgrade`

Instalar dependencias:

`1`	`bun install`

Añadir dependencia:

`1`	`bun add lodash`

Ejecutar script:

`1`	`bun run dev`

Ejecutar TypeScript directamente:

`1`	`bun run scripts/build.ts`

Pruebas:

`1`	`bun test`

Bundle:

`1`	`bun build ./src/index.ts --outdir ./dist`

Ejecutar comando de paquete:

`1`	`bunx cowsay 'Hello, world!'`

Resumen

El valor de Bun no es solo ser “más rápido que Node.js”. Lo importante es que reúne muchas herramientas dispersas del desarrollo JavaScript / TypeScript en un solo comando bun: runtime, gestor de paquetes, runner de scripts, test runner y bundler.

Para proyectos nuevos y herramientas internas, la experiencia integrada puede ser cómoda: instalaciones rápidas, arranque rápido, menos configuración y TypeScript / JSX directos. En proyectos grandes ya existentes, es mejor introducir Bun primero en áreas de bajo riesgo, como instalación, scripts y algunas pruebas, antes de validar build y runtime.

Si la velocidad de instalación, los fragmentos de configuración y el arranque lento de pruebas de la toolchain Node.js te molestan a menudo, Bun merece una prueba seria. Pero la migración de producción vuelve a lo básico: pruebas, compatibilidad, CI estable y rollback.

Referencias:

Guía de inicio en desarrollo de juegos con Godot: de nodos y escenas a tu primer juego 2D

Sun, 17 May 2026 12:37:30 +0800

Godot es un motor de juegos open source adecuado para juegos 2D, prototipos indie y proyectos 3D medianos.

Sus puntos fuertes son que es ligero, abierto, rápido de iniciar y usa un sistema claro de nodos y escenas. Para principiantes suele ser más accesible que Unity, y para desarrolladores independientes permite mantener proyectos pequeños y controlados.

Conclusión rápida

No intentes aprender todo el motor desde el primer día.

Una ruta mejor:

Empieza por 2D, no por 3D.
Entiende nodos y escenas antes de diseñar arquitecturas complejas.
Aprende primero GDScript.
Crea un juego pequeño que pueda empezar, fallar y reiniciarse.
Luego añade animación, audio, UI, niveles y exportación.

Completar un juego pequeño enseña más que ver muchos tutoriales sueltos.

Para quién sirve Godot

Godot encaja bien si quieres aprender desarrollo de juegos desde cero, crear juegos 2D indie, prototipar rápido, evitar toolchains pesadas o entender cómo se organizan los objetos dentro de un motor.

Unity y Unreal siguen siendo más fuertes para pipelines comerciales grandes, tiendas de assets, SDKs de monetización móvil o gráficos 3D de alto nivel. Pero para aprender y crear tus propios juegos, Godot es una gran entrada.

Instalación y proyecto

Descarga Godot desde la web oficial, descomprime y ejecuta.

Para el primer proyecto:

Usa el renderer por defecto.
Usa un nombre en inglés.
Evita rutas complicadas.
Usa Git desde el inicio.

Ejemplo:

`1`	`first-godot-game`

Familiarízate con Scene, FileSystem, Inspector, Script y las vistas 2D / 3D.

Nodos y escenas

Los conceptos centrales son nodos y escenas.

Nodos comunes:

Node2D: objeto base 2D.
Sprite2D: muestra una imagen.
CollisionShape2D: forma de colisión.
CharacterBody2D: personaje controlable.
Camera2D: cámara 2D.
AudioStreamPlayer: reproduce audio.
Label: muestra texto.

Una escena es un grupo reutilizable de nodos. Un jugador, un enemigo o un nivel pueden ser escenas.

Player (CharacterBody2D)
├── Sprite2D
├── CollisionShape2D
└── Camera2D

Primer proyecto recomendado

Haz un juego 2D de esquivar:

El jugador se mueve arriba, abajo, izquierda y derecha.
Los enemigos aparecen desde los bordes.
Tocar un enemigo significa perder.
El tiempo de supervivencia es la puntuación.
Hay pantalla inicial, game over y reinicio.

Esto cubre movimiento, input, colisiones, spawning, UI, timers, audio y recarga de escena.

Movimiento del jugador

Usa CharacterBody2D:

extends CharacterBody2D

@export var speed := 300.0

func _physics_process(delta):
    var direction := Vector2.ZERO

    direction.x = Input.get_axis("move_left", "move_right")
    direction.y = Input.get_axis("move_up", "move_down")
    direction = direction.normalized()

    velocity = direction * speed
    move_and_slide()

Define acciones de entrada:

move_left  -> A / Left
move_right -> D / Right
move_up    -> W / Up
move_down  -> S / Down

Usa actions en vez de teclas codificadas. Así será más fácil soportar mando, táctil o remapeo.

Colisiones y física

Nodos comunes:

CollisionShape2D: define colisión.
Area2D: detecta solapamientos.
CharacterBody2D: jugador o personaje controlado.
RigidBody2D: objeto físico.
StaticBody2D: paredes o suelo.

Para empezar: usa CharacterBody2D si controlas el movimiento, y Area2D si solo necesitas detectar contacto.

1
2
3

func _on_body_entered(body):
    if body.name == "Player":
        get_tree().reload_current_scene()

Instanciar enemigos

Las escenas funcionan como prefabs:

@export var enemy_scene: PackedScene

func spawn_enemy():
    var enemy = enemy_scene.instantiate()
    enemy.position = Vector2(800, randf_range(50, 550))
    add_child(enemy)

Con un Timer, puedes crear enemigos cada cierto tiempo.

UI, puntuación y audio

La UI usa nodos Control: CanvasLayer, Label, Button, Panel.

Puntuación simple:

var score := 0.0

func _process(delta):
    score += delta
    $CanvasLayer/ScoreLabel.text = str(int(score))

Audio:

`1`	`$HitSound.play()`

Un juego necesita feedback: sonidos, parpadeos, estados de botón, vibración o shake. La función por sí sola no basta.

Organización del proyecto

Desde el inicio:

res://
├── scenes/
├── scripts/
├── assets/
└── ui/

Escenas en scenes/, scripts en scripts/, imágenes y audio en assets/, UI en ui/.

Errores comunes

Elegir mal el tipo de nodo.
Olvidar CollisionShape2D.
Codificar teclas directamente.
Meter jugador, enemigos, UI y nivel en un solo script.
Empezar con un proyecto demasiado grande.

Un juego pequeño terminado vale más que una gran idea abandonada.

Ruta de aprendizaje

Editor.
Nodos y escenas.
GDScript.
Input actions.
Movimiento 2D.
Colisiones y Area2D.
Timer y spawning.
UI y puntuación.
Audio y animación.
Exportación a desktop o web.

Resumen

La entrada a Godot no consiste en memorizar todas sus funciones, sino en entender cómo organiza juegos: nodos forman escenas, escenas forman juegos, scripts dan comportamiento y signals conectan eventos.

Empieza con un juego 2D pequeño. Cuando ya tengas movimiento, colisión, UI, audio y reinicio, avanza a TileMap, guardado, máquinas de estado, 3D, shaders y optimización de exportación.

Lectura rápida de la documentación de Ghostty: instalación, configuración y uso diario

Fri, 15 May 2026 14:50:11 +0800

Ghostty es un nuevo emulador de terminal, pero no es simplemente “otra terminal más rápida”. Según su documentación oficial, intenta equilibrar tres direcciones al mismo tiempo: velocidad, funciones y una experiencia de escritorio nativa. Es decir, busca aceleración por GPU y buen rendimiento de renderizado, pero también quiere sentirse como una aplicación local real en macOS y Linux, no como una interfaz completamente dibujada a mano.

Si hoy usas iTerm2, Kitty, Alacritty, WezTerm o la terminal del sistema, lo más interesante de Ghostty no es una función aislada. Es la combinación entre “funciona desde el primer arranque” y “se puede configurar en profundidad”. La configuración predeterminada ya es usable; cuando quieres ajustar más, la documentación ofrece entradas completas para archivos de configuración, temas, atajos, fuentes, integración con Shell y secuencias de control de terminal.

Primero, el posicionamiento

El posicionamiento central de Ghostty se puede resumir en tres puntos:

Es un emulador de terminal multiplataforma, con foco actual en macOS y Linux.
Usa UI nativa de cada plataforma: Swift, AppKit y SwiftUI en macOS; Zig y GTK4 en Linux.
Su núcleo de terminal es libghostty, y las aplicaciones GUI se construyen alrededor de este núcleo compartido.

Este diseño afecta la experiencia diaria. Pestañas, divisiones, mensajes de error, restauración del estado de ventanas y atajos del sistema no son simples componentes que “parecen una aplicación de escritorio”; intentan acercarse a los hábitos de interacción de cada sistema. Los atajos predeterminados de macOS y Linux también se diferencian según las convenciones de cada plataforma.

Instalación: directa en macOS, dependiente de la distribución en Linux

Los binarios precompilados oficiales apuntan principalmente a macOS. La forma más común de instalarlo es descargar el .dmg, abrirlo y arrastrar Ghostty al directorio Applications. Los usuarios de Homebrew también pueden usar el cask mantenido por la comunidad:

`1`	`brew install --cask ghostty`

En Linux la situación está más fragmentada. La documentación de Ghostty separa administradores de paquetes, binarios comunitarios y compilación desde código fuente para distintas distribuciones. Arch, Alpine, Gentoo, NixOS, Snap, Solus, Void y otras tienen rutas propias. Si una distribución no tiene un repositorio oficial o confiable, la documentación tiende a recomendar compilar desde el código fuente antes que instalar binarios de terceros sin revisar.

Esto es especialmente importante en servidores y estaciones de trabajo: un emulador de terminal maneja mucha entrada y salida, portapapeles, enlaces, sesiones SSH y rutas de archivos locales. Conviene ser conservador con la fuente de instalación y priorizar el paquete oficial de macOS, los repositorios de la distribución o un proceso de compilación cuyo origen puedas auditar.

Configuración: no copies una configuración gigante de dotfiles al principio

La filosofía de configuración de Ghostty es “usable con cero configuración”. La fuente predeterminada incluye JetBrains Mono y soporte de Nerd Font, así que la mayoría de usuarios puede trabajar normalmente al abrirlo por primera vez. La documentación incluso sugiere que, si necesitas cambiar una opción no subjetiva para sentirte cómodo, quizá esa conducta debería ser la predeterminada.

Cuando realmente necesitas personalizar, Ghostty usa un archivo de configuración de texto. El nombre actual es config.ghostty, aunque versiones antiguas también soportan config. Las rutas comunes incluyen:

$XDG_CONFIG_HOME/ghostty/config.ghostty
$XDG_CONFIG_HOME/ghostty/config
$HOME/.config/ghostty/config.ghostty
$HOME/.config/ghostty/config

En macOS también lee:

1
2

$HOME/Library/Application Support/com.mitchellh.ghostty/config.ghostty
$HOME/Library/Application Support/com.mitchellh.ghostty/config

La sintaxis es muy directa: key = value. Por ejemplo:

font-family = JetBrains Mono
font-size = 14
theme = light:Rose Pine Dawn,dark:Rose Pine
keybind = ctrl+shift+t=new_tab

Un consejo práctico: no empieces copiando la configuración completa de otra persona. Es más estable usarlo unos días sin cambios y modificar solo tres cosas al principio: fuente, tamaño de fuente y tema. Cuando de verdad notes fricción con atajos, divisiones, ventanas o integración con Shell, agrega esas opciones una por una.

Consulta de documentación: también hay referencia completa local

Ghostty tiene muchas opciones de configuración, y la documentación oficial las reúne en Option Reference. Además de la página web, después de instalarlo puedes consultar la referencia localmente:

`1`	`ghostty +show-config --default --docs`

Este comando imprime la configuración predeterminada y la documentación en la salida estándar, útil para enviarlo a un paginador:

`1`	`ghostty +show-config --default --docs \| less`

Para ver fuentes disponibles:

`1`	`ghostty +list-fonts`

Para ver temas incorporados y disponibles:

`1`	`ghostty +list-themes`

Para ver los atajos predeterminados:

`1`	`ghostty +list-keybinds --default`

Estos comandos son más confiables que copiar fragmentos de internet, porque vienen de la versión de Ghostty instalada en tu máquina.

Atajos: piensa en “acciones” como concepto central

El formato de configuración de atajos de Ghostty es:

`1`	`keybind = trigger=action`

trigger es la forma de activar una tecla o combinación, y action es la operación que ejecuta Ghostty. Crear una pestaña, cerrar la surface actual, recargar configuración o saltar a un prompt son acciones. El modelo es claro: no estás “cambiando una opción de menú”, sino vinculando una secuencia de entrada a una acción.

Después de cambiar la configuración, puedes recargarla en tiempo de ejecución. El atajo predeterminado es:

Linux: ctrl+shift+,
macOS: cmd+shift+,

No todas las opciones se aplican de inmediato. Algunas solo afectan terminales nuevas, y otras requieren reiniciar completamente. Si “la configuración está escrita pero no cambia nada”, revisa primero la explicación de esa opción; suele ahorrar más tiempo que sospechar de la sintaxis una y otra vez.

Temas y fuentes: usa primero lo incorporado y luego ajusta

Ghostty incluye muchos temas y soporta cambiar entre temas según el modo claro u oscuro del sistema:

`1`	`theme = light:Rose Pine Dawn,dark:Rose Pine`

Los temas también pueden venir de archivos personalizados. La documentación lo advierte con claridad: un archivo de tema es, en esencia, un archivo de configuración de Ghostty y puede definir muchas opciones, así que no conviene usar temas de fuentes no confiables.

En fuentes, font-family se puede repetir varias veces para especificar fuentes fallback. Es útil en entornos multilingües: la fuente principal puede cubrir inglés y símbolos, mientras las siguientes cubren chino, japonés u otros caracteres. Si aparecen detalles de visualización con emoji, negrita, cursiva o ligaduras, basta con revisar la opción correspondiente en Option Reference.

Integración con Shell: especialmente importante para usuarios de SSH

Ghostty soporta inyección automática de shell integration para bash, elvish, fish, nushell y zsh. Al activarla, varias experiencias se vuelven más naturales:

Las terminales nuevas pueden abrirse en el directorio de trabajo de la terminal anterior.
Los prompts complejos pueden redibujarse al cambiar tamaño en lugar de reacomodarse mal.
Puedes saltar entre salidas de comandos mediante marcadores de prompt.
El comportamiento del cursor en el prompt se ajusta mejor a hábitos de edición.

Si no quieres inyección automática, desactívala en la configuración:

`1`	`shell-integration = none`

SSH merece atención extra. Ghostty usa xterm-ghostty como TERM, pero muchos hosts remotos todavía no tienen el terminfo correspondiente. La documentación ofrece dos funciones de shell integration, ssh-env y ssh-terminfo, desactivadas por defecto y activables según necesidad:

`1`	`shell-integration-features = ssh-env,ssh-terminfo`

Si te conectas a menudo a servidores antiguos, contenedores, bastiones o entornos de producción con gestión estricta, conviene leer primero la documentación oficial de Terminfo y Shell Integration antes de activar estas funciones. La negociación de capacidades de terminal parece menor, pero cuando falla puede producir colores anómalos, atajos rotos o programas de pantalla completa desordenados.

Mi orden de prueba

Si solo quieres decidir si Ghostty encaja contigo, puedes probarlo en este orden:

Instálalo y úsalo un día sin escribir configuración.
Ajusta solo font-family, font-size y theme.
Usa ghostty +list-keybinds --default para ver los atajos predeterminados, en lugar de importar primero la tabla de otra persona.
Si usas SSH con frecuencia, revisa primero la compatibilidad de terminfo en hosts remotos.
Al final ajusta divisiones, ventanas, transparencia, barra de título, imagen de fondo y preferencias visuales o de flujo de trabajo.

La documentación de Ghostty está escrita con un enfoque bastante ingenieril. Conviene leerla como un manual de referencia de configuración, no como una página promocional. Para la mayoría de usuarios, el criterio real es simple: si la experiencia predeterminada ya resulta cómoda y tus flujos diarios con editor, Shell, SSH, tmux o Zellij son estables. Si esas piezas funcionan bien, Ghostty merece entrar en tu lista de terminales candidatas a largo plazo.

Referencias

Cómo cambiar el idioma de la interfaz de VS Code: chino, inglés y otros idiomas

Fri, 08 May 2026 13:18:57 +0800

VS Code admite muchos idiomas de interfaz. Lo habitual es instalar primero el paquete de idioma correspondiente y luego elegir el idioma de visualización desde la paleta de comandos. Si necesitas fijar VS Code a un idioma concreto, también puedes modificar manualmente el valor locale en argv.json.

Este método no solo sirve para chino simplificado; también funciona con inglés, chino tradicional, japonés, coreano, francés, alemán, español y otros idiomas.

Instalar el paquete de idioma correspondiente

Si quieres cambiar a una interfaz que no sea inglés, normalmente debes instalar primero un paquete de idioma.

Abre el panel de extensiones de VS Code en la barra lateral izquierda, o usa el atajo Ctrl+Shift+X.
En el cuadro de búsqueda, escribe el idioma objetivo, por ejemplo Chinese, Japanese, Korean o French.
Selecciona el paquete de idioma correspondiente y haz clic en Install.
Cuando termine la instalación, reinicia VS Code si se te solicita.

Para chino simplificado, el paquete habitual es Chinese (Simplified). Para chino tradicional, usa Chinese (Traditional).

Cambiar el idioma desde la paleta de comandos

Este es el método recomendado para la mayoría de los usuarios.

Abre la paleta de comandos: Ctrl+Shift+P.
Escribe Configure Display Language.
Selecciona el comando Configure Display Language.
Elige en la lista el idioma que quieres usar.
Reinicia VS Code si se te solicita.

Después del reinicio, los menús, las páginas de configuración y los mensajes habituales usarán el idioma seleccionado. Si el idioma objetivo no aparece en la lista, instala antes su paquete desde el panel de extensiones.

Especificar el idioma manualmente en argv.json

Si el cambio desde la paleta de comandos no funciona, o si quieres fijar explícitamente el idioma de visualización, puedes editar directamente el archivo de argumentos de ejecución de VS Code.

Abre la paleta de comandos: Ctrl+Shift+P.
Escribe y selecciona Preferences: Configure Runtime Arguments.
Busca o agrega la opción locale.
Cambia su valor por el código del idioma objetivo.
Guarda el archivo y reinicia VS Code.

Por ejemplo, para cambiar a inglés:

1
2
3

{
  "locale": "en"
}

Para cambiar a chino simplificado:

1
2
3

{
  "locale": "zh-cn"
}

Para cambiar a japonés:

1
2
3

{
  "locale": "ja"
}

argv.json es un archivo JSON, así que presta atención a las comas y las comillas. Si la configuración no es válida, VS Code puede no leer correctamente el idioma configurado.

Códigos de idioma de interfaz comunes

Idioma de visualización	locale
English (US)	`en`
Chino simplificado	`zh-cn`
Chino tradicional	`zh-tw`
French	`fr`
German	`de`
Italian	`it`
Spanish	`es`
Japanese	`ja`
Korean	`ko`
Russian	`ru`
Portuguese (Brazil)	`pt-br`
Turkish	`tr`
Bulgarian	`bg`
Hungarian	`hu`

Qué hacer si el idioma no cambia

Revisa estos puntos en orden:

Confirma que el paquete del idioma objetivo está instalado.
Confirma que locale usa el código correcto. Por ejemplo, chino simplificado es zh-cn, no zh-CN.
Cierra VS Code por completo y vuelve a abrirlo después de cambiar el idioma.
Si editaste argv.json manualmente, comprueba que la sintaxis JSON sea válida.
Si la configuración está desordenada, elimina la entrada locale y vuelve a elegir el idioma mediante Configure Display Language.

En la mayoría de los casos, Configure Display Language es la opción más sencilla. Edita argv.json solo cuando necesites forzar un idioma concreto o cuando el cambio desde la paleta de comandos no surta efecto.

Referencias

VScode: cambiar el idioma de la interfaz de VS Code a chino simplificado y alternar el idioma de visualización

opencode, Claude Code y Codex: diferencias y guía de herramientas open source de programación con IA

Fri, 08 May 2026 08:33:37 +0800

opencode es un AI Coding Agent open source de anomalyco. Su posicionamiento es directo: dar a los desarrolladores un asistente de código programable, extensible y capaz de conectarse a varios proveedores de modelos dentro de la terminal.

Si lo comparamos con Claude Code y Codex, los tres resuelven una misma clase de problema: llevar la IA a bases de código reales para entender contexto, modificar archivos, ejecutar comandos y correr pruebas. Pero su orientación de producto es distinta.

opencode pone más énfasis en open source, soporte de múltiples modelos y TUI de terminal. Claude Code enfatiza el ecosistema de modelos de Anthropic y la colaboración de ingeniería local. Codex es el AI coding agent de OpenAI, disponible desde la terminal, IDEs, Codex app y tareas en la nube.

Para quién es opencode

opencode encaja mejor con estos tipos de desarrolladores:

Quienes quieren completar cambios de código, análisis de proyectos y tareas de ingeniería desde la terminal.
Quienes no quieren que su AI Coding Agent dependa de un único proveedor de modelos.
Quienes prefieren herramientas open source y quieren auditarlas, ampliarlas o construir sobre ellas.
Quienes ya están cómodos con Neovim, TUI y flujos de línea de comandos.
Quienes quieren controlar en el futuro el mismo agente de programación desde una app de escritorio, móvil u otros clientes.

Su objetivo no es crear otra ventana de chat, sino poner capacidades de programación con IA dentro de la terminal y los directorios de proyecto que los desarrolladores ya usan.

Instalación

El README oficial ofrece varias formas de instalación.

# Instalación directa
curl -fsSL https://opencode.ai/install | bash

# npm
npm i -g opencode-ai@latest

# Windows
scoop install opencode
choco install opencode

# macOS y Linux
brew install anomalyco/tap/opencode
brew install opencode

# Arch Linux
sudo pacman -S opencode
paru -S opencode-bin

# Otros métodos
mise use -g opencode
nix run nixpkgs#opencode

El README oficial también recomienda eliminar versiones anteriores a 0.1.x antes de instalar, para evitar problemas causados por restos de versiones antiguas.

El script de instalación elige el directorio de instalación con esta prioridad:

$OPENCODE_INSTALL_DIR
$XDG_BIN_DIR
$HOME/bin
$HOME/.opencode/bin

Si necesitas especificar una ruta, puedes usar:

1
2

OPENCODE_INSTALL_DIR=/usr/local/bin curl -fsSL https://opencode.ai/install | bash
XDG_BIN_DIR=$HOME/.local/bin curl -fsSL https://opencode.ai/install | bash

La app de escritorio sigue en Beta

Además de la herramienta de línea de comandos, opencode también ofrece una app de escritorio, actualmente marcada como Beta. Se puede descargar desde GitHub Releases o opencode.ai/download.

La versión de escritorio cubre estas plataformas:

Plataforma	Archivo
macOS Apple Silicon	`opencode-desktop-mac-arm64.dmg`
macOS Intel	`opencode-desktop-mac-x64.dmg`
Windows	`opencode-desktop-windows-x64.exe`
Linux	`.deb`, `.rpm` o `.AppImage`

En macOS y Windows también se puede instalar la app de escritorio con gestores de paquetes.

# macOS
brew install --cask opencode-desktop

# Windows
scoop bucket add extras
scoop install extras/opencode-desktop

Dos modos Agent integrados

opencode incluye dos Agent integrados, que se pueden cambiar con la tecla Tab.

build es el modo predeterminado. Tiene permisos completos de desarrollo y sirve para editar código directamente, ejecutar comandos y avanzar en tareas de ingeniería.

plan es el modo de solo lectura. Es más adecuado para analizar bases de código desconocidas, entender la estructura del proyecto y preparar un plan de cambios. Por defecto rechaza ediciones de archivos y pregunta antes de ejecutar comandos bash.

Además, opencode incluye un sub-Agent general para búsquedas complejas y tareas de varios pasos. Los usuarios pueden invocarlo escribiendo @general en un mensaje.

Este diseño es bastante práctico: antes de actuar, usa plan para entender el proyecto; cuando haga falta cambiar código, cambia a build. En repositorios grandes, separar permisos de lectura y escritura ayuda a reducir errores.

Qué es Codex

Codex es el AI coding agent de OpenAI para ayudar a desarrolladores a escribir código, revisar código, corregir bugs y entregar tareas de ingeniería.

A diferencia de una herramienta simple de autocompletado, Codex se parece más a un Agent capaz de operar sobre una base de código. Puede trabajar contigo en herramientas locales y también puede recibir tareas delegadas para ejecutarlas en la nube. Los materiales oficiales de OpenAI describen Codex como disponible desde varias superficies, incluyendo CLI, IDEs, Codex app y flujos en la nube de ChatGPT/Codex.

Para desarrolladores, Codex tiene varios puntos importantes:

Puede leer bases de código, editar archivos, ejecutar comandos y correr pruebas.
Soporta varias interfaces, incluyendo terminal, IDE, app y nube.
Encaja con corrección de bugs, desarrollo de funciones, refactorización, migraciones, revisión de código y generación de pruebas.
Está más ligado a cuentas, modelos y ecosistema de producto de OpenAI.
Las tareas en la nube sirven para ejecutar en paralelo varias tareas de ingeniería relativamente bien definidas.

Si opencode se parece más a un framework abierto de agente en terminal, Codex se parece más a un banco de trabajo completo de programación con IA ofrecido por OpenAI: colaboración local, delegación en la nube y flujos de ingeniería más largos para equipos.

Diferencias principales

opencode, Claude Code y Codex son herramientas de programación con IA, pero la elección se entiende mejor mirando estas dimensiones.

Herramienta	Posicionamiento central	Ventajas principales	Mejor para
`opencode`	AI Coding Agent open source	Open source, múltiples modelos, TUI, arquitectura cliente/servidor	Desarrolladores que quieren una cadena de herramientas abierta, modelos reemplazables y un flujo centrado en terminal
`Claude Code`	Herramienta de programación de línea de comandos de Anthropic	Experiencia con modelos Claude, comprensión de código, contexto largo, colaboración en tareas de ingeniería	Desarrolladores que ya usan el ecosistema Claude/Anthropic y quieren avanzar tareas de código locales
`Codex`	AI coding agent de OpenAI	CLI, IDE, Codex app, tareas en la nube, flujos multi-Agent	Equipos que ya usan ChatGPT/OpenAI y quieren combinar colaboración local con delegación en la nube

En resumen, las palabras clave de opencode son “apertura y reemplazabilidad”; las de Claude Code son “ecosistema Claude y agente local de ingeniería”; y las de Codex son “ecosistema OpenAI y colaboración desde múltiples entradas”.

Diferencias con Claude Code

El FAQ oficial de opencode lo compara directamente con Claude Code. Ambos son muy parecidos en capacidad, pero las diferencias principales son estas.

Primero, opencode es un proyecto 100% open source, alojado en GitHub y publicado con MIT license.

Segundo, opencode no depende de un único proveedor de modelos. Recomienda los modelos ofrecidos a través de OpenCode Zen, pero también puede trabajar con Claude, OpenAI, Google o modelos locales. Para desarrolladores, esto significa que cuando cambien el costo, la capacidad o la disponibilidad de los modelos, no quedarán atados a una sola plataforma.

Tercero, opencode incluye soporte LSP opcional. Para autocompletado, navegación, diagnósticos y comprensión del proyecto, LSP es una base muy importante.

Cuarto, opencode pone más énfasis en TUI. Está creado por usuarios de Neovim y los creadores de terminal.shop, así que el foco del producto está claramente en la experiencia de terminal.

Quinto, opencode usa una arquitectura cliente/servidor. Esto significa que opencode puede ejecutarse en tu computadora y, en el futuro, controlarse desde una TUI, una app de escritorio, una app móvil u otros clientes. La TUI es solo una de las posibles interfaces.

Cuándo elegir opencode, Claude Code o Codex

Si ya usas Claude Code o Codex, opencode no tiene por qué reemplazarlos de inmediato. Una forma más razonable de verlo es que ofrece una opción abierta, con modelos reemplazables y orientada a la terminal.

Conviene considerar primero opencode cuando:

Quieres que tu herramienta de programación con IA sea lo más open source posible.
No quieres atar tu flujo de trabajo a un proveedor de modelos.
Quieres probar Claude, OpenAI, Google o modelos locales con la misma herramienta.
Te gustan los flujos TUI y no quieres que una app de escritorio o web interrumpa tu flujo principal.
Te interesa el potencial de control remoto de una arquitectura cliente/servidor.

Conviene considerar primero Claude Code cuando:

Usas principalmente modelos Claude.
Te importan el contexto largo, la comprensión de código y la colaboración en tareas de ingeniería complejas.
Quieres avanzar cambios, pruebas y refactorizaciones dentro de un repositorio local.
Confías más en la experiencia predeterminada de Claude Code diseñada por Anthropic.

Conviene considerar primero Codex cuando:

Ya usas ChatGPT o el ecosistema de cuentas de OpenAI.
Quieres un mismo coding agent en terminal, IDE, app de escritorio y tareas en la nube.
Quieres delegar en la nube correcciones de bugs, desarrollo de funciones, migraciones o generación de pruebas relativamente claras, en paralelo.
Necesitas revisión de código, tareas en segundo plano, colaboración de equipo y flujos multi-Agent.

Si priorizas una experiencia oficial de extremo a extremo, configuración predeterminada de modelos, administración empresarial e integraciones listas, Claude Code o Codex pueden ser más cómodos. Si priorizas control, apertura y enfoque provider-agnostic, opencode merece atención.

Puntos a tener en cuenta

opencode, Claude Code y Codex avanzan rápido. Los releases de GitHub, comandos de instalación, nombres de archivos de escritorio, disponibilidad de modelos y permisos de planes pueden cambiar. Antes de instalar o elegir, conviene revisar directamente el README, la documentación y las páginas de releases oficiales de cada herramienta.

Además, la app de escritorio de opencode sigue marcada como Beta, así que no conviene tratarla por defecto como una herramienta estable de producción. Para tareas de ingeniería diarias, la versión de terminal sigue siendo la entrada principal.

Visto como tendencia de herramientas, opencode representa la dirección de cadena de herramientas abierta para AI Coding Agents: modelos reemplazables, clientes reemplazables y una capacidad central de agente lo más abierta posible. Codex y Claude Code se parecen más a modelos convertidos por sus empresas en superficies de producto completas para coding agents. Para desarrolladores, ambas rutas probablemente coexistirán durante mucho tiempo.

Referencias

opencode GitHub: https://github.com/anomalyco/opencode
sitio oficial de opencode: https://opencode.ai
documentación de opencode: https://opencode.ai/docs
opencode Releases: https://github.com/anomalyco/opencode/releases
OpenAI Codex: https://openai.com/codex/
Using Codex with your ChatGPT plan: https://help.openai.com/en/articles/11369540-codex-in-chatgpt
OpenAI Codex CLI Getting Started: https://help.openai.com/en/articles/11096431-openai-codex-ci-getting-started

Guía de instalación de uv: cómo elegir entre macOS, Linux, Windows, pipx, Homebrew y WinGet

Thu, 07 May 2026 23:23:58 +0800

uv es un gestor de toolchain de Python creado por Astral. Sirve para gestionar versiones de Python, entornos virtuales, dependencias, scripts, proyectos y herramientas. Tiene muchas formas de instalación. La documentación oficial ofrece instaladores independientes y también admite PyPI, Homebrew, WinGet, Scoop, Docker, GitHub Releases y Cargo.

Si solo quieres instalarlo rápido, da prioridad al instalador independiente oficial. Si prefieres mantener la versión mediante el gestor de paquetes del sistema, usa Homebrew, WinGet o Scoop. Si ya acostumbras instalar herramientas de Python en entornos aislados, puedes usar pipx.

Elección rápida

Escenario	Método recomendado	Comando
Instalación rápida en macOS / Linux	Instalador independiente oficial	`curl -LsSf https://astral.sh/uv/install.sh \| sh`
macOS / Linux sin curl	Script oficial + wget	`wget -qO- https://astral.sh/uv/install.sh \| sh`
Instalación rápida en Windows	Instalador de PowerShell	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 \| iex"`
Instalación aislada de herramientas Python	pipx	`pipx install uv`
Instalación temporal o tradicional de Python	pip	`pip install uv`
Gestión de paquetes en macOS	Homebrew	`brew install uv`
Usuarios de MacPorts en macOS	MacPorts	`sudo port install uv`
Gestión de paquetes en Windows	WinGet	`winget install --id=astral-sh.uv -e`
Usuarios de Scoop en Windows	Scoop	`scoop install main/uv`
Usuarios de Rust	Cargo	`cargo install --locked uv`

Las opciones generales más recomendables son:

macOS / Linux: instalador independiente oficial;
Windows: instalador oficial de PowerShell o WinGet;
si ya gestionas herramientas CLI de Python con pipx: pipx install uv.

macOS y Linux: instalador oficial

El método oficial más directo consiste en descargar el script con curl y ejecutarlo con sh:

`1`	`curl -LsSf https://astral.sh/uv/install.sh \| sh`

Si el sistema no tiene curl, puedes usar wget:

`1`	`wget -qO- https://astral.sh/uv/install.sh \| sh`

Si quieres instalar una versión concreta, coloca el número de versión en la URL. Por ejemplo, el ejemplo oficial usa 0.11.11:

`1`	`curl -LsSf https://astral.sh/uv/0.11.11/install.sh \| sh`

Este método encaja con la mayoría de entornos personales de desarrollo. Es simple, multiplataforma y funciona mejor con el mecanismo oficial de actualización de uv.

El instalador coloca binarios como uv y uvx bajo el directorio del usuario, y puede modificar el shell profile para que los comandos puedan usarse directamente desde la terminal. Si no quieres que el instalador modifique PATH, revisa las opciones oficiales del installer, por ejemplo configurando UV_NO_MODIFY_PATH=1.

Windows: instalador de PowerShell

El método oficial en Windows es ejecutar el script de instalación con PowerShell:

`1`	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 \| iex"`

Para instalar una versión concreta, también puedes poner el número de versión en la URL:

`1`	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/0.11.11/install.ps1 \| iex"`

Aquí ExecutionPolicy ByPass permite obtener y ejecutar el script de instalación desde internet. Como hábito de seguridad, puedes revisar el contenido del script antes de ejecutarlo:

`1`	`powershell -c "irm https://astral.sh/uv/install.ps1 \| more"`

Si estás acostumbrado a gestores de paquetes de Windows, también puedes priorizar WinGet o Scoop.

Instalar con pipx

La documentación oficial indica que uv se publica en PyPI. Si lo instalas desde PyPI, se recomienda ponerlo en un entorno aislado, por ejemplo con pipx:

`1`	`pipx install uv`

Este método es adecuado si ya usas pipx como gestor de herramientas CLI de Python. Evita mezclar uv con el entorno del proyecto actual.

Si no tienes pipx, también puedes usar pip directamente:

`1`	`pip install uv`

Pero ten en cuenta que uv ofrece wheels precompilados en muchas plataformas. Si una plataforma no tiene un wheel compatible, se construirá desde código fuente, y en ese caso necesitarás una toolchain de Rust.

Mi recomendación: en una máquina personal, pipx install uv es más limpio que pip install uv; dentro de un entorno de proyecto, no recomiendo instalar uv como dependencia del proyecto.

Homebrew, MacPorts, WinGet y Scoop

Si prefieres gestores de paquetes del sistema, uv también admite canales comunes.

En macOS, usa Homebrew:

`1`	`brew install uv`

Los usuarios de MacPorts pueden usar:

`1`	`sudo port install uv`

En Windows, usa WinGet:

`1`	`winget install --id=astral-sh.uv -e`

Los usuarios de Scoop pueden usar:

`1`	`scoop install main/uv`

La ventaja de estos métodos es que delegan el mantenimiento en el gestor de paquetes del sistema. La desventaja es que el ritmo de actualización depende del origen de paquetes correspondiente, no del instalador oficial de uv.

Docker, GitHub Releases y Cargo

uv también ofrece imágenes Docker en GitHub Container Registry:

`1`	`ghcr.io/astral-sh/uv`

Esto sirve para CI, Dockerfiles, creación de imágenes y entornos temporales de ejecución. En uso real, conviene revisar también la documentación oficial de integración con Docker.

Si quieres descargar binarios manualmente, puedes hacerlo desde GitHub Releases. Cada página de release suele incluir binarios para las plataformas compatibles y explicar cómo llamar al instalador independiente usando una URL de GitHub.

Los usuarios de Rust también pueden instalar desde crates.io:

`1`	`cargo install --locked uv`

Pero este método compila desde código fuente y requiere una toolchain de Rust compatible. A menos que necesites instalarlo explícitamente desde el ecosistema Rust, los usuarios normales no tienen por qué elegir Cargo primero.

Actualizar uv

Si uv se instaló mediante el instalador independiente oficial, puedes usar el comando de autoactualización:

`1`	`uv self update`

La documentación oficial indica que actualizar uv vuelve a ejecutar el instalador y puede modificar el shell profile. Si no quieres que la actualización modifique PATH, configura:

`1`	`UV_NO_MODIFY_PATH=1`

Si lo instalaste de otra forma, debes actualizarlo con el gestor correspondiente. Por ejemplo, si lo instalaste con pip, usa:

`1`	`pip install --upgrade uv`

Homebrew, WinGet, Scoop y MacPorts también deben usar sus propios comandos de actualización.

Activar autocompletado de shell

uv admite autocompletado de shell. La documentación oficial recomienda comprobar primero cuál es tu shell actual:

`1`	`echo $SHELL`

Bash:

`1`	`echo 'eval "$(uv generate-shell-completion bash)"' >> ~/.bashrc`

Zsh:

`1`	`echo 'eval "$(uv generate-shell-completion zsh)"' >> ~/.zshrc`

fish:

`1`	`echo 'uv generate-shell-completion fish \| source' > ~/.config/fish/completions/uv.fish`

PowerShell:

if (!(Test-Path -Path $PROFILE)) {
  New-Item -ItemType File -Path $PROFILE -Force
}
Add-Content -Path $PROFILE -Value '(& uv generate-shell-completion powershell) | Out-String | Invoke-Expression'

Si también usas uvx con frecuencia, puedes activar el autocompletado de uvx por separado.

Bash:

`1`	`echo 'eval "$(uvx --generate-shell-completion bash)"' >> ~/.bashrc`

Zsh:

`1`	`echo 'eval "$(uvx --generate-shell-completion zsh)"' >> ~/.zshrc`

fish:

`1`	`echo 'uvx --generate-shell-completion fish \| source' > ~/.config/fish/completions/uvx.fish`

PowerShell:

if (!(Test-Path -Path $PROFILE)) {
  New-Item -ItemType File -Path $PROFILE -Force
}
Add-Content -Path $PROFILE -Value '(& uvx --generate-shell-completion powershell) | Out-String | Invoke-Expression'

Después de configurarlo, reinicia el shell o recarga el archivo de configuración correspondiente.

Desinstalar uv

Para desinstalar uv, primero puedes limpiar la caché y los datos gestionados por uv:

1
2
3

uv cache clean
rm -r "$(uv python dir)"
rm -r "$(uv tool dir)"

Después elimina los binarios.

macOS / Linux:

`1`	`rm ~/.local/bin/uv ~/.local/bin/uvx`

Windows:

1
2
3

rm $HOME\.local\bin\uv.exe
rm $HOME\.local\bin\uvx.exe
rm $HOME\.local\bin\uvw.exe

La documentación oficial también recuerda que antes de 0.5.0, uv se instalaba en ~/.cargo/bin. Si actualizaste desde una versión antigua, es posible que los binarios viejos sigan allí y debas eliminarlos manualmente.

Qué hacer después de instalar

Después de instalar, conviene confirmar primero la versión:

`1`	`uv --version`

Luego puedes empezar con algunas tareas comunes:

uv python install
uv venv
uv pip install requests
uvx ruff --version

Si es un proyecto nuevo, puedes seguir aprendiendo:

uv init: inicializar un proyecto;
uv add: añadir dependencias;
uv sync: sincronizar el entorno;
uv run: ejecutar comandos dentro del entorno del proyecto;
uvx: ejecutar temporalmente herramientas CLI de Python.

Mi recomendación

En una máquina personal de desarrollo, prioriza el instalador independiente oficial, porque es el método más alineado con la documentación oficial de uv y admite uv self update.

Si usas Windows y no quieres ejecutar un script remoto, puedes usar WinGet o Scoop. Si usas macOS y prefieres que todas tus herramientas las gestione Homebrew, puedes usar directamente brew install uv.

Quienes ya gestionan herramientas CLI de Python con pipx pueden usar pipx install uv. Pero no recomiendo ejecutar pip install uv dentro del entorno virtual de un proyecto concreto, porque eso mezcla la toolchain con las dependencias del proyecto.

Si se trata de CI o construcción de contenedores, revisa primero Docker y GitHub Releases, y fija la versión según el flujo de creación de la imagen.

Enlaces relacionados

Documentación de instalación de uv: https://docs.astral.sh/uv/getting-started/installation/
uv First steps: https://docs.astral.sh/uv/getting-started/first-steps/
Integración de uv con Docker: https://docs.astral.sh/uv/guides/integration/docker/
uv GitHub Releases: https://github.com/astral-sh/uv/releases

Awesome Codex Skills: un catalogo comunitario para ampliar Codex CLI

Thu, 07 May 2026 20:19:15 +0800

awesome-codex-skills, de ComposioHQ, es un catalogo comunitario de skills para Codex CLI. Su valor no esta en ser otra pila de plantillas de prompts, sino en ofrecer una forma de empaquetar flujos repetibles como Skills instalables, reutilizables y mantenibles.

Si ya usas Codex como parte del desarrollo diario, este tipo de repositorio resulta util de inmediato: reglas, comandos, materiales de referencia y pasos operativos que antes tenias que explicar una y otra vez pueden escribirse una vez y reutilizarse cada vez que se invoque la Skill correspondiente.

Que resuelve este repositorio

Las Codex Skills pueden entenderse como modos de trabajo especializados para Codex CLI. Un prompt normal sirve bien para una instruccion temporal; una Skill encaja mejor con algo que quieres reutilizar durante mucho tiempo.

Por ejemplo, puede que a menudo necesites:

generar mensajes de commit con un formato fijo;
consultar una familia especifica de documentacion de API;
ejecutar comandos de pruebas y despliegue propios de un proyecto;
reescribir articulos, traducir documentos u organizar notas segun reglas del equipo;
llamar herramientas externas para tareas de desarrollo repetitivas.

Escribir estas instrucciones cada vez se convierte rapidamente en sobrecarga. Una Skill coloca las reglas en un directorio independiente. El nucleo suele ser un archivo SKILL.md, a veces acompanado de scripts, plantillas, documentos de referencia o assets. Cuando Codex se activa, lee las instrucciones y sigue el flujo descrito alli.

En que se diferencia de un prompt

Un prompt se parece mas a una instruccion puntual: “haz esta tarea de esta forma”. Una Skill se parece mas a un pequeno manual operativo: “cuando aparezca esta clase de tarea, trabaja de esta manera”.

Sus principales ventajas son:

Reutilizable: los flujos comunes ya no necesitan preparacion por copy-and-paste.
Revisable: los archivos de skill suelen ser Markdown locales que pueden abrirse, editarse y versionarse.
Extensible: las skills complejas pueden incluir scripts, plantillas y referencias, no solo instrucciones en lenguaje natural.

Por eso catalogos como awesome-codex-skills son utiles: ayudan a descubrir skills existentes y luego adaptarlas a tu propio flujo de trabajo.

Instalacion y uso

El repositorio ofrece un script de instalacion y tambien soporta instalacion manual. Un flujo tipico es:

1
2
3

git clone https://github.com/ComposioHQ/awesome-codex-skills.git
cd awesome-codex-skills
python install.py

Si solo quieres probar algunas skills, lee primero el SKILL.md de cada directorio. Revisa que lee, que scripts puede ejecutar, que archivos puede editar y si los valores por defecto encajan con tu entorno local.

Despues de instalar, Codex puede detectar skills cuando la tarea las necesita, o puedes nombrar una skill de forma explicita. Para uso a largo plazo, el enfoque mas practico suele ser instalar primero una skill comunitaria y despues reescribir sus instrucciones alrededor de las convenciones de tu proyecto.

Que skills merece la pena observar

Las skills mas valiosas no son necesariamente las que tienen los nombres mas llamativos. Son las que eliminan trabajo repetido de forma fiable.

Yo miraria primero:

Skills de flujo de desarrollo: review, pruebas, commits, releases, comprobacion de dependencias.
Skills de documentacion: reescritura, traduccion, resumen, organizacion estructurada.
Skills de integracion de herramientas: conectar Codex con servicios externos, APIs y herramientas CLI.
Skills de convenciones de proyecto: codificar reglas del equipo, estructura de directorios, convenciones de nombres y pasos de despliegue.

Si una skill solo envuelve un prompt de una frase, su valor es limitado. Si puede conectar investigacion, juicio, ejecucion, verificacion y salida en un flujo estable, merece conservarse.

Puntos de cuidado

Las skills comunitarias son comodas, pero no deberian tratarse como cajas negras. Esto es especialmente cierto para Skills que incluyen scripts. Antes de instalar una, revisa:

que le pide SKILL.md a Codex;
si incluye scripts que acceden a la red, leen o escriben archivos, o llaman servicios externos;
si las rutas, comandos y permisos por defecto encajan con tu maquina.

Una Skill amplia lo que Codex puede hacer. Bien escrita, hace que Codex se sienta mas como un companero que conoce tu proyecto. Escrita con descuido, puede traer reglas inadecuadas a tu flujo de trabajo. El mejor patron no es instalar muchas skills, sino mantener un conjunto pequeno, ajustarlas con cuidado y conservarlas con el tiempo.

Mi lectura

awesome-codex-skills merece guardarse en favoritos, especialmente si ya usas Codex CLI para desarrollo real, documentacion o automatizacion. No es una capacidad oficial por si misma; es un punto de entrada comunitario para encontrar y adaptar flujos reutilizables.

Para usuarios intensivos, el punto de Codex Skills no es simplemente ayudar a la IA a recordar mas. Es ayudar a la IA a dar menos rodeos en tareas repetidas. Escribir reglas como Skills convierte instrucciones temporales en infraestructura de trabajo reutilizable.

Warp Open Source: de terminal a entorno de desarrollo agentico

Thu, 07 May 2026 20:15:08 +0800

warpdotdev/warp es el repositorio open source del cliente de Warp. Warp se describe ahora como un “entorno de desarrollo agentico, nacido del terminal”: parte del terminal, pero lleva agentes de programacion con IA, indexacion de codebase, gestion de tareas y flujos de desarrollo a un solo entorno.

No es un repositorio open source ordinario de emulador de terminal. Se parece mas a una respuesta a una pregunta mayor: cuando agentes como Claude Code, Codex y Gemini CLI se vuelven comunes, deberia el propio terminal convertirse en un entorno de desarrollo para planificar, observar y gestionar agentes?

La respuesta de Warp es si.

Estado actual del repositorio

Al 7 de mayo de 2026, warpdotdev/warp es un repositorio publico. GitHub muestra alrededor de 56k stars y 4.1k forks. El README dice que el codigo del cliente Warp ahora es open source y da la bienvenida a contribuciones de la comunidad.

El lenguaje principal es Rust. El desglose de lenguajes de GitHub muestra Rust por encima del 98%, lo que encaja con el posicionamiento de Warp: no es un wrapper web, sino una herramienta de desarrollo nativa y multiplataforma.

Varios detalles del README importan:

Warp es un entorno de desarrollo agentico, nacido del terminal.
Puede usar su agente de programacion integrado y tambien conectar con agentes CLI externos como Claude Code, Codex y Gemini CLI.
OpenAI es el patrocinador fundador del repositorio Warp recien abierto.
Los flujos de gestion agentica del repositorio estan impulsados por modelos GPT.
Los crates del framework de UI de Warp usan licencia MIT, mientras que el resto del codigo usa AGPL v3.

Esto muestra que el movimiento open source de Warp no consiste solo en publicar un terminal. Esta operando el proyecto como un campo de pruebas para flujos de trabajo con agentes.

Warp es mas que un terminal

Los terminales tradicionales hacen principalmente tres cosas:

iniciar una shell;
ejecutar comandos;
mostrar salida.

La diferenciacion inicial de Warp era hacer que el terminal se sintiera mas moderno: bloques de comandos, autocompletado, historial, colaboracion, interacciones con estilo de UI y pulido multiplataforma. Ahora el foco se ha desplazado mas hacia organizar el desarrollo alrededor de agentes de IA.

Segun el README, Warp ya no enfatiza solo “un mejor terminal”. Enfatiza:

agentes de programacion integrados;
soporte para agentes CLI externos;
triage de issues;
escritura de especificaciones;
revision de PR;
coordinacion de contribuidores;
sesiones de agentes observables.

En otras palabras, Warp quiere convertir el terminal de “donde escribes comandos” en “donde trabajas con multiples agentes”.

Oz y gestion de proyectos open source

El README menciona Oz varias veces.

La vista de contribucion de Warp muestra miles de agentes Oz trabajando en triage de issues, especificaciones, implementacion y revision de PR. Esto es interesante porque extiende los agentes de IA desde “ayudar a una persona a escribir codigo” hasta “ayudar a gestionar colaboracion open source”.

La parte mas dificil de muchos proyectos open source no es escribir codigo, sino mantener:

demasiados issues y poca clasificacion;
bugs y feature requests mezclados;
nuevos contribuidores sin saber que tareas son abordables;
presion de revision de PR;
maintainers intentando seguir cada hilo de comunidad.

La idea de Warp es dejar que los agentes asuman primero parte del trabajo de gestion de proyecto y colaboracion. El README tambien menciona Oz for OSS, un programa orientado a maintainers para llevar flujos similares de gestion open source agentica a otros repositorios.

Esto sugiere que la ambicion de Warp no es solo el producto terminal, sino tambien un nuevo modelo de mantenimiento open source en la era de la IA.

Estructura del repositorio y stack tecnico

Por la estructura del repositorio, Warp es un proyecto Rust grande.

La raiz contiene:

app/: codigo principal de la aplicacion.
crates/: crates Rust centrales.
assets/: archivos de recursos.
command-signatures-v2/: contenido relacionado con firmas de comandos.
docker/, script/, resources/, specs/ y otros directorios de ingenieria.
.claude/, .warp/, .agents/skills y otras configuraciones relacionadas con agentes.

WARP.md aporta mas detalle de ingenieria. Describe Warp como un emulador de terminal basado en Rust que usa un framework de UI interno llamado WarpUI.

Los modulos principales pueden entenderse aproximadamente asi:

app/: emulacion de terminal, gestion de shell, integracion de IA, Drive, autenticacion, ajustes, workspace y sesiones.
crates/warp_core/: utilidades centrales y abstraccion de plataforma.
crates/editor/: funcionalidad de edicion de texto.
crates/warpui/ y crates/warpui_core/: framework de UI interno.
crates/ipc/: comunicacion entre procesos.
crates/graphql/: cliente GraphQL y esquema.

WARP.md tambien menciona rasgos arquitectonicos como:

un sistema Entity-Handle;
una estructura modular de workspace;
targets para macOS, Windows, Linux y WASM;
integracion de IA, incluyendo Agent Mode, conciencia de contexto e indexacion de codebase;
sincronizacion cloud Warp Drive.

Esta complejidad esta mas cerca de un IDE completo que de un terminal tradicional ligero.

Comandos de build local

El README da un flujo local conciso:

1
2
3

./script/bootstrap
./script/run
./script/presubmit

Donde:

./script/bootstrap realiza la inicializacion especifica de la plataforma.
./script/run compila y ejecuta Warp.
./script/presubmit ejecuta formato, clippy, tests y otras comprobaciones previas al envio.

WARP.md tambien lista comandos mas detallados:

cargo run
cargo bundle --bin warp
cargo nextest run --no-fail-fast --workspace --exclude command-signatures-v2
cargo fmt
cargo clippy --workspace --all-targets --all-features --tests -- -D warnings

Si quieres contribuir a Warp, ./script/presubmit es practicamente obligatorio.

Flujo de contribucion

El flujo de contribucion de Warp no es simplemente “abre un PR”.

El README describe un proceso ligero desde issue hasta PR:

Buscar primero issues existentes.
Si no hay duplicado, abrir un bug o feature request.
Los maintainers revisan el issue y pueden anadir etiquetas de preparacion.
ready-to-spec significa que el diseno puede expandirse en una especificacion.
ready-to-implement significa que el diseno esta lo bastante claro para empezar un PR de implementacion.
Los contribuidores pueden tomar issues etiquetados.

Este proceso encaja con un proyecto open source grande. Separa ideas, diseno e implementacion, reduciendo el riesgo de que los contribuidores pasen tiempo construyendo en una direccion equivocada.

Tambien encaja bien con agentes de IA. Un agente puede organizar issues, redactar specs, anadir tests y luego pasar a implementacion. Warp usa este patron para demostrar gestion de proyecto agentica.

Licencia: MIT + AGPL v3

Warp usa una estructura de doble licencia.

El README dice:

el framework de UI de Warp, concretamente los crates warpui_core y warpui, usa licencia MIT;
el resto del repositorio usa AGPL v3.

Esto importa. AGPL v3 tiene requisitos open source mas fuertes para servicios de red y distribucion. Si estas aprendiendo, investigando o contribuyendo, normalmente es sencillo. Pero si quieres usar codigo de Warp en un producto comercial o en un derivado closed-source, debes leer la licencia con cuidado y consultar asesoria legal si hace falta.

En resumen, Warp es open source, pero no es open source de “tomalo y cierralo libremente”.

Por que merece atencion

Primero, Warp une terminal, agentes y gestion de proyecto.

Muchas herramientas de programacion con IA siguen siendo CLI o plugins de editor. Warp parte del punto de entrada del terminal e intenta unificar tareas de agentes, ejecucion de codigo, salida de comandos, flujos de PR y colaboracion de equipo.

Segundo, el enfoque open source de Warp es un buen lugar para observar flujos con agentes.

No solo publica codigo. Tambien expone vistas de contribucion, sesiones de agentes, triage de issues y flujos de especificacion. Para cualquiera que estudie como la IA puede participar en colaboracion open source, el propio repositorio es una muestra.

Tercero, Warp es una aplicacion de escritorio Rust compleja.

Si quieres estudiar GUI en Rust, emulacion de terminal, apps multiplataforma, clientes GraphQL, sincronizacion cloud e integracion de IA, el repositorio tiene mucho que leer. Pero no es un proyecto pequeno, asi que los nuevos contribuidores deberian leer primero la documentacion y el proceso de issues.

Cuarto, Warp soporta tanto un agente integrado como un enfoque “trae tu propio agente CLI”.

Esto es realista. Los desarrolladores no usaran un solo agente. Claude Code, Codex, Gemini CLI, OpenCode, OpenClaw y herramientas similares probablemente coexistiran. Si Warp puede convertirse en un banco de trabajo para ellos, se vuelve mas valioso que un terminal de proposito unico.

A quien deberia importarle

Si eres un usuario normal de terminal, Warp importa porque el terminal puede estar cambiando de herramienta de linea de comandos a banco de trabajo con IA.

Si eres usuario intensivo de agentes de programacion con IA, Warp merece seguimiento porque intenta gestionar multiples agentes en vez de actuar como otro punto de entrada de chat.

Si mantienes proyectos open source, la direccion de Oz for OSS merece atencion. Explora triage de issues con agentes, revision de PR, colaboracion comunitaria e incorporacion de contribuidores.

Si eres desarrollador Rust, Warp es una aplicacion de escritorio real y de gran escala que merece estudiarse por organizacion de UI, internals de terminal, sincronizacion cloud, integracion de IA y codigo multiplataforma.

Si solo quieres un terminal que pueda reemplazar al actual de inmediato, es mejor descargar primero la version estable y despues decidir si estudiar el codigo fuente. Compilar desde codigo es mas adecuado para contribuidores y usuarios profundos.

Lectura breve

El punto de que Warp se vuelva open source no es simplemente “un terminal moderno se hizo open source”.

Mas precisamente, Warp intenta actualizar el terminal hasta convertirlo en un entorno de desarrollo agentico: el terminal conecta shell, codebase, ejecucion de comandos, agentes, issues, PRs y flujo de colaboracion.

A medida que los agentes de programacion con IA sigan creciendo, el punto de entrada del entorno de desarrollo puede cambiar. Antes, el IDE dominaba la experiencia del desarrollador mientras el terminal ejecutaba comandos. Ahora el terminal puede convertirse en el centro de colaboracion con agentes. El repositorio de Warp explora esa posibilidad.

Enlaces relacionados

GitHub repository: https://github.com/warpdotdev/warp
Warp website: https://www.warp.dev
Warp documentation: https://docs.warp.dev
Warp build overview: https://build.warp.dev
WARP.md: https://github.com/warpdotdev/warp/blob/master/WARP.md
CONTRIBUTING.md: https://github.com/warpdotdev/warp/blob/master/CONTRIBUTING.md

Primeros pasos con la compilación de programas UEFI: desde uefi-simple hasta su primer .EFI

Thu, 30 Apr 2026 19:53:08 +0800

Compilar su primer programa UEFI no es precisamente sencillo. La configuración del entorno puede llevar tiempo, los errores del vinculador son comunes y un programa .EFI no tiene la misma experiencia directa de edición y ejecución que una aplicación de escritorio normal.

Este artículo organiza el tema desde la perspectiva de un principiante: si sólo desea compilar su primer programa UEFI, ¿por dónde debería empezar, qué conceptos importan primero y qué errores es más probable que aparezcan?

¿Qué es un programa UEFI?

Un programa UEFI suele ser un archivo .EFI.

No es un .exe ordinario en el que se hace doble clic en Windows. Es un ejecutable PE/COFF que se ejecuta dentro del entorno de firmware UEFI. Los casos de uso comunes incluyen:

Gestores de arranque
Herramientas de inicialización de hardware.
Herramientas de actualización de firmware
Herramientas de diagnóstico previas al arranque
Flujos de arranque personalizados

Muchas funciones que ve al principio del proceso de inicio del sistema pueden estar relacionadas con aplicaciones, controladores o servicios de firmware UEFI.

Para los principiantes, no es necesario comprender inmediatamente el desarrollo completo del firmware. El primer objetivo es simple: compilar un archivo .EFI que pueda cargarse mediante un UEFI Shell o un emulador.

¿Por qué no empezar con EDK II?

El desarrollo real de UEFI a menudo implica EDK II.

EDK II es completo y más cercano a la ingeniería de firmware real, pero no es muy amigable para principiantes:

La estructura del proyecto es compleja.
El sistema de construcción tiene una curva de aprendizaje.
Las variables de entorno y la configuración de la cadena de herramientas implican muchos detalles.
Los errores del compilador no siempre son fáciles de entender.
Es fácil quedarse atascado en el entorno antes de escribir cualquier código.

Si el objetivo es simplemente ejecutar un programa UEFI mínimo, un ejemplo ligero es un mejor punto de partida.

pbatard/uefi-simple es uno de esos proyectos. Su objetivo es sencillo: proporcionar un ejemplo UEFI Hello World sencillo para que puedas compilar un archivo .EFI primero.

¿Para qué sirve `uefi-simple`?

uefi-simple es un buen primer paso para los principiantes en UEFI.

Resuelve tres problemas prácticos:

Le brinda una estructura de aplicación UEFI mínima y compilable.
Evita la complejidad de grandes proyectos de firmware al principio
Le permite verificar que compilar, vincular y ejecutar todo funciona.

El proyecto admite múltiples métodos de compilación, incluidos Visual Studio 2022 y MinGW/gcc. También se puede probar con QEMU y OVMF.

En otras palabras, no es necesario reiniciar repetidamente una máquina real para los primeros experimentos. Ejecutar primero el programa en un emulador es mucho más seguro.

Qué preparar antes de comenzar

Necesita al menos algunas categorías de herramientas.

La primera categoría es la cadena de herramientas del compilador.

En Windows, puedes comenzar con:

Estudio Visual 2022
O MinGW/gcc

La segunda categoría es un entorno de ejecución UEFI.

Hay dos opciones comunes:

Ejecute el archivo .EFI en UEFI Shell de una máquina real
Pruébalo en un entorno virtual con QEMU + OVMF

La tercera categoría es un proyecto de ejemplo.

Los principiantes no deberían empezar escribiendo scripts de compilación desde un directorio vacío. Usar un ejemplo mínimo como uefi-simple ayuda a evitar muchos problemas del sistema de compilación.

Flujo de trabajo básico

Un flujo de trabajo mínimo de un programa UEFI se puede entender así.

Primero, obtenga el proyecto de ejemplo.

`1`	`git clone https://github.com/pbatard/uefi-simple.git`

En segundo lugar, elija una cadena de herramientas de compilación. Si usa Visual Studio, cree con la solución Visual Studio en el proyecto.
Si usa MinGW/gcc, siga el Makefile o las instrucciones proporcionadas por el proyecto.

En tercer lugar, genere el archivo .EFI.

El punto clave aquí es confirmar la arquitectura de destino. Una PC común suele ser x86_64, es decir, un entorno UEFI de 64 bits.

Cuarto, coloque el archivo .EFI en algún lugar al que pueda acceder UEFI Shell.

En una máquina real, esto normalmente significa preparar una partición FAT32 o una unidad USB.
Con QEMU, puede montar un directorio o una imagen de disco.

Quinto, ejecútelo en UEFI Shell.

El resultado suele ser un resultado mínimo, como un mensaje estilo Hola mundo.

Donde los principiantes suelen quedarse estancados

La parte más difícil de compilar un programa UEFI no suele ser el lenguaje C en sí, sino el entorno y el proceso de vinculación.

Los problemas comunes incluyen:

Arquitectura de compilador incorrecta
Formato de destino incorrecto
Parámetros del enlazador incompletos
Falta el punto de entrada UEFI
Generar un ejecutable ordinario en lugar de un .EFI cargable por UEFI
QEMU u OVMF no configurados correctamente
Arranque seguro en una máquina real que bloquea un programa no firmado

Los errores del vinculador son especialmente fáciles de malinterpretar como problemas de código.
En muchos casos, el verdadero problema es la función de entrada, el subsistema, la arquitectura de destino o el script del vinculador.

Entonces, en la primera etapa, no se apresure a entrar en una lógica compleja. Asegúrese de que el ejemplo original se pueda compilar y ejecutar, luego cambie la salida poco a poco.

¿Por qué utilizar QEMU + OVMF para realizar pruebas?

Es posible probar programas UEFI en una máquina real, pero no es conveniente en la etapa principiante.

Es posible que tengas que repetir este ciclo:

compilar
Copiar a una unidad USB
Reiniciar
Ingrese al UEFI Shell
Ejecutar el programa
Registra el error
Regresar al sistema y modificar el código.

Ese bucle es lento.

QEMU + OVMF le permite simular un entorno UEFI directamente dentro del sistema operativo. Puede verificar si un archivo .EFI se carga más rápidamente y es menos probable que afecte sus entradas de arranque reales.

Una vez que el programa funciona básicamente, probarlo en una máquina real es mucho más manejable.

¿Qué deberían modificar primero los principiantes?

Si ya ha compilado su primer .EFI con el proyecto de ejemplo, no salte a funciones complejas de inmediato.

Un mejor orden es:

Cambie primero el texto de salida para confirmar que la recompilación realmente surte efecto.
Intente leer información sencilla proporcionada por UEFI.
Comprender la función de entrada, protocolo de salida y servicios básicos.
Luego considere funciones más complejas, como sistemas de archivos, salida gráfica o administración de entradas de arranque.

Este enfoque hace que cada paso sea verificable.
Si cambia demasiado a la vez, resulta difícil saber si el problema está en el código, el proceso de compilación o el entorno de ejecución.

¿En qué se diferencia de un programa C normal?

Aunque los programas UEFI se pueden escribir en C, su entorno de ejecución es completamente diferente al de los programas C normales.

Un programa C normal normalmente se ejecuta dentro de un sistema operativo y puede depender de la biblioteca, el sistema de archivos, el modelo de proceso y las llamadas al sistema estándar.

Un programa UEFI se ejecuta antes de que se inicie el sistema operativo. Se basa en los servicios proporcionados por el firmware UEFI. Muchas cosas a las que está acostumbrado en los programas normales no están disponibles aquí automáticamente. Al escribir programas UEFI, es necesario adaptarse a varias diferencias:

La función de entrada es diferente.
La salida funciona de manera diferente
Las bibliotecas disponibles son diferentes.
El acceso a la memoria y a los archivos funciona de forma diferente
La depuración funciona de manera diferente

Es por esto que partir de un ejemplo mínimo es mejor que escribir código como si fuera un programa C normal.

Un camino de aprendizaje práctico

Para principiantes, un camino realista es el siguiente:

Paso 1: compilar uefi-simple
Paso 2: Ejecútelo con QEMU + OVMF
Paso 3: Modificar la salida de Hola Mundo
Paso 4: Comprenda cómo UEFI Shell carga .EFI
Paso 5: aprenda la función de entrada UEFI y el protocolo de salida básico
Paso 6: Luego lea EDK II o material de desarrollo UEFI más completo

El objetivo de este camino es construir primero un circuito de retroalimentación que funcione.

Una vez que pueda generar un .EFI desde la fuente y ver el resultado en un entorno UEFI, ya habrá cruzado el primer umbral más difícil.

Referencias

-pbatard/uefi-simple

[Zhihu: material de compilación del programa UEFI] (https://zhuanlan.zhihu.com/p/643704056)

Pensamiento final

La parte difícil de compilar su primer programa UEFI generalmente no es escribir un poco de código C, sino conectar la cadena de herramientas, el formato de enlace y el entorno de ejecución.

No se apresure a utilizar funciones complejas.
Comience con un ejemplo mínimo como “uefi-simple”, obtenga primero un “.EFI” ejecutable y luego comprenda gradualmente los puntos de entrada, protocolos y métodos de compilación de UEFI.

Notas más recientes sobre la compilación desde el código fuente de GoAccess: desde la instalación del código fuente hasta los informes HTML en tiempo real

Wed, 29 Apr 2026 00:08:00 +0800

Esto está organizado para el 2026-04-29.
En este punto, la última versión estable que figura en el archivo README oficial es “1.10.2”.

1. Instale primero las dependencias de compilación

1
2
3

sudo apt-get update
sudo apt-get install -y build-essential wget tar \
  libncurses-dev libmaxminddb-dev libssl-dev zlib1g-dev

2. Descargue el paquete fuente más reciente

cd /usr/local/src
sudo wget https://tar.goaccess.io/goaccess-1.10.2.tar.gz
sudo tar -xzvf goaccess-1.10.2.tar.gz
cd goaccess-1.10.2

3. Configurar las opciones de compilación

`1`	`sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib`

Si también desea compatibilidad con TLS para informes HTML en tiempo real:

`1`	`sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib --with-openssl`

4. Construir e instalar

1
2

sudo make
sudo make install

5. Verificar la versión

1
2

goaccess --version
which goaccess

6. Ver informes directamente en la terminal

Para registros combinados comunes de Nginx o Apache:

`1`	`goaccess /var/log/nginx/access.log --log-format=COMBINED`

Si la ruta del registro es Apache:

`1`	`goaccess /var/log/apache2/access.log --log-format=COMBINED`

7. Generar un informe HTML estático

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html

También puedes escribirlo en el directorio actual:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o report.html

8. Genere un informe HTML en tiempo real

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html

Para cambiar el puerto:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html \
  --port=7891

Para vincularse solo a localhost:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html \
  --addr=127.0.0.1

9. Siga los registros continuamente

`1`	`tail -f /var/log/nginx/access.log \| goaccess --log-format=COMBINED -`

Desde el principio del archivo y mantenlo activo:

tail -f -n +0 /var/log/nginx/access.log | goaccess \
  --log-format=COMBINED \
  -o report.html \
  --real-time-html -

10. Mire solo ciertas solicitudes

Por ejemplo, solo solicitudes que contengan firefox:

1
2

tail -f /var/log/nginx/access.log | grep -i --line-buffered 'firefox' | goaccess \
  --log-format=COMBINED -

Por ejemplo, sólo 5xx y 3xx:

1
2
3

tail -f -n +0 /var/log/nginx/access.log | awk '$9~/3[0-9]{2}|5[0-9]{2}/' | goaccess \
  --log-format=COMBINED \
  -o out.html -

11. Analizar varios registros juntos

`1`	`goaccess /var/log/nginx/access.log /var/log/nginx/access.log.1 --log-format=COMBINED`

Lea registros comprimidos y sin comprimir juntos:

`1`	`zcat --force /var/log/nginx/access.log* \| goaccess --log-format=COMBINED -`

12. Habilitar subprocesos múltiples

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -o report.html \
  -j 4

Aumentar el tamaño del trozo:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -o report.html \
  -j 4 \
  --chunk-size=8192

13. Procesamiento incremental

Primero persista en un registro antiguo:

`1`	`goaccess /var/log/nginx/access.log.1 --log-format=COMBINED --persist`

Luego agregue el registro actual:

`1`	`goaccess /var/log/nginx/access.log --log-format=COMBINED --restore --persist`

Solo lectura de datos persistentes:

`1`	`goaccess --restore`

14. El conjunto de comandos que ejecutaría primero

sudo apt-get update
sudo apt-get install -y build-essential wget tar \
  libncurses-dev libmaxminddb-dev libssl-dev zlib1g-dev

cd /usr/local/src
sudo wget https://tar.goaccess.io/goaccess-1.10.2.tar.gz
sudo tar -xzvf goaccess-1.10.2.tar.gz
cd goaccess-1.10.2
sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib --with-openssl
sudo make
sudo make install

goaccess --version

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html

Básicamente eso es todo.
Si su objetivo es claro, instalar la última versión fuente y hacer que --log-format=COMBINED más --real-time-html funcione primero suele ser suficiente. Después de eso, la mayoría de los cambios se refieren solo a rutas de registro, archivos de salida y puertos.

Cómo elegir un entorno de desarrollo embebido en 2026: Keil, STM32CubeIDE, VS Code y colaboración AI

Wed, 22 Apr 2026 23:05:00 +0800

Si todavía trabajas con microcontroladores o sistemas embebidos, pronto aparece una pregunta práctica: en 2026, cuando la programación asistida por AI se ha vuelto común, ¿qué entorno de desarrollo tiene sentido?

En la superficie parece una comparación entre varios IDEs. Pero en realidad pregunta otra cosa: ¿quieres una herramienta que simplemente haga correr el proyecto, o un workflow que equilibre compatibilidad de ecosistema, experiencia de programación y colaboración AI?

Desde ese ángulo, la respuesta normalmente no es elegir uno entre Keil, STM32CubeIDE, VS Code y CLion, sino recombinar lo que cada uno hace mejor.

Primero mira las opciones principales y qué resuelve cada una

En desarrollo embebido, los nombres familiares siguen siendo casi los mismos:

Keil
STM32CubeIDE
VS Code
CLion

Si vas aún más atrás, la gente mencionará IAR. Pero para esta discusión importa menos quién tiene el linaje más antiguo y más quién encaja realmente con la realidad actual del desarrollo.

Keil: ecosistema fuerte, entrada fiable, pero edición claramente anticuada

Keil sigue siendo difícil de evitar, y la razón es simple: está en todas partes.

Ya sea en proyectos legacy de empresas, tutoriales online, ejemplos compartidos o codebases antiguas, una enorme cantidad de trabajo embebido sigue organizada alrededor de Keil. Su flujo de build, descarga y debug sigue siendo maduro, y si tu objetivo principal es hacer correr código en una placa, sigue siendo un camino corto.

Sus problemas son igual de obvios:

interfaz anticuada
experiencia de edición promedio
no es un hogar natural para programación asistida por AI

Así que Keil se siente más como punto de entrada de proyecto y base de depuración que como editor ideal para una experiencia de programación en 2026.

STM32CubeIDE: amigable para STM32, pero más herramienta de aprendizaje e inicio rápido

Si vives principalmente en el ecosistema STM32, STM32CubeIDE suele ser el primer entorno que tocas.

Sus fortalezas son claras:

onboarding amigable para principiantes
configuración de periféricos y generación de proyectos cómoda
cadena de debug bastante completa

Para estudiantes, principiantes e inicio temprano de proyectos, la experiencia es directa y suficiente.

Pero al entrar en proyectos largos, colaboración pesada y workflows personalizados, sus limitaciones se hacen más visibles. En trabajo comercial o entornos de equipo más complejos, puede no ser el entorno primario más cómodo.

Encaja mejor como herramienta all-in-one centrada en STM32 para comenzar rápido que como editor primario a largo plazo.

VS Code: no es realmente un IDE, pero gana fuerza en la era AI

Estrictamente, VS Code no es un IDE tradicional. Más exactamente, es un editor extensible.

Eso le da una naturaleza dual.

Sus debilidades:

necesita plugins y configuración
no es suficientemente amable para principiantes
no reemplaza de entrada todo el flujo de un IDE embebido

Pero sus fortalezas vienen del mismo lugar:

gran extensibilidad
experiencia de programación mucho más moderna
mejor resaltado, navegación, búsqueda y refactorización
más impulso alrededor de herramientas AI y flujos de agentes

En esta etapa, muchos desarrolladores ya no quieren solo algo para escribir código. Quieren saber si la colaboración AI encaja naturalmente en el mismo entorno. Desde esa perspectiva, la ventaja de VS Code es difícil de ignorar.

CLion: buena experiencia, pero no suficientemente central en práctica embebida

CLion aparece a menudo porque su experiencia C/C++ lleva tiempo considerándose sólida.

Pero para muchos desarrolladores embebidos, la pregunta no es si es bueno. La pregunta es si vale la pena cambiar:

relativamente menos gente lo usa en workflows embebidos
no se conecta tan directamente con ecosistemas de proyectos embebidos existentes como Keil
quizá no ofrece una ventaja de colaboración AI más práctica que VS Code

Así que se siente más como una opción teóricamente buena que como el centro más natural de un workflow embebido mainstream hoy.

Una respuesta más práctica: Keil para build/debug, VS Code para programar

Si separas estas herramientas por rol, aparece una conclusión mucho más pragmática:

usar Keil para preservar compatibilidad de proyectos existentes, build, flashing y debugging
usar VS Code para programación diaria, búsqueda, navegación y colaboración AI

El valor de esta combinación es que no intenta forzar una herramienta a hacerlo todo. Devuelve cada herramienta al rol donde es mejor.

Para muchos proyectos embebidos, el ecosistema Keil simplemente no es opcional. Si eso es cierto, en lugar de forzar todo de vuelta a Keil, tiene más sentido tratarlo como backend de build y debug, y entregar la experiencia real de edición a VS Code.

Por qué esta combinación tiene más sentido en la era AI

Hoy, la línea divisoria entre entornos ya no es solo si el editor se siente fluido. Es si la AI puede conectarse naturalmente al workflow.

VS Code tiene varias fortalezas prácticas:

soporte más activo para plugins y agentes AI
experiencia de exploración de código más adecuada para que AI lea y modifique proyectos
integración más fácil con ecosistemas modernos de plugins

Eso significa que algunas de las partes más incómodas del desarrollo embebido pueden empezar a descargarse en AI:

encontrar funciones y call chains en un proyecto existente
generar rápidamente código de inicialización
añadir un print UART simple
explicar la estructura de proyectos antiguos
hacer ediciones pequeñas y localizadas en archivos existentes

Estas tareas nunca fueron imposibles. Solo eran incómodas. El significado de VS Code no es solo que se vea mejor, sino que puede convertirse más naturalmente en el banco de trabajo para colaboración AI.

El parche clave: conectar VS Code con proyectos Keil mediante plugins

Que este workflow funcione en la práctica depende de algo: ¿puedes conectar realmente VS Code con un proyecto Keil?

Una clase muy práctica de plugins hace exactamente eso, permitiendo que VS Code lea la estructura de proyecto Keil y llame a programas backend de Keil desde el editor para tareas como:

abrir un proyecto
compilar
descargar

Así no tienes que saltar constantemente entre dos interfaces solo para escribir código. Solo vuelves a Keil para trabajo de depuración pesado, como stepping, breakpoints e inspección de registros.

El valor real de estos plugins no es ahorrar unas ventanas. Es hacer continuo el workflow.

No olvides la configuración básica de plugins C/C++

Si quieres usar VS Code como editor embebido principal, hay un punto básico que suele ignorarse: debes configurar correctamente el plugin C/C++ central y el indexado del proyecto.

Si no, aparecerán problemas que dañan mucho la experiencia:

jump-to-definition no funciona
aparecen subrayados rojos falsos
la calidad de completion es pobre
las relaciones de headers se vuelven confusas

Mucha gente asume que eso significa que VS Code no sirve para embebido. En la práctica, a menudo solo ocurre que el indexado y la configuración de plugins no están conectados correctamente.

Una vez configurada esa capa, VS Code sí puede entregar sus fortalezas al leer proyectos grandes, buscar símbolos y usar AI para cambios de código dirigidos.

Para quién encaja este workflow

Creo que esta combinación funciona especialmente bien para estos grupos.

1. Personas con muchos proyectos basados en Keil

Si tus proyectos de empresa, materiales de curso o código histórico giran alrededor de Keil, no hay razón para tirar ese ecosistema solo por parecer moderno. Conserva Keil y añade VS Code como frontend. Suele ser la transición de menor coste.

2. Personas que quieren ayuda AI con código embebido

Si ya te gusta usar AI para explicar funciones, generar boilerplate o hacer cambios locales de lógica, VS Code asumirá ese rol de forma más natural que los IDEs embebidos tradicionales.

3. Personas que quieren equilibrar materiales de aprendizaje y proyectos reales

Muchos tutoriales siguen construidos alrededor de Keil, pero tu propio workflow no necesita quedarse atrapado en esa época. Trata Keil como capa de compatibilidad y VS Code como capa de productividad, y el equilibrio mejora mucho.

Cierre

En 2026, la pregunta clave sobre entornos embebidos ya no es solo qué IDE tiene más funciones. Es qué combinación encaja mejor con cómo trabaja la gente hoy.

Si solo quieres empezar rápido, STM32CubeIDE sigue teniendo su lugar. Si necesitas heredar mucha realidad de ingeniería existente, Keil sigue siendo inevitable. Pero si también quieres una experiencia moderna de edición y colaboración AI, la respuesta más práctica suele ser:

deja que Keil maneje build y debugging, y que VS Code maneje escribir código.

Quizá no sea la única respuesta, pero probablemente es una de las menos incómodas disponibles hoy.

Cómo elegir entre 8 formatos comunes de configuración: de INI, XML, JSON, YAML y TOML a Markdown

Wed, 22 Apr 2026 21:48:37 +0800

Si escribes código, administras servidores, ajustas opciones de juegos o mantienes toolchains, casi seguro no puedes evitar los archivos de configuración.

Muchas veces, lo que realmente rompe un programa no es el algoritmo ni el framework, sino una línea diminuta de configuración: un espacio faltante, una coma extra o un valor escrito de una forma que el sistema no esperaba. Mirar formatos comunes lado a lado nos devuelve a varias preguntas centrales:

¿Qué formatos son más amables para escribir por humanos?
¿Qué formatos son más amables para parsear por máquinas?
En la era de AI Agents, ¿empezará a cambiar el papel de los archivos de configuración?

Este artículo intenta organizar esa cuestión de forma concisa.

01 Un archivo de configuración es básicamente una negociación entre humanos y máquinas

Hay una forma de decirlo que me parece especialmente precisa: un archivo de configuración es un contrato de comportamiento entre humanos y programas.

Su valor es obvio. No necesitas reescribir lógica de negocio ni recompilar nada. Cambiando unas pocas líneas de texto puedes alterar el comportamiento de un sitio, la lógica de una aplicación, el despliegue o incluso gráficos y opciones ocultas de un juego.

El problema es que este contrato contiene una tensión incorporada.

Desde el lado humano queremos:

algo legible, escribible y estructuralmente claro
preferiblemente con comentarios para entenderlo después
la menor repetición posible, idealmente con reutilización y modularidad
un formato que no explote de inmediato por un pequeño error

Pero desde el lado máquina, la elegancia es irrelevante. Le importan principalmente dos cosas:

el parsing debe ser rápido
las reglas deben ser estrictas, los tipos claros y la ambigüedad mínima

Por eso los formatos de configuración siempre se tensan entre lo human-friendly y lo machine-friendly. Cuanto mejor es un formato para lectura humana, más trabajo suele necesitar la máquina para parsearlo. Cuanto más eficiente es para máquinas, más fácil suele ser que humanos cometan errores al editarlo.

02 INI: simple y directo, pero limitado

Empecemos con INI.

Sus fortalezas son muy directas:

estructura simple
secciones más pares clave-valor fáciles de entender
soporte de comentarios
adecuado para configuración ligera, como ajustes de juegos o entorno básico

Si alguna vez modificaste ajustes de juegos antiguos o parámetros de herramientas a mano, probablemente lo viste.

Pero INI también tiene limitaciones obvias. Su estructura es demasiado plana y no representa naturalmente anidamiento profundo o arrays. Además, normalmente carece de un sistema de tipos estricto, así que muchos valores son básicamente strings y el programa decide cómo interpretarlos.

Eso hace que INI se sienta como una herramienta vieja pero cómoda: excelente para trabajo ligero, fácil de superar cuando el proyecto crece.

Un INI típico:

[server]
host=127.0.0.1
port=8080

[feature]
enable_cache=true

03 XML: riguroso y estable, pero cansado de escribir

El segundo formato importante es XML.

Si mantuviste proyectos Java antiguos o viste archivos enormes llenos de tags de cierre, te resultará familiar.

Sus fortalezas incluyen:

estructura jerárquica clara
soporte de comentarios
reglas estrictas
validación fuerte cuando se combina con un schema

Eso permite a las máquinas conocer tipos, cardinalidad y restricciones estructurales antes de parsear de verdad, dando mucha seguridad.

Pero su coste humano es igual de clásico:

tags verbosos
mucho ruido visual
archivos que crecen rápido
un cierre faltante puede romperlo todo

Por eso XML se siente como un contrato formal sellado. A las máquinas les gusta; los humanos se cansan de mantenerlo. Muchos proyectos nuevos ya no lo eligen primero, pero en sistemas antiguos y entornos con reglas estrictas no ha desaparecido.

La misma configuración en XML:

<config>
  <server>
    <host>127.0.0.1</host>
    <port>8080</port>
  </server>
  <feature>
    <enable_cache>true</enable_cache>
  </feature>
</config>

04 JSON: dominante para intercambio de datos, incómodo para configuración editada a mano

En desarrollo moderno, JSON es casi inevitable.

El juicio clásico es: excelente como formato de intercambio de datos, algo incómodo como configuración mantenida por humanos.

Sus ventajas:

estructuras claras de objetos y arrays
transmisión amigable para red
parsers maduros
encaje fuerte con APIs web y comunicación frontend-backend

Frente a XML, JSON se ve mucho más ligero. La misma estructura suele ser más corta y más fácil de enviar por red.

Pero tiene un defecto grande: JSON estándar no soporta comentarios.

Su sintaxis también es estricta:

las claves deben ir entre comillas dobles
el último elemento no puede tener coma final
un símbolo faltante rompe todo de inmediato

Así que JSON es excelente para APIs e intercambio entre servicios, pero no siempre ideal para configuración que humanos editan, explican y revisan a menudo.

Por ejemplo:

{
  "server": {
    "host": "127.0.0.1",
    "port": 8080
  },
  "feature": {
    "enable_cache": true
  }
}

05 YAML: muy legible, pero la indentación y los tipos implícitos pueden traicionarte

Si trabajaste con Docker, CI/CD, Kubernetes o automatización de despliegues, casi seguro trataste con YAML.

Su mayor atractivo es lo limpio que se ve:

menos llaves y comillas
la indentación expresa jerarquía
soporta comentarios
anchors para reutilización

Desde una primera mirada humana, YAML suele parecer más amable que JSON.

Pero el problema está justo ahí. Oculta mucha complejidad y en uso real produce dos fallos clásicos:

infierno de indentación
conversión implícita de tipos

Los problemas de indentación son fáciles de entender: un espacio extra o faltante puede romper la config. Peor aún, la conversión implícita hace que valores que parecen strings simples puedan interpretarse automáticamente como booleanos u otros tipos.

Por eso tanta gente elogia lo bien que se ve YAML y al mismo tiempo sufre con él. Es realmente bueno para lectura humana, pero las máquinas no lo parsean sin esfuerzo, e incluso distintas librerías pueden discrepar en detalles sutiles.

La misma configuración en YAML:

server:
  host: 127.0.0.1
  port: 8080

feature:
  enable_cache: true

06 TOML: equilibrio entre legibilidad y determinismo

TOML suele presentarse como una respuesta moderna equilibrada.

Su atractivo combina parte de la claridad de INI con parte de la claridad de tipos de JSON:

soporte de comentarios
estructura clara
tipado más fuerte y explícito
manejo más natural de tipos comunes como fecha y hora
muchas menos trampas de conversión implícita que YAML

También se ha vuelto cada vez más común en toolchains modernas, como pyproject.toml en Python.

No es perfecto. En estructuras profundamente anidadas, TOML puede volverse verboso, y la escritura por rutas puede sentirse repetitiva. Pero para config de proyectos pequeños y medianos, herramientas y package management, la experiencia suele ser muy estable.

Si quieres un formato con comentarios, significado claro y bajo dolor de parser, TOML es un candidato fuerte.

Ejemplo común:

[server]
host = "127.0.0.1"
port = 8080

[feature]
enable_cache = true

07 `.conf` y configuración Apache: no es un formato universal, sino un lenguaje de dominio

Vale la pena enfatizar que mucha gente ve .conf y asume que es un formato estándar único. No lo es.

.conf es solo un sufijo de archivo para “configuration”. El contenido depende por completo de las reglas del sistema concreto. Es más una categoría amplia que una sintaxis estándar.

Toma Apache como ejemplo. Su estilo es representativo:

parte parece una lista de directivas de una línea
parte parece bloques etiquetados con comportamiento acotado
encaja naturalmente en el dominio de servidores web

Sus fortalezas son prácticas para operaciones, especialmente al expresar permisos, routing y virtual hosts. La desventaja es que sirve a su propio ecosistema y no tiene mucha portabilidad general.

Eso lo acerca a un lenguaje específico de dominio: excelente dentro del sistema para el que fue diseñado, no algo que tratar como formato universal.

Ejemplo mínimo estilo Apache:

Listen 80

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot "/var/www/html"
</VirtualHost>

08 Protocol Buffers: tipado industrial, pero mayor barrera

Protocol Buffers ya no son realmente “solo escribir una config a mano”. Se parecen más a un sistema formal de definición y serialización de datos.

Sus fortalezas son importantes:

tipado fuerte
schema explícito
buena compatibilidad hacia adelante y atrás
transmisión binaria compacta
procesamiento eficiente por máquinas

Pero los costes también son claros:

hay que definir archivos .proto
se necesitan herramientas y paso de compilación
la barrera es relativamente alta para proyectos pequeños

Así que no son ideales si solo quieres configurar una herramienta pequeña. Pero si construyes sistemas grandes, servicios RPC, sistemas distribuidos o protocolos de datos de larga vida, suelen ser mucho más fiables que formatos ligeros.

Su estilo se acerca a “define primero la estructura y luego genera código”:

syntax = "proto3";

message ServerConfig {
  string host = 1;
  int32 port = 2;
  bool enable_cache = 3;
}

09 En la era de AI Agents, Markdown puede volver a ser formato de configuración

La parte más interesante es poner Markdown dentro de la categoría de “formatos de configuración”.

Desde una perspectiva tradicional, suena extraño, porque Markdown parece más bien documentación. Pero si el objetivo ya no es un parser rígido sino un LLM o AI Agent, el argumento tiene sentido.

¿Por qué?

Porque los programas tradicionales dependen de sintaxis estricta y campos fijos, mientras los modelos grandes entienden mejor significado, estructura y contexto. Para ellos:

los encabezados son jerarquía
las listas son pasos
el texto en negrita es énfasis
el lenguaje natural puede portar reglas

Cuando el objetivo de configuración cambia de “parser rígido” a “agente que entiende significado”, Markdown, como texto estructurado amigable para humanos, puede volverse una configuración más natural.

Esto lleva a un juicio importante: en la era tradicional del software, muchos formatos existían para hacer que humanos se adaptaran a máquinas; en la era AI, las máquinas empiezan a adaptarse a la expresión humana.

Por ejemplo, una configuración de tarea para un agente podría ser:

# Goal

Write a welcome email for a new user.

## Requirements

- Friendly tone
- No more than 150 words
- Mention the product's 3 core features

## Forbidden

- Do not promise features that do not exist
- Do not use exaggerated marketing language

10 Entonces, ¿cómo elegir?

Si comprimimos toda la discusión:

si quieres configuración extremadamente simple, ligera y plana: INI
si quieres estructura fuerte, validación fuerte y compatibilidad legacy: XML
si quieres transmisión de red e intercambio de interfaces: JSON
si quieres alta legibilidad más cloud-native y config de despliegue: YAML
si quieres una experiencia moderna generalista más estable: TOML
si quieres reglas internas específicas de dominio: .conf / DSLs estilo Apache
si quieres diseño industrial de protocolos y evolución a largo plazo: Protocol Buffers
si quieres expresión natural y orquestación de tareas para AI Agents: Markdown

No hay un único mejor formato. Depende de para quién escribes:

humanos que mantienen el sistema
máquinas que parsean a alta velocidad
servicios que se comunican entre sí
o AI Agents que necesitan entender y ejecutar

Conclusión breve

La historia de los archivos de configuración es, en el fondo, la historia de humanos y máquinas renegociando constantemente dónde debe caer el coste de entender.

Antes, los humanos tenían que adaptarse a las máquinas, así que memorizábamos llaves, reglas de indentación, comillas y sintaxis rígida. Ahora que los modelos de lenguaje y sistemas de agentes entienden cada vez mejor la expresión natural, la propia “configuración” empieza a cambiar.

Quizá en el futuro muchos escenarios de configuración ya no giren alrededor de una sintaxis fija, sino de declaraciones estructuradas de intención. Hasta entonces, formatos como JSON, YAML, TOML, INI y XML seguirán coexistiendo, cada uno en el rol que mejor le encaja.

Cree imágenes de Docker en VS Code en Windows: desde la configuración hasta la compilación

Thu, 16 Apr 2026 10:20:00 +0800

Si desea crear imágenes de Docker directamente desde VS Code en Windows, el flujo de trabajo es sencillo. Solo necesitas tres partes: preparar el entorno, crear un Dockerfile y luego ejecutar la compilación.

01 Requisitos previos

Asegúrese de que estos dos elementos estén listos:

Instale y ejecute Docker Desktop.
Instale la extensión oficial de Microsoft Docker en VS Code.

En Windows, usar el backend WSL 2 en Docker Desktop (Configuración > Recursos > Integración WSL) suele ser más estable y rápido.

02 Preparar un archivo Docker

Si tu proyecto aún no tiene uno, VS Code puede generarlo:

Abra la carpeta de su proyecto en VS Code.
Presione F1 o Ctrl+Shift+P para abrir la paleta de comandos.
Ejecute Docker: Agregar archivos Docker al espacio de trabajo.
Elija su plataforma (Node.js, Python, .NET, etc.) y siga las indicaciones.

Normalmente obtendrá al menos:

-Dockerfile

.dockerignore

Esto le proporciona una base de trabajo que podrá perfeccionar más adelante.

03 Tres Maneras de Construir la Imagen

Método A: haga clic con el botón derecho en Dockerfile

En el Explorador de archivos, haga clic derecho en “Dockerfile”, seleccione “Crear imagen…” e ingrese una etiqueta de imagen.

Método B: Paleta de comandos

Presione F1, ejecute Docker: Build Image, luego seleccione el contexto y la etiqueta.

Método C: Terminal integrado

`1`	`docker build -t your-image-name .`

Este comando crea una imagen a partir del contexto del directorio actual con la etiqueta tu-nombre-de-imagen.

04 Comprobaciones rápidas para problemas comunes

Docker Desktop no se está ejecutando: verifique que esté iniciado.
La compilación es muy lenta: verifique si el backend de WSL 2 está habilitado.
La compilación no puede encontrar archivos: asegúrese de que su terminal esté en la raíz del proyecto y que los archivos estén dentro del contexto de compilación.
Los recursos de Docker no se muestran en VS Code: reinicie VS Code y verifique Docker CLI (versión de Docker).

Resumen

La creación de imágenes de Docker en VS Code en Windows es principalmente un problema de configuración. Una vez que Docker Desktop y la extensión VS Code Docker estén implementados, puede generar archivos Docker rápidamente y crear imágenes desde la interfaz de usuario o el terminal.

Guía de recursos CH347: controladores, herramientas y programación SPI Flash

Fri, 03 Apr 2026 10:00:00 +0800

Esta publicación resume los recursos de CH347 que uso con más frecuencia, con un objetivo: pasar de la configuración a la depuración/programación lo más rápido posible.

Si es nuevo en CH347, prepare su entorno en este orden:

Consulte primero la página oficial del producto.
Instale el controlador correcto para su caso de uso
Prepare una herramienta SPI Flash y verifique la conectividad

Entrada oficial

Página del producto CH347: https://www.wch.cn/products/CH347.html

Es mejor descargar primero desde la página oficial para evitar paquetes de controladores obsoletos o de origen desconocido.

Controladores comunes

1) `CH341PAR.EXE`

Propósito:

Controlador de interfaz USB a JTAG / SPI / I2C / Paralelo / GPIO

Uso típico:

Comunicación multiprotocolo y depuración de interfaz de bajo nivel con CH347

2) `CH343SER.EXE`

Propósito:

Controlador de Windows del proveedor para USB a serie de alta velocidad

Uso típico:

Utilizar CH347 principalmente como herramienta en serie, especialmente a velocidades de baudios más altas

Herramienta de programación SPI Flash

ComoProgramador: https://github.com/nofeletru/UsbAsp-flash

Tareas comunes:

Detectar SPI NOR Flash
Leer identificación del chip
Copia de seguridad del firmware original
Borrar / escribir / verificar firmware

Flujo de trabajo recomendado (para evitar errores comunes)

Después de instalar los controladores, vuelva a conectar el dispositivo y confirme la detección en el Administrador de dispositivos.
Antes de escribir por primera vez, realice una lectura completa + copia de seguridad del contenido original.
Ejecute siempre verificar después de escribir. No confíe únicamente en un mensaje de “escritura exitosa”.
Si no se detecta el chip, verifique la alimentación, el nivel de voltaje y el cableado antes de verificar la configuración del software.

Solución rápida de problemas

El dispositivo está enchufado pero no es visible en las herramientas: generalmente hay problemas de carga del controlador o un cable USB de solo alimentación.
Se detecta el dispositivo pero falla la lectura/escritura: primero verifique el orden del cableado, la tierra compartida y la estabilidad de la energía.
Comportamiento inestable a alta velocidad: primero reduzca la velocidad de lectura/escritura y luego aumente gradualmente una vez confirmada la estabilidad.

Resumen

CH347 no es difícil de usar. La clave es hacer bien cuatro cosas: controlador, herramienta, cableado y verificación.

Los recursos anteriores cubren la mayoría de los escenarios de mantenimiento diarios y para principiantes, y deberían permitirle alcanzar rápidamente un flujo de trabajo estable.

Explicación de FFmpeg `-map`: seleccione con precisión transmisiones de video, audio y subtítulos

Thu, 02 Apr 2026 23:14:03 +0800

En flujos de trabajo de múltiples audios y subtítulos, -map es una de las opciones más importantes y más frecuentemente mal utilizadas de FFmpeg.

Si no especifica explícitamente -map, FFmpeg selecciona automáticamente las transmisiones usando reglas predeterminadas y, a menudo, el resultado no es el esperado. Por ejemplo:

Los subtítulos desaparecen después de la exportación.
Se seleccionó la pista de idioma incorrecta
Se incluyen flujos de datos no deseados.

Este artículo utiliza escenarios comunes del mundo real para explicar cómo funciona “-map”.

Primero, comprenda qué es una “transmisión”

Un archivo contenedor (como mp4 o mkv) generalmente contiene múltiples secuencias, que incluyen:

Secuencias de vídeo (v)
Flujos de audio (a)
Secuencias de subtítulos (s)
Archivos adjuntos/flujos de datos (fuentes, portadas, capítulos, etc.)

Puedes inspeccionar transmisiones con ffprobe:

`1`	`ffprobe -hide_banner input.mkv`

Sintaxis básica de `-map`

Patrón más común:

`1`	`-map input_index[:stream_type][:stream_index]`

Ejemplos:

0:v: todas las transmisiones de video desde la primera entrada
0:a:0: la primera secuencia de audio desde la primera entrada
1:s:1: la segunda secuencia de subtítulos desde la segunda entrada

Notas:

input_index comienza desde 0, según el orden -i
stream_index también comienza desde 0

Ejemplos prácticos

1) Vídeo de A, audio de B

ffmpeg -i english.mp4 -i french.mp3 \
  -map 0:v:0 -map 1:a:0 \
  -c:v copy -c:a aac \
  french.mp4

Significado:

Utilice la primera transmisión de video de english.mp4
Utilice la primera secuencia de audio de french.mp3
Fusionar en french.mp4

2) Mantenga todas las transmisiones desde la entrada 1, luego agregue una pista de audio más

ffmpeg -i english.mp4 -i french.mp3 \
  -map 0 -map 1:a:0 \
  -c copy \
  english-french.mp4

Significado:

-map 0 mantiene todas las transmisiones desde la primera entrada
Luego agregue la primera secuencia de audio de la segunda entrada.

Dos trucos avanzados útiles

1) Mapeo negativo: excluye transmisiones no deseadas

Por ejemplo, mantenga todo lo de la entrada 1 pero elimine su segunda secuencia de audio:

`1`	`ffmpeg -i input.mkv -map 0 -map -0:a:1 -c copy output.mkv`

2) Mapeo opcional: no falle cuando falte una transmisión

Si es posible que algunos archivos no tengan subtítulos, utilice ?:

`1`	`ffmpeg -i input.mp4 -map 0:v -map 0:a -map 0:s? -c copy output.mp4`

0:s? significa: subtítulos del mapa si están presentes; de lo contrario, salte sin error.

Errores comunes

Una vez que usa -map, FFmpeg detiene la selección automática de secuencias, por lo que debe mapear todo lo que necesita.
-c copy solo remuxes sin transcodificación. Si el contenedor de destino no admite un códec, igualmente falla.
Con múltiples entradas, los errores de índice son comunes. Los índices de entrada están determinados únicamente por el orden “-i”.
Para scripts robustos, inspeccione primero con ffprobe y luego genere -map dinámicamente.

Resumen

La idea central de -map es simple: decirle explícitamente a FFmpeg qué entrada usar, qué tipo de flujo elegir y qué índice de flujo seleccionar.

Una vez que domine esto, podrá manejar de manera confiable casos complejos como composición de múltiples audios, múltiples subtítulos y transmisiones entre archivos.

Cómo solucionar problemas de uso elevado de CPU de VS Code causado por extensiones

Wed, 01 Apr 2026 00:00:00 +0000

Cuando VS Code de repente se siente lento, el ventilador gira y el uso de la CPU se mantiene alto, la causa más común generalmente no es el editor en sí, sino conflictos de extensiones o un comportamiento anormal de las extensiones.

Esta guía le brinda un flujo de trabajo directo y práctico para identificar el problema rápidamente.

Comience con el método más rápido: iniciar la extensión en bisección

Start Extension Bisect utiliza un enfoque de búsqueda binaria: En cada ronda, VS Code desactiva temporalmente la mitad de tus extensiones y se reinicia. Según si el problema persiste, reduce rápidamente la lista de sospechosos.

Pasos:

Presione Ctrl+Shift+P (macOS: Cmd+Shift+P) para abrir la paleta de comandos.
Ejecute Iniciar extensión bisect.
Después de cada reinicio, verifique si todavía hay un uso elevado de la CPU y un retraso, luego elija “Bien ahora” o “Esto es malo”.
Después de varias rondas, VS Code mostrará las extensiones probablemente problemáticas.

Qué hacer después de encontrar al sospechoso

Una vez que identifique la extensión, manéjela en este orden:

Actualice la extensión a la última versión.
Si el problema persiste, desactívelo durante 1 o 2 días y observe.
Si existen alternativas, cambie a una extensión más ligera.
Si debe conservarlo, revise la configuración avanzada y desactive las funciones innecesarias de análisis, indexación o visualización de archivos en tiempo real.

Dos “amplificadores” comunes que quizás pases por alto

Incluso si una extensión es la causa principal, estas configuraciones pueden amplificar la carga de la CPU:

El alcance de la búsqueda es demasiado amplio
Si los resultados de la compilación, las carpetas de dependencia y los registros se incluyen en la búsqueda global, las extensiones y los indexadores pueden permanecer bajo una carga pesada y continua.
La visualización de archivos incluye carpetas o enlaces simbólicos enormes
Los enlaces simbólicos, los directorios de caché y las carpetas generadas pueden desencadenar una gran cantidad de eventos de archivos y forzar que las extensiones se reprocesen repetidamente.

Puede recortar el alcance en settings.json, por ejemplo:

{
  "search.exclude": {
    "**/node_modules": true,
    "**/dist": true,
    "**/build": true
  },
  "files.watcherExclude": {
    "**/.git/objects/**": true,
    "**/node_modules/**": true,
    "**/dist/**": true
  }
}

Consejo post mortem

Después de aislar el problema, registre tres cosas: nombre de la extensión, escenario desencadenante y solución final.
Esa nota le ahorrará tiempo cuando migre su entorno o reconstruya su máquina más adelante.

Resumen

Para un uso elevado de CPU de VS Code, la ruta más eficaz es utilizar primero “Iniciar extensión Bisect” y luego ajustar el alcance de búsqueda y observación de archivos.
Localice primero, optimice en segundo lugar. Es más rápido y confiable que deshabilitar aleatoriamente muchas extensiones.