Forem: Juan C. Ruiz

Consejos prácticos para proteger tu identidad digital 🔐

Juan C. Ruiz — Tue, 23 Nov 2021 04:51:38 +0000

Hace unos días un amigo me contó de una experiencia que tuvo donde el robo de un celular desencadenó mucho estrés y situaciones que uno muchas veces no contempla.

Por lo general cuando escuchamos de un robo o pérdida de celular lo primero que pensamos es en "va a terminar en una casa de empeño o en el tianguis".

Sin embargo, hoy en día nuestro smartphone es más que una simple herramienta para hacer una llamada o enviar un SMS, la mayor parte de nuestra vida se encuentra contenida en ese pequeño aparato, además de que es la puerta de entrada a nuestra identidad digital.

Desde cuentas de redes sociales (Twitter, FB, IG, TkTk, etc) hasta ya temas más serios, como accesos bancarios, criptomonedas (para estar a la moda), servicios de compra en linea, entre otros, están contenidos a solo un slide de distancia.

Incluso he llegado a escuchar a familiares y conocidos decir "no tengo nada que ocultar" o "no tengo nada que me roben".

Pero viéndolo en perspectiva ¿te has cuestionado, qué pasaría si alguien al robar tu celular tuviera suficiente tiempo para acceder a tu correo electrónico y cambiar tu teléfono de acceso además de las claves de recuperación?

Nota: Todo lo que voy a compartir a partir de aquí son solo consejos de alguien que ya tiene unos cuantos años vagando por este mundo digital, no soy ningún experto en seguridad, ni sé hackear FB. Sin embargo, me pareció importante apoyar un poco a crear conciencia en estos temas.

La seguridad de nuestra identidad digital debe ser algo que tengamos bien presente a la hora de crear cuentas en los distintos servicios en los que nos hemos registrado o estemos por agregar a nuestra lista.

Muchos hemos pasado por el ir agregando nuevos caracteres a una contraseña básica que obtuvimos hace unos ayeres y pensando que nuestra estrategia es infalible y "cómoda" porque nadie nunca sabrá como la creamos.

Pero hoy día, las computadoras pueden calcular una cantidad enorme de passwords por segundo, para expresarlo en números redondos, este artículo de Gizmodo AU escrito en 2020 menciona la cifra de 100,000,000,000 passwords por segundo. Dentro del artículo se comenta que un password de 8 caracteres puede ser hackeado en aproximadamente 12 minutos usando una instancia en la nube. Ahora bien, entre más larga sea nuestra contraseña más tiempo le tomará a un atacante el tratar de calcularla.

Por lo que nuestra mejor opción hoy día es hacer uso de algún servicio de manejo de contraseñas, el cual se encargue de generarlas y almacenarlas quedando así la tarea de aprender solo una contraseña maestra. Esta contraseña debería ser lo suficientemente compleja como para evitar que nos la roben en un par de minutos.

Aquí en los internets existen una gran cantidad de servicios, los cuales podemos usar para esta labor, entre los más populares destacan 1password.com, lastpass.com, enpass.io, safe-in-cloud.com entre otros. El servicio que decidas utilizar dependerá de factores como el si almacena las contraseñas en la nube de la empresa proveedora o en un archivo encriptado en tu nube personal, así como del precio y algunas funciones como llenado de formularios o integración biométrica con tu smartphone. Si aún no utilizas ninguno, no pierdes nada con echarles un ojo, muchas de estas herramientas incluso cuentan con funciones que te permiten detectar si alguno de tus passwords ha sido comprometido y anda vagando por ahí en la Dark web.

Ahora bien esto es algo muy general, si un atacante lograra adueñarse del acceso a tu correo electrónico y de tu número de teléfono, podría simplemente solicitar la recuperación de contraseña a los servicios y comenzar a hacer cargos a tu nombre. Para buscar limitar o retrasar el que el atacante pueda ingresar al resto de los servicios relacionados con tu cuenta. podemos utilizar lo que se le conoce como la autenticación en 2 factores (2FA). Esta función hará que los servicios donde este activa soliciten una clave adicional al momento de iniciar sesión. Esta clave es generada de manera dinámica por algunas aplicaciones como Google Authenticator o Authy.

Algunos servicios te dan la opción de recibas el código via SMS, pero si estamos hablando del caso hipotético de que nos roben el celular, dudo que queramos que sea nuestra opción preferida.

