Subscribe
Share
Share
Embed
Dev&Ops es el espacio donde hablamos de cultura tech, compartimos anécdotas reales y damos consejos prácticos para todo entusiasta del mundo del desarrollo y la tecnología. Acompáñanos a descubrir las últimas tendencias, aprender de nuestras experiencias y recibir tips que te ayudarán a destacar en este entorno digital en constante evolución.
Douglas (00:00)
en cuestión de automatizar que tal vez sería un bash script y ahí...
usaría MySQL dump para sacar el dump del esquema de base de datos y luego el comando CLI de zip para comprimirlo o si quieres usar un tar file, la compresión que prefieras y luego muy probablemente el CLI de AWS para agarrar ese archivo y mandarlo a AWS. Entonces el uso del CLI
está listo para automatizar por medio de scripting o cualquier otra herramienta que sea necesaria y esto se vuelve súper súper útil de nuevo al administrar más de un sistema.
hacerlo manualmente en cada uno toma demasiado tiempo y automatizar es el objetivo final en lo que tiene que ver la cultura DevOps.
Hola, sean todos bienvenidos a un episodio más de Dev & Ops, este espacio en el cual hablamos de desarrollo, tecnología, DevOps y su cultura en general. Y como es costumbre, estoy acompañado de mi amigo y co-host Juan Ramos, a quien por supuesto le doy la cordial bienvenida. Juan, ¿qué tal estás hoy?
Juan (01:14)
Hola Douglas, me encuentro muy bien, gracias por introducirme de esa manera y bueno, sí, estoy con muchos, una gran expectativa por el tema de hoy porque me gusta lo que vamos a hablar y siento que voy a aprender algunas cosas también, muchas cosas nuevas.
Douglas (01:32)
No, esa
es la actitud. Siempre aprendemos uno del otro en este espacio, al igual que estamos tratando de generar valor para aquellas personas que nos ven y nos escuchan. Y hablando del tema, vamos a introducirlo de un solo. Y es que hoy queremos comentar o discutir un poco acerca de CLI versus GUI.
en el mundo de DevOps. ¿Cuál es mejor en la cultura DevOps en general? Quiero aclarar que no estamos hablando solo de DevOps a los que se consideran el puesto DevOps como los system engineers o los sysadmin o las personas de sistema, sino que en la cultura DevOps en general.
cuál es mejor, CLI o el GUI. Y este es un debate que ha existido casi desde que se crearon las interfaces gráficas, obviamente no para usuarios en casa o no para usuarios de oficina.
definitivamente interfaz gráfica tiene un beneficio grande sobre las interfaces de comando en lo que tiene que ver con trabajo de oficina, trabajar con hojas de cálculo, etc. En ese sentido no existe el debate, sino en lo que tiene que ver con administración de sistemas y con la parte de desarrollo. Juan, este tema, CLI versus GUI, ¿qué vibra te traje este tema? ¿Sentís que esto te afecta o te incluye a vos como programador?
Juan (02:58)
Ok, interesante pregunta porque ya lo introdujiste desde un punto de vista de la cultura DevOps, entonces tenemos que recordar que la cultura DevOps abarca mucho más que solamente los que están en sysadmin, administrando los servidores. Y bueno, para los desarrolladores yo creo que también es relevante, yo he visto ambas posturas tanto a favor como en contra del CLI,
en los desarrolladores y yo creo que va dependiendo de la experiencia y qué tan versátiles somos con el uso de la terminal y diferentes comandos o qué tan visuales somos también a veces necesitamos un botón o algo que nos indique qué acciones podemos hacer y es válido también pero
Douglas (03:45)
mmm
Juan (03:58)
pero si desde mi punto de vista es un tema interesante interesante de ver porque pareciera que o es uno o es el otro y bueno no lo sé tal vez tal vez sí tal vez no tal vez hay un matiz de grises por ahí creo yo
Douglas (04:17)
será que hay matices de grises. Más
adelantito vamos a hacer un pequeño ejercicio, Juan, para tal vez ilustrar un poco qué tanto, si es cierto que nos afecta, más que todo nuestro día a día, y porque también tiene diferentes niveles ese tema. Lo mencioné al principio de que a nivel de usuario, de oficina, trabajar con...
reportes y cosas por el estilo, el GUI definitivamente tiene una ventaja y esa está necesaria y te vuelve más eficiente. Pero también lo que tiene que ver con que orquestrar sistemas grandes, sistemas que corren en múltiples contenedores o múltiples instancias, es ahí donde de repente nos ponemos a pensar.
aún ahí existen guis para ese tipo de cosas, pero lo vamos a ir discutiendo más adelante qué es lo que nos conviene más. Y yo creo que conviene, hablando de conveniencia, empezar con las definiciones para aquellas personas que tal vez no están tan familiarizados con los términos o lo han escuchado y lo entienden para sí mismo, pero nunca se han puesto a profundizar en ello, las definiciones. Y CLI, por sus iniciales en inglés, significa
Line Interface o Interface de Línea de Comandos. Es una interfaz, como su nombre lo dice, interfaz es lo que es la cara para comunicarte con un servicio o con un sistema. Y esta interfaz es por medio de texto, por medio de comandos, por medio de diferentes indicaciones vía teclado, le decimos a este sistema, a este servicio qué hacer.
Ejemplos de CLI, el GitHub CLI, tal vez alguien no lo sabía, pero GitHub tiene su propio CLI que no es Git, sino que es para trabajar con GitHub, abrir pull requests, para incluso aprobar pull requests, abrir issues, etc. También tenemos el CLI de AWS para interactuar con los diferentes servicios. Tenemos lo que se conoce como el Kube CTL o el Kube Control, no sé cómo lo llama a cada quien.
El Kripsyt LCLI que es para interactuar con el API de Kubernetes o en pocas palabras para interactuar con Kubernetes, levantar Deployments, Pots, Ingress y todo lo que se puede hacer con Kubernetes. Tenemos el Docker CLI que el que ejecutamos el Docker Run y el Docker Stop y todos los diferentes comandos de Docker, incluso Docker Compose que ahora está integrado en el mismo Docker CLI. También existen herramientas como NPM.
Juan (06:37)
NPM, at Docker Zone.
Douglas (06:53)
el popular npm que nos descarga medio internet cada vez que le damos npm install a ciertas aplicaciones de Node.js. Pero estos son algunos de los CLI más comunes. No sé, Juan, si te suena a otro CLI que vos digas, este CLI es súper popular y si alguien no lo ha entendido, este lo fijo lo ha usado y entiende que es un CLI.
Juan (07:13)
Sí, yo creo que depende del entorno de cada quien porque, por ejemplo, alguien que trabaja con Laravel probablemente está utilizando los diferentes CLI, por ejemplo, PHP, Artisan y todos estos comandos. Si estamos trabajando con infraestructura de AWS, probablemente tenemos el AWS CLI. Entonces, sí, hay muchos CLI que son muy buenos para cuando estamos trabajando con ese tipo.
de comandos. También hay otros que son como que más generales, por ejemplo en Linux y si no me equivoco también en Mac está el Grep, me parece que está en Mac, no estoy seguro. Y este tipo de comandos que ya están habilitados para nosotros y son muy populares. Requieren cierto conocimiento pero son muy populares en la comunidad.
Douglas (07:57)
Sí, si están en Mac.
Sí, sí. Y
me gusta que lo mencioné porque en efecto estos comandos son un CLI en sí mismos. Son una interfaz gráfica. Ahora, para dar la definición de GUI, GUI, por sus iniciales en inglés significa Graphical User Interface o interfaz gráfica de usuario. Similar al CLI, es para interactuar con un servicio, con una aplicación, pero por medio de una interfaz gráfica. Aquí ya tenemos botones,
tenemos drop downs, tenemos text box y tenemos notificaciones y a lo más bonito o a lo más simple que puede.
Juan (08:51)
animaciones
y todo.
Douglas (08:52)
animaciones incluso en efecto,
¿verdad? Entonces desde lo más simple a lo más elegante y bonito que puede haber. Ejemplos, tal vez dándole un poco de continuidad a los que dimos con CLI, pero en el caso de GUI tenemos el dashboard de GitHub. Ese es un GUI, ¿verdad? Donde hacemos lo mismo los pull requests, creamos hit-shoes y las diferentes interacciones, pero desde la interfaz gráfica, tenemos el dashboard de AWS.
al igual que con el CLI, se hace todo desde el dashboard, súper grande y súper complejo por cierto, pero ese es un ejemplo de GUI, tenemos el Docker Desktop.
Juan (09:29)
Abrumador, diría yo.
Abrumador, diría yo, que es el dashboard de AWS. Sí.
Douglas (09:34)
AWS sí, es abrumador, no
tenés razón, es abrumador. Yo no uso todos los servicios de ellos en mi día a día ni por cerca. Pero sí, también tenemos Juan el Docker Desktop, para aquellas personas que tienen Docker Desktop y no corren tal vez desde Linux nativo que...
Juan (09:46)
Sí.
Douglas (09:52)
Ya hay una versión de Docker de esto para Linux, por cierto, y es para aquellas personas que quieren interactuar con Docker por medio de la interfaz gráfica, en lugar de interactuar por medio de los comandos. Pero esos son como algunos de los ejemplos de interfaces gráficas como más populares. Y la misma pregunta, Juan, en este caso, ¿alguna interfaz gráfica que vos digas, esta es bien popular y vale la pena mencionarla?
Juan (10:19)
Interesante, diría yo que tal vez la interfaz para interactuar con los repositorios ya sea el github, no recuerdo el nombre la aplicación de github que la instalas en tu escritorio y puedes... exacto también hay una para bitbucket, source tree es muy popular también, la utilizan mucho en general por ejemplo cuando toca interactuar con git lo más común desde mi punto de
Douglas (10:33)
La explicación de escritorio de GitHub.
Sí.
Juan (10:48)
vista es que utilizan aplicaciones de interfaz casi no utilizamos la línea de comando a menos que sea algo muy corto algo muy muy muy concreto yo diría que esos son unos muy muy populares y bueno también hoy en día Docker Desktop y esas también cada vez son más populares como que prefieren eso a utilizar los comandos directamente en la terminal
Douglas (11:14)
Ajá, ajá. Sí, sí,
sí, porque en Desktop cada vez puedes hacer mucho más. Y esa es la intención, que la gente pueda acceder a las funcionalidades y beneficios de Docker sin tener que memorizarse comandos. Y también me llama la atención lo que mencionás de Git. También incluso los IDEs, como VS Code, tienen diferentes add-ons que permiten interactuar con Git. Y entonces, tratar de facilitar el flujo como vol...
Juan (11:38)
Sí.
Douglas (11:42)
decías y ahí donde pues vemos si en qué punto me facilita el trabajo un CLI y en qué punto me facilita el trabajo el GUI y para allá vamos y continuando entonces Juan con el tema lo que quisiera hacer es tal vez listar algunas de las ventajas y desventajas
tanto de los CLI como de los GUIs. Hay muchísimas ventajas y bastantes desventajas para cada uno de ellos, pero tal vez las más comunes, las que más suenan en internet o las que más se mencionan. Cuando alguien nos quiere dar un argumento, ya sea a favor o en contra de usar uno de los dos, y que vayamos dando nuestro comentario respecto a cada una de ellas, ya sea si lo compartimos o si hemos tenido experiencias con alguna de esas ventajas o desventajas. Y comenzando, por supuesto,
con el CLI, una de las mayores ventajas que se menciona y comienzo diciendo que yo estoy muy de acuerdo con ella, es que tiene un mejor rendimiento en cuanto a recursos. Como no tiene que cargar una interfaz, no tiene que tener procesos necesariamente corriendo en memoria para estarme mostrando algo todo el tiempo.
un CLI normalmente se ejecuta al momento que yo le doy una instrucción. Completa la instrucción y deja de correr, pero una interfaz gráfica continúa corriendo. Entonces, en ese sentido tiene un mejor rendimiento y a veces eso llega a generar un impacto bien grande en nuestro sistema dependiendo que tanto estamos haciendo con esa herramienta en particular. Pero esa es una de ventajas mayores.
grandes y conocidas de lo que es un CLI la cual yo comparto pero Juan me gustaría saber tu opinión en ese sentido.
Juan (13:37)
Si, definitivamente, es un motivo por lo que yo también prefiero en alguna, dependiendo de la situación, prefiero utilizar los CLIs porque es mucho más amigable con mi sistema operativo el utilizar una herramienta en vez de abrir toda la ventana y esperar a que carguen los recursos por detrás y luego pues que renderice la parte gráfica. En cambio, pues
en la terminal solo escribo lo que tengo que escribir y listo. Y ya después si son CLIs que utilizo muy seguido, empiezo a agregar pequeños macros o aliases y ya incluso es mucho más fácil. Por ejemplo, volviendo al tema de Git, hay mucha gente que tiene ya alias para simplemente con dos letras ya acortan toda una línea de comandos de Git. ⁓ Git commit add o Git
Douglas (14:34)
Sí.
Juan (14:37)
este pull, clone, estas diferentes comandos de git ya los tiene. Yo suelo hacer eso más con Docker porque en Docker a veces se empiezan a generar estas comandos bastante largos, incluso cuando empezas a filtrar los contenedores, empezas a darle formato a las columnas que quieres ver, entonces se vuelve un poco más largo la instrucción. Ahí entonces yo
Douglas (14:59)
mmm
Juan (15:07)
también utilizó aliases y macros como podríamos verlo como una macro pero de nuevo es más ligero la ejecución de eso desde mi punto de vista y más cuando estamos utilizando tal vez Douglas equipos que son más limitados por ejemplo hace poco mi laptop tuvo un percáncer y ahora tuve que quitarle una de las memorias RAM así que estoy con la mitad de RAM ahora
Douglas (15:19)
Sí. Sí,
Sí.
Juan (15:37)
por lo cual ya mi laptop ya no tiene la misma capacidad que tenía antes y pues trato de optimizar lo más que puedo mi trabajo cuando estoy utilizando la laptop.
Douglas (15:49)
Sí, sí, sí, no, yo... Dices en el punto, creo yo, ¿verdad? No es, tal vez tu perspectiva, sino que dices en el punto. Y esta es una de las razones, de hecho, por lo cual servidores Linux no se les instala siquiera interfaz gráfica, ¿verdad? Porque estos procesos que están corriendo en el fondo para desplegar una interfaz gráfica...
Juan (16:05)
Sí.
Douglas (16:13)
las estemos usando en el momento o no, el proceso está corriendo para estar preparado cuando lo necesites, eso consume recursos y que no son necesarios todo el tiempo para la aplicación que estamos corriendo y tal vez haya una ventaja contra servidores Windows en mucho sentido o para la mayoría de servicios, ¿verdad? Pero esa es una de las ventajas del CLI, Juan, que es más óptimo en cuanto a rendimiento y recursos. Otra ventaja...
Juan (16:16)
jajaja
Douglas (16:40)
es que me hace más eficiente o me hace hacer mi trabajo más rápido. De nuevo Juan yo estoy de acuerdo con esto, ¿en qué sentido aplica? En el que cuando sé lo que estoy haciendo, quiero aclarar, cuando sé lo que estoy haciendo es más rápido para mí ejecutar el comando con dos o tres flags que irme a un menú.
y luego irme a la opción 1 y le doy click para que me aparezca una ventana donde en esa ventana voy a hacer scroll hasta el final para darle click a dos opciones para que me salga un pop-up y en ese pop-up va a activar un box y darle ok, verdad, entonces ese proceso en GUI, aunque fácil e intuitivo, me tomó varios segundos y tal vez un comando lo hubiera hecho en uno o dos segundos y eso me vuelve más eficiente, más rápido.
Esto no es un beneficio que todos accesan, yo quiero reconocerlo, es un beneficio que no todos accesan porque tal vez, aunque hacer una acción... ⁓
me hace ganar 3, 4, 5 segundos hacerlo por comando a veces mucho más, a veces mucho más porque a veces vos mencionabas le doy click y tengo que esperar a que renderice porque está haciendo bastante llamadas a un API, etcétera, tengo que esperar a que renderice porque me va a mostrar un montón de registros que no voy a usar pero la ventana los tiene que cargar entonces a veces mucho más que sólo 2, 3 segundos pero si voy a hacer esa acción sólo una o dos veces al día en realidad no me va a hacer diferencia.
pero aquellas personas que muchas veces estamos constantemente trabajando, haciendo acciones, dándole mantenimiento a algo, orquestrando algo, ahí sí nos genera un beneficio. Quiero aclarar que este no es un beneficio al cual todos accesan o no todos lo ven, sin embargo yo lo comparto. Hace que mi trabajo sea más rápido porque escribo lo que necesito y se ejecuta. ¿Vos cómo ves esa parte, Juan?
Juan (18:46)
Sí, también estoy de acuerdo porque muchas veces es más fácil hacer eso que estar esperando que cargue una aplicación. me viene a la mente, actualmente he estado configurando mucho mi red local y lo hago a través de algo llamado SDN, Software Defined Network, o networking, donde tenemos una interfaz gráfica para ir configurando todos los equipos de red.
es muy beneficioso porque tiene centralizado toda la configuración y luego solo si cambio de por ejemplo un access point o adquiere un nuevo access point simplemente lo conecto a la red el controlador lo detecta y automáticamente configura todo pero tiene recursos limitados el aparato este así que cuando estoy en la interfaz gráfica y cambio de pestaña se
demasiado es es llega el punto donde es es frustrante para mí más cuando estamos acostumbrados a en el ambiente web no vamos a una página web y estamos acostumbrados que todo sea mucho más responsivo y que sea rápido entonces en ese aspecto pues por eso te decía que prefiero ir a una interfaz de comandos conectarme por ssh o algo similar
a tener que esperar que le de click a un enlace y luego esperar 2-3 segundos a que descargue y luego que renderice y luego si tiene animaciones pues esperar que las animaciones terminen y bueno tal vez en la realidad solo fueron 1-2 segundos pero para mí fue una eternidad lo que tuve que esperar entonces si para mí eso es tedioso y lo otro que también se me viene a la mente cuando decías respecto a la eficiencia que estamos trabajando
más eficiente. Seminalmente, el hecho de que podemos a veces concatenar comandos mediante pipes y esto lo hace más fácil. ⁓ Cuando estamos trabajando por ejemplo manipulando archivos, es muy fácil buscar una palabra, el resultado de esa búsqueda la vamos a
a modificar y esa modificación la vamos a guardar en una copia de otro archivo mediante línea de comandos eso se vuelve una instrucción y eso se puede hacer con muchos otros comandos de hecho creo que con cualquier comando se puede hacer ese no recuerdo el término, solo sé que se le llama pipes a cómo vas encadenando pero si estoy de acuerdo en que hace que tu trabajo sea más eficiente, más óptimo
Douglas (21:35)
Sí, sí, yo uso bastante eso para... Lo uso en muchísimas cosas, lo de concatenar comandos con pipe. Pero algo que lo uso mucho más de lo que te puedes imaginar es para copiar el contenido de archivos. A veces, por ejemplo, me piden la llave pública de SSH para agregarla a un servidor. Y si vos haces eso de manera manual en Mac o en Linux va a ser lo mismo. Tenés que abrir el Explorer, tenés que irte a tu directorio home.
entrar al director de SSH, buscar la llave, abrir el archivo, luego seleccionar el contenido, control C y luego pegarlo donde quiero. Ajá, así darle highlight o tal vez ponle que eso es un poco más pilas y le das comando A o control A y selecciona todo o le das tres clics y selecciona todo.
Juan (22:14)
darle highlight con el mouse, seleccionar
Sí.
Douglas (22:27)
pero el proceso de llegar al archivo y abrirlo no te lo quitas mientras que desde la terminal yo solo hago un cat al directorio completo ¿cómo se llama ese? el directorio ¿cuánto es? ¿desde dónde estás? o el full path se me olvidó eso ahorita, fíjate, ¿no? sí, pero cuando vos comenzás con una ruta desde el home
Juan (22:37)
al arcio.
el directorio HOME
Douglas (22:55)
hasta donde estás comparado con una ruta desde donde estás relativo y absoluto. Pucha, mira, se me ha olvidado, gracias. Le doy un cut con el director absoluto y le hago un pipe con un comando más que se llama pbcopy y eso lo que hace es que el output o la salida del comando anterior lo agarra y lo copia y me lo tiene ahí en el clipboard y ya solo vengo y lo pego. son dos pasos.
Juan (22:58)
Relativa?
Douglas (23:22)
para hacerlo y para tenerlo listo. Entonces yo paso usando eso bastante y es prueba de que en efecto te vuelve más rápido o más eficiente. Entonces me gusta lo que decís. Ahora para continuar Juan, la última ventaja que vamos a mencionar no es que sea la última de un CLI, pero la que vamos a mencionar acá y esta es de las más grandes, esta es la que nos comienza a llevar a...
nivel de querer orquestrar cosas más grandes y es que con el CLI, usar CLI me pone listo para automatizar por medio de scripting, automatizar procesos repetitivos si vos querés hacer un backup de una base de datos.
y agarrar ese backup, comprimirlo y luego subirlo a un bucket de S3. Y entonces vas a usar CLI commands de cada uno de estos servicios para que lo haga de manera automatizada y lo pongas todo en un script.
hay otras maneras de automatizar, tal vez un poco más eficientes en cuanto a orquestrar más servidores, pero estoy poniendo como un nivel principiante en cuestión de automatizar que tal vez sería un bash script y ahí...
usaría MySQL dump para sacar el dump del esquema de base de datos y luego el comando CLI de zip para comprimirlo o si quieres usar un tar file, la compresión que prefieras y luego muy probablemente el CLI de AWS para agarrar ese archivo y mandarlo a AWS. Entonces el uso del CLI
está listo para automatizar por medio de scripting o cualquier otra herramienta que sea necesaria y esto se vuelve súper súper útil de nuevo al administrar más de un sistema. Cuando somos responsables de más de un servidor a la vez, hacerlo manualmente en cada uno toma demasiado tiempo y automatizar es el objetivo final en lo que tiene que ver la cultura DevOps.
Yo creería Juan, creería que está de acuerdo en esa ventaja o tenés otro punto de vista.
Juan (25:44)
Si estoy de acuerdo, creo que va como... creo que tiene un punto similar al que dijiste antes donde no todas las personas van a poder verse beneficiadas del todo con esto. Creo que todos podríamos vernos beneficiados.
pero esto es algo que recuerdo que vos mencionabas en episodios anteriores donde probablemente son tareas que realizas una vez cada dos años pues no hay problema en hacerlo dar clic por aquí dar clic por allá se vuelve algo beneficioso cuando se vuelve algo repetitivo en tu flujo entonces sí en ese aspecto totalmente de
Bueno, creo que desde que hablaste de automatizar ya estamos hablando de tareas que son repetitivas. Creo que tal vez por ahí va la cuestión. Y en ese tipo de tareas sí es muy beneficioso tener pequeños scripts. Bueno, pequeños a veces son bastante grandes. Y lo bueno de estos scripts, también más allá de la automatización, que ya lo tenemos todo en un solo punto, es el hecho de que ya tenemos
Douglas (26:51)
Sí.
Juan (27:01)
ya tenemos la lista de los comandos que podemos consultar más adelante
Por ejemplo, hace poco me pasó donde yo tengo, tal vez lo podemos mencionar más adelante hablando sobre GUIs y este tipo de cosas y los dashboards, tengo instalado en mi servidor DocPloy y este es un servicio que te permite, pues es un dashboard donde puedes instalar otros servicios, aplicaciones, etc. Pero me molesta, digo molestar, pero o sea, me incomoda cómo ellos
la documentación te dan los scripts pero no me dan algo como por ejemplo un Docker Compose o no me dan algo que ya esté listo, que pueda descargar este archivo y ver todas las instrucciones. Normalmente la documentación que ellos dan es, corre este comando y listo. es como, bueno ese comando se perdió en mi historial de la terminal y luego revisar qué versión de Postgres instaló.
version de redis tiene, cuales son los flags que esta utilizando, las variables de entorno que están corriendo, se vuelve mas complejo porque no tengo ese punto, ese script donde esta definido.
todas las diferentes recursos que necesitan estos servicios. Entonces sí, tener estos scripts para mí se vuelve bastante útil porque puedes consultar cómo está configurado cada una de las cosas que estás corriendo. Para mí eso es muy beneficioso y obviamente, como decía, la automatización ya se corre automáticamente o ya sea automáticamente en un periodo de tiempo, cada hora, cada día o pues automática
cuando lo elegís, lo ejecutas el comando y hace muchas acciones al mismo tiempo entonces sí estoy de acuerdo en ese aspecto
Douglas (29:04)
Sí,
fíjate que mencionas algo y que lo comparto, que no todos se benefician de esto y la automatización la buscamos más cuando tenemos que administrar bastantes o más de un servidor.
también con las tareas repetitivas, pero te sorprenderías de lo que mucha gente se beneficiaría de automatizar procesos que hacen continuos en su flujo de trabajo de su día a día. Mentionaste cosas como gente que tiene aliases para comandos de git, por ejemplo, esa es una forma de automatizar de cierta manera porque estás resumiendo un comando, a veces un alias.
Son varios comandos a la vez anidados y ese es un mini script, es un script de una línea. Si lo quieres ver de esa manera. También hay cosas como los make files que puedes tener para tu ambiente local y le das make build y ese make build internamente corre varios comanditos que te construye la aplicación y te reinicia el contenedor del servicio y ya no tienes que hacer eso manual.
Juan (29:48)
Sí, sí.
Sí.
Douglas (30:12)
que te borra todas las dependencias para que la vuelva a bajar y limpiar el caché. Entonces te sorprenderías lo mucho que le puede mejorar a mucha gente la automatización y tal vez no lo hacen en su día a día porque no le ven esa gran ventaja pero sí la tiene, ¿verdad? Pero...
Juan (30:31)
Sí, incluso
por ejemplo actualmente estoy trabajando en un CLI, ya entraría en la categoría de CLI para manejar toda la infraestructura de la empresa donde estoy. Ojo, la infraestructura local, todo el Docker y las dependencias de AWS y todo esto. Y me gusta porque...
Como decías, a veces pareciera que no nos beneficia cosas que tal vez no se ejecutan tan seguido como por ejemplo descargar todos los repositorios de todos los microservicios que pertenecen a la empresa. Es algo que no hago todos los días.
pero de vez en cuando si ya esto es gusto personal no me gusta como hacer un una limpieza y volver a instalar todo y con un CLI es muy muy intuitivo porque número uno ya tener los comandos que incluso la terminal te va dando la el autocompletado y dependiendo de cómo esté construido el CLI podés consultar la documentación de cada uno de los comandos qué flags le puedes pasar qué diferentes comandos no entonces
se vuelve también muy beneficioso en ese aspecto porque te automatiza el hecho de por ejemplo como te decía no descargar todos los repositorios pero también me es fácil consultar qué opciones tengo con un CLI, me es fácil ver qué parámetros puedo ir configurando dependiendo de lo que necesite
Douglas (32:07)
Si,
si si no no totalmente de acuerdo. Ok, si te parece Juan continuemos entonces ahora a las desventajas de un CLI porque tiene sus desventajas por supuesto como todo en la vida tiene sus pros y sus contras. Una de las desventajas del CLI es que tiene poca información visual.
Esto, Juan, lo vuelve difícil o complicado para trabajar al momento de tal vez visualizar gráficas o animaciones porque si querés algo, una gráfica bien elaborada, tal vez métricas de tus servicios, métricas de un web server o incluso gráficas en cuestión de presupuestos o gastos.
no lo vas a visualizar de la mejor manera en un CLI, lo que normalmente tenés son tablas que las puedes desplegar de manera eficiente, hay algunas librerías que te dan cierta proporción de gráfico o tal vez tenés esta barra de porcentaje que la puedes utilizar pero realmente si querés...
un proceso que dependa de gráfico o animación bastante, como lo es muchas veces el monitoreo de métricas, un CLI ahí sí se vuelve complicado y esa es una desventaja, la información visual de qué te provee un CLI porque está limitado por caracteres en una interfaz de texto.
¿Te parece a vos eso? ¿Cómo lo ves? ¿O creerías que no debería de ser una limitante?
Juan (33:49)
Tengo sentimientos encontrados con ese punto, fíjate, porque definitivamente es una desventaja si estás trabajando con gráficos. Definitivamente. Con gráficos me refiero a gráficos de barra, gráficos de pastel, Todo esto.
Douglas (34:01)
Sí, sí.
Juan (34:07)
Pero normalmente dudo mucho que alguien necesite hacer eso desde la terminal, aunque se da. Y se me viene a la mente cómo lo implementa las herramientas de Go, el Go tooling. Go tiene unas herramientas que te permite generar un reporte del rendimiento de tu aplicación. Dónde está todos los coches de botella, dónde está el mayor uso de la RAM, CPU, todo esto, ¿no?
y eso lo podemos hacer mediante el CLI generamos todo, el formato que queremos, que cosas queremos incluir, eso va en los flags, los comandos, etc. pero al final podemos generar un reporte y ese reporte ya lo abrimos con una herramienta externa como por ejemplo el navegador y ya en el navegador vemos todos los diferentes porcentajes de cada una de las cosas
como un diagrama de flujo contiene todas las flechas donde va dando cada uno de los recursos. Entonces por eso te digo que tengo sentimientos encontrados porque existe, yo siento que cada vez están siendo más pulidos los tuis, que los tuis son, si no me equivoco, sería terminal
user interface y pues básicamente es una interfaz gráfica entre comillas en la terminal y yo utilizo muchas de esas por ejemplo una que utilizo para docker se llama Ctop
Douglas (35:35)
Sí.
Juan (35:48)
y es muy bueno porque me da lo que me interesa ver a que es ver la lista de los contenedores, cuanto están utilizando cada uno de RAM, de CPU y tiene sus pequeñas, muy limitadas animaciones de cómo estás subiendo, bajando el uso del CPU también utilizo otra llamada BTM, Bottom, que es un juego de palabras con Top entonces es como una interfaz Top, es lo mismo
me muestra el uso de la RAM, CPU, cuánto está el tráfico de la red y no es una gráfica con colores y todo esto pero sí te indica con cierta animación cómo va subiendo el uso de la RAM, el uso de CPU. Entonces hay ciertas alternativas dependiendo de lo que necesites pero también estoy
de acuerdo en que van a haber momentos donde necesitamos, por ejemplo, va a ser mucho más fácil verlo en el navegador, verlo con gráficas. Como por ejemplo en Elasticsearch tenemos estos gráficos que podemos ver y podemos crear dashboards muy potentes. En ese aspecto pues sí, no hay comparación. Pero bueno, no sé, dependiendo de lo que necesitemos.
tal vez exista alguna alternativa en la terminal para los que no queremos dejar la terminal.
Douglas (37:22)
Sí, yo creo, fíjate Juan, que yo entiendo tu punto y lo comparto en cuestiones locales para ver recursos tal vez de mi máquina local o para ver poca cosa. aún, vaya vos mencionaste Git, si vos querés ver el historial de Git cuando tenés bastante y querés ver si querés rebase un commit o tal vez haya un conflicto.
realmente que lo vas a apreciar más cómodo en la interfaz gráfica que en la línea de comandos. Estamos hablando de muchos commits, ¿verdad? No estamos hablando de que solo he hecho cuatro en el repositorio, no debería de tener un conflicto si solo tengo cuatro commits, debería de reevaluar mi carrera si tengo un conflicto con apenas cuatro commits. Estamos hablando de mucho o tal vez tienes el comando div. Es muy bueno.
Juan (38:01)
Sí.
mmm
Douglas (38:18)
pero cuando tenés archivos grandes realmente se vuelve tedioso, es la realidad y yo trabajo en terminal todos los días, se vuelve tedioso, es lo mismo entonces verlo en la interfase gráfica que te va a remarcar todavía más claro los reglones donde están las diferencias y estoy hablando...
Juan (38:22)
Sí.
que de hecho,
perdón que te interrumpa pero por ejemplo git es un, para mí es el ejemplo donde yo casi no utilizo la línea de comandos de git
casi siempre utilizo una interfaz gráfica o un Tui. Actualmente utilizo uno llamado LazyGit en la terminal. Me encanta porque tiene casi todo lo que necesito. El único momento donde cambio hacia el add-on de VS Code es cuando tengo que resolver conflictos de merge. Ahí sí, como lo tiene integrado VS Code, hasta el momento es el que más me gusta. Pero luego utilizo esta...
este CLI, Lazy Git, bueno Tui, el Lazy Git y creo que nunca he utilizado realmente desde la terminal el Git add y ir viendo todos los archivos utilizo lo que todo mundo sabe tal vez el Git stash Git stash pop Git pull pero luego para realmente ir seleccionando los archivos hacer el commit y todo esto siempre me ha apoyado con algo gráfico algo más visual
así que ahí sí
Douglas (39:48)
Ok, pero imaginate,
estos son ejemplos basados en texto. Ya cuando estamos hablando de gráficas, vos diste el ejemplo de en Go, cómo lo maneja Go, pero al final tenés un archivo que tenés que abrir en el navegador. Si lo quieres ver de manera eficiente, si tenés bastante información ahí, al final lo tenés que abrir en el navegador, porque no vas a tener la misma experiencia y a ese punto, Juan, mira lo que voy.
Juan (40:07)
Sí.
Douglas (40:15)
que yo lo logre entender en la terminal porque estoy tan acostumbrado a estar en la terminal y no quiero usar un GUI. Pero a ese punto estoy haciendo mi trabajo más despacio que los demás, sólo porque estoy encerrado en no querer abrir un navegador. Entonces, a ese punto es de ventaja aunque yo lo pueda usar. Entonces, en efecto, cuando lo visual...
Juan (40:29)
Sí.
No,
Douglas (40:42)
es importante para el trabajo que estamos realizando, un CLI si se nos queda corto. ¿Que? Ahí es donde entra la ventaja. ¿Que me pueda mostrar la información? Sí. Pero de la misma manera que lo haría una interfaz gráfica, no, ¿verdad?
Juan (40:47)
Ahí es donde entra la desventaja.
Ok
Douglas (41:00)
Yo creo que en ese sentido, a mí, que soy de sistemas y yo que trabajo con la terminal, yo creo que vos has visto mi terminal. Cuando yo abro mi terminal, me despliega un texto, entrada, tengo mi calendario, los compromisos del día me aparecen en la terminal y tengo diferentes versiones y cosas, yo paso en la terminal todo el día, ¿verdad?
Juan (41:11)
Sí.
Mhmm.
Douglas (41:26)
pero me toca reconocer que en ese sentido un CLI se queda corto cuando nuestro flujo depende de gráficos.
Juan (41:33)
sí y yo creo que también como mencionabas cuando es algo local tal vez podrías utilizar estas alternativas que te decía yo pero bueno me imagino que ya cuando estás manejando múltiples servidores y estás monitoreando múltiples aplicaciones servicios pues ni modo ahí es con una ayuda de la interfaz gráfica ⁓
Douglas (41:57)
Sí, sí, sí,
muy de acuerdo, muy de acuerdo. Continuemos Juan, tengo una de ventaja más, no que solo esas dos existan, pero una de ventaja más, perdón, para el CLI y es que la curva de aprendizaje es alta, ¿verdad? Porque nos toca memorizar los comandos y sus diferentes argumentos y los diferentes flags y si el...
cómo formatear el resultado del comando, ordenarlo ascendente, descendente, y cada una de estas cosas significa memorizarnos comandos, memorizarnos texto, básicamente. Aparte de entender la herramienta, que eso lo estamos dando por sentado, que ya sea que usés un GUI o un CLI, tenés que entender la herramienta, qué vas a querer hacer. Por ejemplo, si vas a ejecutar un contenedor, es un Docker run.
verdad, entonces porque yo sé que quiero correr un contenedor pero ya estoy entendiendo la herramienta pero tengo que memorizarme cómo expongo un puerto, en qué orden llamo la imagen, cómo le doy un nombre y tengo que memorizarme ese tipo de argumentos comandos, subcomandos para utilizar el CLI y eso es una realidad en mi opinión vuelve la curva de aprendizaje un poco más alta de lo que es tal vez un
una interfaz gráfica que se vuelve un poco más intuitiva. Entonces, no sé qué pensáis, Juan, porque vos sos bien de tener tu entorno en Linux y sos bastante de interfaz gráfica. Tal vez para vos, en lo personal ha sido diferente la experiencia, pero de manera generalizada, ¿te parece que esto es una desventaja en los CLI?
Juan (43:42)
Pues creo que es una, si es un punto a favor respecto a la interfaz gráfica versus el CLI Douglas. Me duele darle el punto en este aspecto porque siempre soy un poco más a favor del CLI pero bueno, es lo que hay. Si es más intuitivo filtrar una tabla en una interfaz gráfica en un reporte, por ejemplo algo como Excel, es mucho más fácil filtrar.
ordenar y todo esto
Douglas (44:14)
Juan, te voy a interrumpir
Es la curva aprendizaje. Y esto es.
Juan (44:18)
Sí, sí, sí, sí. Pero de
nuevo, la curva de aprendizaje viene dada por qué tan intuitivo es desde mi punto de vista. Y claro, no tenés que memorizar, no tenés que memorizar cosas. Pero bueno, ahí me gustaría acomodarte un contraargumento que creo yo, que si bien la curva de aprendizaje es mayor...
Douglas (44:30)
Mm-hmm.
Mm-hmm.
Juan (44:44)
yo considero que eso es un beneficio para nosotros a largo plazo porque el hecho de que tengamos que aprender los comandos y entender cómo funciona lo que resulta en nosotros es que luego entendemos mucho mejor cómo funcionan estas herramientas que estamos utilizando y pues bueno será esta es mi opinión personal y es que si yo trabajo con Docker todos los días
Creo que tiene sentido que entienda.
un poco mejor como funciona Docker, que si sale un error respecto a los puertos y que un servicio no encuentra al otro pueda entender por dónde puede estar el error y para poder corregirlo. Sé que con la interfaz gráfica se puede hacer muchas cosas, el hecho de entender cada uno de los comandos, las diferentes opciones que existen, esto a veces te lleva a leer la documentación, qué flags puedes pasarle, qué opciones
existen esto te lleva a tener un entendimiento un poco más amplio sobre estas herramientas entonces sí es una desventaja que es más difícil pero a largo plazo yo lo veo como algo positivo
Douglas (46:04)
Fíjate Juan, que mira, te doy la razón, estoy de acuerdo con vos, en que a largo plazo me beneficia, la curva de aprendizaje es más amplia, sin embargo a largo plazo me beneficia, pero voy a contrarrestar tu...
de lo que mencionas de que si estoy en Docker todo el día entonces debería de aprender los comandos y te podría decir lo mismo con respecto a Git. Vos mencionas que te basas más en el gráfico y yo podría decirte bueno debería de aprender todos los diferentes comandos de Git y cómo funciona cada uno de ellos para que lo entendas más a profundidad. Sin embargo
Juan (46:34)
jajaja
Douglas (46:49)
el punto ahí termina siendo que te vuelve a vos más eficiente. Y hay que reconocer que hay parte del flujo donde me beneficia el comando y eso va a variar de profesional a profesional. Hay profesionales que yo los he visto en redes sociales o en internet, no los conozco en persona nadie, te voy a decir, pero he visto profesionales que manejan Git de una manera donde si ellos abren una interfaz gráfica se van a atrasar.
es exagerado ver cómo fluyen, vez en tu caso te pasa lo mismo con Docker, pero es ahí donde te contesto un poco tu argumento y te digo si es cierto, pero si fuese cierto, toda herramienta que tiene una interfaz gráfica, solo esa deberíamos de usar. Creo que al final del día se vuelve qué beneficia mi flujo personal de trabajo y por eso, por eso de manera generalizada,
Juan (47:39)
Sí.
Douglas (47:48)
te repito, soy de acuerdo con tu comentario, lo comparto de que a largo plazo es mejor para mí aprender o usar el CLI, pero de manera generalizada yo creo que eso sí se vuelve una realidad de que es de ventaja que la curva de aprendizaje es más amplia, no una de ventaja que debería detenerme, pero sin embargo sí una de ventaja comparado con algo más intuitivo como una interfaz gráfica.
Juan (47:54)
Mm-hmm.
sí sí y es que depende no también de la herramienta de cuál es el objetivo por ejemplo siempre las herramientas que tienen que ver con bueno en este caso kit no estás comparando dos dos archivos uno está en un en el futuro otro en el pasado no de los cambios que ha habido y la verdad es que te seré honesto yo he notado que mi falta de conocimiento de kit me a veces me pasa factura a veces mi solución es
pues
borro todo y vuelvo a descargar el repositorio porque realmente no conozco los comandos que me ayudarían a solucionar el problema que tengo. Entonces sí considero que llega un punto donde me pasa factura, pero ⁓ no, estoy de acuerdo que a veces es mucho más beneficioso apoyarte con el aspecto visual.
o tal vez mi punto aquí Douglas es que cuando tiene una curva de aprendizaje más grande tiene su recompensa al final también yo así lo quiero ver como que tenés esta recompensa
Douglas (49:25)
No, no, sí, tiene su
recompensa totalmente de acuerdo, pero de nuevo de manera generalizada, vos estás poniendo Git como ejemplo y voy a seguir usando los ejemplos que está dando, ante la premura, en lugar de ponerte a aprender los comandos que necesitas de Git, terminás haciéndolo por GUI porque estás ante la premura, ocupás dedicarle un tiempo aparte para estudiar Git.
Juan (49:47)
Sí.
Douglas (49:52)
para mejorar esas cosas que te están limitando por tal vez la falta de conocimiento que estás diciendo. Ocupas tiempo para dedicarle, pero ante la premura, entonces te vas a la interfaz gráfica. Entonces siento que eso sigue reforzando el hecho de que de manera generalizada sí es de ventaja. De nuevo,
Juan (50:05)
Sí.
Douglas (50:16)
de acuerdo con vos que aprenderlo y lo hemos repetido varias veces ambos, de acuerdo que aprenderlo a largo plazo me va a dar un beneficio, pero el hecho de que ante la premura tengamos que recurrir a la interfaz gráfica y de nuevo vos estás usando Git como ejemplo para alguien puede ser otra herramienta.
Juan (50:31)
sí
Douglas (50:32)
y ellos sí manejan Git bien, pero nos toca recurrir a la interfaz gráfica ante la premura y eso vuelve que es una realidad que la curva de aprendizaje es más amplia. Vale la pena tomar el tiempo muy de acuerdo, ¿verdad? Y ahí creo que sí sería una recomendación tomarse el tiempo para aprender la interfaz gráfica.
Juan (50:44)
Sí.
Correcto,
Douglas (50:56)
Bueno, avancemos Juan, avancemos si te parece por motivos de tiempo y pasemos ahora a ventajas de GUI que yo creo que aquí tal vez vamos a ir un poco más rápido no porque las ventajas sean pocas sino que en lo que hemos ido abarcando ventajas y desventajas de CLI de manera indirecta hemos ido tocando ventajas y desventajas del GUI.
Juan (50:58)
No,
se interseccionan.
Douglas (51:21)
Exacto, exacto. Entonces, ventajas. Realmente que como mayor ventaja, Juan, tengo una acá y es su formato visual. Como de manera global, lo digo, su formato visual. Esto lo vuelve intuitivo para personas no técnicas. Y siempre nos toca enseñar, mostrar o ilustrar cosas a personas no técnicas. Lo vuelve intuitivo, una gran...
ventaja, el hecho de que es intuitivo hace que la curva de aprendizaje sea más corta a lo que recién estamos hablando, Terminar recurriendo ante la prisa, ante la premura, al GUI, porque no tengo ahorita el tiempo para buscar el comando correcto para algo tan complejo, por lo mismo que es intuitivo genera que el aprendizaje sea más rápido porque me guío por cuestiones visuales, trato de seguir la lógica, si quiero encontrar cómo cambio una configuración
comienzo a buscar un menú de settings, comienzo a buscar el iconito del gear, de la tuerca, o algo similar para buscar settings y me voy por lo intuitivo, la curva aprendizaje la vuelve más rápida, su formato visual lo vuelve perfecto para trabajos.
que son fuertes en gráficos o en multimedia, lo que estábamos mencionando. Si estoy monitoreando múltiples sistemas o si querés ver adentro de tu aplicación en servicios como DataDoc o New Relic, donde querés ver cuánto tarda en conectarse a la base de datos, al cache, cuánto tarda el web server, este tipo de métricas de APM.
el gráfico es el que le beneficia y aparte de eso, al ser gráfico y lo decía vos al inicio de la conversación, también tenés como ventaja agregada a todo esto, no que te vuelva eficiente, pero como una ventaja agregada y la cerecita del pastel que puede ser tan atractivo y moderno como te lo puedas imaginar. Ya puede ser algo como más agradable de ver, de visualizar, de que muchas veces, a veces solo cargamos el dashboard.
y nos genera una sensación de sentirnos bien. Ajá, correcto, en mi día a día. Entonces, ya como cerecita del pastel, hasta me hace sentir bien que se vea bonito, que se vea atractivo. su forma visual como tal tiene todas estas ventajas. Yo las comparto todas, Juan, estas ventajas, pero me interesa saber tu opinión, cómo lo ves en este sentido.
Juan (53:34)
para mina.
si es que el formato visual te permite tener mucha información de un solo por ejemplo si estas como mencionabas al inicio una herramienta de monitoreo inmediatamente podes tener diferentes graficos en la pantalla al mismo tiempo y es más intuitivo claro yo podría sacar un reporte en el CLI y ver cuanto estoy utilizando de memoria RAM, estoy utilizando de disco duro
pero sin siquiera leer, con solo ver que una gráfica está más arriba que la otra, ya es fácil identificarlo. También hay herramientas donde necesitas ver directamente cómo va a quedar. Me refiero, por ejemplo, a un editor de texto. Yo utilizo mucho Obsidian. También nosotros, manera colaborativa con Douglas, utilizamos Notion.
Douglas (54:32)
Sí, así es.
Juan (54:58)
en estas herramientas es muy fácil ver, necesito que este texto esté en negrita, pues lo seleccionas y ya está en negrita y lo puedes ver directamente. En su contraparte podrías ver por ejemplo un texto en Markdown, lo puedes editar y le agregas todas estas sintaxis que por ejemplo un texto entre asteriscos significa que está en negrita dependiendo del editor o que esté en itálica.
pero no lo estás viendo así, lo estás viendo solamente con la sintaxis. Entonces, por eso existen estas otras herramientas que te permiten ver ya de un solo cómo está quedando el texto. Y no se diga, también la fuente del texto. Inmediatamente puedes ver cuando cambias de fuente cómo se va ver el texto cuando, por ejemplo, lo imprimís en una página. Entonces, yo creo que sí, una interfaz gráfica
Douglas (55:30)
Mm-hmm.
Juan (55:58)
te da una información más inmediata también Douglas por ejemplo los colores que esto también podríamos argumentar que existe en la la terminal color verde es un log que está bien está en rojo un log está mal pero pues también en la interfaz gráfica podemos valernos de esto para los iconos un icono una X en rojo sabemos que
es eliminar
está mal, un lápiz en amarillo pues editar y así. Todas estas cosas que no necesitamos leer, no necesitamos entender solamente con los iconos ya sabemos, ya de antemano ya tenemos toda la información que necesitamos. Y también que hoy en día, Douglas, el lenguaje visual cada vez está más estandarizado. Como decías, vas a buscar una tuerca, un icono de una llave, ¿no? De tuerca. Eso es, universalmente es
settings de las configuraciones yo podría venir y hacer otro icono para mi aplicación pero pero porque lo voy a hacer si voy a perder a usuarios los voy a confundir entonces sí una gran ventaja es que tenemos toda la información de un solo
Douglas (57:19)
Sí,
sí, no, muy de acuerdo, muy de acuerdo y aunque sólo tengo esta como ventaja del GUI, sea la única, pero abarca tanto esta ventaja como tal, los beneficios que genera que...
a dejarlo hasta ahí en el sentido con ventajas y pasemos a las de ventajas, de nuevo que han sido, que estas van a ser prácticamente el antónimo de las ventajas del CLI y es que una de las de ventajas primero es que necesita más recursos, ya lo mencionamos, verdad, necesita de procesos, necesita de memoria para que cargue en memoria algo gráfico de procesos en el background para que estén listos para hacer
contenido o no, te está mostrando 50-20 registros que no necesitas, tal vez solo ocupas uno y si fuese un comando de CLI, le haces el grep de un solo y no lo tiene que mostrar o de un solo le pones un flag de search y solo te muestra lo que necesitas, necesita más recursos y
Otra ventaja anidada a esa que es las ventajas del opuesto a la ventaja del CLI es que me vuelve es menos eficiente para mí en cuestión de tiempo por lo que mencionábamos verdad múltiples clics cargar diferentes ventanas para llegar a lo que necesito donde con el CLI hubiese sido un solo comando entonces opuesto a ello con un GUI normalmente en ese sentido me va tomar más tiempo
menos que sea combinado con la ventaja que es de momento solo tengo el GUI y en lugar de invertir tiempo en aprender me voy al GUI entonces hoy para mí va a ser más rápido pero si lo ponemos en general en si lo hiciera y si supiera hacerlo con GUI o si supiera hacerlo con CLI el CLI va a ser mucho más rápido verdad y cómo se llama otra de las de las ventajas
Juan (59:21)
Pero...
con ese punto Douglas, me gustaría también hablar a favor de los GUIs y sí, es una desventaja que cuesta verla al inicio, que es más lento no pareciera que es más lento porque decimos bueno, solo doy dos clic aquí y ya está listo pero no tomamos en cuenta todas las acciones que van previas a eso sin embargo también me gustaría mencionar que a veces, bueno no a veces, la gran mayoría de las veces
⁓ las aplicaciones de interfaz tienen shortcuts tienen estos atajos que podemos utilizar y yo creo que eso aplica tanto para la interfaz gráfica como para las herramientas, los tuis también en la terminal yo estaba viendo hace un tiempo un youtuber se pone él y el dio un ejemplo que
una comparativa que me gustó y es que por ejemplo si vos estás jugando starcraft para los que no sepan starcraft es un juego de estrategia en tiempo real donde tenés tu
ejército y te enfrentas contra otro ejército. Así que en StarCraft puedes seleccionar las unidades, seleccionar los edificios y en cada edificio hay botones para sacar más unidades, mejorar sus habilidades, seleccionar los enemigos y decís vayan de aquí para allá. Pero está la otra forma de jugar a StarCraft y es donde todo lo utilizas mediante el teclado y haces comandos y haces macros y estás utilizando esto y ya no tocas la interfaz gráfica
con el ratón, el ratón ya lo utilizas para otras cosas. Así que él daba esa comparativa y me pareció muy acertada porque también lo podemos utilizar en muchas herramientas que aunque son gráficos tienen estos comandos, atajos que podemos utilizar. Se me viene a la mente Douglas, por ejemplo Visual Studio Code, donde para abrir un archivo tenemos que seleccionar el menú, etc. Pero también está un
un atajo donde presionas control o o querés ir a un archivo dentro de tu proyecto bueno le das clic a la jerarquía de archivos de directorios luego buscas el archivo y le das clic
pero también podrías simplemente escribir o presionar control p y ponerse el nombre del archivo y te lo muestra. Entonces, así como yo mencionaba que tiene beneficios dedicarle tiempo al CLI, si estás utilizando o vas a utilizar mucho cualquier herramienta, yo digo que vale la pena aprender a exprimirlo más que se pueda dicha herramienta. Entonces, bueno, solo lo quería como un paréntesis que
que sí puede ser muy lento pero muchas herramientas también te permiten ser rápido con ellas aunque sea gráfico
Douglas (1:02:28)
Sí,
estoy muy de acuerdo Juan, 100 % de acuerdo y me gusta el consejo que das de que si voy a dedicarle trabajar mucho en una herramienta, sea de CLI o sea gráfica, en este caso particular gráfico porque estamos tocando las ventajas de GUI, me conviene aprender todo lo que pueda hacer para llegar a ser más eficiente con ella y definitivamente usando todos estos shortcuts, todos estos atajos, voy a ser más rápido. Ahora.
Juan (1:02:55)
Sí.
Douglas (1:02:57)
uniéndolo en contexto, entre si lo hiciera en CLI o si lo hiciera en GUI, independientemente de los shortcuts, va a ser más rápido el CLI. Esto es un contexto directo y genérico en si supieras, de la misma manera cuando lo ejemplificamos con CLI, en si supiera hacerlo en ambos, el CLI va a ser más rápido porque abrir un archivo, me dijiste que le doy control o...
Juan (1:03:07)
Sí. Sí.
Douglas (1:03:24)
pero todavía tengo que ir a seleccionar el archivo dentro de la ventana que me va abrir. Eso me alivió el ir al menú File, Open. Es lo que me alivió, me alivió dos clics y tal vez desplazar el mouse hasta allá. No que es poquito, no estoy diciendo que sea poquito, me alivió y tenemos que usar esos shortcuts o aprender a usarlos, pero de nuevo, si nos vamos uno a uno en la comparación, sí sería más rápido si lo vuelvo a en CLI.
Juan (1:03:28)
Sí.
Sí.
Douglas (1:03:52)
Esto es un ejemplo donde cuál de los dos sería más rápido. De nuevo.
hay herramientas que tienen que ser GUI por los otros beneficios que genera GUI como un editor de texto pues puedes usar Vim o cualquier otro de estos y son muy buenos conozco gente que es muy eficiente con ellas pero la mayoría usamos algo como VS Code o un editor gráfico entonces bajo ese contexto tenemos que usar el gráfico sí o sí y aprender los shortcuts es mejor pero cuando hay funciones que una se puede hacer con CLI
Y también con GUI, si supiera hacer una, el CLI sería, si supiera hacer ambas, perdón, debería escoger el CLI porque va a ser más rápido siempre. Entonces, ese contexto, ¿verdad? En ese contexto. Pero me gusta la aportación que está dando porque es algo que tenemos que considerar y al final del día se trata en ganar tiempo y lo que pueda ganar con un shortcut debería de aprovecharlo, ¿verdad? A optimizar.
Juan (1:04:35)
rápida así
si aunque no le
vayas a ganar digamos a la versión CLI pues al menos algo no va reduciendo lo más que se puede el tiempo con el la interfaz gráfica
Douglas (1:05:04)
No, y cuenta mucho,
de nuevo al final del día herramientas como VS Code vas a estar trabajando en una interfaz gráfica entonces saquemosle el provecho de esa manera, me gusta. Continuando Juan, con desventaja del GUI es que otra de ellas es que no me permite automatizar y acá pueden haber argumentos de que pero yo puedo ir al GUI y automatizar el backup.
Juan (1:05:17)
Sí.
Douglas (1:05:33)
de tal aplicación desde el GUI, sí lo puedes hacer, pero lo que el GUI hizo es crear un comando, un cron job en el background que está corriendo múltiples comandos, verdad, entonces como tal un proceso, si quisieras automatizar ese proceso...
por CLI, te tocaría ejecutar esos comandos atrás y tal vez en una situación de esa lo que el CLI hizo fue resumirte esa tarea de que no tuvieras que hacer manual los comandos, pero si hay un proceso donde por ejemplo cae una alerta y tengo que darle acknowledge a la alerta, por medio de un GUI no lo voy a poder automatizar.
Alguien puede decirme que hay, ¿cómo se llama? Driver IO y estas herramientas que se usan para testear los gráficos y vos puedes hacer algo como eso, pero realmente eso es demasiado tedioso porque tenés que ver el DIP, el elemento en particular en HTML, filtrar por algún ID, etcétera, para llegar a ello y esto es demasiado tedioso, entonces, que existan formas tal vez de llegar a hacerlo.
sigo dependiendo de que exista una sesión activa en un servidor, de que exista esa sesión activa para que se mueva el mouse, que se quede aquí, se mueva allá y escriba. Entonces realmente, realmente menciono estas cosas por si alguien quisiera decir no, hay forma de automatizar un GUI, sí, sí hay forma, pero que lo usaría para orquestrar algo, no, no creo que nadie lo haga de esa manera. O a vos te parece que sí, Juan.
Juan (1:07:08)
No...
No, definitivamente. Y creo que esa es una de las grandes desventajas de una interfaz gráfica. De nuevo, dependiendo para qué sirve la interfaz, porque no se me ocurren muchas optimizaciones o automatizaciones con, por ejemplo, con Microsoft Word, Office Word. Pero ya hablando del tema de nuestro ambiente más técnico, definitivamente la automatización se va a dar más
y más controlada desde la línea de comandos porque bueno se me viene a la mente de nuevo estos dashboards donde puedes con un botón le das deploy y ese ese bot ese deploy por detrás está haciendo un docker stack deploy y ejecuta muchas cosas levanta los volúmenes etcétera y es muy conveniente es como el equivalente a tener un alias ⁓ en el aspecto visual pero qué pasa cuando
ya lo decía vos cuando tenés múltiples servidores y querés hacer una automatización que corra en todos ellos al mismo tiempo y no tenés que depender de al botón yes, ok y todas estas cosas, simplemente pasás los comandos, los flags necesarios la variable de entorno necesarias y ejecuta todo entonces ahí si no hay mucho que hacer con una interfaz gráfica
al menos en una escala más grande, ¿verdad?
Douglas (1:08:42)
Sí, sí, no hay mucho que salvar. Pero bueno, estamos de acuerdo en ese sentido. Y para continuar, tengo una de ventaja más.
que creo que vale la pena mencionar y es que la fun... eso no va aplicar a todo, pero la funcionalidad es limitada de un GUI en comparación a su contraparte CLI en muchos casos. En situaciones en las que tal vez proyectos primero crearon el CLI y con el tiempo implementaron el GUI o tal vez son proyectos donde son diferentes equipos.
que maneja, que desarrollan unos al CLA y otro equipo que desarrolla el GUI, el equipo que maneja al CLA suele avanzar más rápido normalmente, entonces en cuestión de funcionalidad hay muchas cosas que aunque tengamos un GUI no se puede hacer porque no ha sido implementado.
y el CLI se lo tiene. Un ejemplo puede ser el CLI de Docker. Tenemos Docker Desktop y podemos hacer muchas cosas, levantar contenedores, diferentes servicios, crear volúmenes, eliminarlos, administrar las imágenes, etc. Pero Docker Desktop y su interfaz gráfica no tiene todas las funcionalidades que están en el CLI, ¿verdad?
Entonces, cuando queremos orquestrar de manera profunda, cuando queremos administrar de manera profunda, en situaciones como esta, de nuevo, no aplica a todos, pero sí suele pasar cuando estamos haciéndolo para orquestrar cosas grandes, el GUI se ve limitado en cuestión de funcionalidad comparado con su contraparte CLI. No sé si te ha pasado, Juan, si te has topado con algo así o tal vez no lo has experimentado. No sé, contámos.
Juan (1:10:25)
Si, por ejemplo hace tiempo que no utilizo Docker Desktop creo que ese es un gran ejemplo La última vez vi ciertas actualizaciones que le hicieron y me dieron ganas de volverlo a probar porque veo que tiene más cosas pero bueno la verdad es que ya me acostumbré mucho a la interfaz de comandos y recuerdo que hace un tiempo atrás como decía muchas cosas no estaban no sé cómo está hoy tal vez ya tiene mejor compatibilidad
pero lo más probable es que hayan cosas que aún no estén del todo del todo compatibles tiene otras ventajas es que también de nuevo volvamos al punto que las ventajas del GUI son otras van más por por ejemplo en volviendo al ejemplo de Docker Desktop me gusta mucho que ahí mismo podemos buscar imágenes en Docker Hub
Douglas (1:11:08)
Mm-hmm.
Juan (1:11:18)
No tengo que abrir un navegador y buscarlo, ahí está integrado. me permite... Tiene muchas otras integraciones en la misma aplicación que son muy cómodas. Entonces, esa es su gran ventaja. Luego, estas otras compatibilidades que tal vez no están, no buscan eso, no es su finalidad. También Douglas creo que a veces es a propósito.
por ejemplo, en este caso ya es más como algo más general pero pero es el ejemplo que se me va a a la mente con
con las distribuciones de linux un ambiente de desktop muy famoso es gnome y en gnome las últimas versiones ya están incluyendo muchas compatibilidades con los monitores más nuevos que hdr variable refresh rate pero estas opciones han estado ocultas no están si vas a la configuración de la pantalla no te las muestra porque porque no
que toques algo que todavía no está listo, está en versión beta, entonces no te las muestra. Para acceder a ellas, tenés que utilizar la línea de comandos y activarlo de esa manera. O descargás otras aplicaciones que ya te dan ese acceso. Pero el diseño que ellos tienen es que no te lo muestran para evitar que hagas algo que todavía no está disponible. Y eso suele suceder, que a veces tenemos funcionalidades extra en el CLI,
Douglas (1:12:25)
Sí.
Juan (1:12:53)
que por defecto en la versión GUI no lo muestran porque consideran que tal vez la gente se va a confundir o les falta polirlo etc. A veces también pasa eso. Pero bueno, el punto central es que no suelen tener la misma lista de opciones. Eso es cierto.
Douglas (1:13:16)
Sí, sí, sí.
Es parte de cómo evoluciona el software. Y fíjate que, ligado a eso y continuando, hay también ventajas y desventajas tanto para GUI como para CLI en cuestión de su desarrollo y mantenimiento. Las que hemos nombrado hasta ahorita son en sentido del uso.
Juan (1:13:38)
ok
Douglas (1:13:39)
del uso del
GUI o el uso de un CLI, pero también en sentido de lo que es el desarrollo de un GUI, el mantenimiento comparado con el desarrollo de un GUI o un CLI, también tiene sus pros y contras que mayormente es que suele ser más rápido desarrollar el CLI que es justo lo que estaba diciendo, muchas veces no está listo el feature o tal vez está listo pero quienes manejan la parte gráfica en este release no tuvieron el tiempo de implementarlo.
entonces todavía no va a salir. Entonces, lo menciono Juan, no vamos a profundizar en esto porque el tema va alrededor de qué es mejor en la cultura de box en cuestión de uso.
CLI o GUI, pero ya que lo dijiste, creo que vale la pena aclarar de que también en lo que se requiere con mantenimiento y desarrollo, desarrollar o mantener un GUI o desarrollar o mantener un CLI, cada uno por su parte tiene pro y contras y normalmente en cuestión de rapidez gana el CLI en ese sentido, vale la pena mencionarlo. Ahora, aquí Juan es donde quisiera que hagamos un pequeño ejercicio.
vos y yo y es que yo te voy a te voy a mencionar tareas comunes en IT, no sólo tareas comunes para vos como desarrollador o para vos como sistemas que las hay muchas, o sea, tienes tantas tareas que son comunes para vos como desarrollador de la manera que yo tengo tantas que hago y repito mi día a día como alguien de sistemas, pero tal vez esas comunes que algunas de ellas que convergemos
Juan (1:14:47)
Ok, ok.
Douglas (1:15:15)
Y vos me vas a decir, o vamos a decir ambos, pero te voy a dejar que vos participes primero, si estas tareas las ejecutas o con CLI o con GUI en tu flujo trabajo, en tu día a día, ¿verdad? Entonces la primera ya la respondiste, pero la tengo en la lista y la voy a comentar porque también yo voy a responderla, pero es hacer un git commit. ¿Lo haces con CLI o lo haces con GUI?
Juan (1:15:24)
Ok, me gusta.
Bueno, si me voy a lo más común, lo utilizo el Tui. Podría encajar con GUI.
Douglas (1:15:53)
Guy.
Juan (1:15:55)
por qué y aquí tal vez voy a expandir un poquito mi respuesta y es que es más fácil seleccionar archivos yo normalmente trabajo con una una infraestructura que es monorepo y en el mismo repositorio hay múltiples microservicios así que a veces estoy trabajando en múltiples servicios pero no quiero comitear todos los cambios solo solo de un servicio o uno que otro entonces es más cómodo para
para mí con algo visual si realmente sé que lo que estoy haciendo es solamente un archivo, modifique pues ahí si git add y le doy todo y git commit-m y listo y luego git push pero también esta también es la cuestión con el tuy, el que utilizo actualmente también se vuelve más fácil porque el git commit solo presiona la C
en
mi teclado y ya escribo el mensaje y listo. Para el git push solo presiono control p y ya se pushea incluso si no existe la rama hace el upstream entonces se vuelve más cómodo pero diría que un 99 % gubi
Douglas (1:17:17)
Fíjate, qué interesante y lo entiendo porque como programador trabajas con muchísimo más código de lo que yo puedo trabajar en mi día a día. es una herramienta que uso en mi día a Yo uso el CLAIWAN, pero mi uso definitivamente y objetivamente es menor que el tuyo. Normalmente yo estoy trabajando en features y...
No tengo que estar abriendo tantos archivos. Y aún cuando abro varios archivos, son parte del mismo feature que estoy trabajando, misma funcionalidad o mismo fix. Entonces, casi que cuando estoy listo, Git status para ver y asegurarme. Siempre hay que asegurarme de que solo voy a agregar lo que está. Pero luego Git add punto, Git commit, Git push.
Juan (1:18:01)
Sí.
Mm-hmm.
Douglas (1:18:07)
y puse como ejemplo Git con Meet, pero de manera general, mi interacción con Git son mayormente clonar un repositorio, pull y push, y ahí casi que está a veces resolver conflictos de merge en mi local, pero hasta ahí, verdad, mi funcionalidad. Pero yo sí lo hago de CLI, sí lo hago de CLI, realmente que no recuerdo cuándo fue la última vez que usé un GUI para Git, pero...
te aseguro que tengo más de 6, 7 años probablemente.
Juan (1:18:39)
que
bueno, que bueno, es más cómodo, bueno pensándolo, como dándole otro pensado en mi mente y creo que tengo como una mezcla porque para crear ramas o para descargar cambios es el CLI, es más rápido para el commit como ya te dije utilizo el GUI y luego para
Douglas (1:18:57)
Sí.
Juan (1:19:02)
para resolver conflictos, ahí sí me voy a Visual Studio Code. Yo no utilizo VS Code, pero para eso sí lo utilizo. Entonces, tengo como que, dependiendo del caso.
Douglas (1:19:06)
No ha.
te
terminas abriendo tres cuatro herramientas para terminar comitiando algo. Pero bueno, está bien. Continuando, entonces Juan, otra tarea, crear un pull request. Lo haces desde la interfaz de, digamos, GitHub o usas el CLI de GitHub para crear un pull request.
Juan (1:19:19)
Sí. Sí.
No.
suelo utilizar el dashboard trabajo más con Bitbucket y lo hago desde el dashboard porque es más cómodo buscar quiénes van a ser los colaboradores que van a revisar el pull request seleccionar otras cual es la rama es más cómodo definitivamente es más fácil no utilizo y también cuando lo he hecho también con github de nuevo seleccionar los colaboradores es más fácil desde el dashboard
incluso cuando no recuerdo muy bien cuál es el correo de la persona que va ser el reviewer pues ya te muestra el profile picture entonces ya ok, él, ya lo selecciono así que sí eso lo hago totalmente desde el dashboard
Douglas (1:20:20)
mmm
Sí, yo igual, desde la interfaz gráfica, creo el pull request, yo trabajo mayormente con GitHub o con GitLab, en GitLab se llama Merge Request, pero es el mismo concepto, y justo lo que vos estás diciendo, más fácil seleccionar los branches y quién va a revisarlo e incluso la interacción luego del pull request, lo que significa agregar comentarios, aprobarlos, etcétera, desde la interfaz gráfica. Creo que hay
tanto que ver al mismo tiempo, al momento de un pull request que es ahí donde la interfaz gráfica brilla comparado de un comando, donde tengo que poner cuántas flags tendría que agregarles si uso el CLI.
Juan (1:21:07)
Sí... Sí...
Sí, por ejemplo te muestra
los checks que ha pasado, tenes diferentes comandos, perdón, actions, GitHub actions que corren, tenes una pestaña para los comentarios, otra pestaña para que archivos se ejecutaron, se modificaron, otra pestaña para cuántos commits lleva ese pull request. Sí, es mucha información, es bastante.
Douglas (1:21:41)
sí, sí,
sí, entonces ahí sobresale, ahí brilla el dashboard, el GUI, entonces ambos le damos un punto al GUI en ese sentido. Ahora continu… Bueno, vos vas dos por dos GUI, yo voy uno y uno.
Juan (1:21:44)
Sí.
será que vamos a terminar dándole la razón al guía
Douglas (1:22:00)
hay que continuar,
hay que continuar. Ahora es levantar un contenedor de Docker. Lo hacé desde... Y de nuevo, ya respondiste prácticamente esto, pero aquí puedes aclarar cosas si es necesario, levantar un contenedor de Docker. Lo hacé desde la interfaz gráfica o desde el CLI.
Juan (1:22:21)
Sí, desde el CLI. No tengo instalado Docker Desktop para empezar.
No tengo como una respuesta muy compleja para esto. Diría que simplemente me acostumbré. También lo que mencionaba también al inicio que cuando probé Docker Desktop no tenía todos los features. Consume más recursos. No lo sé, es más cómodo para mí desde el CLI, definitivamente. Ya tengo mis alias creados, así que es más fácil. Sí, para mí es más cómodo.
Douglas (1:22:56)
Sí, yo igual CLI, CLI definitivamente. Yo creo que la explicación es así aprendí Docker desde CLI, entonces me siento más cómodo, más rápido el hecho de que ya están las funciones ahí, entonces como lo manejo bien, soy más rápido en el CLI.
La respuesta corta es así lo trabajé del principio y así me acostumbré y así soy más rápido. soy más rápido. Entonces punto para CLI ahí. Entonces vos vas dos a uno a favor de GUI. Yo voy dos a uno a favor de CLI.
Juan (1:23:25)
Así soy yo.
Pero también creo que otro punto...
Otro motivo por el que creo que los dos utilizamos más el CLI de Docker es que, por ejemplo, tenés que interactuar con servidores que tienen, ya sea Docker o Kubernetes, y ahí no vas a tener una interfaz gráfica. No vas a hacer eso. Y yo, por mi parte, pues tengo proyectos aparte que manejo de vez en cuando. Y lo mismo, en el servidor no existe la interfaz gráfica. Así que estamos más acostumbrados, creo que por eso.
Douglas (1:23:53)
Sí.
Sí, sí,
muy de acuerdo, muy de acuerdo. Ok, 2-1, de mi parte a favor de Nuevo Cielo y vos 2-1 a favor de GUI, una tarea sencilla Juan, copiar un archivo.
Juan (1:24:23)
Ok, aquí sí estoy dividido porque a veces lo hago en el CLI y a veces lo hago desde el buscador de archivos. Quiero pensar cómo lo hago. Ok, creo que si estoy trabajando suelo hacerlo en la terminal, pero si necesito, qué se yo, copiar un archivo para algo random, ¿no?
por ejemplo, una imagen de mi familia y la voy a copiar de un lado otro desde el buscador de archivos. Sí, creo que así sería. No sé, mi respuesta está dividida ahí. No sé. Pero ya que estoy mencionando el GUI, se lo voy dar al GUI. Sí.
Douglas (1:25:02)
¡Ve!
Fíjate que yo
pensé que tal vez por ahí va a ir tu respuesta, yo igual estoy dividido, creo que me encuentro la mayoría del tiempo copiando desde la terminal porque ya estoy en la terminal la mayoría del tiempo y luego desde ahí, pero si no estoy cargando nada y necesito copiar un archivo de un lugar a otro inmediatamente me voy al GUI, no me voy a la terminal, me voy al GUI.
Juan (1:25:22)
Ajá, exacto.
Douglas (1:25:35)
Entonces yo creo que ese hecho, aunque por lo que hago en mi día a día, lo haga mayormente vía terminal, lo voy a dar empate también porque cuando no estoy haciendo nada, no me voy a la terminal, sino que me voy al GUI. Bueno, un último Juan, para empatar.
ambos porque este lo dejamos nulo por así decirlo o empatamos dos a dos o termina de ganar uno y es monitorear los recursos en tu local, sentís que tu local, tu laptop está lenta monitorear los recursos, lo haces por interfaz gráfica o lo haces por CLI.
Juan (1:26:27)
pues sería un Tui, así que es una interfaz en la terminal suelo utilizar eso si son los recursos de mi PC si quiero revisar qué recursos está utilizando un contenedor utilizo el comando de Docker aunque también utilizo otras herramientas, no lo sé
Douglas (1:26:39)
Uhum.
No,
Juan (1:26:52)
No sé, podrías actuar como juez y decidir si el TUI cuenta como una interfaz gráfica.
Douglas (1:26:59)
¿Qué
herramienta como tal?
Juan (1:27:02)
Tengo
una, utilizo una llamada Boram que me muestra, ¿no? Como... Como... Los niveles de... del CPU, la RAM y cosas así. No suelo utilizar el... famoso H-Top. No me gusta, no, no lo suelo utilizar. Pero es similar.
Douglas (1:27:21)
Sí, sí,
No te lo voy a dar como CLI, porque al final el CLI acomoda de una manera visual los resultados. Y yo en mi caso CLI. Cuando quiero revisar los recursos en mi local, ya sea comando directo como un VM stat o un free para ver la memoria RAM o directamente a veces un...
Juan (1:27:26)
jaja
Douglas (1:27:52)
mucha información, aunque cuando yo quiero trabajar con los servicios pues uso el comando PS y le doy diferentes argumentos para ver qué están consumiendo los servicios no necesariamente el top, pero sí lo hago desde desde el CLI, entonces creo que te buscaste dos a dos.
Juan (1:28:09)
Ok.
Douglas (1:28:09)
Yo quedé 3 a 1,
¿verdad? Pero creo que fue un ejercicio interesante, Juan, y nos pone en perspectiva, ¿verdad? Imagínate, vos sos alguien, y esto no es crítica ni nada, sino que es una reflexión interesante. Vos sos alguien más que aboca por Linux, y de hecho trabajas en Linux por años, y te estás dando cuenta que...
Juan (1:28:24)
Sí.
Douglas (1:28:35)
muchas tareas de tu día a día las haces más en un ambiente gráfico, en un ambiente de CLI. En mi caso yo tengo Mac y siento que la Mac por mi trabajo me vuelve más efectivo y tal vez de las tareas que mencioné acá hago un poquito más en CLI, tal vez por la naturaleza de mi trabajo también, ¿verdad? Pero es perspectiva y fíjate que en esa perspectiva, por ejemplo, yo quiero aclarar de que cuando trabajo con AWS, que es el proveedor de nube con el que más trabajo.
Juan (1:28:40)
Sí.
Sí.
Douglas (1:29:03)
en mi día a día, verdad. Cuando no estoy haciendo infrastructure as code, que es como realmente se maneja la infraestructura para orquestrarla para sistemas grandes, pero a veces querés probar algo o simplemente ocupás hacer un cambio rápido, lo hago desde el dashboard, el GUI, y mucho, mucho, profesional de sistemas usa el CLI de AWS.
la mayoría usa, al menos de los que yo he topado, usa el CLI. Yo uso el GUI porque la parte intuitiva y de velocidad gano, similar al motivo por el cual vos usas GUI en GIT. Y es que son tantas cosas.
Juan (1:29:47)
Sí.
Douglas (1:29:48)
y
un comando de CLI para hacerle un cambio a una instancia de EC2 puede tener 8, 10, 12 flags fácilmente, fácilmente, verdad? Entonces memorizarse todo eso o estar yendo a la referencia o al manual cada vez que lo quiero ejecutar a ese punto es más rápido para mí ir al GUI. Entonces lo que vos decía se vuelve cierto si le dedicara el tiempo a memorizar
serían mucho más rápidos totalmente pero fíjate que en ese caso que es algo que todo el tiempo cuando no estoy automatizándolo uso el GUI en lugar del CLI me parece interesante
Juan (1:30:33)
Sí, pero es
que de nuevo va a depender de la escala, creo yo, ¿verdad? Y esto es algo que yo te he escuchado a vos decirlo. Por ejemplo, en mi trabajo levantamos, en mi local yo levanto muchas instancias y utilizamos muchos comandos de AWS para levantar diferentes buckets, los secrets y muchas cosas. Pero es porque estamos automatizando algo que, o sea, necesito levantar
toda la instancia entonces con un comando hace todo así que me parece muy bien que existen las dos versiones una donde puedes automatizar y levantar y crear diferentes servicios pero también está la versión gráfica cuando necesitas hacer una cosa por ejemplo yo necesito revisar los archivos un archivo en los buckets pues me voy a la parte gráfica y reviso cambio mi rol y listo pero bueno volviendo a lo que mencionabas al inicio
solo me gustaría hacer un paréntesis en eso porque me llamó la atención. Yo creo que el ejercicio que hiciste en este momento y quisimos creo que refleja más que todo, tal vez no tanto el sistema operativo, sino la naturaleza de nuestros trabajos. En tu caso, yo me esperaba que eso, que seas alguien que utiliza mucho más la terminal.
porque te toca estar, digamos, metido en servidores. Es mucho más normal que vos estés así. En mi caso, las cosas que yo hago en la terminal son casi por decisión propia, porque casi todas las opciones en Dev están en opciones gráficas. Entonces, yo estoy mitad y mitad. Y también, bueno, voy a aprovechar para hablar de Linux, como siempre. Creo que habla bien de Linux el hecho de que
preconcepción que muchos tenemos, que yo tenía también antes, que Linux es sólo línea de comandos y la verdad es que no, desde hace mucho tiempo atrás Linux no es así y de hecho si no quieres utilizar la terminal y sólo quieres utilizar el sistema operativo normal, se puede, también está ese punto.
Douglas (1:32:52)
Sí, sí, es interesante y definitivamente la naturaleza del trabajo que hacemos es lo que determina, parte del por cuál quería hacer este ejercicio también es porque a veces somos bien radicales.
No digo, me incluyo como profesional de IT, pero tal vez vos y yo no somos radicales en ese sentido, pero hay mucha gente que radical entre el uso de GUI y CLI y muchas veces el que se encierra en que el GUI es mejor, si aprendieron poquito de CLI, fuese un poco más eficiente. O a veces el que piensa que CLI es mejor y se encierra en ello, si empezara a ver las gráficas y los dashboard en...
Juan (1:33:18)
Sí.
Douglas (1:33:34)
en Google y en lugar de CLI sería más eficiente, a veces cuando nos... cuando somos cerrados en algo es lo que nos afecta, pero ahorita hemos demostrado que tratamos de sacar el beneficio a cada uno de los dos, porque cada uno tiene sus fortalezas y desventajas.
Juan (1:33:37)
Sí.
Sí,
correcto.
Douglas (1:33:57)
Bueno, continuando Juan, plática se ha extendido bastante y realmente que ni he sentido el tiempo, pero creo que vale la pena tal vez dar un poquito de consejo aquí o incentivar a la gente que nos ve y nos escucha de por qué deberían de priorizar el uso de CLI en la medida de lo posible. En la medida de lo posible, tal vez esto va más dirigido a las personas que son más GUI, pero...
pudieran utilizar CLI porque las herramientas que usan tienen una versión en CLI y yo creo que si tendría que dar una recomendación es lo que hemos dicho de que están listos para automatizar. El objetivo final en DevOps y por DevOps me refiero a la cultura que incluye el ciclo de vida de las aplicaciones, el objetivo final en DevOps es automatizar.
Y como ya lo dijimos, un CLI es lo que nos acerca a ello. Fíjate que hay una anécdota que quiero contar que fue en este trabajo donde tuvimos la oportunidad de colaborar, Y cuando estábamos migrando aplicaciones se hacían Lucy, era el engine, Lucy para que nos lo sepan, es un lenguaje que se llama CFML.
ColdFusion creado por Adobe. ColdFusion es la parte de Enterprise, Lucy es la parte de Open Source que ha quedado hasta donde yo sé, todavía siguen, tengo ahí donde no trabajar con Lucy. Pero entonces estos ColdFusion y Lucy tienen un administrador gráfico.
Juan (1:35:29)
Sí, creo que sí.
Douglas (1:35:39)
muy bueno, intuitivo. En este administrador gráfico se conectan las bases de datos que quieres tener y manejas diferentes paths y caché y todas las configuraciones desde una interfaz gráfica y lo vuelve intuitivo y de hecho ese fue un gran diferenciador de ColdFusion, estoy hablando hace muchos años, que ya no me acuerdo, 2006, 2008, por ahí, bastante tiempo.
Pero esto fue un diferenciador bien grande y lo hizo popular. A mí me tocaba administrar muchos servidores con Confusion y nos tocaba usar lo que se conoce como workarounds o truquitos para orquestrarlos mejor y era buscar, generaba la configuración en archivos XML.
verdad, XML, y era buscar interactuar con esos archivos de manera directa para poder orquestrarlos en grandes cantidades y a los developers que tenían acceso a servidores de producción, pésima práctica, quiero aclararlo, pero era una práctica que existía en su momento en esta empresa, ellos sí les gustaba la interfaz gráfica. A mí me gustaba la interfaz gráfica, pero para orquestrarlo era complicado. Entonces, ¿por qué doy el contexto? Porque en algún momento...
comenzamos a migrar esto de VM a contenedores y queríamos usar un framework que si no me equivoco se llamaba Coldbox. Este fue un nuevo set de un framework y herramientas que permitían orquestrar por CLI la configuración de Lucy.
y en lugar de tener ese admin por medio de CLI, cambiar configuración y tenías archivos de configuración y todo lo que necesitás para orquestrar y para automatizar. Entonces cuando empezamos a querer mover esto a contenedores y cambiarlo a code box para que tuviera sentido que esté en contenedores,
Habían dos developers, uno de ellos mayormente, que tenía muchos años en la empresa y tenía acceso a ciertos servidores de producción. Él manejaba un sistema crítico y él tenía acceso a esos servidores de producción. Mala práctica, pero queríamos un cambio a la vez, Ahorita váyamos a Contraladores, luego corregimos esa parte. Y discutimos con él y no lo pudimos convencer.
Juan (1:37:56)
Claro,
sí.
Douglas (1:38:06)
de los beneficios de orquestrar comparado con una interfaz gráfica. Y su respuesta era y decía, pero ¿por qué me van a quitar? O sea, ¿por qué vamos a cambiar algo que funciona bien? Y nosotros, ¿por qué puede ser mejor? ¿Por qué se puede automatizar? Y todos los beneficios, ¿verdad? Y esta persona no quiso.
simplemente no quiso y entonces ese fue un servicio que quedó corriendo en servidores porque esta persona al final nunca quiso cambiar su mentalidad, verdad? yo quiero animar a que no caigamos en eso, verdad?
Juan (1:38:37)
Sí.
Douglas (1:38:44)
En la medida de lo posible, tratemos de aprender el CLI, aunque sea una o dos funciones a la vez, porque eso nos va acercando para estar listos para automatizar, que es el objetivo final en todo lo que tiene que ver con la cultura DevOps.
Juan (1:39:03)
Sí, es normal que haya resistencia al cambio, es normal que haya fricciones, es doloroso volver a aprender algo que, como decía él, ya funciona, ya lo manejamos, pero sí, es necesario ir evolucionando en nuestro trabajo, manera en cómo hacemos las cosas para ir buscando algo que sea mejor, Y también ir acomodándonos también a los nuevos estándares que existen en la
Obviamente antes, pues hoy en día lo vemos como una mala práctica como lo hacían pero en aquel entonces tal vez esa era la forma en que se manejaba en la región y pues así funcionaba. Pero la idea es ir cambiando, ir mejorando. que ese es el objetivo de nosotros que lo que nos escuchan no vayan tomando estos pequeños tips para que puedan ir mejorando donde se pueda.
Douglas (1:40:03)
Sí, ok. Bueno, continuando Juan, con un consejo más y es la pregunta, ¿cuándo es aceptable usar GUI en producción? Y aquí quiero comenzar estableciendo la base de que cuando administramos sistemas de producción, manejar configuraciones por medio de GUI debería de ser un delito penalizado con cárcel. No se debería de manejarnos una práctica correcta.
no es una práctica correcta pues quienes lo hagan así no hay ningún problema o tal vez sí tienen problemas pero los tienen ustedes por tal vez no querer dar el paso de automatizar lo correcto hacer en producción
es no usar GUI, sino que automatizar, idealmente con ya sea infraestructura como código o para provisionar la infraestructura o configuration management, Ansible, Poppetshev para manejar las configuraciones. Pero estableciendo que idealmente no se tiene que hacer eso para que esté todo en version control.
¿Cuándo es aceptable hacer click-ups? Así se le llama a eso, click-ups, que es por medio de clicks hacer operaciones, click-ups, como DevOps, pero con clicks. ¿Cuándo es aceptable, Juan? Y hay un par de situaciones, hay tres situaciones en mi opinión de cuándo es aceptable. Una de ellas es cuando estoy aprendiendo la herramienta.
una herramienta nueva, ya sea un nuevo servicio, una nueva herramienta y esto puede o no puede contar como producción, sin embargo lo voy a agregar aquí, verdad, porque tal vez lo voy a probar desde la cuenta de, digamos, un nuevo servicio en AWS, ya sea que sacaron un nuevo servicio o que es un servicio que yo no he utilizado y lo voy a probar en la cuenta de producción. Ahí voy a entrar al dashboard y voy a clicar por todos lados porque estoy queriendo entenderlo, estoy queriendo conocerlo y no voy a ponerme a ver cómo hacer
con terraform o cloud formation para quienes usen cloud formation no lo recomiendo pues sin embargo claro cloud formation es muchísimo mejor a hacerlo manual de producción pero cuando se está aprendiendo la nueva herramienta ahí hay que darle clic con todo y por todos lados para tratar de entenderlo y no entrar en eso de que no
hay que hacerlo con Terraform, hay que hacerlo con Infrastructure as Code. Entonces en esa parte creo yo que sí se puede ser flexible y de hecho es hasta recomendado. Otro momento en el cual en mi opinión es aceptable usar un GUI o hacer click ops en producción es cuando se da un problema en producción. Cuando hay un fallo lo identificamos y hay que corregir rápido.
y entonces si está caído el sistema yo te digo mira estas instancias están fallando hay que sacarlas y crear nuevas y entonces me vas a decir ok hacelo ya y yo te voy a decir ok perame porque lo tengo que hacer en Terraform dejame crear un feature branch hacer el cambio en Terraform y perame que tengo que mandar el pull request para que alguien lo apruebe ahí mirá vea hay problemas en producción no no entremos en eso anda de un solo al dashboard
hace el cambio. Quiero aclarar que que no lo puedan hacer con CLI, se puede hacer también en CLI, no hay ningún problema y lo que aplica para GUI en producción, de que no se deberían hacer cambios en GUI, también también aplica para cambios con CLI directos, que no sean por medio de tu orquestrador. Pero ahí anda de un solo cuando hay problemas en producción y hace el cambio, no te compliques y luego actualizas Terraform, verdad, pero ahí es válido.
Juan (1:43:42)
Sí.
Douglas (1:43:53)
ahí es válido usar click-ups en producción. en mi opinión, Juan, evitarlo en producción a toda costa, pero en estos escenarios es aceptable y de hecho yo en lo personal diría hasta recomendable. ¿Qué te parece?
Juan (1:44:09)
si
se me viene a la mente
creo que va por ahí también nosotros utilizamos esta herramienta llamada ArgoCD y ahí es posible manejar lo que son los ambiente perdón las variables de ambiente y esto se maneja a través de repositorios cambias el repositorio de la configuración y eso actualiza todo pero también es posible hacerlo directamente desde el dashboard y al menos de la manera en que está configurada no sé si es así por defecto
te permite hacer el cambio pero cuando detecte que hay una nueva versión de la aplicación se va actualizar y va a volver a agarrar la configuración que ya existía en el repositorio. Entonces eso lo que nos permite a nosotros es por ejemplo cambiar el nivel del log
Normalmente tenemos un nivel de log que es lo más básico para no estar generando tanta cosa, pero a veces necesitamos un nivel de log más amplio para ver todo lo que está sucediendo en el servidor. que podemos hacer ese cambio porque sabemos que es momentario, es algo temporal y luego se va a quitar de todas maneras. que hacemos el nivel de log, revisamos lo que está pasando y si identificamos lo que pasó, podemos actualizar la aplicación y una vez que se actualiza el nivel
DLOCK se vuelve a poner el que ya estaba configurado en el repositorio de la infraestructura. Entonces sí, me recuerda mucho a lo que estabas mencionando porque no tenemos que ir y modificar el repositorio de infraestructura, de todas maneras vamos a tener que volverlo a cambiar después, entonces solamente vamos al dashboard y ya se hace el cambio pequeño.
Douglas (1:45:56)
Sí, sí
se trata de ser efectivo, yo creo que esa es la métrica, se trata de ser efectivo y sí, aseguramos de inmediatamente hacer el cambio en código, pero resolvamos el problema desde el Bueno Juan, fíjate que es tiempo de que vayamos cerrando, la conversación ha sido muy buena, muy entretenida, pero...
Creo que podemos cerrar y yo quiero dar un consejo final y te voy a dar la palabra para que en base a lo que discutimos hoy vos también nos puedas dar tus palabras finales, pero el consejo que yo le voy a dar a las personas que nos ven y nos escuchan es no discutir al respecto, ¿verdad? No discutir entre qué es mejor el Ciela o si es mejor el GUI. Podemos dar nuestro punto de vista.
Podemos incluso tratar de convencer al otro de por qué creo y darle argumentos de por qué creo que debería de cambiar, ya sea al CLI o al GUI, dependiendo de qué lado estés y dependiendo de la herramienta. Ese tipo de cosas son válidas, pero entrar en discusión en realidad no es algo que vale la pena calentarse la cabeza. Al final del día, aunque crea que yo tengo razón y si la otra persona creo que está siendo ineficiente por su manera de trabajo, pues bueno.
démosle la libertad y la tranquilidad de que opere como mejor le convenga. Los que hemos discutido ahorita e incluso los ejercicios que hicimos pudimos ver de que no puede ser solo blanco o solo negro. Hay muchas áreas donde se pone gris y son esas áreas en las que con tal que nos hagan más efectivos.
Juan (1:47:31)
.
Douglas (1:47:38)
ese es el que cogemos o CLI o GUI. Entonces mi consejo final sería para todos evitemos discutir por un tema como este. Juan, ¿qué mensaje nos das para cerrar?
Juan (1:47:51)
voy a dar un mensaje muy similar al tuyo y es que definitivamente no existe, creo yo, un solo punto y más cuando esta vez un ambiente más local y estamos trabajando, estamos desarrollando aplicaciones no es bueno solo centrarnos en uno y dejar de lado el otro por lo que yo he visto, esta es mi experiencia muy personal donde suele haber más rechazos
es pasar del aspecto visual al lado de la línea de comandos. Ahí es donde suele haber más fricción.
y yo lo que les puedo decir es que si se sienten así como que no les interesa, no quieren yo lo que les diría es, bueno primero, inténtenlo y van a ver que algo van a aprender si después de intentarlo y utilizarlo dicen, bueno, definitivamente no es para mí pues es válido, no pasa nada hoy en día muchas herramientas a nivel visual son muy completas
y se puede, pero yo personalmente considero que sí pueden obtener un beneficio, algo bueno para como profesionales utilizando las interfaces de la terminal. hasta hace mucho, hasta hace un tiempo atrás Douglas yo utilizaba mucho VS Code. Luego por el hype de internet vi que todo el mundo hablaba sobre NeoVim y pues
intenté utilizarlo, ya había utilizado otros editores en el pasado, no es como que solo he utilizado VSCO toda mi vida, ya he utilizado otros, bajo esa permisa dije bueno voy a intentar esto y definitivamente no voy a decir que es mejor pero sí cambió mi flujo de trabajo incluso mi mentalidad al momento de abordar un proyecto
y eso definitivamente para mí fue muy beneficioso entonces de nuevo no voy a decir que es mejor lo que quiero dar a entender es que a veces podes encontrar un valor en probar estas otras herramientas que son muy diferentes a las que estamos acostumbrados así que sí existen muchas líneas grises y no hay que mantenerse en una sola no hay que entrar en fanatismos
Douglas (1:50:23)
Sí, muy
de acuerdo, muy de acuerdo, Juan y pues te agradezco por esas palabras finales. Igual te agradezco por la conversación. Me resultó muy entretenido como siempre. Me llamaron mucho la atención tus puntos de vistas y en eso pues pudimos reflexionar y tratar de llegar a un mutuo acuerdo en las áreas en las que se puede o simplemente entender de que para.
funciona de una manera y para otros funciona de otra manera, Entonces eso es lo bonito de esto. Gracias por el tiempo a las personas que nos ven y nos escuchan y llegaron hasta este punto. Muchas gracias por su atención. Nos veremos hasta el próximo episodio. Bye.
Juan (1:50:59)
Sí.
Bye.