Más contenido sobre aplicaciones a medida, tendencias en inteligencia artificial y estrategias efectivas para proyectos tecnológicos exitosos.

Capítulo F Práctica con LangChain usando Google Gemini y DuckDuckGo: en este artículo práctico explicamos paso a paso cómo crear una aplicación basada en LangChain que conecta el modelo Gemini de Google con una herramienta de búsqueda como DuckDuckGo para obtener información en tiempo real y generar resúmenes inteligentes.

Requisitos previos: Python 3.8 o superior, una clave de API de Google obtenida desde Google AI Studio y conocimientos básicos de Python. También es recomendable tener acceso a un entorno como Google Colab o un entorno virtual local para instalar dependencias.

Instalación: instala los paquetes necesarios con el comando pip install -U langchain langchain-google-genai langchain-community duckduckgo-search. Descripción de cada paquete: langchain es el framework para encadenar modelos LLM con herramientas, langchain-google-genai es el conector para Google Gemini, langchain-community aporta integraciones mantenidas por la comunidad como DuckDuckGo y duckduckgo-search habilita búsquedas web desde LangChain.

Configuración de claves API: guarda tu clave en las variables de entorno para mayor seguridad, por ejemplo usando os.environ[GOOGLE_API_KEY] = your_api_key o configurando las variables en el sistema o en secretos de Colab. Evita dejar la clave en el código fuente público.

Carga del modelo Gemini: importa el conector from langchain_google_genai import ChatGoogleGenerativeAI y crea la instancia del modelo indicando el modelo gemini-1.5-flash. Gemini 1.5 Flash es una opción rápida y optimizada para respuestas ágiles y actúa como el LLM central que generará el texto.

Incorporación de la herramienta de búsqueda: desde langchain_community.tools importa DuckDuckGoSearchResults y crea una instancia search = DuckDuckGoSearchResults(). Esta herramienta permite al LLM consultar la web y obtener contexto actualizado cuando la información supera el conocimiento de entrenamiento del modelo.

Plantilla de prompt: usa ChatPromptTemplate para construir prompts dinámicos, por ejemplo ChatPromptTemplate.from_template(Search the web and summarize the latest news about {topic}.) El marcador {topic} permite reutilizar la plantilla para cualquier tema.

Construcción de cadenas: combina las piezas con LLMChain y SequentialChain importando from langchain.chains import LLMChain, SequentialChain. Un LLMChain conecta un modelo con una plantilla de prompt, y un SequentialChain permite encadenar procesos como buscar y luego resumir, lo que hace la arquitectura modular y escalable.

Ejemplo de ejecución: crea una cadena global overall_chain que reciba la variable topic y devuelva text. Al invocar overall_chain con topic igual a AI in healthcare el flujo realiza la búsqueda en DuckDuckGo y Gemini resume los hallazgos produciendo un resumen claro y útil.

Por qué es importante: LangChain simplifica la orquestación entre modelos LLM y herramientas externas, Gemini aporta generación rápida y precisa y DuckDuckGo añade contexto en tiempo real. Este patrón es ideal para asistentes de investigación, agregadores de noticias y herramientas de conocimiento para empresas que necesiten soluciones de inteligencia artificial y agentes IA integrados.

Albania ha dado un paso sin precedentes al nombrar a Diella, un ministro virtual basado en inteligencia artificial, con la misión de eliminar la corrupción en la contratación pública y tomar decisiones de licitación sin intervención humana. Anunciada por el primer ministro Edi Rama el 12 de septiembre de 2025, Diella ya había funcionado como asistente virtual en la plataforma e-Albania desde enero y, según fuentes oficiales, procesó 36.600 documentos digitales, ofreció casi 1.000 servicios y ahora tiene autoridad sobre decisiones de contratación pública, operando 24/7 y manteniendo trazabilidad completa de las decisiones.

Desde la perspectiva técnica, este tipo de despliegue no es solo procesamiento de lenguaje natural o análisis documental. Requiere árboles de decisión complejos para la calificación de proveedores, algoritmos de evaluación multicriterio, integración con bases de datos gubernamentales existentes, generación de auditorías transparentes y mecanismos fail-safe para casos límite. Además plantea retos de escalabilidad, actualización sin tiempo de inactividad y mantenimiento de integridad frente a ataques adversarios.

