Continuamos explorando innovación en IA, software personalizado y trucos para optimizar procesos de desarrollo. Inspiración y conocimiento para profesionales y empresas.

Hola a todos ¿Cómo van las cosas? Bienvenidos a una guía práctica para encontrar trabajo sin volverse loco diseñada para quien busca entrar al mundo tech o mejorar su posicionamiento profesional.

Primero lo primero Construye tu arsenal profesional Antes de lanzarte necesitas herramientas reales y visibles que te respalden No me refiero a títulos en papel sino a proyectos concretos que demuestren que sabes resolver problemas reales Si no tienes experiencia crea la tuya misma Diseña una aplicación para un comercio local automatiza una tarea administrativa o desarrolla un prototipo que puedas mostrar

Por qué funciona Esto te da experiencia probada y te transforma de alguien que estudió X en la persona que construyó Y y logró Z Resultado Además te ayuda a detectar qué habilidades debes mejorar

Tecnologías clave Abre varias ofertas del puesto que deseas y fíjate en las tecnologías recurrentes Si piden React Python y AWS ese es tu plan de estudio Construye proyectos personales con esas herramientas y prioriza el aprendizaje práctico No solo leas ¡crea!

Introducción: Gemini 2.5 Flash Image conocido como nano-banana es un modelo de generación de imágenes de Google optimizado para velocidad y consistencia. Para equipos de producto y desarrolladores que necesitan convertir ideas difusas en direcciones visuales concretas, nano-banana resulta especialmente útil para generar bocetos UI móviles rápidos y coherentes sin abrir una herramienta de diseño completa.

Todos hablan de modelos de IA más grandes. Se están perdiendo la oportunidad real. Un modelo compacto y optimizado para usar herramientas cambia la hoja de ruta: más pensamiento por token, menos coste y latencia.

Baidu presenta ERNIE-4.5-21B, un modelo que aprovecha una arquitectura Mixture of Experts con solo 3B de parámetros activos por token, ofreciendo razonamiento profundo sin incendiar el presupuesto. Su contexto de 128K tokens permite alimentar especificaciones completas, contratos y bases de código de una sola vez, y su capacidad nativa para usar herramientas lo convierte en un ejecutor y no solo en un orador. Al ser open source facilita el despliegue propio, la auditoría y el lanzamiento rápido de funciones.

En una prueba de laboratorio, una empresa de SaaS mediana procesó un SOW de 180 páginas y generó notas de revisión en 95 segundos. El coste de inferencia descendió un 32% respecto a su baseline denso y la precisión en casos límite mejoró un 11%.

Si diseñas productos AI piensa en tres ejes:

Pensamiento: elige MoE con pocos parámetros activos por token para velocidad y coste. Mide en tareas de chain of thought relevantes para tus usuarios.

Contexto: apunta a 100K+ tokens para gestionar artefactos reales de extremo a extremo. Recorta la hinchazón de prompts y cachea secciones reutilizables.

Herramientas: integra el modelo con repositorios, APIs y calculadoras. Comienza por recuperación, llamadas a funciones y tests unitarios. Así lanzas funciones más rápido, reduces alucinaciones y bajan las facturas de inferencia.

Concurrencia es un patrón, no una forma de ejecución. En algunos libros sobre Dart se explica la concurrencia como si fuera ejecutar código en un solo núcleo y el paralelismo como la ejecución en varios núcleos. Esa explicación puede ser útil para personas que empiezan desde cero, pero resulta incompleta. Concurrencia describe cómo se diseña el programa para dividir tareas en piezas independientes que pueden progresar sin bloquearse mutuamente, mientras que el paralelismo es una forma de ejecución física que aprovecha varios núcleos o máquinas.

Jonathan Bodner define la concurrencia como descomponer un proceso en componentes independientes y especificar cómo esos componentes comparten datos de forma segura. Esa definición es muy útil para entender por qué la concurrencia es más un patrón de diseño y coordinación que una propiedad de hardware. Pensar en concurrencia como separación de responsabilidades permite escribir aplicaciones más mantenibles y escalables.

Introducción: Las reglas de firewall de entrada con destino en una cuenta de servicio permiten aplicar políticas de red a todas las máquinas virtuales que ejecutan una cuenta de servicio específica independientemente de etiquetas o nombres. Este enfoque es ideal cuando se gestiona el acceso en función de la identidad del workload en lugar de etiquetas estáticas, y encaja muy bien en entornos cloud nativos donde los workloads heredan automáticamente identidades.

