Suena intro del Príncipe de Bel Air:
Nota: Historia escrita con un teclado configurado con el alfabeto, y comandos, en inglés.
Un mensaje de Slack apareció. “¿Puedes verificar qué es lo que esta causando este error? Tengo una reunión importante con un cliente a las 3 pm, y quisiera poder mostrar la capacidad del programa”, leía.
Busqué mi listado de música “escribiendo furiosamente”, me hice una dona en el pelo, me tomé un poco de café, y le di a las teclas de acceso directo a hacer búsqueda en “Spotlight” [command + barra espaciadora ] para buscar “Terminal” y poder accesar las líneas de comando del sistema operativo Mac.
Note: Comandos van a estar entre corchetes ( [ ] ).
¡Vamos a mandar!
“¿Dónde estoy?” Sonó filosófico cuando lo pensé, pero en realidad, al entrar [ pwd ] ( Imprimir Directorio de Trabajo. pwd por sus siglas en inglés) tengo una mejor idea de mi localización en el directorio. [ pwd ] es como mi mapa de Google para archivos, me enseña en cuál directorio estoy.
“!Excelente! Estoy en el directorio que quiero estar. Ahora, no recuerdo el directorio al que quiero navegar,” pensé instantáneamente.
Pero me contesté: “[ ls ] (Listado del contenido del directorio) viene como anillo al dedo”. [ ls ] muestra el contenido dentro del directorio actual.
Mis pensamientos continuaron: “Ahora que recuerdo en cuál directorio copié el proyecto, necesito [ cd ] (cambiar de directorio) hasta llegar al a la copia.”
Entrando [ cd ], seguido por el nombre del directorio subsiguiente al que quiero navegar, separando cada nombre con una barra [ / ] continué y comencé a cambiar de directorio.
Hasta que me encontré adentro del directorio src (directorio fuente). “¡Espera un momento!, ¿el paquete json (package.json) estará dentro del directorio src? ¡Déjame [ ls ] esta cosa!,” continué.
“Nope, no hay forma de que pueda ejecutar el programa desde este directorio,” me dije… en voz alta.
“Shhhhhhhhhh, ¡estoy en una reunión!” dijo Ramona, mi colega.
Susurrado: “Necesito subir un nivel en el directorio, pero ¿cómo?”
Para eso es que se utilizan los dos puntitos: [ cd .. ]. Dos puntos luego de cd significa subir un nivel en el directorio.
Mi pensamiento dijo: “Antes de ejecutar el app, déjame aprovechar este momento para abrir el editor de código Visual Studio Code”. Así que ejecuté el comando [ code . ] .
“Vale, ahora ejecutemos la aplicación,” pensé. Y con [ npm start ] se inicializó la aplicación.
Momento de git
“Antes de hacer algo, necesito asegurarme de que tengo una copia local de la versión mas actualizada del programa que esta en desarrollo,” continuaron mis pensamientos.
Así que es momento para: “La rutina git”.
“Pero antes ☝️, déjame abrir una nueva pantalla, entrando [ command + t ] para abrir una pantalla nueva en el terminal, para que la aplicación siga siendo ejecutada en la pantalla actual,” me dije.
Déjame decirte, lectora (or) de mi pensamientos, en qué consisten los Casi cuatro pasos de la rutina git. Eso sí, asumo que tienes conocimiento de lo básico en git. ¡No te preocupes si no sabes! Te comparto una breve introducción.
Casi cuatro pasos de la rutina git
Primero, verificar el estado de árbol de trabajo local. Porque francamente, siempre olvido que estaba haciendo antes. Así que entro el comando [ git status ].
Si la rama no esta limpia, guarda los cambios
Segundo, he aprendido, luego de muchos intentos, que git no cambia de rama si hay algún cambio en el código y estos cambios no están guardados temporeramente (“stashed”) ó si los incluirás eventualmente en la rama máster (“commit”).
Así que, procedí a entrar y ejecutar el comando [ git stash ] para guardar los cambios de forma temporera.
Ahora, intentaré cambiar de la rama actual a la rama local de desarrollo para asegurarme de que tengo el contenido actualizado de la version remota de la rama de desarrollo.
Cambiar rama local
Ahora que la rama esta limpia, necesito cambiar el HEAD del árbol de trabajo a la rama de desarrollo (“development”). [ git checkout development ] hace justo eso.
Actualizar la rama de desarrollo
Finalmente, actualiza la rama local de desarrollo con la rama de desarrollo del repositorio remoto. sí que entro [ git pull origin development ].
El comando [ git pull ] busca el contenido de la rama de desarrollo en el repositorio remoto y lo une el contenido remoto con el contenido de la rama local. El comando [ origin development ] se refiere a la rama que el sistema va a buscar para actualizar. “Origin” se refiere al repositorio de origen, en este caso el remoto. “Development” se refiere al nombre de la rama del árbol de trabajo.
Luego de la rutina
De este punto en adelante, mis comandos git varían dependiendo de lo que tengo que hacer en el día. En esta ocasión, tengo que encontrar la causa de un error y solucionar ese problema. Por lo que, tengo que crear una nueva rama para ejecutar los cambios en la nueva rama. Eso require que cambie el HEAD del árbol de trabajo de la rama local de desarrollo (“development”) a la rama creada.
“¿Cómo se va a llamar la rama nueva?” comenzaron pensamientos nuevamente.
“Algo sencillo, directo al grano,” señaló un pensamiento con la voz del líder del equipo.
“Me voy con fix/this-feature,” decidí. Así que hice una entrada del comando [ git checkout -b ‘fix/this-feature’.
Para asegurarme de que no estoy en la rama de desarrollo, comando [ git status ].
“Sí, estoy en la nueva rama de trabajo,” me confirmé.
Luego, necesito unir la rama actualizada con la nueva rama para que la nueva rama de trabajo esta al día con la rama de desarrollo actualizada. El comando [git merge development ] ejecuta esta unión.
Few. Me alegra haber sacado eso del medio. Esos pasos, justo hasta cambiar desde la rama de desarrollo a la rama nueva o retrabajada, siempre me ponen nerviosa.
“¡Ahora, sí estoy lista para capturar ese error!” Y así fui a la aplicación y a mi editor de código a averiguar que estaba pasando.
Ocurrió un error
Estaba envuelta mientras escribía código, y todo estaba funcionando bien hasta que algo pasó que un error confuso comenzó a aparecer.
“Otra aplicación esta usando ese puerto”, leía pero en inglés.
Como excelente depuradora, detuve el programa de la aplicación con [ control + c ] …
… y volví a ejecutar el programa, pero no ayudó.
Así que le pedí ayuda a mi amigo Google, y me sugirió que localizara y matara el proceso en el puerto. Para lograr esto, necesito identificar el id del proceso que intentaba matar, y pues, terminarlo.
El comando para localizar y visualizar el listado de procesos trabajando en un puerto específico es [ lsof -i:PORT ], donde [ lsof ] significa listado de archivos abiertos, [ -i ] es la lista de procesos y [ PORT ] es el número de puerto a verificar. En este caso, queremos verifiar el puerto 3000, por lo que [ lsof -i:PORT ] realmente se entra en el terminal como [ lsof -i:3000 ].
Luego de localizar el proceso que quiero terminar, procedo a entrar el comando [ sudo kill -9 PID ] para matar el proceso.
Estoy lista para reinicializar el programa de la aplicación.
“Grrrrrlrllrrlrlr” gruño mi estómago. “Estoy hambrienta, y no puedo pensar cuando mi estómago me grita,” pensé.
“¿Almorzamos?” me pregunta Ramona.
“¡Por favor!” respondí y salí a almorzar como que sintiendome así:
Punto aparte
Disfrute de estas hojas de anotaciones o “cheat sheets” que incluye los comandos usados a través de la historia.
También, escribí esta historia escuchando de fondo el nuevo álbum de Four Tet, Sixteen Candles, que fué lanzado recientemente. El principio de la primera canción establece un ánimo increíble todvía sutíl para tener un día productivo. A sido mi álbum a escuchar durante este periodo de cuarentena.