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.

Programar a ciegas RSS vuelve a estar disponible para iOS

La app Programar a ciegas RSS vuelve a estar disponible en la AppStore para poder leer con más comodidad los artículos de este sitio web.

Podéis encontrar más información en la página de ProgramarACiegas RSS en Tyflos Accessible Software.

Dentro de las novedades de esta versión se incluyen las siguientes:

  • Toda la app se ha rehecho utilizando SwiftUI y las últimas librerías de Apple para proporcionar la experiencia más accesible posible.
  • La aplicación ahora incluye persistencia de la información utilizando Realm para poder leer los artículos en cualquier momento.
  • Con esta nueva reconstrucción de la app es posible la publicación en otras plataformas como MacOS, TvOS, WatchOS o VisionOS si el feedback de los usuarios así lo piden.

Qué es Fastlane

Dentro del desarrollo de software es habitual que los entornos de desarrollo incluyan muchas herramientas para realizar tareas relacionadas con el mantenimiento y la publicación de una aplicación software. Pero la mayoría de estas herramientas integradas en los entornos de desarrollo funcionan de forma manual requiriendo una completa atención por parte de la persona que está desarrollando el software.

La automatización de procesos dentro de la ingeniería del software se ha demostrado como uno de los caminos más beneficiosos para aumentar la productividad y la fiabilidad del software. Por esta razón han ido apareciendo multitud de herramientas que permiten realizar más tareas y procesos que los entornos de desarrollo y, sobre todo, automatizar estos procesos.

¿Qué es Fastlane?

Fastlane es una de estas herramientas que permiten automatizar muchos de los procesos y tareas relacionadas con el desarrollo de software para iOS y Android.

Esta herramienta creada por Felix Crause consiste en un conjunto de servicios y aplicaciones ejecutadas desde la línea de comandos (CLI) utilizando lenguaje Ruby y permite automatizar muchos de los procesos que se realizan con Android Studio y Xcode.

Entre las diversas tareas que permite automatizar Fastlane están las siguientes:

  • Creación de capturas de pantalla para la tienda de aplicaciones
  • Despliegue de la app dentro de entornos de betatesting como Test flight.
  • Publicación del proyecto en la tienda de aplicaciones
  • Firma de paquetes de software para la distribución del proyecto
  • Ejecución de planes de tests

Como todas estas automatizaciones se ejecutan desde la línea de comandos es muy fácil incluir scripts de la Terminal para realizar comprobaciones o actualizaciones de recursos para la distribución de nuestro proyecto software.

En futuros artículos veremos algunas de estas automatizaciones con más detalle.

La instalación de fastlane es muy sencilla y su uso consiste principalmente en la ejecución de ciertos comandos de Terminal en la propia carpeta raíz de nuestro proyecto software. Este uso de la Terminal hace que el uso de Fastlane resulte más accesible que utilizar ciertas herramientas visuales incluidas en Xcode o Android studio.

Puedes obtener documentación, ejemplos y más información en la página oficial de Fastlane.

Obtener el contenido del portapapeles con AppleScript

Ya hemos visto que en AppleScript podemos acceder a mucha de la información que está disponible en nuestro equipo pero aún no hemos visto una de las funciones más simples y útiles de los sistemas operativos modernos: el portapapeles.

El portapapeles es un espacio en memoria donde se aloja una copia del contenido que hayamos copiado o cortado con las funciones del sistema operativo.

¿Para qué podemos querer acceder a la información de portapapeles desde un script? Pues desde una simple función para mostrar el contenido del portapapeles en un cuadro de diálogo para verificar qué tenemos almacenado en esa memoria o para crear un script que nos traduzca el texto del portapapeles al idioma que necesitemos.

Con AppleScript podemos acceder a ese espacio de memoria utilizando la variable the clipboard. Esta variable de AppleScript puede almacenar cualquier tipo de contenido como imágenes, texto, audio o la información de un fichero de una carpeta. Esto nos obliga a convertir esta información en algo comprensible para nuestro script.

Veamos un ejemplo en el que obtenemos como texto la información guardada en el portapapeles:

