Recientemente, mientras exploraba Twitter/X, vi una publicación que destacaba contenido de calidad para perfeccionar las habilidades en Vue.JS. Entre las opciones, llamó mi atención el libro «Design Patterns for Vue.JS». Dado que en ese momento estaba enfocado en mejorar mis habilidades de pruebas de código y aplicar patrones de diseño, decidí darle una oportunidad y contactar al autor para comprar una copia.

Al realizar la compra, me percaté de que para aquellos que residen en países en vías de desarrollo pueden obtener un descuento contactando directamente al autor. Así que me comuniqué con Lachlan Miller, quien generosamente me ofreció un considerable descuento. En el transcurso de nuestra conversación, Miller mencionó que estaba en proceso de reescribir el libro para garantizar la compatibilidad del código con Vue 3. Agradecido por la rebaja, opté por esperar a la nueva edición y así poder disfrutar de una lectura actualizada, cuya opinión compartiré con ustedes.

Portada de Design Patterns for Vue.JS
Portada del libro

Contenido de Design Patterns for Vue.js

El enfoque principal de este libro radica en cómo escribir tus componentes y código en Vue.JS de una manera que facilite su prueba. Se centra en la creación de código que permita generar pruebas automatizadas rápidamente y sin complicaciones, haciendo hincapié en la estructuración de soluciones que sean reutilizables y accesibles desde el ámbito de las pruebas.

Es importante destacar que si buscas un libro que enseñe los patrones de diseño más comunes para aplicarlos, este no es el indicado para ti. Aquí, los patrones de diseño presentados están diseñados para facilitar la creación de pruebas automatizadas y, por ende, mejorar la calidad de tu código. Esto resulta especialmente beneficioso si careces de conocimientos sobre cómo realizar pruebas o si no estás familiarizado con la creación de código escalable, sencillo y probado.

Todos los ejemplos se han sido actualizados a Vue 3 con Composition API, lo que los hace muy accesibles y comprensibles para captar las ideas sobre qué patrones aplicar. El contenido abarca desde las partes básicas de un componente hasta la creación de componentes complejos, así como la interacción con APIs, entre otros temas. En resumen, es un libro sumamente completo, por lo que también lo recomiendo para aquellos que deseen aprender más sobre Vue.

Recomendaciones

Este libro es interesante si deseas mejorar la forma en que escribes código que será probado con pruebas automatizadas. En mi opinión, Design Patterns for Vue.js es un buen libro para aprender a usar Vue.JS si vienes de otro framework, pues explica con detalle todo lo necesario para escribir aplicaciones con esta librería.

También es un buen repaso de lo que puedes hacer con Vue.JS y reforzar como escribir código que sea fácil de probar. Yo recomiendo este libro a cualquier desarrollador web que desee mejorar sus habilidades con Vue.JS (sobre todo, aquellos que están iniciándose)

Compra el libro en su pagina oficial y disfruta de su contenido.

La entrada Design Patterns for Vue.js: Iníciate en Vue escribiendo buen código se publicó primero en El blog de Skatox.

Hace un par de años, me embarqué en la búsqueda de formas para potenciar mis habilidades en pruebas de software. Fue en un hilo de Twitter (ahora X) donde me topé con una discusión sobre las diferencias entre stub y mock. En medio de esta conversación, alguien recomendó el libro «Unit Testing Principles, Practices, and Patterns» de Vladimir Khorikov. Después de haber adquirido el libro hace algún tiempo, finalmente encontré el momento oportuno para sumergirme en sus páginas y, en este artículo, compartiré mis impresiones al respecto.

Portada del libro Unit Testing Principles, Practices, and Patterns de Vladimir Khorikov
Portada del libro, si deseas comprarlo haz clic en él para mas información

Contenido de Unit Testing Principles, Practices, and Patterns

En mi opinión, el libro abarca todo lo necesario para aprender a aplicar pruebas a cualquier software que desarrolles. Desde las razones fundamentales para realizar pruebas hasta conceptos como unit testing, mocks, test doubles, integration testing, end to end tests, entre otros. Además, finaliza con una sección muy interesante sobre anti-patrones, la cual nos brinda valiosas enseñanzas para mejorar nuestras prácticas de codificación y hacer que el código sea más accesible de probar.

Cada sección comienza con la presentación del concepto, seguido de su aplicación en el ámbito profesional. Posteriormente, se ofrece una serie de ejemplos de código que abarcan tanto el método o sección de código a probar como el código de las pruebas correspondientes. Este enfoque estructurado garantiza una comprensión completa y práctica de los temas tratados.

