Consejos y experiencias reales en ingeniería de software, IA aplicada y desarrollo de soluciones digitales que marcan la diferencia.

Introducción: por qué creé esta herramienta. ¿Te interesa el tarot pero te abruma la cantidad de barajas e interpretaciones? Quise diseñar una forma sencilla e interactiva de explorar el tarot usando Python, creando una experiencia accesible para principiantes y entretenida para entusiastas.

Sobre el proyecto: mi programa en Python simula una tirada de tarot barajando una baraja completa con Arcanos Mayores y Menores, extrayendo cartas y mostrando sus significados en formato claro y fácil de leer. Emplea programación orientada a objetos para gestionar el mazo y las cartas, lo que hace que el código sea modular y fácil de ampliar. Entre sus características destacan barajado aleatorio para lecturas auténticas, formato limpio de los significados y funciones sencillas para sacar una o varias cartas.

Nota rápida: los precios y los límites cambian periódicamente. Los ejemplos y cifras que aparecen aquí son válidos a modo orientativo y corresponden a otoño 2025, pero comprueba siempre la página de precios del proveedor antes de desplegar producción.

¿Has intentado entender la tarifa de AWS Bedrock y te has perdido entre números y siglas? Este artículo explica en lenguaje claro qué es Bedrock, qué son los tokens, cómo se factura y cuánto pueden costar realmente las cosas, además de comparar con OpenAI y Anthropic.

Qué es AWS Bedrock: AWS Bedrock funciona como una tienda de modelos de lenguaje. Amazon gestiona la infraestructura pesada por ti. Solo necesitas elegir un modelo, enviar texto y recibir respuestas, y pagar por uso. A diferencia de proveedores que solo ofrecen su propio modelo, con Bedrock puedes mezclar modelos nativos de Amazon y de terceros detrás de una experiencia AWS unificada, aprovechando seguridad consolidada, herramientas conocidas de AWS y una facturación centralizada.

Qué son los tokens: piensa en piezas de Lego de texto. Los modelos no procesan las palabras exactas como lo hacemos nosotros, sino que dividen el texto en unidades llamadas tokens. En inglés un token suele ser cerca de 4 caracteres, más o menos tres cuartas partes de una palabra. Como referencia aproximada, 1 000 tokens equivalen a unas 750 palabras, es decir una o dos páginas escritas. Por eso los precios suelen indicarse por 1 000 tokens.

Cómo se factura: te cobran por los tokens que envías al modelo y por los tokens que el modelo devuelve. Si mandas una pregunta de 300 tokens y recibes una respuesta de 200 tokens, tu consumo total es de 500 tokens. Ese total se multiplica por la tarifa por cada 1 000 tokens del modelo que uses. Este sistema de tokens es muy similar entre AWS Bedrock, OpenAI y Anthropic, lo que permite comparaciones directas.

Qué son las embeddings y en qué se diferencian del texto normal: cuando envías texto para obtener una respuesta legible estás pidiendo salida en formato texto. Una embedding convierte el texto en un vector numérico que representa el significado. Es como obtener coordenadas en un espacio semántico: textos con significado cercano quedan cerca en ese espacio aunque estén redactados de forma distinta. Las embeddings son muy útiles para búsqueda semántica, recomendaciones y para sistemas RAG de recuperación y respuesta. En la práctica, las embeddings suelen facturarse por los tokens de entrada únicamente, porque no se genera texto de salida grande. En Bedrock, Titan Embeddings es una alternativa muy económica para convertir texto en vectores para búsqueda y RAG.

Cómo cobra AWS Bedrock: no hay tarifa plana mensual: pagas por el volumen de texto procesado en tokens. Bedrock ofrece tres modalidades: On-Demand pago por petición ideal para pilotos y tráficos impredecibles; Batch más barato pero asíncrono, útil para procesos grandes sin urgencia; y Provisioned para reservar capacidad y obtener rendimiento y costes predecibles en cargas estables y altas.

