Code File Catcher: una herramienta para dar contexto a tus consultas a la IA

Muchas veces, cuando queremos pedir ayuda a una IA para depurar un fallo, revisar una estructura o mejorar un código, necesitamos enviar más que una simple función. Necesitamos compartir el contexto completo del proyecto: otros archivos, dependencias, configuraciones, etc.

Los entornos de desarrollo incluyen un navegador de archivos para moverte entre los distintos ficheros de un proyecto pero, en la mayoría de los casos, el navegador de archivos incluye alguna barrera de dificultad o la cantidad de ficheros es bastante grande lo que dificulta la tarea a los desarrolladores con discapacidad o con poca destreza a la hora de moverse en su entorno de desarrollo. Con Code File Catcher puedes hacer eso fácilmente.

Code File Catcher es una aplicación sencilla pero poderosa que te permite seleccionar una carpeta de tu disco, elegir los tipos de archivos de código que quieres incluir, y obtener automáticamente un texto con todo el contenido de esos archivos perfectamente organizado y listo para copiar o exportar.

Esto resulta especialmente útil si estás trabajando con asistentes de inteligencia artificial como ChatGPT, Gemini o similares, que requieren el contexto completo del código para ofrecer respuestas precisas y útiles.

Entre las distintas operaciones que puede realizar actualmente están: recopila todos los archivos fuente relevantes de un proyecto o carpeta, muestra un texto estructurado con el nombre del archivo y su contenido y puede copiar ese texto al portapapeles o exportarlo como archivo `.txt`.

El proyecto está disponible bajo una licencia libre en GitHub. Puedes consultarlo, usarlo, modificarlo y, si lo deseas, contribuir con mejoras o sugerencias. El proyecto está abierto a colaboraciones, especialmente si pueden ayudar a que la herramienta sea aún más útil para más personas.

Puedes encontrar el código del proyecto y participar en él en el repositorio de Code File Catcher en Github.

Obtener el idioma del sistema en AppleScript

En algunos proyectos con AppleScript puede que queramos dar soporte a varios idiomas. La solución inicial pasa por distribuir nuestro fichero de AppleScript adaptado a cada uno de los idiomas que queramos incluir en el proyecto. Esta solución es poco eficiente e incrementa mucho el coste de mantenimiento.

Pero si nuestro AppleScript pudiese detectar qué idioma necesita el usuario y se pudiera adaptar la selección de cadenas de texto al idioma que necesitemos podríamos utilizar un único fichero de AppleScript para todos los idioma.

Limitaciones y soluciones para identificar el idioma

En principio AppleScript no puede acceder a la información del sistema desde su propia librería de comandos. Pero sí podemos usar otros entornos para acceder a dicha información.

Por ejemplo, con el comando defaults tenemos acceso a mucha de la información del sistema. Si ejecutamos en la Terminal de MacOS el comando defaults read NSGlobalDomain AppleLanguages por la pantalla de la Terminal aparecerá algo como:

(
"es-ES",
"en-ES"
)

Es un array o lista de los idiomas y regiones que tenemos instalado en nuestro sistema. Como buscamos obtener un resultado con el texto es que representa a Español debemos cortar todo el texto sobrante para quedarnos con ese primer elemento de la lista.

Con el comando sed podemos realizar todas estas operaciones. Enlazando el comando defaults con sed podemos obtener lo que buscamos utilizando el comando:

defaults read NSGlobalDomain AppleLanguages | sed -n '2s/[^a-zA-Z-]//gp' | cut -d '-' -f1 

Al ejecutarlo en la Terminal aparecerá:

es

Ahora podemos utilizar un comando de Terminal en un AppleScript.

Función para AppleScript

Nuestra función finalmente quedaría así:

on getSystemLanguage()
    return do shell script "defaults read NSGlobalDomain AppleLanguages | sed -n '2s/[^a-zA-Z-]//gp' | cut -d '-' -f1"
end getSystemLanguage

Becas de Formación Individual de Por Talento Digital y KeepCoding

En el marco del programa Por Talento Digital, KeepCoding y Fundación ONCE han firmado un acuerdo para ofrecer becas del 80 % a personas mayores de edad y con un grado de discapacidad reconocido igual o superior al 33%.