Hay preguntas críticas que los desarrolladores debemos formular y que a menudo quedan fuera del debate público: con qué datos se entrenó a Diella y cómo se mitigó el sesgo en datos históricos de contratación; cómo se implementa un rollback cuando hay una decisión manifestamente errónea; quién tiene acceso administrativo para ajustar reglas y modelos; qué protecciones existen contra ataques de envenenamiento de datos o prompt injection; y cómo se audita el sistema para detectar manipulaciones.

Las implicaciones éticas y legales son profundas. La responsabilidad por decisiones que afectan contratos y empresas entraña un problema de rendición de cuentas: ¿responden los desarrolladores, el proveedor tecnológico, o el Estado? La transparencia total ayuda a generar confianza pero aumenta el riesgo de que actores malintencionados optimicen estrategias para explotar el sistema. Además surge el conflicto entre permitir un override humano que restaure flexibilidad y mantener la pureza del objetivo anti corrupción.

Para la industria, el experimento albanés es un A/B test a gran escala de gobernanza algorítmica. Un resultado exitoso puede acelerar despliegues gubernamentales de IA, generar demanda de sistemas de grado gubernamental y crear nuevas demandas en cumplimiento normativo, explicabilidad y auditoría de decisiones automatizadas. Si fracasa, dejará lecciones valiosas sobre los límites de la automatización en sistemas sociopolíticos complejos.

Como desarrolladores, estas son algunas lecciones prácticas que debemos asumir: diseñar para auditabilidad desde el primer día, registrando trazas de decisión y motivos explicables; contemplar el esquema human-in-the-loop con rutas claras de escalado y revisión; priorizar la seguridad frente a usos adversariales; y balancear rendimiento técnico con requisitos de confianza, transparencia y responsabilidad.

El caso también plantea un reto constitucional y jurídico. Líderes de la oposición han cuestionado la legitimidad del estatus ministerial de Diella y si el software puede ejercer funciones públicas con efectos legales. Esto obliga a pensar cómo el código y los modelos respetan principios constitucionales y cómo se resuelven conflictos entre salidas algorítmicas y precedentes legales.

Ingeniería inversa de la realidad con IA de Google presenta una herramienta creativa llamada Reverse Engineering Reality que permite a cualquier usuario subir la foto de un objeto cotidiano y, mediante inteligencia artificial avanzada, recibir un plan detallado e imaginativo para montarlo o desmontarlo desde cero.

La aplicación transforma la curiosidad en experiencia activa y educativa: lo que empieza como un pensamiento tipo me pregunto cómo está hecho se convierte en una guía práctica con lista de materiales, herramientas necesarias, pasos detallados e ilustraciones personalizadas que fomentan la comprensión del diseño y la ingeniería detrás de los objetos.

En la demostración se puede probar el applet desplegado en Cloud Run y experimentar cómo la visión computacional se combina con generación de contenido para crear un blueprint ficticio pero coherente de elementos del mundo real.

Para su desarrollo se ha empleado la API de Gemini, la misma tecnología que potencia Google AI Studio, aprovechando modelos como gemini-2.5-flash por su rapidez y razonamiento y imagen-4.0-generate-001 para la generación de imágenes. El flujo incluye salida estructurada en JSON para garantizar respuestas previsibles y fáciles de parsear, instrucciones de sistema que convierten al modelo en un experto en ingeniería inversa y un asistente conversacional mediante ai.chats.create que mantiene el contexto y permite preguntas de seguimiento naturales.

La solución es multimodal: convierte imagen a texto para generar el blueprint, realiza detección de objetos devolviendo nombres y coordenadas de bounding boxes para que el usuario seleccione el elemento de interés y usa un pipeline texto a imagen para crear diagramas e ilustraciones por paso. Este encadenamiento de análisis visual, generación textual y creación gráfica provoca una experiencia interactiva y enriquecida.

Introducción: Un servicio de acortador de URLs convierte una URL larga como https://example.com/some/very/deep/path en un alias mucho más corto como https://short.ly/aBcD12. Cuando un usuario accede a la URL corta, se le redirige a la URL original. Ejemplos comerciales incluyen TinyURL y Bitly.

Requisitos funcionales principales: permitir acortar una URL larga, redirigir desde la URL corta hasta la original y ofrecer analítica básica por enlace. Soporte para hasta 100M DAU con una relación lectura/escritura de 100:1, con alrededor de 1M de escrituras al día y retención de datos por 5 años.