Cómo elegir la modalidad adecuada: On-Demand para experimentos y tráfico variable; Batch para trabajos masivos y nocturnos; Provisioned cuando ya tienes patrón de uso estable y necesitas rendimiento garantizado a menor coste por token. Muchos equipos comienzan en On-Demand, usan Batch para tareas por lotes y pasan a Provisioned al estabilizar la carga.

Precios indicativos de modelos de Amazon (orientativos a otoño 2025 y sujetos a cambio): Nova Micro On-Demand coste entrada 0.000035 por 1 000 tokens y salida 0.00014 por 1 000 tokens. Nova Micro Batch aproximadamente la mitad. Nova Lite entrada 0.00006 salida 0.00024. Nova Pro entrada 0.0008 salida 0.0032. Titan Embeddings 0.00002 por 1 000 tokens de entrada y capacidad para procesar alrededor de 8 000 tokens por petición; una de las opciones más económicas para embeddings.

Límites de contexto y cómo influyen: cada modelo tiene un límite combinado de entrada y salida. Si excedes ese límite la petición falla, así que es habitual fragmentar documentos largos. Ejemplos de límites: Titan Text Lite alrededor de 4 000 tokens, Titan Express alrededor de 8 000 tokens, Titan Premier alrededor de 30 000 tokens, mientras que algunos modelos de Anthropic ofrecen ventanas de contexto mucho mayores, por ejemplo Claude Sonnet 4 hasta alrededor de 65 000 tokens y Claude 3.7 Sonnet hasta 131 000 tokens. Ten en cuenta que el parámetro max_tokens que defines para la respuesta cuenta dentro del límite total.

Comparación rápida con OpenAI y Anthropic: a nivel general Amazon suele ofrecer modelos muy baratos por token para tareas cotidianas. OpenAI y Anthropic pueden salir más caros, pero ofrecen en muchos casos capacidades de razonamiento más avanzadas, versiones optimizadas y ventanas de contexto más amplias según la familia de modelo. Por ejemplo, precios orientativos: OpenAI GPT-3.5 Turbo cerca de 0.0005 entrada y 0.0015 salida por 1 000 tokens y contexto alrededor de 16 000 tokens; OpenAI GPT-4 8K es sensiblemente más caro; Anthropic Claude 3.7 Sonnet tiene coste por token más alto pero puede procesar hasta 131 000 tokens.

Qué modelo elegir: Nova Micro, Lite o Pro para generación de texto, chatbots, resúmenes y reescritura; Nova Micro es muy económico para tareas sencillas, Lite y Pro aportan mayor calidad. Titan Text en sus variantes es recomendable si buscas integración nativa en AWS. Titan Embeddings es la opción para búsqueda semántica, recomendaciones y RAG. Rerank mejora el orden de resultados cuando ya tienes candidatos. Regla práctica: usa el modelo más pequeño que satisfaga la calidad que necesitas para ahorrar costes.

Consejos para reducir costes: mide y registra tokens por petición; recorta prompts y respuestas cuando sea posible; usa Batch para trabajos no interactivos y ahorrar hasta 50 por ciento en modelos soportados; ajusta max_tokens para evitar respuestas excesivamente largas; fragmenta documentos largos para evitar errores y aprovechar límites de contexto; cachea instrucciones repetidas mediante plantillas para no enviar el mismo bloque de texto en cada petición. Evitar estos errores puede reducir la factura entre 30 y 50 por ciento sin sacrificar calidad.

Ejemplo práctico de cálculo: supongamos 100 000 interacciones al mes, cada una con 300 tokens de entrada y 200 tokens de salida usando Nova Micro. Entrada 100 000 por 300 = 30 000 000 tokens = 30 000 unidades por 1 000 × 0.000035 = 1.05. Salida 100 000 por 200 = 20 000 000 tokens = 20 000 unidades por 1 000 × 0.00014 = 2.80. Coste mensual aproximado 3.85 para 100 000 interacciones. Con esta mentalidad de calculadora puedes prever costes antes de lanzar y ajustar longitud de salidas, inputs o modalidad de facturación si te resulta demasiado alto.