Paso 1 Concepto clave: Al elegir Target equal Service Account se crea una regla de ingreso que afecta a todas las VM que usan esa cuenta de servicio. Es una forma basada en identidad que facilita la gestión centralizada y reduce la fragilidad de las reglas que dependen solo de tags o nombres.

Paso 2 Crear la instancia VM y script de arranque: Prepare un script de inicio que instale nginx y configure una página simple que muestre hostname e IP. En la VM se ejecutan comandos como span>#!/bin/bash apt update apt install -y nginx apt install -y telnet systemctl enable nginx chown -R www-data:www-data /var/www/html y se crea un index html con información de la VM. Cree la VM en una subred personalizada con un comando como gcloud compute instances create myvm3-service-accounts --zone=us-central1-a --machine-type=e2-micro --network-interface=subnet=mysubnet1 --metadata-from-file=startup-script=nginx-webserver.sh. Verifique la instancia con gcloud compute instances list.

Pruebas iniciales: Antes de crear la regla de firewall intente conectar a puerto 80 usando telnet EXTERNAL_IP 80 o curl EXTERNAL_IP. Debería fallar si no existe una regla de ingreso permitiendo el puerto 80 para esa VM.

Paso 3 Crear la regla de ingreso basada en cuenta de servicio: Desde la consola VPC o usando gcloud, cree una regla con Target equals Specified service account y como Target service account seleccione la cuenta de Compute Engine correspondiente. Configure Source 0.0.0.0/0 y protocolos TCP puerto 80. En consola: VPC Networks > vpc-custom > FIREWALLS > ADD FIREWALL RULE. En gcloud puede ejecutar un comando equivalente para crear la regla especificando --target-service-accounts y --allow tcp:80.

Paso 4 Comprobar acceso: Tras crear la regla pruebe de nuevo con telnet EXTERNAL_IP 80 y curl EXTERNAL_IP y abra en navegador https://EXTERNAL_IP. Si la VM ejecuta la cuenta de servicio que coincide con la regla, la aplicación desplegada será accesible por el puerto 80.

Paso 5 Limpieza: Elimine la regla de firewall y la VM cuando ya no las necesite con comandos como gcloud compute firewall-rules delete fw-ingress-80-service-accounts y gcloud compute instances delete myvm3-service-accounts --zone=us-central1-a --delete-disks=all.

Aprendizajes clave: Target all instances es rápido pero amplio y menos seguro. Target tags es útil para agrupar por función. Target service accounts es identity based y más dinámico, recomendado para arquitecturas cloud native donde los workloads heredan identidades. Este método facilita auditoría, políticas basadas en identidad y escalabilidad operativa.

Montar un clúster de Kubernetes en Ubuntu 24.04 debería ser directo, pero en la práctica aparecen sorpresas. Aquí presento mi ruta de resolución de problemas al configurar un clúster de dos nodos en Ubuntu 24.04, con los obstáculos encontrados y las soluciones que funcionaron.

Problema inicial Paquetes y repositorios: al intentar instalar kubectl kubelet kubeadm apareció un error indicando que no se encontraban los programas. Causa y solución: Google actualizó las URLs de su repositorio en 2024 y muchos tutoriales usan las antiguas packages.cloud.google.com. Pasos que resolvieron el problema: sudo rm -f /etc/apt/sources.list.d/kubernetes.list sudo rm -f /etc/apt/keyrings/kubernetes-apt-keyring.gpg sudo apt-get update sudo apt-get install -y apt-transport-https ca-certificates curl gpg curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.31/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg echo deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.31/deb/ / | sudo tee /etc/apt/sources.list.d/kubernetes.list sudo apt-get update sudo apt-get install -y kubectl kubelet kubeadm sudo apt-mark hold kubelet kubeadm kubectl