Requisitos no funcionales: alta disponibilidad 24/7, latencia baja en redirecciones objetivo cercano a 200 ms y alta durabilidad para garantizar persistencia ante fallos de servidores.

APIs sugeridas: POST /api/urls/shorten con body JSON que incluya longUrl devuelve shortUrl. GET /:shortcode que devuelve o realiza un redirect 301/302 hacia la longUrl.

Flujo de alto nivel: el cliente envía una POST al API Gateway con la URL larga. El gateway enruta a un servicio de acortado que genera un shortCode, persiste la relación shortCode a longUrl en la base de datos y devuelve la shortUrl al cliente. Cuando alguien accede a la shortUrl, el gateway dirige la solicitud al servicio de redirección que consulta la base de datos y responde con un 301 o 302 indicando la ubicación final.

Mecanismo de redirección: el servicio de redirección realiza una búsqueda por shortCode y responde con HTTP 302 Found o 301 Moved Permanently y el header Location apuntando a la URL larga. Use 302 si la asignación puede cambiar y no debe ser cacheada permanentemente por navegadores o motores de búsqueda; use 301 cuando la relación sea realmente permanente y deba ser indexada como tal.

Elección de base de datos: un almacén NoSQL tipo key value es ideal para un acortador de URLs por la simplicidad de las consultas shortCode a longUrl, alta escalabilidad horizontal y baja latencia. Opciones recomendadas incluyen DynamoDB o Cassandra para alta disponibilidad y rendimiento en lectura intensiva.

Modelo de datos mínimo: URL objeto con campos shortcode, longUrl, createdAt y opcionalmente userId. Tabla de usuarios separada para gestión de cuentas y permisos. Diseñe índices adecuados sobre el campo shortcode para acelerar búsquedas de redirección.

Optimización para lectura intensiva: añadir una capa de caché en memoria como Redis para almacenar las mappings más populares reduce lecturas al backend y mejora la latencia. Use TTL o políticas LRU para gestión de memoria y caches en borde si aplica.

Métodos de generación de shortCode: contador global con codificación Base62 para códigos muy cortos y sin colisiones pero que exige coordinador central; cadenas aleatorias Base62 con verificación de colisiones para escalado horizontal y mejor privacidad; hashing de la URL para idempotencia a costa de riesgo de colisiones; o UUIDs codificados cuando se requiere unicidad global aunque con códigos más largos. Para la mayoría de implementaciones Small/Medium la opción aleatoria con verificación de colisión ofrece buen equilibrio.

Escalado y disponibilidad: shardear la base de datos para distribuir carga, usar balanceadores para repartir solicitudes entre instancias, y emplear una CDN para cachear redirecciones en el borde y reducir latencia global. Diseñar estadísticas y telemetría para identificar hot spots y balancear tráfico según consumo.

Analítica y métricas: registre eventos de redirección con agregaciones para clicks diarios, origen geográfico, y parámetros de campaña. Considere almacenar metadatos por URL para soporte de campañas y expiraciones. Respete la privacidad y regulaciones aplicables al almacenar datos de usuarios.

Esta es una propuesta para el Google AI Studio Multimodal Challenge. Lo que hemos construido es el applet Forja de Sabores, una herramienta que ayuda a crear recetas nuevas a partir de los ingredientes que el usuario introduce. Forja de Sabores aprovecha las capacidades multimodales de Gemini para sugerir recetas sabrosas y originales, resolviendo la pregunta qué cocino esta noche al transformar unos pocos ingredientes en una receta completa con instrucciones detalladas.

Cómo lo usamos en Google AI Studio: el applet fue diseñado y desplegado íntegramente desde Google AI Studio y publicado en Cloud Run. Utiliza la API de Gemini para analizar listas de ingredientes en tiempo real y generar recetas creativas, equilibradas desde el punto de vista nutricional y optimizadas por algoritmo para adaptarse a preferencias y restricciones del usuario.

Características multimodales: el motor culinario analiza texto e imágenes de ingredientes cuando el usuario los carga, interpretando contextos como cantidades, cortes o conservaciones para generar instrucciones paso a paso, tiempos de cocción y sugerencias de acompañamiento. El prompt al modelo está cuidadosamente construido para incluir la lista de ingredientes y solicitar una receta detallada con instrucciones, permitiendo al modelo comprender el contexto más allá de una simple búsqueda y ofrecer una experiencia culinaria única.