Errores comunes: no contar las tokens de salida; usar un modelo grande para una tarea sencilla; no fijar max_tokens y obtener respuestas largas inesperadas; mandar instrucciones largas en cada petición en lugar de reutilizarlas. Evitar estas prácticas reduce costes sin perder calidad.

Conclusión: la clave para desmitificar los precios de IA es entender que los tokens son la unidad de uso, que entrada y salida se facturan por separado, que cada modelo tiene un límite de contexto y que diferentes modelos sirven para distintas necesidades. Con estas nociones puedes proyectar costes, elegir el modelo adecuado y evitar sorpresas.

Particionamiento de MySQL es una técnica potente para gestionar tablas grandes dividiéndolas en partes más manejables llamadas particiones. Cada partición se comporta como una tabla individual a nivel de almacenamiento y ficheros, pero MySQL las trata lógicamente como una sola tabla. La división se basa en una función o esquema de particionamiento que define el desarrollador.

Por qué usar particionamiento Los principales beneficios incluyen mejor rendimiento de consultas cuando estas filtran por la clave de particionamiento gracias al llamado pruning de particiones, gestión de datos más sencilla ya que eliminar datos antiguos puede ser tan rápido como eliminar una partición mediante una operación de metadatos, mayor paralelismo y throughput en ciertas operaciones, y mejor localidad de datos que puede mejorar uso de cache e I O.

Limitaciones y precauciones Entre los inconvenientes están la mayor complejidad en diseño y mantenimiento, la obligación de que todas las claves únicas y la clave primaria incluyan las columnas de particionamiento en muchas versiones de MySQL, el límite de ficheros abiertos porque cada partición puede ser un fichero separado y la posible ausencia de mejora si las consultas no filtran por la columna de particionamiento, lo que puede incluso empeorar el rendimiento por la sobrecarga añadida.

Cuándo usarlo Es recomendable cuando se trabaja con tablas muy grandes de millones o miles de millones de filas, con datos de series temporales donde poder purgar periodos antiguos rápidamente, cuando existen políticas de retención y archivado por segmento, o cuando los escaneos de tabla son comunes y lentos y encajan con la estrategia de particionamiento. No es aconsejable para tablas pequeñas o medianas, tablas con joins complejos que no se alinean con la partición, o cuando las consultas habituales no usan la columna de particionamiento.

Métodos principales de particionamiento

RANGE Particiona datos según valores que caen en rangos contiguos. Ideal para datos por fecha o rangos numéricos. Sintaxis conceptual PARTITION BY RANGE (expresión) con definiciones VALUES LESS THAN. Ejemplo simplificado: CREATE TABLE sales sale_id INT NOT NULL, cust_id INT NOT NULL, sale_date DATE NOT NULL, amount DECIMAL(9,2) PARTITION BY RANGE ( YEARWEEK(sale_date) ) PARTITION s1 VALUES LESS THAN (202002), PARTITION s2 VALUES LESS THAN (202003), PARTITION s999 VALUES LESS THAN (MAXVALUE). Para reorganizar se usa ALTER TABLE ... REORGANIZE PARTITION.

LIST Particiona por conjuntos de valores discretos. Ideal para códigos de región o estados fijos. Sintaxis conceptual PARTITION BY LIST COLUMNS(columna) con VALUES IN. Ejemplo simplificado: CREATE TABLE sales_list sale_id INT NOT NULL, geo_region_cd VARCHAR(6) NOT NULL, amount DECIMAL(9,2) PARTITION BY LIST COLUMNS (geo_region_cd) PARTITION MIDDLEEAST VALUES IN (SA, QT, SY), PARTITION EUROPE VALUES IN (EUR_I, EUR_F) etc. Para añadir valores se puede reorganizar la partición correspondiente.

HASH Usa el resultado de una expresión hash para distribuir filas equitativamente entre N particiones. Útil para balanceo y paralelismo. Sintaxis conceptual PARTITION BY HASH(expresión) PARTITIONS N. Ejemplo: PARTITION BY HASH(cust_id) PARTITIONS 4 distribuirá clientes entre 4 particiones.

