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.

Hace unas semanas tuve la oportunidad de participar en una edición de FullStapps. Una comunidad para hacer crecer a desarrolladores brindando contenido de alta calidad. En ese episodio fui entrevistado por el Ing. Henry Bravo para hablar principalmente de 3 temas:

  • WebAssembly: breve introducción sobre esta gran tecnología que nos permite ejecutar aplicaciones de alto rendimiento en la web; qué es eso y para que sirve en tus aplicaciones.
  • ¿PHP ha muerto? Comento sobre cómo el lenguaje esta muy vivo, es usado ampliamente y tiene gran oferta laboral. Desmiento algunos mitos y por qué puedes aprender este lenguaje en el 2001.
  • ¿Universidad? Mi opinión sobre si debes estudiar una carrera de Ingeniería de la computación, informática o sistemas.

También comento de otros temas y un poco de mí. Por lo que te invito a escuchar o ver el episodio.

Episodio de Fullstapps

Así que si la quieres ver, a continuación puedes ver el episodio de Fullstapps donde tuve la oportunidad de participar y compartir conocimientos. Fue una excelente experiencia y la entrevista la sentí diferente a las démas. El hecho de hablar sobre varios temas me gustó.

Si les gustó no duden en compartirlo en redes sociales y suscribirse a FullStapps para que crezcan como desarrolladores. Si tienes algún comentario que añadir, expresar un desacuerdo o solicitar mas información, no dejes de comentar al final de la entrada.

La entrada Mi participación en Fullstapps se publicó primero en El blog de Skatox.

A pesar de que mi trabajo es realizar, actualizar, mantener aplicaciones y sitios web. Había estado tan ocupado que no había podido dedicar tiempo a mi blog, que al igual que todo sistema informático requiere mantenimiento cada cierto tiempo.

Desde que inicié este blog en el 2005. He tenido un diseño y paleta de colores similar, pero cada cierto tiempo debo cambiar la plantilla de WordPress porque la han dejado de mantener o debo adaptarla a las nuevas tecnologías. La última vez que lo hice fue en el 2019 (lee para conocer mi experiencia en ese entonces) pero el diseño era exactamente igual al de la modificación del 2014.

Principales cambios de mi blog

Cambios a la plantilla

Primero fue actualizar la plantilla, pues la que utilizaba fue descontinuada y no soportaba muchas características de personalización de WordPress. Utilicé una llamada Autor por recomendación de Richzendy, que era similar al diseño anterior pero con la barra a la izquierda (que es mejor para nuestro idioma).

Cambios a los diseño

Luego fue actualizar el fondo y el Skatux (mi logo del pingüino Tux). El diseño lo llevaba usando desde el 2010, en el 2014-2015 usé uno con un teléfono de Firefox OS en la mano y una gorra con colores de Mozilla, pero luego de volver al original y mirarlo en el 2021 me di cuenta que ya no representa mi actual yo.

El primer cambio fue la gorra, ya no la uso para atrás como en mi adolescencia; quité la muñequera de punk y le puse una deportiva por la misma razón; decidí cambiar el color a vino tinto por el equipo de fútbol de Venezuela; mantuve el logo de Arch y la patineta porque sigo usándolos. Finalmente cambié el teléfono por uno con iOS porque es lo que uso desde hace varios años y en vez de tener auriculares le puse unos AirPods (esto me dio risa porque en el 2010 ese tipo de audífonos no existían)

Skatux del 2010
Skatux del 2010
Skatux del 2021
Skatux del 2021

Otro cambio realizado fue el fondo, ésta vez iba a hacer la 3ra iteración del mismo. Lo primero que hice fue actualizar la imagen del PS4 por un PS5. Quité tecnologías y aplicaciones que ya no uso, agregué de nuevas que uso como VueJS, PHPStorm, WebAssembly, entre otros. Los fondos me han permitido ver mi evolución a lo largo de estos años.

Fondo de Skatox.com del 2010
Fondo del 2010
Fondo de Skatox.com del 2014
Fondo del 2014
Fondo de Skatox.com del 2021
Fondo del 2021

Me llamó la atención realizar estos cambios, porque pude ver cómo he avanzado en la pasada década y como la tecnología avanza. Ya con estos cambios puedo dar una imagen mas renovada para la próxima década.

Cambios técnicos

Respecto a los cambios técnicos, la plantilla del blog es usa un tema hijo desde el inicio (antes hacía hacks al tema original), se aumentó la versión de PHP 7.2 a 7.4. Actualicé todos los plugins. Revisé que el tema tenga buena usabilidad para las personas con discapacidades visuales y demás.

Fue una grata experiencia actualizar todo el sitio después de varios años y no hacer modificaciones menores, siento que ahora la página vuelve a ser más mi imagen y espero seguir retomando publicación de artículo.