Estas becas permiten el acceso a cualquiera de los bootcamps tecnológicos que ofrece KeepCoding en su sitio web. El objetivo es facilitar la inclusión laboral en uno de los sectores con mayor proyección de empleabilidad y transformación social.

Los bootcamps incluyen Una formación intensiva, actualizada y altamente orientada al empleo, en áreas como desarrollo web, inteligencia artificial, ciberseguridad o big data, entre otras.

Esta no es la primera colaboración entre Fundación ONCE y KeepCoding, ya en el 2012 se impartió la primera formación de KeepCoding para Fundación ONCE. Esto identifica a KeepCoding como una academia de formación digital concienciada y conocedora de las necesidades de las personas con discapacidad a la hora de recibir formación. Además, el enfoque formativo aplicado por Fernando Rodriguez suele ser divertido, eficaz y comprensible, sobre todo para los amantes de Star wars o el Señor de los anillos.

Puedes obtener más información sobre estas y otras becas ofrecidas por KeepCoding en su sitio web.

Tests dentro de la ingeniería del software

Dentro de la mayoría de metodologías de diseño y desarrollo de software existe un apartado enfocado a las comprobaciones de las funciones, aspecto y comportamiento de una aplicación. Es lo que se conoce como testing dentro del proyecto.

Beneficios del testing

Dentro de la multitud beneficios que aporta realizar testing en nuestro proyecto se encuentran los siguientes.

  • Se pueden realizar pruebas específicas y generales del comportamiento de clases y funciones de nuestro proyecto. De esta forma podemos validar que las funciones y clases que desarrollamos dentro de nuestro proyecto cumplen los requisitos definidos por el documento de análisis.
  • Se pueden realizar pruebas completas de una experiencia de usuario. De esta forma podemos verificar que nada se ha roto cuando añadimos algún elemento nuevo a nuestro proyecto.
  • Las pruebas de uso de la aplicación se pueden automatizar para que nuestro ordenador compruebe que la aplicación funciona como se espera.
  • Además permite automatizar otros procesos que pueden resultar laboriosos o tediosos como la toma de capturas de pantalla, validación del aspecto visual de cada pantalla de la aplicación e incluso se pueden crear comprobaciones de accesibilidad en algunas plataformas para la detección temprana de barreras de accesibilidad.

Problemas del testing

Incluir testing en nuestro proyecto implica la aparición de los siguientes problemas, sobre todo si el equipo de desarrollo no está acostumbrado al uso de testing:

  • Incremento en los costes de organización y tiempo. Las pruebas o tests no se planifican ni se escriben solas. Es necesario organizar el plan de trabajo para que el testing sea correctamente incluido en la metodología de trabajo utilizada por el equipo dentro del proyecto.
  • Prevención de falsos errores. Cuando se realizan cambios visuales o funcionales dentro de una ventana o una sección de nuestra aplicación todos los tests relacionados con dicha pantalla fallarán. Es necesario que algún miembro del equipo actualice esos tests para que acepten los nuevos cambios y validar cuales son los nuevos comportamientos y aspectos válidos para el proyecto.
  • No existe la fiabilidad al completo. Aunque podamos pensar que un proyecto software siempre se comportará igual en cualquier situación cuando el proyecto es complejo también aumenta la complejidad para cubrir todos los posibles casos de uso con los tests. Incluso así es posible que nuestro conjunto de tests no detecte algún posible error o problema de funcionamiento de nuestra aplicación. Cuando esto sucede es necesario ampliar el número de tests para verificar que el error detectado no vuelva a ocurrir.

Tipos de testing

Dentro de la creación y mantenimiento de un proyecto de software existen distintas necesidades de comprobación por esta razón existen diversos tipos de testing.

Cada tipo de testing tiene un objetivo claro que ayuda a detectar y solucionar un tipo de problema específico del proyecto.

Tests funcionales

Este tipo de test comprueba si la funcionalidad de un método o función se adapta al comportamiento esperado. De esta forma podemos comprobar si una función de conversión de divisas funciona como se espera o si el cálculo de el total del precio de un pedido no comete errores.

Dentro de este tipo de tests encontramos los tests unitarios, tests de aceptación, tests de integración y tests de regresión.