Es importante destacar que si bien los ejemplos de código están escritos en Java, su estructura y lógica son fácilmente transferibles a otros lenguajes de programación como PHP o C++. Cualquier profesional, independientemente de su preferencia de lenguaje de programación podrá leer los ejemplos sin problemas.

Además, el texto cuenta con secciones que contienen notas sobre consideraciones importantes a tener en cuenta, así como experiencias personales del autor frente a diversas situaciones. Esta combinación de teoría, ejemplos prácticos y reflexiones personales enriquece la experiencia de aprendizaje y ofrece una perspectiva más completa sobre el proceso de pruebas de software.

¿Debería leerlo?

Este libro es verdaderamente accesible para personas de todos los niveles de experiencia. Ya seas un principiante absoluto o un profesional experimentado en el campo de las pruebas de software, encontrarás que Unit Testing Principles, Practices, and Patterns ofrece valiosos conocimientos y perspectivas. En definitiva, si deseas adentrarte en el mundo del testing o mejorar tus habilidades existentes, este libro es para ti.

La entrada Unit Testing Principles, Practices, and Patterns: libro para iniciarte en el testing se publicó primero en El blog de Skatox.

TypeScript Origins: The Documentary es un documental creado por Keyboard Stories que explora el proceso de creación de TypeScript. Lo más me gustó de ese documental, es que cuenta con comentarios de sus creadores y de las personas involucradas en su desarrollo, presentación y difusión, ofreciendo una visión completa de la historia detrás de este lenguaje. Este documental de TypeScript es algo que no se deben perder si están involucrados de alguna forma con el mundo de la programación.

¿Qué tiene de importante TypeScript?

Si te parece extraño que hayan hecho un documental de TypeScript de este calibre, es porque actualmente es uno de los lenguajes mas populares. JavaScript probablemente es el lenguaje mas popular actualmente, pero tiene muchas carencias como la falta de tipado/tipos (para mí es una de las cosas por las cuales opino que no es un buen lenguaje) que permite entre muchas cosas, crear código mas complejo, ayudar a los programadores escribir mejores programas limitando el tipo de datos que se pueden guardar o pasar en funciones, optimizar la velocidad de ejecución de los programas, entre otros.

TypeScript nace como solución a este problema, expandiendo su uso rápidamente e inclusive siendo sustituto de JS en muchas compañías. Ademas de ser el lenguaje que hizo posible en su día a tecnologías como Angular y Visual Studio Code.

Mi opinión del documental de TypeScript

El documental comienza con los principales creadores narrando cuáles fueron las causas para desarrollar este lenguaje dentro de Microsoft. Luego, muestra un poco el proceso de desarrollo y, posteriormente, el lanzamiento al público. En estas partes, podemos recordar las conferencias en las que fue anunciado.

Me llamó la atención, cómo comentan que querían liberarlo bajo una licencia abierta pero Microsoft no estaba acostumbrado a eso. Pero con la nueva gerencia les tocó evolucionar y lo consiguieron.

En el proceso de creación de TS, vemos como el lenguaje fue usado para construir Visual Studio Code; posteriormente el equipo de Angular (del rival Google), se unió para hacer que TypeScript soportara decoradores gracias al proyecto AtScript.

Pero en vez de contarte mas, te recomiendo que lo veas a continuación:

YouTube Video

Me pareció muy inspirador ver este documental de TypeScript. Ver la historia contada por los mismos creadores, observar como creció desde una idea para poder terminar otro proyecto, hasta ser uno de los principales lenguajes de programación, es muy placentero.

Ojalá hagan mas documentales de este tipo, tal vez uno de Visual Studio Code. Pues luego de ver este documental me dio curiosidad de cómo desarrollaron este editor.

Finalmente, te recomiendo aprender este lenguaje y hacer tu experiencia con JS mas placentera.

La entrada Documental de la creación de TypeScript se publicó primero en El blog de Skatox.

Este es un artículo que quería publicar hace un par de años. Quería escribir una comparación breve de React vs Vue para que cualquier persona con deseos de empezar con un nuevo proyecto o aprender front-end tenga una base de cual elegir. Pero siempre quedaba en borrador porque sentía que necesitaba mas experiencia con React (Vue lo uso diariamente en mi trabajo). Pero con la actualización de mis plugins de WordPress he logrado trabajar mas con React y poder hacer una comparación.

Comparación inicial entre React vs Vue

Algo que tienes que tener claro es que ambas tecnologías son librerias. No incluyen todos los componentes para hacer SPA. Pero si permiten crearlas y son la base para crear buenas interfaces dinámicas y ligeras.