La entrada Actualización del diseño de mi Blog luego de 7 años se publicó primero en El blog de Skatox.

El pasado noviembre del 2020 tuve la oportunidad de participar en el JSConf México para dar una breve charla titulada: ¿Por qué WebAssembly? En ella comento las razones de su existencia, cómo viene ayudar a Javascript a solucionar los problemas que ese lenguaje no permite hacer (o al menos de forma óptima).

Estaba muy emocionado por participar en este evento por muchas razones. Principalmente era volver a México luego de muchos años y compartir con la gente de allá. Pasar unos días allá, pero debido al COVID-19 se tuvo que retrasar y posteriormente hacerla virtual.

¿Por qué WebAssembly?

Esta charla es una variación de las anteriores que he dado, porque ya WebAssembly es usado cada día y no es tecnología del futuro, sino del presente. Ya hoy en día puedes usarlas sin problemas y entonces cambio el enfoque de la charla a por qué usarla.

En fin, si deseas verla totalmente en español puedes hacerlo a continuación. Una vez finalizada, me gustaría conocer tus opiniones, dudas o recomendaciones respecto al tema.

Why WebAssembly?

Me pareció muy chévere como el audio mi charla fue traducida a inglés. Agradezco al equipo de JSConf México 2020 por realizar esa labor. Gracias a ello, mi mensaje puede llegar a más personas y puedan aprender sobre ésta tecnología. Si prefieres escuchar el audio en inglés, a continuación te comparto esa versión del video.

Fue una gran experiencia participar en mi 2do JSConf, lamentablemente tuvo que ser virtual. Hubiese querido estar allá y regresar a México luego de muchos años (me encanta la comida mexicana real). Compartir tiempo con varios amigos de México como Yuliana y Luis Sanchez y disfrutar de la hermosa cultura del país.

Recuerda compartir este artículo si te gusta o deja tu comentario si deseas preguntar o complementar la información.

La entrada ¿Por qué WebAssembly? Mi charla del JSConf México 2020 se publicó primero en El blog de Skatox.

Hoy en día es normal un dispositivo con disco duro SSD. Cuando salieron al mercado hace unos años, su vida útil era menor a un disco duro magnético debido a la cantidad limitada de escrituras. Existen técnicas como TRIM que permiten reducir la escritura en el disco y alargar su vida útil. Con el paso de los años la tecnología de los disco duros de estado sólido ha mejorado mucho y permiten que los discos SSD sean confiables para almacenar nuestros datos.

Hace unos días empecé a usar una MacMini con Apple Sillicon en mi trabajo y los disco duros vienen soldados al equipo. Por los momentos no son reemplazables por ello toca realizar cosas para evitar que el disco dura tenga mucha escritura y dure por muchos años.

kernel_task escribe mucho en el disco

Analizando el uso del disco en el Monitor de Actividad de MacOS. Noté un proceso llamado kernel_task que escribió 50GB en 1 día y me pareció mucho porque principalmente estuve leyendo artículos e instalando paquetes de npm. Leyendo en foros, ese proceso del sistema suele realizar muchas escrituras cuando Spotlight indexa el contenido del sistema.

Si eres desarrollador web, al instalar frameworks o scripts de npm. Estarás descargando miles de archivos que Spotlight empezará a indexar cada uno de ellos. Esto genera mucha información de indexado que obviamente será escrita al disco y por ello parecerá que escribe basta.

Como reducir la escritura del disco de kernel_task

Para ello, debemos seleccionar las carpetas que no queremos indexar. En mi caso excluí la carpeta de mis proyectos web porque nunca voy a realizar una búsqueda de ellos en Spotlight. Para ello puedo usar el IDE y acceder rápidamente al contenido.

Para desactivarlo, escribe Spotlight en la barra de Spotlight (la que abres con Command + Espacio) y se abrirá la lista de cosas que puedes indexar. Luego haz clic en la pestaña Privacidad y podrás agregar las carpetas que no deseas que sean indexadas o que tenga muchos archivos en constante cambio.

Opciones de Spotlight para reducir la escritura del disco
En las opciones de Spotlight agrega las carpetas con archivos que no deseas indexar para reducir la escritura del disco

Una vez agregadas, puedes hacer pruebas y verás cómo disminuye la escritura del disco y por lo tanto mejora la vida de los disco duros SDD.

Hacer que Firefox use cache desde la RAM

Otra cosa que hice para reducir la escritura del disco es que Firefox escriba la cache de archivos en la RAM. El problema es que cada vez que apagues el equipo se va a perder y que gastaras mas RAM. Pero si quieres hacerlo a cambio de alargar la vida de tu disco, puedes hacerlo siguiendo estos pasos:

  • Escribe about:config en la barra de direcciones.
  • Busca las llaves browser.cache.disk.enablebrowser.cache.disk_cache_ssl y las cambias a false.
  • Busca la llave browser.cache.memory.enable y la cambias a true.