Sobre Q2BSTUDIO: Forja de Sabores es un ejemplo de cómo aplicamos inteligencia artificial al desarrollo de aplicaciones prácticas. Q2BSTUDIO es una empresa de desarrollo de software especializada en aplicaciones a medida y software a medida, con experiencia en inteligencia artificial, ciberseguridad, servicios cloud aws y azure, y servicios de inteligencia de negocio. Ofrecemos soluciones de ia para empresas, desarrollo de agentes IA y proyectos de Power BI que ayudan a extraer valor de los datos.

En este artículo relato la experiencia de Q2BSTUDIO usando PgBouncer con una aplicación Django en producción, por qué lo necesitamos, cómo lo instalamos y qué problemas nos obligaron a aplicar trucos y ajustes concretos. Q2BSTUDIO es una empresa de desarrollo de software y aplicaciones a medida especializada en software a medida, inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio y soluciones como agentes IA y power bi para empresas.

Por qué añadimos PgBouncer: nuestro backend no estaba permanentemente saturado, pero durante campañas publicitarias sufríamos picos de tráfico que abrían cientos de conexiones al servidor PostgreSQL. Cada nueva conexión implica handshake TCP, autenticación y, si usamos TLS, una negociación adicional, además de consumir memoria y CPU en el servidor. Cuando el número de conexiones supera max_connections en, por ejemplo, Amazon RDS, las nuevas conexiones pueden fallar. PgBouncer mantiene un conjunto fijo de conexiones calientes hacia la base de datos y sirve conexiones a los clientes de forma inmediata desde ese pool, reduciendo el coste por conexión y protegiendo al servidor Postgres del overhead.

Instalación y elección de despliegue: instalar PgBouncer es sencillo, existe imagen oficial Docker o compilación desde fuentes. Nosotros elegimos Docker para integrarlo con ECS en nuestro pipeline. La pieza central es el fichero de configuración pgbouncer.ini o variables de entorno en el contenedor. Parámetros que usamos en producción: PGBOUNCER_LISTEN_ADDRESS=*, PGBOUNCER_POOL_MODE=transaction, PGBOUNCER_PORT=6432, PGBOUNCER_MAX_CLIENT_CONN=1000, PGBOUNCER_DEFAULT_POOL_SIZE=80, PGBOUNCER_MIN_POOL_SIZE=30, PGBOUNCER_AUTH_TYPE=md5, POSTGRESQL_PASSWORD=<TU_PASSWORD>, POSTGRESQL_HOST=<TU_HOST>, POSTGRESQL_PORT=<PUERTO>, POSTGRESQL_USERNAME=<USUARIO>, POSTGRESQL_DATABASE=<DB>, PGBOUNCER_DATABASE=<PGBOUNCER_DB>. Observaciones sobre parámetros importantes: PGBOUNCER_LISTEN_ADDRESS determina en qué interfaz escucha; usar asterisco implica exponerlo en todas las interfaces, así que asegure sus security groups y preferiblemente use la IP privada del host. PGBOUNCER_POOL_MODE define el modo de pooling; describo opciones más abajo. PGBOUNCER_MAX_CLIENT_CONN limita clientes totales, DEFAULT_POOL_SIZE es el número de conexiones calientes por par usuario:base de datos, MIN_POOL_SIZE mantiene conexiones mínimas para reducir latencia y AUTH_TYPE define método de autenticación. Trate PgBouncer como si fuera una puerta de entrada a la base de datos: restrinja el acceso a la red de confianza y aplique las mismas políticas de seguridad que para el Postgres original.

Modos de pooling: existen session, transaction y statement. Statement es el más agresivo y el menos compatible porque rompe transacciones; session es el más compatible y el menos eficiente; transaction está en medio y suele ser la opción por defecto para muchas apps Django. En nuestro flujo probamos session en desarrollo, luego pasamos a transaction en producción por rendimiento y tuvimos que resolver varios efectos secundarios.

Problemas y soluciones que encontramos al usar transaction mode con Django