Complementando lo que hablábamos de manejadores de contraseñas, algunos de estos servicios incluyen ya la funcionalidad para que también manejar el token dinámico del 2FA. Por el momento no tengo una postura respecto a manejar las contraseñas y los tokens de 2FA en una sola herramienta o dividir las responsabilidades. Si tu utilizas la misma herramienta para ambas labores me gustaría leer tu opinion.

Si realmente quisiéramos llevar este tema del segundo paso de autenticación a otro nivel, existen herramientas como las YubiKey creadas por yubico.com, las cuales nos permiten hacer login hasta que la llave este conectada a nuestra computadora o smartphone y lo hayamos aprobado.

El principal contra de estas llaves es que no todos los servicios lo soportan, sin embargo es una buena opción para proteger los servicios más importantes, como nuestro correo electrónico (en el caso de Gmail).

Como un último consejo, identifica donde puedes dar de baja dispositivos de tus cuentas principales, por ejemplo Google tiene esta ruta donde puedes ver que dispositivos están conectados a tu cuenta y terminar la sesión desde ahí. https://myaccount.google.com/device-activity

Recapitulando:

Nunca dejes tu teléfono sin contraseña para entrar a las aplicaciones.
Utiliza un manejador de contraseñas en lugar de usar "la misma con unos pequeños cambios".
Siempre activa la autenticación de dos pasos.
No uses SMS como tu opción para recuperar cuentas
Si puedes y tienes la oportunidad invierte en una llave física para el 2FA
Identifica donde desconectar dispositivos de tus cuentas principales en caso de una emergencia.

Espero este artículo te sea de utilidad, repito no soy un gurú de seguridad, sin embargo creo esta es información valiosa que puede servirle a más de una persona, si conoces a alguien que le pudiera servir por favor ayúdame a difundirlo.

Potenciando tu carrera profesional a través del Open Source

Juan C. Ruiz — Wed, 27 Oct 2021 02:43:16 +0000

Durante las últimas semanas tuve la oportunidad de dar una charla titulada "Potenciando tu carrera profesional a través del Open Source" en diferentes eventos y comunidades, te comparto la grabación de la presentación con el equipo de Código Facilito en su 10 Aniversario.

En esta charla traté de plasmar algunos de los aprendizajes obtenidos a lo largo de casi 6 años contribuyendo a proyectos de código abierto, si no tuviste la oportunidad de verla o bien prefieres el formato en texto, aquí te comparto el contenido de esta.

Primero que nada el contenido de este blogpost no es sobre qué es el Open Source o como contribuir a este, está más bien orientado en por qué comenzar a contribuir.

Nota: Todo lo expresado en esta charla viene desde mi experiencia personal así que puede que haya cosas que a otros no les resulte relevantes o bien no sea el camino que siguieron, sin embargo si estas tomándote el tiempo de leerlo espero sea de tu agrado.

Contribuyendo desde tu comezón

Creo la mejor manera de explicarte esto es empezar por mi primer intento por contribuir a un proyecto de código abierto. Hace unos años estaba trabajando en una devshop donde necesitábamos implementar un meta-buscador de productos y una de nuestras fuentes de información era Amazon, cuando estábamos haciendo la implementación nos encontramos con una biblioteca de JavaScript de nombre t3chnoboy/amazon-product-api la cual contenía algunas de las operaciones que necesitábamos en nuestro proyecto; sin embargo, ya que avanzamos con la implementación, nos encontramos con que no todas las operaciones que íbamos a utilizar estaban contenidas en esta dependencia, por lo que decidí ponerme a leer cómo estaba hecha la biblioteca e intenté agregar las operaciones que nos faltaban.

Ya que terminé de realizar el primer cambio, decidí probar suerte y abrí un pull request titulado Added support for ItemPage donde después de un poco de feedback por parte de t3chnoboy terminó siendo integrado.

Después de enviar otro aporte al repositorio t3chnoboy me ofreció hacerme colaborador del proyecto para que pudiera hacer aportes sin necesidad de depender de mi Fork, no sé si fue porque ya no le interesaba tanto la dependencia o bien porque vio mi interés por seguir haciéndole mejoras.

De este primer intento aprendí que no se necesita ser un Super Senior para comenzar a contribuir, solo es de tener una necesidad y un poco de ganas de intentarlo. La comunidad está abierta a recibir gente nueva y a ayudarte a mejorar, así que no te descartes sin intentarlo.

No todo lo que envíes será aceptado