KEY Similar a HASH pero emplea la función de hashing interna de MySQL y suele basarse en columnas de la clave primaria o única. Sintaxis conceptual PARTITION BY KEY(columna1, columna2) PARTITIONS N.

COMPOSITE o SUBPARTITIONING Combina dos métodos, por ejemplo RANGE externo para segmentar por año y HASH interno para distribuir uniformemente dentro de cada año. Esto es útil cuando se necesita facilitar la eliminación por rango y al mismo tiempo equilibrar la carga interna de cada partición.

Qué método elegir RANGE es el preferido para series temporales y políticas de retención; LIST para valores enumerados como regiones o estados; HASH y KEY cuando la prioridad es distribuir datos y reducir contención; COMPOSITE cuando se necesitan las ventajas de dos métodos a la vez.

Cómo mejora el rendimiento Principalmente por dos mecanismos. Uno, partition pruning donde el optimizador analiza la cláusula WHERE y descarta particiones irrelevantes, reduciendo I O. Por ejemplo en una tabla particionada por YEARWEEK(sale_date), una consulta que filtre por un rango de fechas solo escaneará las particiones correspondientes en vez de toda la tabla. Dos, operaciones de gestión de datos como borrar o archivar se vuelven muy eficientes porque es posible eliminar una partición completa mediante ALTER TABLE DROP PARTITION, que es una operación casi instantánea a nivel de metadatos.

Hola a todos, somos Krzysztof y Tymek desde Software Mansion y les traemos un resumen con lo más relevante en el ecosistema React y tecnologías afines para esta semana. Destacamos el anuncio de TanStack Start 1.0 Release Candidate, una propuesta full stack basada en TanStack Router orientada a SSR, streaming, funciones en servidor y despliegues en cualquier entorno que ejecute JavaScript.

En el frente de enrutamiento, React Router avanza y en la versión v7.9.2 amplía el soporte para React Server Components al modo Framework, complementando lo ya ofrecido en Data Mode. Gracias a nuevos plugins de Vite se pueden devolver Server Components desde loaders y actions, crear rutas como Server Components y combinar directivas use client y use server para separar lógica cliente y servidor.

La documentación oficial del plugin ESLint para React Hooks ahora cuenta con una referencia exhaustiva de API, lo que facilita detectar violaciones de las reglas de Hooks en tiempo de compilación. Esto se complementa con novedades en herramientas del ecosistema como TanStack Form y TanStack DB, mejoras en DevTools y utilidades para formularios y consultas en tiempo real.

En React Native la actividad ha sido más moderada pero relevante: Expo SDK 54 añade funciones nuevas entre ellas compatibilidad con sintaxis similar a localStorage, hay avances en Nitro Modules para acelerar el paso de datos, nuevas librerías de animaciones abiertas y paquetes como expo-live-activity para gestionar Live Activities en iOS. También surgen iniciativas como react-native-nitro-fetch para prefetching y actualizaciones en react-native-iap con adopción de OpenIAP.

También vale la pena mencionar recursos prácticos y artículos técnicos: cómo evitar el efecto waterfall en RSCs con renderizado paralelo y recursivo, guías para migrar SPA a aplicaciones SSR con TanStack Start, y propuestas experimentales de animación como ViewTransition para transiciones suaves entre vistas.

Fuera del mundo React, noticias sobre seguridad y rendimiento siguen en primer plano: GitHub comparte su plan para asegurar la cadena de suministro de npm, W3C publica borradores sobre variables de entorno CSS, Wasm 3.0 avanza con soporte a espacio de direcciones 64 bits, múltiples memorias y recolección de basura, y la comunidad debatiendo mejores prácticas de CSS y especificidad para proyectos modernos.