¡Listo! Con estos dos trucos podrás reducir la escritura del disco en tu computadora y alargar la vida útil de tus disco duros.

La entrada Como reducir la escritura del disco en MacOS si eres desarrollador Web se publicó primero en El blog de Skatox.

Debido a la naturaleza de rolling-release de Archlinux, si tienes varios equipos con Arch tendrás que lidiar con gastar mucho de ancho de banda al descargar las actualizaciones (casi diarias y a veces de gran tamaño). Ademas es probable que los equipos posean el mismo hardware y software. Entonces, técnicamente estarías descargando los mismos paquetes muchas veces. Pero gracias a PacServe evitaremos este problema.

¿Qué es PacServe?

Es un software permite usar uno de tus equipos con Arch como servidor de actualizaciones de paquetes. Entonces los demás equipos antes de descargar desde los repositorios oficiales, se conecta primero a este equipo con PacServe para descargar usando la red local (sin acceder a Internet) los paquetes y evitar gastar ancho de banda externo.

Instalación en la computadora con los paquetes

El primer paso es instalar el demonio de pacserve en el equipo con acceso a Internet y que se encargará de descargar los paquetes en el disco. Para ello debes instalar el PKGBUILD de pacserve y luego iniciar el demonio:

# systemctl start pacserve

Con esto ya tenemos corriendo el servidor. Comienza el anuncio a la red local y en lo demás equipos utilizas el cliente para conectarte aquí. En este equipo utilizas pacman como en cualquier instalación de Archlinux y mantén la cache con los paquetes descargados. No los elimines porque eso son los que se enviaran a los demás equipos.

Uso desde los clientes

En las computadoras que no tienen los paquetes y deseas actualizar. Debes usar pacserve en vez de pacman. Ya que este cliente se encargará de buscar un servidor en la red local para iniciar la descarga de paquetes antes de usar pacman y descargar desde los repositorios oficiales.

¡Listo! Ya puedes ahorrar ancho de banda al instalar actualizaciones en tu equipos con Arch. Para mayor información puedes consultar la entrada de Pacserve en la Wiki de Archlinux.

La entrada Pacserve: sincroniza tus paquetes de Archlinux en tu red local se publicó primero en El blog de Skatox.

Todo desarrollador requiere tener acceso inmediato a la documentación de las tecnologías que trabaja. Pues nuestro trabajo es resolver problemas y no sabernos de memoria como funciona todo. El principal problema es que la documentación suele ser extensa, variante y por ello suele encontrarse hospedada en Internet. Pero cuando no tenemos buen acceso a Internet debido a que estamos viajando, nos encontramos en un café con mala conexión, vivimos en un lugar con poco ancho de banda y otros, se vuelve un problema acceder a esta documentación. Para estos casos podemos usar DevDocs, un sitio que nos permite almacenar en nuestro navegador la documentación de muchos sitios web.

Cómo funciona DevDocs

DevDocs posee una lista de tecnologías junto a su respectiva versión. Al hacer clic sobre cada uno de ellas verás desplegada la documentación oficial (al menos en las que probé). Encima de cada enlace del menú puedes hacer clic en Enable y empezará a descargar la documentación al almacenamiento local del navegador para posterior lectura, así no tengas acceso a Internet.

Entonces al estar guardada en tu navegador, puedes acceder a DevDocs y podrás acceder a toda la documentación guardada sin la necesidad de tener conexión a Internet. Inclusive, si tienes conexión pero es lenta, es mucho mas rápido acceder a esta documentación guardada. Otra ventaja es que la documentación se sincroniza automáticamente entonces no debes preocuparte por si esta obsoleta o con errores por actualizar.

Interfaz de DevDocs
Interfaz de DevDocs

Ventajas de usar DevDocs

  • Tienes acceso rápido a la documentación en tu propio equipo sin acceder a Internet.
  • Puedes ver la documentación de varias tecnologías en un mismo formato. Tal vez no parece importante pero es cómodo no estar viendo formatos distintos cuando trabajas con varias tecnologías a las vez.
  • El buscador integrado te permite hacer una búsqueda en varios lenguajes a la vez. Útil para comparar o ver donde es mas fácil hacerlo.
  • Al ser una página web, puedes acceder la desde cualquier dispositivo. Puedes tener la documentación abierta en tu tableta o lector de libros así sea viejo.

Espero que te sirva esta información y permite mejorar tu flujo de trabajo. Recuerda compartir este artículo en las redes si te y gustó, o deja un comentario aportando tu opinión.

La entrada DevDocs: guarda la documentación de varias tecnologías en tu navegador se publicó primero en El blog de Skatox.