Por esas fechas estaba explorando un paquete llamado cropuploader para un framework de JavaScript llamado Meteor JS, envié un pull request donde agregaba algunos archivos de configuración faltantes para que el ejemplo funcionará y apliqué una indentación automática para satisfacer a JSHint. Sin embargo, al autor le parecieron innecesarios estos cambios de estilo y prefirió aplicar él mismo los cambios de configuración que consideró necesarios, cerrando mi pull request.

De esta experiencia aprendí que no todo lo que envíes a un repositorio público necesariamente será aceptado, pero esta no es razón para desmotivarte. Hay muchos proyectos ahí afuera esperando gente entusiasta en busca de sumarse a un proyecto.

Nunca sabes quién terminará viendo tu trabajo

En otra ocasión necesitábamos hacer una prueba de concepto para un proyecto que teníamos que estimar relacionado con visualizar archivos de impresión 3D STL. Parte de los requerimientos del proyecto era que este fuera desarrollado con React, así que en nuestra búsqueda encontramos una biblioteca de nombre react-stl-viewer la cual hacia la implementación para visualizar los archivos STL utilizando Three.js. Después de echar un ojo al código terminamos haciendo un refactor de esta biblioteca para remover código duplicado que encontramos y hacerla más mantenible, ya que existía la posibilidad de si el cliente decidía seguir adelante con el proyecto era una dependencia que íbamos a terminar utilizando en producción, y no hacer estas mejoras se podía volver un dolor de cabeza potencial; y pues hecho dicho refactor decidimos enviar su respectivo pull request.

Lo interesante de este aporte fue que años después me contactaron para invitarme a grabar un curso relacionado con esta dependencia, aunque lamentablemente por falta de tiempo no pude seguir adelante con ello. Sin embargo de esta experiencia me quedó el aprendizaje de que uno nunca sabe quién verá tu trabajo y tal vez termine abriéndote puertas a cosas que no esperabas.

Creando impacto con tus aportes

Más delante en mi carrera, estuve trabajando en un proyecto de eCommerce donde utilizábamos Solidus como framework de desarrollo. Conforme iba haciendo mejoras al proyecto, aportes para el framework iban saliendo a la luz.

De los aportes que pude ir enviando al framework, hubo uno que me dejó un aprendizaje muy valioso, fue el cambio titulado [API] Complete Shipments Big json with small json fields #3221. Este cambio consistía en fusionar los campos que devolvía el endpoint de Shipments Big JSON con los campos del endpoint de Shipments Small JSON, ya que de primera vista daba la impresión de que small JSON era solo un subset de Big JSON pero en la práctica contenían diferente información, lo que hacía que no fuera posible intercambiarlos.

Después de hablarlo con uno de los miembros del Core Team en el Slack de la comunidad, apliqué el cambio, el cual literal fue agregar solo 1 línea de código a un archivo y remover 10 líneas que ya no eran necesarias. Este Pull request terminó etiquetado como un cambio importante para el release de la siguiente versión del framework. De esta experiencia aprendí que cambios grandes no implican tocar miles de archivos sino estar consciente del impacto que tu contribución puede causar al ecosistema.

Enseñando desde el Open Source

Para este momento de mi carrera ya había trabajado como maestro en una universidad local y había participado como mentor en un bootcamp. Sin embargo, el papel del Open Source era el de utilizar frameworks o librerías para hacer proyectos más allá de conocer cómo estaban hechas las dependencias que se utilizaban. En 2019 tuve la oportunidad de ser aceptado como mentor en el programa de RubyMe organizado por Ruby Together, este programa consistía en apoyar a un mentee a iniciar a hacer aportes al Open Source utilizando Ruby. Mis aportes a proyectos de Open Source fueron mi carta de presentación para formar parte de este proyecto.

Durante 3 meses estuve trabajando con Alicia, una chica de Atlanta que decidió hacer su cambio de carrera de ciencias políticas a desarrollo de software. Estuvimos haciendo aportes a diferentes proyectos, enviando desde mejoras a la documentación así como funcionalidades nuevas. Considero que lo más interesante durante este programa de mentorías fue hacer la transferencia de conocimiento de cómo abordar un proyecto cuando no estás familiarizado con él.

Concluyendo