Ambas tienen una funcionalidad similar pero con una sintaxis y forma de resolverlo diferente. Por ello, cuando quieres saber de React vs Vue debes enfocarte en cual se te hace mas fácil o te beneficia para tu próximo proyecto.

Ninguna es mejor que la otra, y todo se reduce a facilidad de conseguir programadores, documentación y cual se adapta a tu manera de pensar. Por eso lee los siguentes puntos que me parecen importante para que puedas elegir tu próxima librería de frontend.

Curva de aprendizaje y sintaxis

En mi opinión Vue es el mas fácil de aprender. La sintaxis es HTML con unos atributos especiales como v-if, v-if, v-model que permiten controlar el flujo de ejecución o generación del HTML, de resto es HTML estándar usando {{ }} (doble llaves) para mostrar las variables.

Actualmente posee dos formas de crear los componentes: usando Composition API y Options API. La diferencia entre ellas, es que la primera es parecida a la de React y esta enfocada en la facilidad de importar y reutilizar código. El otro, es la versión clasica donde creamos un objeto del componente con llamadas a los metodos, propiedades, datos, entre otras cosas.

También Vue tiene conceptos como variables computadas y asignación de modelos, que abstraen procesos que se harían manuales en otras librerias pero aqui se hacen de forma automática y podemos, por ejemplo, tener una variable que se compute automaticamente ante cambios, sin preocuparnos por desarrollar el proceso de actualización de la misma.

Aquí puedes ver un ejemplo de un componente sencillo que usa Composition API:

import { ref } from 'vue';

export default {
  setup() {
    const mostrarMensaje = ref(false);
    const nombre = 'María';

    const toggleMostrarMensaje = () => {
      mostrarMensaje.value = !mostrarMensaje.value;
    };

    return {
      mostrarMensaje,
      nombre,
      toggleMostrarMensaje
    };
  },
  render() {
    return (
      <div> 
        <h1>¡Bienvenido/a, {nombre}!</h1>
        <button onClick={toggleMostrarMensaje}>
          <span v-if="mostrarMensaje">Mostrar mensaje</span>
          <span v-else>Ocultar mensaje</span>
        </button>
        <p v-if="mostrarMensaje">Este es un ejemplo de sintaxis de renderización en Vue.</p>
      </div>
    );
  }
};

En cambio React usa JSX para renderizar los componentes. Es una sintaxis que mezcla XML con JS. Utiliza JS para controlar la lógica de renderizado y luego etiquetas HTML para definir los componentes y elementos de la página. Pero no es 100% igual, hay atributos como las clases que se llaman className, en vez de class y otros detalles que debes aprender.

Respecto a la parte de datos, utiliza algo llamado hooks que nos permite reutilizar el código mas facilmente. Aqui la data se maneja con estados. En mi opinión en React como no se abstraen tantas cosas, puedes tener mayor control de tu componente pero requiere que comprendas mejor el ciclo de video de ellos para obtener mejores resultados.

Aquí puedes ver un ejemplo de un componente sencillo que usa hooks:

import React, { useState } from 'react';

const Saludo = () => {
  const [mostrarMensaje, setMostrarMensaje] = useState(false);
  const nombre = 'María';

  const toggleMostrarMensaje = () => {
    setMostrarMensaje(!mostrarMensaje);
  };

  return (
      <div>
        <h1>¡Bienvenido/a, {nombre}!</h1>
        <button onClick={toggleMostrarMensaje}>
              { mostrarMensaje ? 'Ocultar mensaje' : 'Mostrar mensaje'}
        </button>
        { mostrarMensaje && <p>Este es un ejemplo de React JSX.</p> }
      </div>
  );
};

export default Saludo;

Aunque si observan ambos casos la sintaxis es muy similar, con saber buen HTML, no importa si es React vs Vue. Respecto a la sintaxis general

Documentación y comunidad

React debido a su popularidad posee una comunidad mas grande que provee mayor información y contenido. La documentación oficial es muy buena y enseña su uso sin importar que no tengas experiencia en la librería. Está dirigida a todo publico y me parece que nunca tuve dificultad para conseguir información para resolver problemas con React.

Vue también tiene una documentación muy buena, pero no es tan detallada. La comunidad es mas pequeña y en algunos casos debido a esto, no encontrarás mucha información o tutorial como los que existen en React.

En realidad ambos tienen documentación que te permiten aprender a usar estas tecnologías, solo que la de React tiene mas forma de tutorial y por el tamaño de su comunidad, te será mas fácil de encontrar solución a tus problemas.

Developer tools