El pasado mayo tuve la oportunidad de participar en el WordCamp España. Esta WordCamp España fue la primera en español en realizarse de forma remota debido al COVID-19. Debido al cambio de formato no sabía que esperar, pero fue una grata experiencia y me encantó el desarrollo del evento.

En esta edición tuve la oportunidad de participar con una charla sobre las herramientas de desarrollo del navegador. La misma fue orientada hacia WordPress por lo que verás como puedes usarla cuando creas un sitio web con este gran CMS.

El navegador es tu mejor amigo para el desarrollo con WordPress

A pesar de tener el mismo título que charlas anteriores. En esta edición actualicé el contenido de algunas herramientas, el orden y realicé mejoras gracias a unos consejos de Angel Zinsel, uno de los organizadores del WordCamp España.

El contenido de la misma es conocer algunas herramientas que ofrecen los navegadores para hacer sitios web y conocer como aprovecharlas cuando trabajas en WordPress. Te recomiendo verla y aprender a usarlas en tu navegador favorito para ahorrar tiempo de desarrollo y mejorar tu flujo de trabajo. Esta dirigida tanto a diseñadores, constructores de sitios, programadores de frontend y de backend.

Espero que te haya gustado mi ponencia del WordCamp España. Fue una gran experiencia haber participado en mi primer WordCamp remoto, el equipo de España hizo un excelente evento, la calidad de ponencias, el trato a ponentes, la organización, las salas de socialización, entre otros.

Recuerda compartir esta charla en redes sociales si te gustó y comienza a usar las herramientas de desarrollo de tu navegador favorita para mejorar el desarrollo de sitios con WordPress.

La entrada Mi charla sobre las DevTools en el WordCamp España se publicó primero en El blog de Skatox.

Desde hace año y medio empecé a usar un segundo monitor cuando trabajo en mi portátil. El monitor es uno sencillo con resolución Full HD (1080p) pero el de mi portátil es Retina Display (2K), resulta que en X.Org no es tan fácil tener multi-monitor con diferentes resoluciones y densidades de píxel.

Toca utilizar la herramienta xrand y con ella poder colocar la distintas resoluciones de los monitores. Pero tenía los siguiente inconvenientes:

  • Solo podía ejecutarla luego de cargar el entorno gráfico y reiniciar el gestor de ventana. Yo quería entrar de una vez a la nueva resolución.
  • Existe un bug que al utilizar compositores la pantalla parpadea. Las soluciones que vi afectaban el rendimiento.
  • No podía hacer configuraciones diferentes para dispositivos. Por ejemplo, suelo viajar a conferencias y cada proyector es una resolución distinta.
Mi entorno multi-monitor con diferentes resoluciones
Mi monitor y mi portátil

Wayland

Wayland es un protocolo de comunicación para las ventanas. Lleva muchísimos años en desarrollo pero no tiene tanto soporte como X.org. Las razones que me impedían usarlo era su soporte en KDE y la imposibilidad de pegar con el botón del medio del ratón.

Con el lanzamiento de KDE 5.20 se resolvieron estos problemas así que pude migrar a KDE. Y desde la misma pantalla de configuración pude tener multi-monitor con diferentes resoluciones ajustando la opción de zoom/aumento de la pantalla.

Problemas con las aplicaciones GTK y Firefox

El problema es que las aplicaciones GTK respetan la configuración de GTK que es manejada por GNOME. Como siempre he usado KDE en el portátil no tenía la configuración base y las ventanas se veían muy grande. Luego descubrí que esto se maneja con variables del entorno GDK. En el caso de Firefox, para activar Wayland hay que activar una variable de entorno.

Para lograr activar estas variables en .config/plasma-workspace/env y dentro del mismo colocar lo siguiente:

export MOZ_ENABLE_WAYLAND=1
export GDK_SCALE=1
export GDK_DPI_SCALE=0.5

Al reiniciar deberías tener tantos las aplicaciones GTK, Firefox y las demas corriendo bien dentro de Wayland.

Este par de líneas me tomó 3 horas de mi tiempo, pero espero que te sirva esta solución para tener multi-monitor con diferentes resoluciones en KDE.

La entrada Multi-monitor con diferentes resoluciones en KDE con Wayland se publicó primero en El blog de Skatox.

Si tienen tiempo visitando mi blog, conocerán de la categoría de Música Geek donde comparto música con contenido informático o similar. En esta ocasión les comparto The Time Has Come realizada por el equipo de SuSE. Como siempre tiene buena producción y las letras cargadas con contenido de código abierto.

Así que si te gusta el rock de Estados Unidos de los 80’s y el open source, no dejes de ver esta grandiosa parodia de The Times Has Come. Además la canción es pegajosa y agradable.

Si conoces otra similar, no dudes en dejar un comentario o si te gustó compártela con otros.

La entrada The Time Has Come (parodia de SuSE) se publicó primero en El blog de Skatox.