Trata de que tus aportes sean relacionados con algo que estés trabajando, de esta manera no lo verás como algo forzado o un trabajo extra.
No hay aportes pequeños, siempre que sea algo para mejorar el proyecto es un candidato a ser integrado. Roma no se hizo en un día, posiblemente quieres que tus aportes sean al repositorio más importante de la comunidad a la que perteneces, sin embargo, hasta hacer una corrección en la documentación es algo que ayuda a crear un mejor ecosistema y sentará las bases de otros aportes que en un futuro estarás haciendo.
Considera el Open Source como parte de tu portafolio profesional, un pull request o merge request público dice más que un curriculum lleno de estrellitas sin pruebas.
Usa el Open Source como una herramienta para enseñar a otros o aprender algo nuevo. A menudo escucho comentarios como “no tengo experiencia” o "no sé por dónde empezar". El Open Source es un excelente lugar para empezar a crear experiencia comprobable, incluso antes de empezar a buscar trabajo activamente. Las guías de contribución, los issues y los pull request existentes son un excelente lugar para que empieces a relacionarte con el proyecto y tengas un mejor entendimiento de a dónde va este encaminado.

Y bueno, quiero agradecerte por leer hasta aquí, espero este pequeño ensayo te sea de utilidad en tu camino como desarrollador, si quieres charlar puedes encontrarme en redes sociales en @JuanCrg90 y en la comunidad de Calzada Code, mis DMs están abiertos.

Quiero ser un ingeniero de software remoto

Juan C. Ruiz — Sat, 09 Oct 2021 05:19:11 +0000

Este Artículo esta basado en un hilo de twitter que publiqué hace unas semanas: Quiero ser un Ingeniero de software remoto

Hace unos días recibí un DM de un joven de primer año de universidad en computer science con el texto: "Señor, quiero ser ingeniero de software remoto" seguido de un par de mensajes y la pregunta en concreto: "Entonces señor, ¿cómo puedo conseguir un trabajo remoto ...?"

Nota: los textos citados en el párrafo anterior, pasaron por google translate, si me ves en algún evento digital o físico post pandemia no me digas Señor soy chavoruco joven forever así que un "wey 🇲🇽" o "Juan" basta.

Para no hacerte el cuento mas largo te comparto algunos de los consejos que se me vinieron a la mente al leer su comentario y que fue parte de lo que le terminé compartiendo. Nota: Los siguientes párrafos vienen desde mi experiencia personal y puede que a otros les haya funcionado diferente, no hay recetas mágicas en la vida:

Comienza a practicar y crear un portafolio, no te esperes hasta ver los temas en tu universidad, hoy día hay recursos como

En los que puedes ir aprendiendo de los temas que a ti te interesan.

Trabaja en tu comunicación en Inglés, si estas leyendo este artículo, es muy probable tu Idioma nativo sea el español así que enfócate en pulir tus habilidades para comunicarte en Inglés. La gramática, ortografía y una buena pronunciación son tus aliados. De lo anterior puedo decirte, no te detengas con el argumento de "mi ingles no es el mejor" yo a la fecha cometo muchos errores y sigo estudiando, pero el simple hecho de poder trasmitir una idea en más de un idioma te abre muchísimas puertas. Hoy día hay Herramientas como Duolingo, Elsa Speak donde puedes practicar en tus ratos libres y a tu ritmo. Ya si buscas atención personalizada con un maestro, italki es una buena opción.

Previamente hablaba de un portafolio, pero es bueno comentar que las bases son muy útiles, buenas bases hacen que tu capacidad de adaptarte a nuevas herramientas y tener un mejor entendimiento de los problemas sea más solida. Por lo que conocer conceptos como Notación Big O o algoritmos "de libro" te ayudará a la hora de aplicar a algunas empresas. Plataformas como: CodeSignal o HackerRank son Lugares buenos para practicar. Hay quien también recomienda el libro de "Cracking the Coding Interview" para eso, en lo personal nunca lo he leído así que no puedo decir que es 100% necesario.

Volviendo al tema de la comunicación, aprende a trabajar de forma asíncrona. Cuando trabajas remoto para una empresa de otro país es muy común trabajar con personas que están en husos horarios distintos por lo que el concepto de "Para YA" no existe como tal. de lo anterior, eso no significa que no haya trabajo urgente, simplemente es que escribir un mensaje y esperar respuesta inmediata no es el estándar.

En cuanto a libros que a mi me motivaron al inicio de mi carrera en software hay 2 que quisiera recomendarte:

Passionate Programmer en el cual, a través de una serie de pasajes cortos, Chad Fowler te comparte su perspectiva de ser un desarrollador de software después de haber tenido una carrera en música.
Remote: Office Not Required el cual fue escrito por los creadores de @basecamp y hoy día es un buen referente de lo "ideal" en un ambiente remoto. OJO, NO es una biblia, no es un manual que debes seguir al pie de la letra, son consejos de lo que a ellos les ha funcionado.

Algo muy importante que te ayudará en tu camino es acercarte a comunidades de entusiastas y expertos que existen en tu zona o bien en internet, este tema ha cambiado mucho desde que empezó el distanciamiento social. Comunidades como Calzada Code, Future Lab, Hackademy, Visual Partner-Ship, enrails son solo algunas de las comunidades que hoy día están en linea y que realmente disfrutan compartir y ayudar a otros en su carrera.

Recientemente el equipo de Hackademy creo este recurso para que podamos conectar con más comunidades https://comunidades.lat.

Ahora sí, tal vez en este punto es de ¿y bueno cómo consigo el trabajo remoto? Una vez que hayas pulido algunas de tus habilidades (OJO de nuevo, no estoy diciendo TODA la lista de arriba), comienza tocando puertas buscando alguna oportunidad. Plataformas como remotiveio, fiverr, Upwork son buenos lugares para inicia buscar y darte una idea de lo que hay en el mercado actual. Ya que hayas ganado más experiencia es posible buscar en empresas grandes como GitLab, Shopify, X-Team, entre otras.

Espero te sea de utilidad este pequeño blogpost. Repito, todo lo que puse ha sido desde mi experiencia personal, puede que haya cosas sean distintas en tu forma de ver el mundo y es totalmente válido. Mis redes sociales están abiertas si tienes dudas o simplemente quieres charlar.

¿Por qué aprender Ruby en 2021?

Juan C. Ruiz — Sun, 27 Jun 2021 16:37:05 +0000

Ruby es un lenguaje de programación open source de propósito general el cual tiene más de dos décadas de vida. Su creador, Yukihiro Matsumoto, lo define como un lenguaje optimizado para la felicidad de los programadores. Cuenta con una sintaxis amigable la cual permite escribir piezas de código fáciles de leer y escribir.

Sin embargo, tal vez te preguntes si vale la pena aprender este lenguaje de programación en pleno 2021. He llegado a escuchar comentarios como: "Ruby ya es viejo ¿no?" o "¿Aún hay quién lo use?". Para responder a estos dos comentarios basta con revisar un par datos los cuales pueden ayudarnos a crear nuestro propio criterio.

Ruby fue lanzado oficialmente al público en 1995, mientras que la primer versión pública de Python fue liberada en 1991 siendo esta la 0.9.0. A su vez, JavaScript que hoy día es uno de los lenguajes más populares, fue anunciado por Netscape y Sun Systems en diciembre de 1995. Actualmente Ruby se encuentra en su versión 3.0, siendo totalmente compatible con la versión 2.7 y cuenta con características como concurrencia a través de Ractor y Fiber Scheduler así como Análisis estático utilizando RBS y TypeProf.

Ruby ha destacado en el campo de las aplicaciones de internet siendo Ruby on Rails su framework más popular. Este es utilizado por empresas de talla internacional como GitHub, GitLab, Shopify, Cookpad, Domestika entre otras, así como por startups las cuales aprovechan las bondades del lenguaje y del framework para poder crear iteraciones de sus productos rápidamente.

Además de Ruby on Rails, existen bastantes proyectos creados en Ruby que son ampliamente utilizados por la comunidad de desarrolladores de software, aún cuando no desarrollen en este lenguaje. Por listar algunos tenemos:

Homebrew, el manejador de paquetes de MacOS
Cocoapods, el manejador de dependencias para Swift y Objective-C.
Fastlane, la herramienta para automatizar tareas de liberación de aplicaciones Android y iOS
Vagrant, la herramienta para creación y distribución de entornos de desarrollo.
Metasploit, el framework de pruebas de penetración más utilizado a nivel mundial.

Al ser un lenguaje maduro, Ruby cuenta con una documentación robusta de sus diferentes versiones siendo https://docs.ruby-lang.org/ la página oficial de esta y https://ruby-doc.org/ la referencia generada desde RDoc. Además de la documentación, Ruby cuenta con una comunidad activa en diferentes plataformas como Stack Overflow, La lista de correo oficial, Boletines semanales como Ruby Weekly, enrails entre otros.