Ambas librerías poseen herramientas para los navegadores a través de una extensión. En mi opinión las de Vue son mas cómodas, soporta gran variedad de tecnologías, permite ver mejora la información y son mas sencillas.

En cambio las de React, me pareció menos potente. A pesar de que puedes ver todos los componentes, no puedes editarlo o hacer operaciones avanzadas sobre los componentes. Y hay limitaciones como no poder usarlas dentro de un iframe que le quitan puntos.

Herramientas de desarrollo de React en Firefox

Pero ambas funcionan correctamente, permiten interactuar con los componentes y cumplen con el objetivo principal de ayudar al programador ver como se renderizan los componentes y ver las variables internas.

Mis recomendaciones

Si estás comenzando en el desarrollo front-end, considero que Vue es la opción ideal debido a su curva de aprendizaje suave y el uso de HTML simple para la creación de componentes visuales. No obstante, si tu objetivo es adquirir habilidades que te ayuden a conseguir trabajo, React es la elección más acertada debido a su mayor popularidad en el mercado laboral. Además, es posible encontrar una mayor cantidad de recursos e ejemplos para aprender, aunque es importante tener en cuenta que se requerirá un dominio previo de JavaScript y mayor esfuerzo inicial para dominarlo por completo.

¡Elige el que te parezca mas cómodo y se ajuste a tus necesidades! Comenta cual usas tú y por qué.

La entrada React vs Vue: ¿Cuál usar? se publicó primero en El blog de Skatox.

Desde hace un par de años, se libera una versión de PHP cada año y por lo tengo para estar al día, es recomendable estar actualizando el código para que sea compatible con futuras versiones. Si utilizas alguna herramienta de contenedores como Docker y tienes tu stack armado allí tarde o temprano tienes que cambiar de versión. Pero si usas PHP en laradock, el proceso es muy fácil como puedes ver.

Cambio de versión de PHP en laradock

El primer paso es ir a la carpeta raíz de Laradock y buscar el archivo de variables de entorno llamado .env. Ábrelo con tu editor de textos favorito y buscar la variable de entorno denominada PHP_VERSION y escribir la versión deseada, por ejemplo:

PHP_VERSION=8.2

Reconstruir imágenes

Luego debes volver a construir los contenedores de php-fpm que es el que procesa el código PHP en laradock y el de workspace para poder ejecutar scripts de PHP como composer, phpcs, entre otros.

docker-compose build php-fpm
docker-compose build workspace

Luego para que los cambios tomen efecto, debes reiniciar los contenedores. En mi caso como uso un stack LAMP sería:

docker-compose down
docker-compose up -d nginx mariadb phpmyadmin workspace

Comprobar que la versión de PHP en laradock es correcta

Y finalmente ya todo debería estar en la versión definida. Para comprobar, puedes crear un archivo .php con la función php_info() por dentro para imprimir todos los datos de la versión. Para el caso del workspace puedes ejecutar: php –version y ver la versión instalada.

Finalmente, espero que te sirva y puedas usar PHP en laradock con la versión que desees. Si necesitas volver a la versión anterior, simplemente edita de nuevo el archivo .env y comienza de nuevo.

La entrada Cambiar la versión de PHP en Laradock se publicó primero en El blog de Skatox.

Hace unas semanas Brent Roose publicó un vídeo de por qué considera mejor un tema claro en los editores de código. Me llamó la atención su opinión y los artículos que compartió que decidí intentarlo. Ya al segundo día, había notado los cambios y no volví a usar el tema oscuro exceptuando en la terminal (empecé a usar computadoras en los tiempos de MS-DOS y para mí la terminal siempre será con fondo oscuro).

El reconocido meme entre los programadores sobre el miedo a usar un editor con tema claro.
El reconocido meme entre los programadores sobre el miedo a usar un editor claro.
Fuente: @programming_tips

¿Usar un tema claro es mejor para mis ojos?

Hace tiempo leí que los temas oscuros eran mejores porque las pantallas no iluminaban tanto ni cegaban la vista, ocasionando cansancio con el tiempo. Pero al parecer sólo es válido para monitores viejos de tipo CRT. Pero viendo la entrada de Brent Roose, en él comparte enlaces a varios artículos y estudios donde muestran que el ojo humano está acostumbrado a reconocer patrones oscuros sobre fondo claro. Por ejemplo, el ojo al ver algo oscuro va a tardar mas en procesarlo que en fondo blanco, pero en cambio, cuando hay colores fuertes sobre fondo oscuro, la información queda mejor grabada en el cerebro. Pero en el caso de programar, nos interesa es tener menor cansancio y ser productivos durante el día.