Primera impresión Tu sitio web suele ser la primera impresión que recibe tu marca. Un sitio sólido genera confianza y crea impulso; uno débil hace que la gente se vaya antes de darte una oportunidad. Es fácil acostumbrarse a los detalles de tu propio sitio y dejar pasar pequeños fallos que a los visitantes les saltan a la vista. Esos detalles invisibles muchas veces son la razón por la que alguien abandona en lugar de interactuar. La buena noticia es que cada bandera roja tiene una solución práctica y clara.

Playwright elemento fuera del viewport por qué ocurre y cómo solucionarlo

Resumen del problema Un checkbox con id AcceptedTermsOfUse puede existir en el DOM y ser visible en términos de CSS pero estar posicionado fuera del área visible de la página con coordenadas X muy negativas. Al intentar ejecutar una acción de usuario real con Playwright como locator.click Playwright devuelve un error indicando que el elemento está fuera del viewport o no es accionable. Esto significa que aunque el elemento no tenga display none ni visibility hidden, no está en una posición donde un usuario físico podría hacerle clic.

Por qué sucede Causas habituales Off screen styling El elemento puede tener position absolute o transform que lo empuja fuera de la pantalla usando valores negativos en left o translate. Label estilizado y input escondido Muchos frameworks de interfaz ocultan el input real y usan un label con pseudo elementos para renderizar la casilla visible. El usuario interactúa con el label y esa interacción se propaga al input escondido que permanece fuera del viewport.

Comprobaciones de acción de Playwright Antes de ejecutar locator.click Playwright realiza comprobaciones de accionabilidad: el elemento debe ser visible, estar habilitado, estable y debe estar dentro del viewport o poder ser scrolleado hasta él. Si alguna comprobación falla Playwright no ejecuta el clic. Esto es intencional: Playwright busca simular la interacción real de un usuario y evitar clicks sobre elementos inaccesibles.

Casos engorrosos Es habitual encontrar inputs de tipo checkbox técnicamente visibles pero inaccesibles por el diseño CSS. Un ejemplo real: el checkbox estaba localizado con bounding box con x en valores muy negativos, posicionado en absoluto y sin un contenedor scrollable que permitiera traerlo a la vista. Por eso Playwright no podía realizar el click físico aunque el elemento estuviera habilitado.

Cómo investigar en el navegador Abre DevTools y examina el elemento en el DOM, verifica su bounding box, overflow y estilos position y transform. También puedes simular la acción desde la consola invocando el click a nivel de DOM sobre el elemento para comprobar si los listeners y el estado cambian aunque el elemento esté fuera de pantalla. Esta prueba ayuda a distinguir entre fallo de acción por estar fuera del viewport y ausencia de listeners.

Por qué document.getElementById id .click funciona y Playwright click no Cuando llamas al método click del elemento en el navegador se ejecuta programáticamente HTMLElement.prototype.click que dispara los eventos mousedown mouseup click input change y actualiza el estado sin requerir que el elemento esté dentro del viewport. En cambio Playwright modela la interacción del usuario y por eso exige que la acción sea físicamente posible en la página real.

Soluciones prácticas 1 Usar ejecución en contexto de página para invocar el click a nivel DOM Cuando la lógica de la aplicación responde correctamente a events programáticos puedes usar page evaluate para localizar el elemento por su id y llamar a click desde el contexto de la página. Esto permite marcar el checkbox aunque esté fuera del viewport. 2 Ajustar el checked y disparar events Otra alternativa es establecer la propiedad checked del input y despachar manualmente un evento change para que los listeners reaccionen. 3 Interactuar con el label visible Si la UI usa un label estilizado lo ideal es apuntar y clicar el label visible en lugar del input escondido. 4 Corregir el CSS o el flujo de la página Cuando sea posible modifica estilos para que el elemento o su contenedor sean scrolleables o para que el input esté dentro del viewport, manteniendo así las comprobaciones de Playwright. 5 Forzar el clic en Playwright como excepción Playwright ofrece la opción de forzar la acción si es estrictamente necesario pero debe usarse con cuidado porque evita las comprobaciones que garantizan que la interacción replica la de un usuario real.