En Resumen, Ruby es un lenguaje que a sus más de 25 años sigue dando de que hablar, cuenta con una amplia variedad de proyectos donde la comunidad contribuye activamente y cada día nuevas aplicaciones son lanzadas a internet utilizando Ruby on Rails.

Si estás interesado en aprender los fundamentos de este lenguaje, mi curso de Ruby desde Cero es para ti. En el curso aprenderás desde como instalar el lenguaje en tu sistema hasta cómo aplicar la orientación a objetos para crear tus primeros programas en este maravilloso lenguaje.

Referencias

Optimizando costos en GitHub Actions

Juan C. Ruiz — Sun, 31 May 2020 03:19:53 +0000

English version

Recientemente en EasyBroker migramos nuestro sistema de Integración continua a GitHub Actions.

Inicialmente configuramos un Workflow con 12 contenedores considerando que era una buena idea para identificar rápidamente donde fallaron las pruebas.

En promedio cada contenedor tardaba 6 minutos en completar su tarea, mientras que 2 contenedores en específico (modelos y un grupo de controladores) tardaban en promedio 12 minutos.

Después de una semana trabajando con esta nueva implementación recibimos un mensaje de GitHub alertándonos que estábamos por llegar al límite de uso de la capa gratuita que GitHub nos provee 💸💸💸, por lo que decidimos investigar.

En primer lugar notamos que de los 6 minutos que tardaban los 10 contenedores más rápidos, en promedio 4 minutos eran tareas de configuración.

Posteriormente notamos que a pesar de tener el cache "configurado", nuestro contenedor estaba descargando las gemas una y otra vez.

Y finalmente solo se invertían entre 20 y 50 segundos en ejecutar las pruebas.

Ahorrándonos unos minutos

Lo primero que decidimos hacer fue pasar de 12 contenedores a 2 contenedores. Considerando que las pruebas de los controladores de agentes son las que toman más tiempo, decidimos que lo modelos podían convivir con las pruebas de los 10 contenedores que tardaban 6 minutos en promedio, terminando con una configuración como la siguiente.

Antes