1 Migrations: operaciones como CREATE INDEX CONCURRENTLY o DROP INDEX CONCURRENTLY o el uso de locks de sesión fallan porque Django envuelve migraciones en transacciones y PgBouncer en transaction pooling puede cambiar la conexión entre pasos. Solución: ejecutar migraciones contra Postgres directamente sin pasar por PgBouncer, por ejemplo exportando variables para que la conexión apunte a Postgres y ejecutando python manage.py migrate

2 Search path y settings de sesión: al usar un esquema personalizado y depender de search_path en la conexión, en transaction pooling cada consulta puede aterrizar en un backend distinto y perder settings de sesión como SET search_path, SET ROLE o SET TIMEZONE. Esto genera tablas fantasma en public o consultas que no encuentran objetos. Solución: convertir el esquema personalizado en el predeterminado a nivel de rol con ALTER ROLE tu_usuario SET search_path = tu_esquema; y eliminar la dependencia de OPTIONS -c search_path en la configuración de Django. Migramos objetos desde public a nuestro esquema mediante scripts SQL y ajustamos roles para que no dependan de configuraciones efímeras.

3 Cursores del lado servidor: Django puede usar cursores server side para iterar grandes querysets sin cargar todo en memoria, pero esos cursores requieren conexión fija durante toda la iteración. Con transaction pooling el cursor desaparece al liberar la conexión y aparecen errores InvalidCursorName o lecturas inconsistentes. Solución práctica: deshabilitar cursores server side en la configuración de Django OPTIONS DISABLE_SERVER_SIDE_CURSORS True. Esto fuerza a Django a traer resultados completos al cliente y evitar errores, con la advertencia de mayor uso de memoria al procesar resultsets grandes.

4 Mecanismo de fallback y alta disponibilidad de aplicación: añadimos una verificación simple para probar la conexión a PgBouncer con un timeout corto y, si falla, alternar la configuración para conectar directamente a Postgres. De este modo la aplicación degrada su comportamiento perdiendo el pooling beneficioso temporalmente, pero permanece online. Este enfoque mejora la resiliencia operacional y evita caída total por problemas en el pooler.

PgBouncer vs CONN_MAX_AGE de Django: CONN_MAX_AGE permite reutilizar la conexión por proceso y evita reabrir sockets constantemente, y es útil en muchos escenarios. Sin embargo CONN_MAX_AGE no resuelve picos cuando muchos procesos o instancias abren conexiones simultáneas resultando en cientos de clientes concurrentes hacia Postgres. PgBouncer aporta escalabilidad centralizada frente a entornos con muchos workers, autoscaling o lambdas que generan muchas conexiones. La recomendación es evaluar primero si CONN_MAX_AGE y tuning de max_connections bastan; si se esperan picos impredecibles o arquitectura con muchos procesos, PgBouncer es la solución adecuada.

Monitoreo y operativa: introducir PgBouncer añade complejidad operativa y cambios sutiles que afectan migraciones, search path y cursores. Implemente monitoreo sobre métricas de PgBouncer como cl_active, cl_waiting, sv_active, sv_idle, y monitorice latencias y fallos de autenticación. Pruebe en staging con los mismos patrones de carga y automatice rollback de configuración si detecta regresiones. En Q2BSTUDIO combinamos estas prácticas con despliegues controlados y playbooks de incident response que incluyen pasos para desconectar clientes de PgBouncer y ejecutar migraciones directamente contra Postgres cuando es necesario.

Cuando conviene adoptarlo: PgBouncer es la herramienta indicada cuando las conexiones a Postgres son un cuello de botella real y las soluciones simples no bastan. No lo añada por defecto; evalúe carga, patrón de escalado, uso de transacciones y features de sesión de su app. Si decide adoptarlo, documente los impactos en migraciones, search path y cursores, ajuste Django en consecuencia y entrene al equipo en operación de la nueva pieza.

Desde la última vez que hablé sobre los recursos que utilicé para entender qué es la programación quiero compartir el que considero el más importante. Ese recurso fue el que me dio el sentimiento de ok estoy empezando a comprender cómo funciona todo y que luego se convirtió en una sensación constante a lo largo de mi camino en el mundo del software.