Buenas prácticas para pruebas y desarrollo Evita depender únicamente de clicks programáticos si quieres que tus tests reflejen la experiencia real. Documenta los componentes que ocultan inputs reales y proporciona selectores robustos para usar el label visible o la API pública del componente cuando exista. Usa herramientas de inspección para comprobar bounding boxes y stacking context antes de automatizar clicks.

Entender rápidamente una base de código grande y desconocida es una habilidad clave para cualquier desarrollador. Suele pasar que tras 6 o 7 saltos de ir a definición uno se pierde en la cadena de llamadas. A continuación comparto un método práctico y herramientas que funcionan bien en proyectos en C y Go, junto con cómo nuestro equipo en Q2BSTUDIO puede ayudar.

Primeros pasos: antes de lanzarte a navegar archivos busca la documentación inicial, README, guía de arquitectura y scripts de arranque. Intenta compilar y ejecutar un escenario mínimo para ver el flujo en ejecución. Identifica puntos de entrada claros como main, handlers, endpoints o comandos CLI y anota un mapa mental de módulos principales.

Herramientas esenciales: combina las capacidades del IDE con herramientas de línea de comandos. Para Go usa gopls, go list, go doc y go test. Para C aprovecha clangd, cscope, ctags, cflow y herramientas de build. Utiliza grep o ripgrep para búsquedas rápidas, y Sourcegraph o similares para navegación entre repositorios. Las funciones de Call Hierarchy y Find All References del IDE suelen ahorrar muchos saltos innecesarios.

Técnicas de exploración: crea ejemplos pequeños que ejerciten el comportamiento que quieres entender, añade logs temporales o instrumentación, escribe tests de integración que sigan la ruta de ejecución, y dibuja diagramas secuenciales o de componentes para fijar una visión general. Revisa el histórico de Git, PRs y comentarios para entender decisiones de diseño y evitar malentendidos.

Automatización y visualización: genera grafos de dependencias con herramientas y exporta diagramas con Graphviz para ver acoplamientos. Los analizadores estáticos y linters detectan patrones recurrentes y puntos de riesgo. Si trabajas con básicos monolitos, fragmenta mentalmente en capas y busca interfaces bien definidas.

Colaboración: pregunta a quien conoce el código, busca tickets y documentación interna, y realiza pair programming cuando sea posible. Un par de sesiones guiadas suelen ahorrar días de investigación solitaria.

Enfoque práctico: establece un objetivo claro por día: entender un subsistema, cubrir con tests un flujo crítico, o preparar un PR pequeño que sirva de experimento. Usa scripts personalizados para automatizar búsquedas comunes y mantener notas centralizadas que se puedan compartir.

IconFY lanzado: generador de iconos gratis sin registro y gratuito para siempre. IconFY permite crear iconos en PNG ICO y SVG, exportar en todos los tamaños necesarios para iOS, Android y Web y procesar lotes para acelerar flujos de trabajo.

Entendiendo express.json en Express.js: cuando se construye una aplicacion backend con express, manejar los datos entrantes es habitual. Uno de los formatos mas habituales es JSON. La funcion express.json convierte el cuerpo de la peticion HTTP en un objeto de Javascript accesible desde los manejadores de ruta, facilitando la lectura de propiedades como nombre o email.

Por que necesitamos express.json: las peticiones HTTP, especialmente POST, envian datos en el body y sin parseo express no interpreta automaticamente JSON. Si intentas acceder a req.body sin usar express.json obtendras undefined. Un ejemplo de cuerpo seria { name: Vasanth, email: vasanth@example.com } y para leerlo es necesario el middleware.

Como usar express.json: registra el middleware en tu app con app.use(express.json()); a partir de ahi en rutas POST puedes leer directamente req.body y trabajar con propiedades como req.body.name o req.body.email. Esto evita errores y simplifica la logica de validacion y almacenamiento.

Buenas practicas: valida el esquema de JSON, controla tamaños maximos y maneja errores de parseo para prevenir entradas malformadas. Combina express.json con middlewares de seguridad y limitadores de peticiones para fortalecer tu API.