Para mayor información del tema, te recomiendo leer el artículo sobre el lado oscuro del modo oscuro y el estudio sobre el efecto de mejores visualizaciones en la comprensión de código fuente.

Si aún no te convences, fíjate en la siguiente imagen extraída del artículo anterior. Cómo es mas fácil de reconocer el rostro de la derecha porque la información que necesita nuestro está en color oscuro y con fondo claro. Si aplicas esta lógica para el código, veras como nuestro cerebro necesita menos tiempo para reconocer texto oscuro en fondo claro. Suma ese tiempo a lo largo del día, cada vez que haces desplazamiento del texto o cambias de ventana, al regresar al editor y leer el código, estarías ahorrando un tiempo.

Es mas fácil distinguir al Abraham Lincoln
El rostro de la derecha es mas fácil y rápido de reconocer que de la izquierda. Fuente: Tidibits

Al ver este ejemplo, me convencí de que es mejor tener la tipografía oscura sobre el fondo blanco. Inicialmente era probarlo por una semana pero ya al segundo día vi mejoras y me quedé usándolo.

Mi experiencia usando el tema claro luego de una semana

El cambio mas inmediato que noté fue que al cambiar entre el editor y el navegador. Como la mayoría de las páginas suelen ser fondo claro con letras oscuras. No hay cambio brusco de colores al cambiar de aplicaciones. Imagino que si usas todo en modo oscuro pasa lo mismo, pero la web es clara por defecto y no todas las aplicaciones tienen un modo oscuro.

Durante la semana, si noté menos cansancio lugar de mirar la pantalla luego de varias horas usando el tema claro. El hecho de bajarle el brillo al monitor al principio porque me encandilaba el fondo blanco, posiblemente ayudó a reducir el agotamiento visual. Porque ahora la pantalla no necesitaba tanto brillo para mostrar el contenido a diferencia de cuando el modo oscuro es usado. También indirectamente esto debería disminuir el consumo eléctrico del monitor al requerir menos brillo.

Respecto a los colores del código, no vi ningún cambio porque a pesar de ser diferentes, resaltan la misma información. Durante las primeras horas me costó el cambio pero luego de me adapté.

En mi opinión, si vale la pena cambiar a un tema claro y si siento que me descansa mas la vista al durar varias horas en él. La adaptación me llevó dos días y luego me pareció normal el nuevo esquema de colores.

¿Cuando no recomiendo usarlo?

En monitores antiguos de CRT siento que se cansa mas la vista usando un tema claro, porque hay mas brillo en la pantalla. Pero si tienes un monitor moderno no ocurre lo mismo.

Sin embargo, si tienes una pantalla OLED y necesitas ahorrar batería, usar el modo oscuro puede darte de 3% a 9% mas tiempo de energía. Podría no parecer una cifra significante, pero si estas en una emergencia laboral y no tienes suministro eléctrico. Ese tiempo adicional es valioso.

Otro punto donde no recomiendo, es al momento de explicar o hacer presentaciones. El hecho de usar un fondo oscuro con letras de colores, facilita que se guarde la información del contenido de las palabras. Ahí no importa la velocidad de procesamiento de la información sino que resalte y se almacene en las personas que ven el código.

Recomendaciones finales

Te recomiendo probar durante una semana usar un tema claro. Recuerda que si sientes que te estas cegando de tanta luz, entonces significa que debes bajar el brillo de la pantalla y mejorar la iluminación de la habitación/oficina. Luego en un par de horas es probable que te acostumbres y sientas la diferencia.

¡Pruébalo y mejora tu salud visual!

La entrada Usar el tema claro en el editor de código es mejor y te explicó por qué se publicó primero en El blog de Skatox.

Docker es una gran tecnología que nos permite correr los servicios en contenedores. De esta forma podemos aislar y manejar mejor nuestros entornos de desarrollo y producción. Hace unos meses tenía un contenedor de docker con Nginx corriendo código en PHP y necesitaba agregar un certificado de seguridad. Pero no sabia como hacer para instalar Let’s Encrypt en la imagen sin modificarla para poder generar los contenedores.

Descubrí que existe una versión oficial para Docker. Con ella podemos ejecutar el comando certbot que se encarga de validar y generar los certificados para nuestro dominio web. Parte del proceso consiste en subir un archivo generado a la raíz del servidor web para que el servicio de Let’s Encrypt puede acceder remotamente y así validar que el dominio es nuestro. Pero por la naturaleza de los contenedores, es como complicado hacer que certbot suba archivos al contenedor del servidor web.

