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.

Obtener la dirección IP de tu Mac con AppleScript

En AppleScript hay varias formas de obtener información sobre el estado de la máquina que está ejecutando un script. 

Una de esas formas es mediante system info.

Con get system info obtenemos un diccionario con información sobre qué versión de MacOS, nombre de usuario, nombre completo, dirección IPv4, memoria RAM instalada y más datos interesantes.

Ejemplo básico

Con esta información es muy sencillo crear un script de AppleScript que obtenga la información de la dirección Ip de nuestra máquina y mostrarla en un cuadro de diálogo.

El código sería algo como:

set ipText to IPv4 address of (get system info)
display alert "IP: " & ipText

Código limpio con comentarios útiles

Un código con buenos comentarios ayuda a su legibilidad como vimos en el artículo sobre cómo escribir código limpio y legible.

Cada bloque de código tiene un propósito, puede recibir parámetros y puede devolver un resultado. Toda esta información debería estar explicada brevemente en un bloque comentado, preferentemente antes de los bloques de ejecución. Por ejemplo:

// Función calculaPrecioFinalDeCarrito

//    Calcula el precio final del carrito ajustando impuestos y conversión de moneda

//

// Entrada:

//    lista de productos, tipo de impuestos, tipo de moneda

// Salida:

//    precio final a pagar por el cliente

function calculaPrecioFinalDeCarrito(listaProductos, tipoDeImpuestos, tipoMoneda) {

    var precioSinImpuestos = calculaPrecioDeListaDeProductos(listaProductos)

    var precioConImpuestos = calculaImpuestos(precioSinImpuestos, tipoDeImpuestos)

    var precioFinal = convierteAMoneda(precioConImpuestos, tipoMoneda)

    return precioFinal

}

Pero se debe ser breve y evitar comentar todo lo que hace el código línea a línea explicando sólo lo esencial.

Se debe explicar el porqué de las cosas y no cómo se hacen. Un buen código se da a entender por sí solo y no necesita extensos comentarios para ello.

Consistencia y legibilidad para un código limpio

En el artículo sobre cómo escribir código limpio y legible hablamos de la necesidad de coherencia cuando escribimos código.

Legibilidad por encima de la simplicidad

Algunos lenguajes de programación permiten realizar varias operaciones en una sola línea de código. Por ejemplo en Swift, Java o C++ podemos crear una instancia de clase, llamar a uno de sus métodos y realizar una comparación dependiendo del resultado de esa llamada todo en una sola línea de código. Esto reduce el número de líneas que pueda tener una función pero no mejora la legibilidad del código ya que quizás esas características del lenguaje de programación no son conocidas por todos los programadores.

Recuerda escribir el código para que lo pueda leer otra persona, porque incluso hay altas probabilidades que esa otra persona seas tú y puede que no entiendas tu propio código pasado unos meses o años.

Consistencia en la arquitectura de un proyecto

Una de las decisiones principales a tomar cuando empezamos un proyecto software es la de qué patrón de diseño utilizaremos para la arquitectura de nuestra aplicación.

Una vez tomada esta decisión debemos evitar mezclar arquitecturas ya que aumentamos la complejidad a la hora de entender cómo se organiza nuestro proyecto.

Código limpio sin código inutil

En el artículo sobre cómo escribir código limpio y legible hablamos de la necesidad de un código que no tenga bloques de código inútil.

Estos bloques de código inútil se originan normalmente cuando estamos probando un código de forma temporal para hacer un experimento en nuestro proyecto.

Activando y desactivando bloques de código

Dentro de un proyecto de software puede que durante una ejecución de prueba controlada nos interese desactivar un bloque de código y activar otro. Esto se consigue gracias a las instrucciones para añadir comentarios en un código.

Cada lenguaje de programación posee uno o varios métodos para comentar un trozo de código. Por ejemplo la función original sería:

Funcion calcularImpuesto() {

    calcularImpuestosDelCarrito()

}

Y para nuestro experimento quedaría así:

Funcion calcularImpuesto() {

    // Comentamos la siguiente línea para la prueba

    // calcularImpuestosDelCarrito()

    // Usamos el experimento

    calcularImpuestosDelCarritoDeOtraForma()

}

El problema

El problema aparece cuando dejamos esos comentarios porque nos ha gustado más el resultado de la prueba. El código resultante está lleno de bloques inútiles que dificultan la lectura del código.

La solución consiste en quitar esos bloques de código y dejar sólo el código útil. El ejemplo quedaría al final así:

Funcion calcularImpuesto() {

    calcularImpuestosDelCarritoDeOtraForma()

}

¿Cómo no perder esos bloques comentados?

Puede que para nuestro proyecto nos interese no perder ese código alternativo que al principio estaba desactivado con comentarios y que posteriormente borramos para mejorar la limpieza de nuestro código.

Para evitar perder este código alternativo lo mejor es utilizar un sistema de gestión de versiones de código como Git o Mercurial.

Con estas herramientas podemos tener varias versiones de nuestro proyecto e ir manteniendo el código límpio en todo momento sin perder nada ya que con la herramienta de gestión de versiones podemos consultar código más viejo en cualquier momento.

Funciones simples para un código limpio

En el artículo sobre cómo escribir un código limpio y legible hablamos de la necesidad de escribir funciones simples y cortas.

Esto se debe a que a la hora de leer código de otra persona si una función es demasiado larga y posee muchas líneas de código es muy probable que perdamos el foco de atención. Además eso puede significar que la función está realizando demasiadas tareas y debemos atomizar nuestro código.

Código atomizado

Una función con código atomizado tiene un propósito y no puede reducirse o simplificarse mas. Cuanto más simple sea nuestra función más claro será nuestro código.

Por ejemplo una función llamada calcularAlmacenajeDeSucursales puede dividirse en varias funciones más pequeñas que calculen el resultado que estamos buscando en nuestra función inicial.

Dividiendo una función en varias funciones más pequeñas conseguimos atomizar nuestro código y mejorar su legibilidad.