set clipboardContent to (the clipboard as text)

Con esto podemos crear un script para verbalizar el contenido del portapapeles utilizando la voz del sistema. El código sería algo como esto:

set clipboardContent to the clipboard as text

say clipboardContent

Este código funciona pero no tiene en cuenta si en el portapapeles el contenido que está almacenado es convertible a texto. Para evitar posibles errores de ejecución de nuestro script debemos emplear un bloque try que nos permita controlar errores de ejecución en un script. El código quedaría así:

try

  set clipboardContent to the clipboard as text

  say clipboardContent

on error

  say "El portapapeles no contiene texto"

end try

Con esta modificación nuestro script siempre verbalizará algo aunque sea para notificarnos que el contenido de nuestro portapapeles no es texto.

Regla YAGNI – You aren’t gonna need it

La última de las 5 reglas para escribir software simple y robusto es la regla de YAGNI. Su acrónimo traducido dice: no lo vas a necesitar.

En muchas ocasiones cometemos el error de hacer sobreingeniería en un proyecto. Esto significa que el cliente nos ha pedido una calculadora para hacer sumas y terminamos desarrollando una hoja de cálculo con soporte para funciones y un lenguaje propio de scripting. Esto provoca que el mantenimiento y el esfuerzo para desarrollar y mantener el proyecto se ha sobredimensionado de forma incontrolada e innecesaria.

Para evitar caer en este código innecesario o código YAGNI debemos centrarnos en los requerimientos del producto final, no desarrollar código que no se esté utilizando en el proyecto, eliminar el código comentado (Si está comentado es que no es necesario) y utilizar ciertos patrones de trabajo como TDD (Test Driven Development) o trabajar con PullRequests pequeñas enfocadas en aspectos muy específicos de un requerimiento o característica del proyecto. También realizar procesos de refactorización del código al terminar un plazo de entrega o el desarrollo de un módulo facilita la desaparición de código YAGNI.

Regla SOC – Separation of concerns

Dentro de las reglas para escribir software simple y robusto tenemos la regla de SOC cuyo acrónimo significa Separation of concerns. Esto se traduce como separación de intereses. Este término de ingeniería fue creado por Edsger Dijkstra en un artículo para indicar la necesidad de centrar la atención en aspectos específicos dentro de las distintas estructuras de manipulación de la información dentro del software. Esta separación de intereses dentro del software se puede aplicar a nivel de arquitectura del proyecto y a nivel de codificación de los métodos y funciones.

Arquitectura de intereses

A nivel de arquitectura debemos agrupar los distintos intereses dentro de módulos o microservicios. Cada módulo o servicio deberá encargarse de un aspecto del proyecto.

Se busca que cada módulo o microservicio sea independiente y tengan claras sus responsabilidades.

Dentro de la modularización del código se aplican patrones de diseño como MVC (Modelo vista controlador), MVP (Modelo vista presentador) y patrones de diseño similares. Esta forma de organizar el código nos permite diferenciar cláramente las clases relacionadas con el modelo de datos, la interfaz de usuario y la forma de presentar y manipular los datos en la interfaz de usuario. 

Aplicando estos patrones de diseño a la hora de modularizar nuestro código podremos realizar modificaciones en la interfaz de usuario sin necesidad de afectar al modelo de datos o a la lógica de negocio ya que las responsabilidades de cada parte del módulo están conceptualmente definidas.

Separación del código por intereses

Para separar el código por intereses se debe realizar un ejercicio de análisis observando desde el punto más alto de abstracción de nuestro proyecto, tanto en funcionalidad como en la información que se manipula, hasta delimitar la responsabilidad y relación entre las distintas clases y módulos del proyecto.

Con este esfuerzo se busca obtener las siguientes ventajas: eliminar la posible duplicación en la lógica de negocio, ampliar la capacidad de mantenimiento del proyecto, incremento de la cohesión entre clases y reducción del acoplamiento entre clases y módulos.

Una vez realizado este análisis se aplican distintos paradigmas de programación como la programación orientada a aspectos, arquitectura hexagonal, inyección de dependencias y la separación de métodos por responsabilidad.