Tests no funcionales

Este tipo de test representa  las pruebas que se realizan en la aplicación o producto y que no están relacionadas con el código del proyecto.

Algunas de estas pruebas son las pruebas de rendimiento, las pruebas de carga y las pruebas de estrés.

Qué es Docker

En la actualidad tanto para el uso profesional como el personal existen 3 principales plataformas o sistemas operativos para los ordenadores de escritorio: Linux, Windows y MacOS. Estas 3 plataformas publican actualizaciones y nuevas versiones para que todas las personas puedan acceder a una versión más optimizada y segura de su entorno de trabajo. Esta premisa debería permitir que una aplicación o proyecto software se pueda ejecutar en cualquier ordenador que esté corriendo la misma plataforma para la que se diseñó la aplicación pero esto no es así.

Dentro de un ordenador que está ejecutando una de las 3 plataformas que hemos mencionado antes se ejecutan multitud de procesos, programas de apoyo y se disponen de distintas librerías que hacen de herramientas de apoyo a otras aplicaciones. Cada proceso, librería y programas de apoyo también tienen sus correspondientes actualizaciones y nuevas versiones. Unido a todo esto se ha de mencionar que tanto Windows, MacOS y Linux permiten al usuario personalizar ciertas características y configuraciones que permiten al usuario optimizar su máquina a su gusto o necesidad. Por ejemplo, la configuración y personalización de un ordenador dedicado a hacer de servidor web para miles de usuarios es muy distinta a la configuración de un ordenador que se utiliza en casa para tareas educativas, ócio y personales.

En mi máquina funciona

Dentro de la ingeniería del software es muy habitual que la persona encargada del desarrollo de un proyecto no pueda utilizar el ordenador que se utilizará como servidor en producción por lo que tendrá que configurar su ordenador de trabajo con una configuración lo más semejante posible a la que tendrá ese servidor en producción. Esto casi siempre es imposible debido tanto a las diferencias en el hardware como en las posibles diferencias entre versiones y configuraciones del conjunto de librerías, procesos y programas de apoyo entre una máquina y otra.

En un primer momento la industria del software optó por el uso de máquinas virtuales pero esto implicaba que los equipos dedicados al desarrollo fuesen más potentes que los equipos de producción ya que la ejecución de una máquina virtual requería tanta potencia como la máquina anfitriona y la virtualizada.

Con el cambio de arquitectura de proyectos monolíticos a proyectos con microservicios la situación mejoró. En lugar de tener que utilizar una maquina completa para ejecutar toda la aplicación empaquetada en un único ejecutable (arquitectura monolítica) se pasó a la arquitectura de microservicios en la que un proyecto software completo se divide en muchos módulos pequeños y cada uno de estos módulos sólo se encarga de resolver uno de los problemas existiendo una comunicación interna entre cada uno de los microservicios que forman un proyecto completo.

Con este nuevo paradigma el uso de una máquina virtual para desarrollar un microservicio era innecesario ya que el microservicio requería de muy poca potencia para su ejecución tanto simulada durante el desarrollo como durante su explotación en producción. Era necesario la aparición de un nuevo método de virtualización que permitiese la ejecución de un microservicio que requiera sólo los recursos mínimos necesarios para su correcta ejecución y que al ejecutarse ya incluya todo lo necesario sin necesidad de depender de la máquina que lo ejecute. Nace Docker, un sistema de virtualización muy pequeño especializado en la ejecución de microservicios.

De esta forma un desarrollador instala Docker para crear sus entornos de ejecución y desarrollar su microservicio. Una vez desarrollado puede instalar Docker en la máquina de producción, trasladar el microservicio desarrollado y ejecutarlo en la máquina final. Como Docker facilita que el microservicio se ejecute siempre con la misma configuración en cualquier máquina ya no sucede el problema de que en la máquina de desarrollo todo iba bien y en producción todo va mal.

En conclusión podemos decir que Docker es una herramienta que permite ejecutar programas y aplicaciones de forma aislada, sin que se afecten entre sí. Es como una caja virtual que contiene todo lo que un programa necesita para funcionar correctamente. Esto facilita la instalación, ejecución y distribución de aplicaciones en diferentes máquinas.