Para quien no lo conozca la 42 Network es una red internacional de escuelas de programación con matrícula gratuita tras superar un proceso de selección intenso de un mes en el que se programa en una versión básica de C. Tuve la fortuna de ser seleccionado para la promoción siguiente y durante ese verano reforcé mis habilidades en C gracias al curso CS50 de Harvard. CS50 es un curso de introducción a la informática que recorre desde Scratch hasta Flask pasando por cinco semanas intensas de C donde se abordan algoritmos y estructuras de datos. Las lecciones y los problem sets de CS50 me ayudaron a confirmar que la programación era lo que quería hacer en la vida y estoy agradecido a David J. Malan Carter Zenke Doug Lloyd y Brian Yu por su trabajo y su impacto en mi formación.

Si hablamos de David J. Malan conviene mencionar que es profesor en Harvard y creador de CS50 reconocido por su estilo pedagógico enérgico y claro. Su enfoque facilita que conceptos complejos se vuelvan accesibles y aplicables tanto a quienes empiezan como a quienes buscan profundizar en temas como C seguridad o desarrollo web.

Encapsulación significa agrupar datos y funciones y restringir el acceso directo a esos datos. En programación orientada a objetos la encapsulación es envolver variables y código dentro de una clase de modo que la información sensible quede oculta y solo sea accesible a través de métodos específicos como getters y setters. Esto aporta seguridad, control, mantenibilidad y una mejor organización del código.

A continuación se muestra un ejemplo en C++ que ilustra el concepto de encapsulación traducido y adaptado al español. Observe cómo los atributos quedan declarados como private y solo se manipulan mediante métodos públicos.

<code>#include<iostream>#include<string>using namespace std;class EntradaPelicula{private:string nombrePelicula;int precioEntrada;int asientosDisponibles;public:void setDetalle(){cout<<"Pelicula: "<<nombrePelicula;cout<<"Precio entrada: "<<precioEntrada;cout<<"Asientos disponibles: "<<asientosDisponibles;}void reservar(int n){if(n<=asientosDisponibles){cout<<"Reservando "<<n<<" entradas..."<<endl;asientosDisponibles-=n;cout<<"Reserva realizada con exito! <3"<<endl;}else{cout<<"Lo siento, solo "<<asientosDisponibles<<" asientos disponibles!"<<endl;}}void disponibles(){cout<<"Asientos disponibles: "<<asientosDisponibles<<endl;}};int main(){EntradaPelicula e;e.setDetalle();int n;cout<<"Cuantas entradas desea reservar?"<<endl;cin>>n;e.reservar(n);e.disponibles();}</code>

En este ejemplo los datos internos nombrePelicula, precioEntrada y asientosDisponibles quedan protegidos por el modificador private. Solo los métodos públicos setDetalle, reservar y disponibles permiten interactuar con esos datos, evitando accesos directos que podrían dejar el objeto en un estado inconsistente.

Encapsulación significa agrupar datos y funciones y restringir el acceso directo a los datos. En programación orientada a objetos la encapsulación consiste en envolver variables y métodos dentro de una clase y mantener la información oculta y segura, accesible solo mediante funciones específicas como getters y setters. Esto aporta seguridad, control, modularidad y una mejor organización del código, facilitando mantenimiento y evolución de la aplicación.

En la práctica la encapsulación permite validar y controlar cómo se modifica el estado interno de los objetos, evitando efectos colaterales y accesos indebidos. Por ejemplo una clase que gestiona entradas de cine puede ocultar el número de asientos disponibles y exponer métodos públicos para reservar y consultar disponibilidad, garantizando reglas de negocio y coherencia.

Ejemplo en C++ traducido y simplificado: <iostream> using namespace std; class Movieticket{ private: string moviename; int ticketprice; int seatsavailable; public: void setdetail(){ cout<<"Pelicula: "; cin>>moviename; cout<<"Precio ticket: "; cin>>ticketprice; cout<<"Asientos disponibles: "; cin>>seatsavailable; } void Booking(int n){ if(n<=seatsavailable){ cout<<"Reservando "<<n<<" tickets..."<<endl; seatsavailable-=n; cout<<"Reserva exitosa!"<<endl; }else{ cout<<"Lo siento, solo "<<seatsavailable<<" asientos disponibles!"<<endl; } } void available(){ cout<<"Asientos disponibles: "<<seatsavailable<<endl; } }; int main(){ Movieticket m; m.setdetail(); int n; cout<<"Cuantos tickets quieres reservar?"<<endl; cin>>n; m.Booking(n); m.available(); }