La solución para ello es utilizar volúmenes. Abrimos certbot y le indicamos que la ruta a subir el archivo sea la carpeta que se monta como volumen en el servidor web.

Docker + Let's Encrypt = Amor
Puedes combinar estas tecnologías para hacer sitios mas seguros.

Generar el certificado con el contenedor de Let’s encrypt

Para ello, puedes ejecutar el siguiente comando. Lo que hace es decirle a docker que ejecute el comando de generación de certificados en las carpetas deseadas para el dominio definido y lo haga dentro de la imagen certbot/certbot que ofrece let’s encrypt. Recuerda agregar este comando al cron para que se ejecute por lo menos semanalmente o cada 3 días (me parece exagerado hacerlo diariamente)

/usr/bin/docker run -it --rm -v /CARPETA_CON_LOS_CERTIFICADOS:/etc/letsencrypt -v /CARPETA_SERVIDOR_WEB:/app certbot/certbot certonly -a webroot --webroot-path /app -d MI_DOMINIO

Recuerda sustituir en este comando las siguientes variables:

  • CARPETA_CON_LOS_CERTIFICADOS es la carpeta donde se van a guardar los certificados generados. La configuración de tu servidor web debe apuntar a este lugar.
  • CARPETA_SERVIDOR_WEB es la carpeta raíz del dominio dentro del servidor web. Es decir si subes un archivo llamado test.txt debería estar visible en midominio.extension/test.txt . De esta manera certbot puede subir el archivo que permite confirmar que eres dueño del dominio a asegurar con certificado.
  • MI_DOMINIO es el dominio público para el cual se crearán tus certificados de seguridad.

Configurar el servidor web para usar los certificados

La aplicación Certbot de Let’s encrypt tiene un comando para auto-configurar los servidores web donde esta funcionando. Debido a que estamos un contenedor para Let’s encrypt y otro para el servidor web. No habrá comunicación directa entre ello, por lo que recomiendo actualizar la configuración manualmente, en mi caso, para una pagina hospedada con nginx la sección es la siguiente:

listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/MI_DOMINIO/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/MI_DOMINIO/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

Luego de esto, debes reiniciar el servidor web (en mi caso aprovecho y reinicio el contenedor del servidor para liberar memoria) y ya deberías tener tu dominio con el certificado web generado por let’s encrypt.

¡Ahora puedes disfrutar de un sitio web mas seguro!

La entrada Como usar Let’s Encrypt (versión de Docker) junto a un servidor web corriendo en Docker se publicó primero en El blog de Skatox.

Hace unos meses adquirí una Mac mini con el nuevo procesador de Apple Sillicon (M1). Estaba buscando remplazar mi Mac mini anterior y cuando vi que sacaron nuevos equipos con el chip M1 que en las pruebas de rendimiento superaban a la mayoría de procesadores, no producían mucho calor (vivo en un lugar caliente ) y por lo tanto no eran equipos ruidosos.

¿Que tienen de distinto los chips M1 y cual adquirir?

Los chips de Apple Sillicon (M1) son diseñados por la misma Apple. Utilizan la arquitectura ARM a diferencia de x86 que era la utilizada por AMD e Intel (quien proveía procesadores a Apple desde el 2005).

Esto significa que utilizan otra instrucciones, por lo tanto los programas deben ser compilados para esta arquitectura. Pero tiene como ventaja que los equipos con ARM se diseñan para consumir menos energía y actualmente poseen gran rendimiento.

El chip de Apple Sillicon (M1)
El chip de Apple Sillicon (M1)

Apple Sillicon (M1) para el desarrollo web

Respecto a la compatibilidad de aplicaciones, macOS ofrece Rosseta 2. Una aplicación que traduce el código de x86 a ARM permitiendo ejecutar cualquier aplicación previa sin problemas. Respecto al rendimiento, obviamente es menos al nativo pero igual están a la par con los equipos anteriores de Apple con procesadores Intel.

Sin embargo, a estas alturas la mayoría de aplicaciones ofrecen compatibilidad para el Apple Sillicon (M1). Por lo que podrás trabajar sin problemas como si estuvieses en otro equipo.

Editores o IDEs

Actualmente los principales IDEs para programación web ofrecen compatibilidad nativa. El primero en probar fue Sublime Text 4 que es el mas rápido que usado. Xcode como es el propio de Apple también es rápido pero casi no me gusta para desarrollo web. Visual Studio Code también ofrece version nativa que funciona muy rápido al igual que la suite de Jet Brains.