Problema 2 Confusión con el socket CRI: al ejecutar kubeadm init apareció un mensaje para definir el crisocket. Esto ocurre cuando hay más de un runtime de contenedores instalado, por ejemplo Docker y containerd. Solución: elegir un runtime y usar el socket explícito. En mi caso opté por containerd e hice: sudo apt-get install -y containerd sudo mkdir -p /etc/containerd containerd config default | sudo tee /etc/containerd/config.toml sudo sed -i s/SystemdCgroup = false/SystemdCgroup = true/g /etc/containerd/config.toml sudo sed -i s/disabled_plugins = \\[\'cri\'\\]/disabled_plugins = \\[]/g /etc/containerd/config.toml sudo systemctl enable --now containerd sudo kubeadm init --cri-socket unix:///var/run/containerd/containerd.sock

Problema 3 Error CRI v1 Runtime API: aunque containerd estaba instalado, apareció el error runtime.v1.RuntimeService no implementado. Causa y arreglo: la configuración generada por defecto podía tener el plugin CRI deshabilitado o una config incompatible. Pasos efectivos: sudo systemctl stop containerd sudo rm /etc/containerd/config.toml sudo containerd config default | sudo tee /etc/containerd/config.toml sudo sed -i s/SystemdCgroup = false/SystemdCgroup = true/g /etc/containerd/config.toml Comprobar que disabled_plugins no incluya cri y reiniciar sudo systemctl start containerd Probar con sudo crictl version

Problema 4 Resolución de nombres del host: Ubuntu 24.04 registra 127.0.1.1 para el hostname local, pero 127.0.1.1 no es accesible desde otras máquinas del clúster. Solución: usar la IP real de la interfaz de red en /etc/hosts y en la inicialización del API server. Obtener la IP real con ip route get 8.8.8.8 y usar esa dirección en /etc/hosts y en kubeadm init como --apiserver-advertise-address=192.168.1.244

Problema 5 Puerto 6443 ya en uso: tras varios resets seguía apareciendo el error de puerto en uso. La limpieza a fondo fue la clave: sudo kubeadm reset --force --cri-socket unix:///var/run/containerd/containerd.sock sudo rm -rf /etc/kubernetes/ sudo rm -rf /var/lib/etcd/ sudo rm -rf /var/lib/kubelet/ sudo rm -rf ~/.kube/ sudo rm -rf /etc/cni/net.d/ sudo iptables -F && sudo iptables -t nat -F && sudo iptables -t mangle -F && sudo iptables -X sudo pkill -f kube-apiserver sudo pkill -f etcd sudo pkill -f kubelet sudo systemctl restart containerd sudo systemctl restart kubelet

Problema 6 El nodo worker no alcanza el control plane: al intentar unir el worker apareció timeout al pedir la config del cluster. Aunque la IP era correcta, no había conectividad. En mi caso influyeron factores como ejecutar Tailscale solo en el control plane, reglas de firewall y complejidad de la red virtualizada de las VM.

La solución final y lección aprendida: a veces empezar de cero es la mejor opción. En vez de seguir depurando un entorno con muchos elementos cambiantes, hice lo siguiente: crear una VM limpia configurar primero Tailscale antes de instalar cualquier componente de Kubernetes elegir un solo runtime de contenedores desde el principio usar las IP de Tailscale para toda la comunicación del clúster Esto simplificó el enrutamiento, evitó problemas de firewall y eliminó la confusión de IPs y runtimes.

Puntos clave y recomendaciones: Google cambió las URLs de repositorio para Kubernetes en 2024, usar pkgs.k8s.io. En Ubuntu 24.04 containerd necesita SystemdCgroup habilitado. Siempre especificar el CRI socket cuando haya más de un runtime. No usar 127.0.1.1 para clústeres multinodo, usar la IP de red real o las IPs de una red overlay como Tailscale. Al resetear kubeadm limpiar directorios, iptables y procesos colgados. Los problemas de conectividad de red son los más difíciles de depurar; considerar redes overlay o VPN desde el inicio.

Viaje de 3 días: CI/CD desde cero

La semana pasada participé en el Chattingo Mini-Hackathon con un objetivo ambicioso: construir una canalización CI/CD completa desde cero. La idea en papel era simple pero en la práctica exigía mucho trabajo, porque quería un flujo automatizado que compilara, probara y desplegara aplicaciones directamente a producción usando Docker, Jenkins y Nginx en un VPS.

Día 1: Fundamentos con Docker y VPS

El primer día dediqué tiempo a asegurar la base. Contenericé la aplicación con Docker para garantizar que se ejecutara igual en cualquier entorno. Levanté un VPS, configuré SSH y reforcé la seguridad con reglas de firewall. Instalé las dependencias necesarias y dejé un entorno estable y reproducible, listo para la automatización. Fue como poner los cimientos antes de levantar la casa.

Día 2: Construyendo la pipeline en Jenkins

El segundo día fue el más emocionante. Diseñé una pipeline en Jenkins con etapas claras de build, test y deploy. Cada vez que hacía push al repositorio, Jenkins construía la imagen Docker, ejecutaba las pruebas automatizadas y desplegaba a producción. Ver mis commits viajar desde Git hasta Docker y finalmente a producción fue muy satisfactorio.

Día 3: Pruebas en producción y documentación

El último día validé el flujo en producción y realicé pruebas end to end. Surgieron un par de incidencias menores que resolví rápidamente. Cerré el trabajo documentando todo el proceso para que cualquiera pudiera repetir la configuración y preparé un video demo que mostrara el resultado final.

Lecciones aprendidas

En solo tres días gané experiencia práctica en empaquetado con Docker, automatización de pipelines con Jenkins, despliegues en VPS y la importancia de la documentación para proyectos reproducibles. La pipeline obtuvo una puntuación de 34/40 en el hackathon, lo que confirmó que la solución era robusta y cumplía la mayoría de los requisitos.

Sobre Q2BSTUDIO y próximos pasos

Las aplicaciones empresariales enfrentan retos únicos que las distinguen de aplicaciones de escritorio o web sencillas. Deben gestionar lógica de negocio compleja, manejar grandes volúmenes de datos, soportar acceso concurrente, integrar múltiples sistemas y garantizar alta disponibilidad. Los patrones de diseño de arquitectura empresarial ofrecen soluciones probadas para abordar estos retos y mejorar la mantenibilidad, la escalabilidad y la seguridad.

Qué diferencia a una aplicación empresarial: lógica de negocio compleja, persistencia de datos en múltiples fuentes, acceso concurrente de usuarios, integración con servicios externos, distribución de componentes y requisitos de rendimiento. Estos factores condicionan la elección de patrones como modelo de dominio, repositorios, unidad de trabajo y capas de servicio.

Categorías centrales de patrones: patrones de lógica de dominio, patrones arquitectónicos de origen de datos, patrones object relational, patrones para presentación web, patrones de distribución, patrones de concurrencia offline, gestión de estado de sesión y patrones base. Cada grupo ayuda a separar responsabilidades y facilita la evolución del sistema.

Patrón Modelo de Dominio: organiza la lógica de negocio en objetos ricos que combinan datos y comportamiento. En un sistema de gestión de pedidos, las entidades como pedido, línea de pedido y producto encapsulan reglas como validaciones de stock, cálculo de totales y estados de pedido. Esto facilita pruebas unitarias y mantiene las reglas de negocio cerca de los datos que afectan.

Patrón Repositorio: centraliza el acceso a datos permitiendo abstraer la persistencia de la lógica de negocio. Un repositorio para pedidos ofrece operaciones como guardar, buscar por identificador o buscar por cliente, y permite cambiar la implementación de almacenamiento sin alterar el dominio. Esto mejora la testabilidad y la flexibilidad frente a múltiples fuentes de datos.

Patrón Unidad de Trabajo: supervisa objetos nuevos, modificados y eliminados durante una transacción y coordina su escritura en la capa de persistencia. Esto asegura consistencia y atomicidad de los cambios relacionados, evitando estados intermedios incoherentes en caso de errores o concurrencia.

Patrón Capa de Servicio: define los límites operativos de la aplicación y expone operaciones de alto nivel para clientes y interfaces. Una capa de servicio orquesta validaciones, consultas a inventario, procesamiento de pagos y llamadas a repositorios, manteniendo la lógica de coordinación separada del dominio y de la infraestructura.

Ejemplo de alto nivel en comercio electrónico: al recibir un pedido, la capa de servicio valida inventario mediante un servicio de inventario, crea el modelo de dominio con líneas de pedido, delega el procesamiento de pago a un servicio especializado y utiliza la unidad de trabajo para persistir el pedido y reservar stock. Si algún paso falla, la unidad de trabajo y las estrategias de compensación garantizan la consistencia.

Integración y distribución: en arquitecturas distribuidas conviene aplicar patrones de mensajería asincrónica, circuit breaker y backoff exponencial para tolerancia a fallos. Para escalabilidad, separar lectura y escritura, usar cachés y diseñar contratos de integración estables reducirá la complejidad operativa.

Concurrencia y consistencia: cuando varios usuarios modifican los mismos datos, técnicas como control optimista de concurrencia, versionado de entidades y patrones de reconciliación offline ayudan a mantener integridad sin sacrificar experiencia de usuario.

Beneficios de aplicar estos patrones: separación de responsabilidades, mayor testabilidad mediante inyección de dependencias, flexibilidad para cambiar tecnologías de almacenamiento, consistencia transaccional con unidad de trabajo y una base escalable para crecimiento futuro. Las desventajas potenciales incluyen complejidad añadida y sobrecarga en proyectos muy simples, por eso es clave aplicar patrones cuando aporten valor real.

Los asistentes de programación impulsados por inteligencia artificial han transformado los flujos de trabajo de desarrolladores en los últimos años. Herramientas como GitHub Copilot o Codeium son populares, pero Qwen Code, proyecto open source del equipo Qwen de Alibaba, está marcando una diferencia con su enfoque abierto y sus recientes mejoras en las versiones v0.0.10 y v0.0.11. Estas actualizaciones buscan ofrecer una experiencia de desarrollo más fluida, inteligente y productiva, ideal para equipos que necesitan control, privacidad y flexibilidad.

Por qué Qwen Code destaca en 2025: su naturaleza open source permite forkear, personalizar o incluso desplegar localmente para entornos sensibles a la privacidad. Tiene además una mentalidad local first que facilita integraciones sin depender permanentemente de APIs en la nube. Al formar parte de la familia Qwen, se beneficia de las mismas mejoras que impulsan sus modelos LLM, lo que lo hace atractivo para quien busca asistentes sin vendor lock in y con evolución rápida.

Principales novedades de v0.0.10 y v0.0.11: una de las incorporaciones más relevantes son los subagents, pequeños agentes especializados que descomponen tareas complejas. En lugar de un único agente intentando resolver todo, los subagents pueden encargarse por ejemplo del esquema de base de datos, de actualizar endpoints de API o de modificar componentes frontend. Ventaja práctica: al añadir una nueva funcionalidad wishlist en una app de comercio electrónico, los subagents pueden coordinar cambios de backend, generar UI frontend y proponer actualizaciones de documentación sin solaparse.

Otra novedad es la herramienta Todo Write que integra la gestión de tareas dentro de la sesión de codificación. Mantener pendientes dentro del contexto del asistente ayuda a afinar sugerencias y priorizar acciones sin depender de notas externas. Además Qwen Code ahora muestra un resumen Welcome Back al reabrir un proyecto, indicando los archivos editados, tareas pendientes y el contexto de cambios recientes, una función ideal para retomar proyectos secundarios o tareas interrumpidas.

La estrategia de caché es ahora configurable para adaptarse a distintos tipos de proyectos: priorizar velocidad en aplicaciones pequeñas o eficiencia de memoria en monorepos. En el plano de rendimiento se han introducido mejoras que eliminan bucles de edición frustrantes, pruebas de estrés de terminal integradas, menos reintentos y manejo de login más robusto, optimización en la lectura de archivos para repositorios grandes, mejor integración con IDE y shells, soporte mejorado para MCP y OAuth, y una gestión de memoria y sesión que mantiene la coherencia de conversaciones largas. La documentación multilingüe también se ha ampliado para equipos globales.

Integraciones prácticas: mantener la documentación actualizada suele ser un reto, y herramientas como Deepdocs ayudan a sincronizar código y documentación para que al refactorizar o añadir funciones la guía del proyecto no quede desfasada. Combinado con Qwen Code, esto facilita flujos donde el código y la documentación evolucionan al mismo compás.

Qué significa esto para las empresas y desarrolladores: onboarding más rápido gracias a los resúmenes Welcome Back y los Todos, colaboración mejorada por la división de trabajo entre subagents, menor dependencia de roadmaps comerciales gracias al open source y mayor estabilidad diaria por las optimizaciones de rendimiento. Para equipos que trabajan en soluciones de gran escala o en proyectos sensibles, estas mejoras reducen fricciones y aceleran el desarrollo.