strategy:
      fail-fast: false
      matrix:
        test_folder: [models, helpers, jobs, lib, mailers, presenters, services, controllers/*.rb, controllers/admin, controllers/agent, controllers/webhooks, controllers/api]

Ahora

strategy:
      fail-fast: false
      matrix:
        test_folder: [models helpers test/jobs test/lib test/mailers test/presenters test/services test/controllers/*.rb test/controllers/admin test/controllers/webhooks testcontrollers/api, controllers/agent]

Lo siguiente fue actualizar el apartado de cache para hacerlo funcionar, nuestra configuración utilizaba la versión 1 de actions/cache e incluía la opción de restore-keys la cual según la documentación es opcional.

- name: Gem cache
        uses: actions/cache@v1
        with:
          path: vendor/bundle
          key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }}
          restore-keys: |
            ${{ runner.os }}-gems-

Por lo que simplemente actualicé a la versión 2 de la acción y removí la opción de restore-keys al considerar que no es algo que requerimos aún.

- name: Gem cache
        uses: actions/cache@v2
        with:
          path: vendor/bundle
          key: ${{ runner.os }}-gem-use-ruby-${{ hashFiles('**/Gemfile.lock') }}

Además de eso, revisando el paso donde se instalan las dependencias, encontré que lo teníamos fusionado con el paso para crear la base de datos y nos mostraba un deprecation warning al momento de ejecutar bundle install con la bandera para indicar la ruta de instalación de las gemas.

- name: Bundle Install and Create DB
        env:
          RAILS_ENV: test
          DB_PASSWORD: root
          DB_PORT: ${{ job.services.mysql.ports[3306] }}
        run: |
          sudo /etc/init.d/mysql start
          cp config/database.ci.yml config/database.yml
          gem install bundler --version 2.0.2 --no-ri --no-rdoc
          bundle install --jobs 4 --retry 3 --path vendor/bundle
          bin/rails db:setup

[DEPRECATED] The `--path` flag is deprecated because it relies on being remembered across bundler invocations, which bundler will no longer do in future versions. Instead please use `bundle config set path 'vendor/bundle'`, and stop using this flag

Por lo que opté por separarlo en 2 pasos independientes y actualizar la forma en la que bundler detecta la ubicación de las gemas.

- name: Bundle install
        run: |
          gem install bundler --version 2.0.2 --no-ri --no-rdoc
          bundle config path vendor/bundle
          bundle install --jobs 4 --retry 3

- name: Create DB
        env:
          RAILS_ENV: test
          DB_PASSWORD: root
          DB_PORT: ${{ job.services.mysql.ports[3306] }}
        run: |
          sudo /etc/init.d/mysql start
          cp config/database.ci.yml config/database.yml
          bin/rails db:setup

Con estos pequeños cambios logramos pasar de 4 minutos en la instalación de las gemas a tan solo 4 segundos.

Antes

Ahora

Como paso final para esta primer etapa de optimización, revisé los pasos dónde realizábamos la instalación de algunas dependencias por apt-get y encontré que algunos eran innecesarios. Por ejemplo, cuando verificábamos la conexión a MySQL, estábamos tratando de instalar el cliente que ya está disponible y esto tomaba 20 segundos en promedio (entre verificar la instalación y verificar que la conexión fue exitosa) con solo remover la llamada de apt-get que no era necesario logramos bajar a un promedio de 6 segundos.

Antes

Ahora

Notas finales

Esta fue la primer etapa de nuestra actualización para tener un sistema de integración continua saludable y eficiente, logramos pasar de un promedio de 1 hora 30 minutos por ejecución.

A tan solo 20 minutos en promedio.

Como experiencia nos llevamos que, en servicios donde la factura es por tiempo de uso, el ahorrar segundos es crucial y es importante poner atención a los detalles por pequeños que sean. Como en el caso de la instalación de dependencias que ya existen en el contenedor. Puede que 13 segundos ahorrados suene a nada, pero si lo multiplicamos por el número de builds que tiene tu empresa al día, puede que logres ahorrar un par de horas en tu factura.

Lo siguiente que haremos será tratar de mover la instalación de dependencias que requieren ser instaladas manualmente a un contenedor Docker (aún necesito investigar si es posible esto) y utilizar alguna herramienta como TestProf para identificar los tests más lentos y ver la manera de optimizarlos.

Optimizing costs in GitHub Actions

Juan C. Ruiz — Sun, 31 May 2020 03:00:11 +0000

Recently in EasyBroker we decided to migrate our continuous integration system to GitHub Actions.

Our first setup was a workflow with 12 containers considering a good idea to quickly identify errors in our tests.

The average time per container was about 6 minutes, while only 2 containers in specific (models and a group of controllers) took about 12 minutes.

After a week working with this new implementation, we received a message from GitHub warning us about we were near to consume all the minutes of the free tier that they provides 💸💸💸, so we decided to investigate.

First of all, we noticed the 10 containers that took 6 minutes to complete the task, 4 minutes were for setup.

Later we found despite we had the cache "configured", our container was downloading the gems over and over again.

And finally, the tests were taken only between 20 and 50 seconds of the process.

Saving some minutes

The first change that we did was going from 12 containers to 2. Considering the agent controller tests takes most of the time, we decided to merge the models container with the other 10 containers that were taken between 20 and 50 seconds to complete the tests, ending with a configuration like the following.

Before

strategy:
      fail-fast: false
      matrix:
        test_folder: [models, helpers, jobs, lib, mailers, presenters, services, controllers/*.rb, controllers/admin, controllers/agent, controllers/webhooks, controllers/api]

Now

strategy:
      fail-fast: false
      matrix:
        test_folder: [models helpers test/jobs test/lib test/mailers test/presenters test/services test/controllers/*.rb test/controllers/admin test/controllers/webhooks testcontrollers/api, controllers/agent]

The next change was updating the cache setup to make it work, our configuration was using the version 1 of actions/cache and we were including the restore-keys option, the documentation mentions that this input is optional.

- name: Gem cache
        uses: actions/cache@v1
        with:
          path: vendor/bundle
          key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }}
          restore-keys: |
            ${{ runner.os }}-gems-

So I updated to version 2 of the action and I removed the restore-keys input considering is not necessary at this moment.

- name: Gem cache
        uses: actions/cache@v2
        with:
          path: vendor/bundle
          key: ${{ runner.os }}-gem-use-ruby-${{ hashFiles('**/Gemfile.lock') }}

In addition to that, reviewing the step where the dependencies are installed, I found that we had it merged with the step to create the database and it showed us a deprecation warning when executing bundle install with the flag to indicate the installation path of the gems.

- name: Bundle Install and Create DB
        env:
          RAILS_ENV: test
          DB_PASSWORD: root
          DB_PORT: ${{ job.services.mysql.ports[3306] }}
        run: |
          sudo /etc/init.d/mysql start
          cp config/database.ci.yml config/database.yml
          gem install bundler --version 2.0.2 --no-ri --no-rdoc
          bundle install --jobs 4 --retry 3 --path vendor/bundle
          bin/rails db:setup

[DEPRECATED] The `--path` flag is deprecated because it relies on being remembered across bundler invocations, which bundler will no longer do in future versions. Instead please use `bundle config set path 'vendor/bundle'`, and stop using this flag

So I opted to separate it into 2 separate steps and update the way the bundler detects the location of the gems.

- name: Bundle install
        run: |
          gem install bundler --version 2.0.2 --no-ri --no-rdoc
          bundle config path vendor/bundle
          bundle install --jobs 4 --retry 3

- name: Create DB
        env:
          RAILS_ENV: test
          DB_PASSWORD: root
          DB_PORT: ${{ job.services.mysql.ports[3306] }}
        run: |
          sudo /etc/init.d/mysql start
          cp config/database.ci.yml config/database.yml
          bin/rails db:setup

With these little tweaks we were able to pass from 4 minutes installing the gems in just 4 seconds.

Before

Now

As a final step for this first stage of optimization, I took a look at the steps where we did the installation of some dependencies using apt-get and I found that some calls were unnecessary. For example, when we verified the MySQL connection, we were trying to install the client that is already installed in the container and this took about 20 seconds (between verify the installation and perform the connection test). Removing this unnecessary apt-get call we were able to down the time to 6 seconds.

Before

Now

Takeaways

This was the first stage of our update to have a healthy and efficient CI system, after apply these changes we were able to reduce from about 1 hour and 30 minutes per execution.

To only about 20 minutes.

The experience of this is, in services where the billing depends on the execution time, saving seconds is crucial, and it is important to pay attention to the little details. Like the apt-get dependency installation scenario where the dependencies are already installed in the container. Maybe 13 seconds sounds as nothing relevant, but if you consider the number of builds that you have in your company every day probably you can save 1 or two hours per day and this will be reflected in your billing.

The next step is to try to move the dependencies that require to be installed manually into a Docker container (I still need to investigate if this is possible) and use a tool like TestProf to identify the slowest tests and try to optimize them.

Maintaining an open source gem in the Hacktoberfest

Juan C. Ruiz — Fri, 25 Oct 2019 02:24:07 +0000

Some months ago I created a little gem to quickly access to different GitHub sections from the command line. The name of my gem is vpr (view pull request).

The idea of this gem is simple, you call the vpr command + some instruction + a commit SHA and you can access to a Github section of your interest. For example, vpr visit 123abc sends you to the commit page of the selected commit.

In this Hacktoberfests I decided to open some issues to add the support for bitbucket pages. It was incredible the speed that the users started to contribute and recommend things for the project, like @andrewmcodes who added a GitHub action to run standardRB in the pull requests.

Add linter/formatter GitHub action #12

andrewmcodes posted on Oct 04, 2019

I noticed you aren’t using a linter/formatter like rubocop or standardRB. Would you be interested in adding one?

If so I can hook up a GitHub action for you. Check out this repo for an example of actions I have created.

View on GitHub

Even if this is a simple side project, I'm happy to have had the opportunity to be a maintainer this year. I hope the next year have the opportunity to host a contribution fest in my city.

All these contributions will be released to RubyGems in November, thanks to all the participants for your support. If you are interested in know more about vpr, please visit the Github repository.

JuanCrg90 / vpr

VPR is a CLI that helps you to quickly manage your project in GitHub/GitLab/Bitbucket

vpr

VPR is a CLI that helps you to quickly manage your project in GitHub/GitLab/Bitbucket You can visit with ease different project sections, like the issues page, a specific commit create pull requests (merge requests for GitLab), and more, also is configurable for other platforms PRs are open.

Installation

  $ gem install vpr

Usage

All the commands use the URL set as origin in your git remote to perform the web request, you can use the flag --remote=REMOTE to specify which service you want to visit if you have your project stored in more than one platform.

`vpr branch`

Open in your browser your current branch.

`vpr branches`

Open the page that shows the uploaded branch list.

`vpr help`

Show the likst of available vpr commands, you can pass an specific command to get more details.

`vpr home`

Open in your browser the project page.

`vpr issues`

Open the in…

View on GitHub