Lo único que se debe tener cuidado es con instalar la versión para ARM y no la de x86. Ya que todos estos editores ofrecen ambas versiones y a pesar que la versión de x86 corre en tu equipo. No lo hará de forma nativa y es muy lento.

Compatibilidad con lenguajes de programación

macOS ofrece versiones nativas de lenguajes com Ruby, PHP, entre otros. Sin embargo, puedes conseguir versiones nativas de Rust, Go, PHP, Ruby, JavaScript (con Node) y usarlas sin problemas. Si usas lenguajes interpretados, el código será igual entre arquitecturas así que no habrá problemas al momento de ejecutar o desarrollar tus aplicaciones. En nodeJS tuve que compilar algunos módulos para que quedaran nativos para que funcionara en mis proyectos, pero creo que otro sistemas operativos también hace eso la primera vez.

Docker

Docker requiere de Linux para funcionar, en macOS Big Sur ofrecen algo llamado Virtualization Framework que sirve para correr otros sistemas como Linux en un hypervisor. Docker desde la version 3.3 ofrece soporte para equipos con Apple Sillicon (M1). Desde que actualicé a la versión 4 no he tenido problemas siguiendo estas recomendaciones:

  • Uso las imágenes de mis contenedores en versiones de ARM para mejorar la velocidad. Algunos contenedores como el de Mailcatch, solo tienen para x86 y lo uso sin problemas.
  • Usar qemu como método de virtualización para tener 100% de estabilidad. Yo uso Virtualization Network y a veces falla al hacer operaciones pesadas con la base de datos.
  • La imagen oficial de MySQL no está para ARM y uso MariaDB en ARM. Siempre que intente usar MySQL inclusive con la emulación falla, desconozco la causa y por eso lo dejé de usar.

Pero en general funciona bien, estable y hasta los momentos no ha afectado mi trabajo.

Homebrew y aplicaciones del sistema

Te recomiendo visitar Does it ARM para buscar si el software corre en tu equipo. Aunque no he tenido problemas de compatibilidad. Suelo instalar las aplicaciones del sistema a través Homebrew y este separa las versiones de x86 y ARM por separado, así que si ofrece versión nativa se instala esa, si no, usará la arquitectura de x86. Todo esto funciona de forma transparente así que no habrá que intervenir.

Recomendaciones finales

Me parece que los equipos con Apple Sillicon (M1) son buenos para el desarrollo web, la relación costo/rendimiento es muy buena, gran compatibilidad con las aplicaciones existentes de macOS, gran potencia, poco consumo de energía y ningún ruido en el hardware. Hacen de estos unos equipos una buena compra para el desarrollo web.

Por ahora, la única limitación que veo es la cantidad de RAM, actualmente un máximo de 16GB, esta cantidad compartida con el chip de vídeo puede ser muy poco para algunos usuarios y probablemente deseen esperar por la siguiente generación de equipos con Apple Sillicon. Sin embargo, debido a la velocidad de los discos, al usar el área de intercambio o swap, la velocidad sigue siendo muy alta por lo que si necesitas mas RAM la velocidad sigue siendo muy potente, pero no es lo recomendable.

Respecto al disco duro, no me preocupa. Tengo una portátil con un disco duro SSD de menor calidad y hasta los momentos me ha durado 7 años, estoy seguro que esos me durarán mucho mas. Ademas he tomado medidas como no indexar ciertos archivos para aumentar el rendimiento y vida útil del disco duro.

En fin, si buscas un equipo con buen costo/rendimiento para realizar desarrollo web y prefieres usar macOS. Te recomiendo las computadoras con Apple Sillicon (M1). No tendrás problemas de compatibilidad con las aplicaciones existentes y el rendimiento será muy bueno.

Si compraste un equipo o vas a hacerlo, ¡Bienvenido(a) a la arquitectura ARM!

La entrada ¿Sirve una Mac con Apple Sillicon (M1) para el desarrollo web? se publicó primero en El blog de Skatox.

Hoy se celebra el día del programador y programadora por ser el día 100 (en hexadecimal) del año. Y este año, te comparto 3 grandes canciones geek sobre la recursividad, desbordamiento de pila y optimización de la cola (conceptos básicos sobre la ejecución de código recursivo).

Las canciones sobre el desbordamiento de pila (Stack Overflow)

Disfruta de las canciones con un fondo musical de Disney. Éstas canciones fueron creadas e interpretadas porAnjana Vakil y Natalia Margolis para la conferencia !!Con del 2019 para entreteneros y aprender sobre funciones de pila, sobre todo, el famoso error conocido como StackOverflow. De hecho, de ahí viene el nombre de la famosa página para responder dudas a programadores. Así que sin mas preámbulos haz clic en reproducir y disfruta del video.

Si te gustó, recuerda compartilo en las redes para que otros lo descubran o deja tu comentario sobre lo que opinas de este vídeo.

Y recuerda evitar que tus funciones recursivas produzcan desbordamiento de pila 😉

La entrada ¡Feliz día del programador(a)+! se publicó primero en El blog de Skatox.

Esta semana Microsoft anunció Github Copilot, un servicio que utiliza el motor de inteligencia artificial GPT-3 qué según Wikipedia, es un modelo de lenguaje autorregresivo que emplea aprendizaje profundo para producir textos que simulan la redacción humana. Es decir, utiliza Inteligencia Artificial para crear contenido que parece ser escrito por personas.

Github Copilot lo que hace es escribir código de programación como si fuese un desarrollador con tan solo definir qué es lo que se desea hacer. Por ejemplo, si haces una función llamada ordernarAlfabeticamente(), se generará código para ordenar alfabéticamente un arreglo. Esto es posible gracias a que se alimenta del código fuente de muchos proyectos de código abierto hospedados en Github. Como mi tesis de pregrado fue un generador de código de PHP/PostgreSQL me llamó mucho la atención.

Al ser una tecnología innovadora que permite crear código sin ayuda de un programador. Muchos programadores les causó un miedo y piensa que pronto remplazará a los programadores.

Ejemplo de Github Copilot generado una función para crear una dirección de envío
Ejemplo de Github Copilot generado una función para crear una dirección de envío

¿Github Copilot reemplazará a los programadores?

Si no quieres leer el artículo completo, mi respuesta es NO. Ahora si quieres leer mi opinión, siento que va a ser otra herramienta que permitirá acelerar el desarrollo y mejorar la productividad de los programadores.

Si vemos la historia de la programación, al principio la gente programaba en lenguaje ensamblador, es decir, directamente en el lenguaje del hardware donde se ejecutaban los programas. Luego surgieron los compiladores y lenguajes de programación que permitieron ahorrarnos tiempo al abstraernos muchas cosas del hardware. Los programadores de ASM no desaparecieron sino que migraron a usar estas herramientas para ahorrar tiempo.

Luego surgieron herramientas RAD (Rapid Application Development) donde con tan solo arrastrar algunas cosas teníamos aplicaciones de escritorio en poco tiempo y también herramientas para chequear errores en el código en tiempo real y sin tener que compilar. Todas ellas vinieron a mejorar el ecosistema de programadores y no remplazarlos.

Recordemos que Github Copilot lo que hace es generar código, muchas veces como programadores nuestro primer paso es revisar si hay algo existente, buscar en Internet, copiar el pedazo y adaptarlo o mejorarlo. Pues Github Copilot viene a automatizar ese proceso, en vez de perder tiempo investigando y cambiando al navegador y luego al editor, podemos buscar el código que necesitamos desde el mismo editor. Ya el diseño de la arquitectura, como resolver el problema del negocio, la ingeniería de software y demás procesos seguirán haciéndose por una persona.

¿Cuál será su uso e implicaciones en el futuro?

Yo creo que Github Copilot se utilizará bastante para que no nos preocupemos de cosas triviales de la programación y dedicarnos mas a resolver los problemas del negocio. Es decir lo que el software busca solucionar en la vida diaria. Por ejemplo, ayer en mi jornada laboral tuve que dedicar unas horas para validar 2 campos de forma simultánea en Vuetify porque no es algo directo de hacer. Con Github Copilot lo podría haber hecho mas rápido e invertir ese tiempo en mejorar la solución de software del cliente.

Me parece que esta es una herramienta muy revolucionaria, aparte de automatizar parte de la generación de código. Creo que también será interesante la parte de licenciamiento del código. Si la I.A. genera código desde un proyecto GPL teóricamente afecta donde lo incrustemos. O si pertenece a otro equipo por ejemplo, de un competidor, sería correcto ponerlo en nuestro programa. Creo que se abrirá un debate sobre el licenciamiento de estos códigos generadores y de los proyectos de los cuales Github Copilot aprende.

Ésta herramienta es la primera de muchas, otras vendrán y nos acostumbraremos a esta nueva realidad. Los programadores no seremos reemplazados (al menos por este tipo de herramienta) pero si ahorraremos tiempo al momento de crear código. No te asustes que no vienen a sustituirte…todavía faltan años para eso jejee.

La entrada Github Copilot: ¿el reemplazo de los programadores? se publicó primero en El blog de Skatox.