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.
Juan (00:00)
él habla el por qué está dando esta charla y de entrada eso me llamó la atención porque él menciona que aún los proyectos más exitosos tienen cosas que pudieron haber sido mejores. Entonces ya de entrada él en su charla habla que sí, él está muy orgulloso del lenguaje de programación, está muy
muy
orgulloso por como el proyecto ha crecido, la comunidad ha crecido, eso no significa que todo fue bien y listo, vamos a dormir. No, aún así hay cosas que aprender, aún así hay cosas que se pueden ir mejorando.
bienvenidos amigos amigas también a un video más de nuestro podcast de Dev&Ops en esta ocasión como siempre me acompaña mi buen amigo Douglas Douglas cómo ha estado hace tiempo que no te veo y esta vez es mucho más que las veces anteriores me disculpo de nuevo ante ante nuestra audiencia por haberme on sentado fueron por motivos de fuerza mayor no pero pero bueno
Douglas los dejé aquí en buenas manos aquí con Douglas. ¿Qué tal Douglas?
Douglas (01:07)
Bueno,
muy bien, muy bien. Contento de tener la oportunidad de desarrollar otra charla en la que siempre esperamos.
proveer algo de valor a las personas que nos ven y nos escuchan, pero también contento de tenerte de vuelta, Creo que probablemente no seré el único. Muchas personas que nos ven y nos escuchan van a preferir escucharnos conversar en lugar de escucharme a mí como un monólogo desarrollando un tema. Pero bueno, estas son las bondades de estos formatos del podcast. Podemos desarrollarlo como conversación.
desarrollarlo como presentación. Cada uno de nosotros tiene habilidades, experiencias distintas que en algún punto se complementan, en la mayoría de los puntos o en los extremos a veces son bien distintas y eso es lo que en nuestra mente esperamos que llene de valor este espacio, el contenido que damos, pero en fin, contento de volver a tener otra charla con vos, y démosle viaje.
Juan (02:10)
Me encanta, me encanta. Yo también estoy contento de regresar. Y bueno, muchas gracias a las personas que nos siguen. Como dije, me disculpo con ustedes porque sé que muchos de ustedes están pendientes de los episodios y están escuchándonos día semana con semana, día con día. Muchísimas gracias. No es nada más recordarles si les gusta el contenido, pueden darle like, pueden compartirlo, pueden darle photo.
todas esas cosas, interacciones a nosotros nos ayudan mucho a seguir creciendo. Bien, el día de hoy vamos a tener una dinámica interesante Douglas y para los que nos están escuchando. El día de hoy quiero traerles a la mesa unos puntos que he recapitulado de una charla de uno de los creadores del lenguaje de programación Go. Esta es una charla que fue impartida por
Rob Pike ⁓
y Rob Pike también son personas que son muy conocidas dentro de la industria y precisamente por esto, por desarrollar diferentes lenguajes de programación, ayudar a...
a diseñar diferentes features que nosotros utilizamos y tal vez ni nos damos cuenta pero pero bien Robb Pike el año pasado dio una conferencia y habló sobre los puntos que él considera que hicieron muy bien en Go y los puntos que tal vez no hicieron tan bien así que es una charla muy entretenida muy interesante para los que les gusta el lenguaje de Go se las recomiendo totalmente vamos a tratar de dejar los enlaces
en las descripciones del video para que puedan ver la charla completa. El día de hoy no vamos a escuchar la charla, no la vamos a leer toda desde el principio de fin. Simplemente he recapitulado unos puntos que me parecieron muy interesantes de lo que él habló y que aplican no solamente a un lenguaje de formación, sino que aplican a otros aspectos de nuestra vida profesional e incluso podríamos decir que de la vida en general a veces.
si te pasa Douglas que a veces yo estoy haciendo alguna tarea nada que ver con programación, nada que ver con tecnología, pero mi mente de programador, mi mente de profesional de la tecnología empieza a desarrollar la idea, la tarea como ya lo he hecho en mi trabajo, en programación y todo esto, ya estamos programados internamente para hacer las cosas de esa forma.
Douglas (05:19)
No
solo me pasa de vez en cuando, de hecho me pasa seguido Juan y me vuelto intencional en ello porque he descubierto que por gracias de Dios la experiencia en nuestra profesión, en nuestro trabajo pues me he convertido en un buen profesional y al ser bueno en algo entonces puedo llevar eso a mis otros aspectos en la vida
Juan (05:28)
Qué bien.
Douglas (05:44)
Y de hecho, soy intencional en traerlo mi vida personal y he implementado lo que he aprendido en mi rol para organizar mi día a día, para poder salir con todas las cosas y planes a nivel personal, familiar, proyectos aparte. Y la forma como estructuro lo que voy a hacer, si no lo tengo anotado, si no lo tengo en un calendario, se me va a olvidar. Entonces, no solo me pasa que no me doy cuenta, de hecho me he vuelto intencional en ello.
y me llama la atención que lo mencioné porque me pasa bastante.
Juan (06:17)
jajaja
que bueno que bueno que ya lo has integrado ya con propiedad de hecho hace un tiempo atrás un amigo mío él es diseñador un buen amigo mío y empezó a comentarme cuál era su proceso al momento de hacer un trabajo y todo lo que me narraba a mí me sonaba ok estás utilizando una metodología que es lo que se suele hacer al momento de programar como lo típico
definir las tareas grandes y hacerlo más pequeñas, ir haciendo las tareas de esta manera y así, así, así. Y le empecé a decir, me parece que tenés una mentalidad un poco más de ingeniero que de diseñador. Que, ojo, es muy buen diseñador, tiene el lado artístico muy bien desarrollado. Y después de un tiempo me comentó que se cambió y se pasó a sistemas porque se sentía más cómodo.
Douglas (07:18)
Sí,
tiene sentido.
Juan (07:19)
entonces ya lo traía,
¿no? el talento. Bien, regresando a lo que queremos hablar el día de hoy, como mencionaba es una charla muy interesante, él hace un repaso por ciertos puntos y vamos a ir comentando algunas pequeñas notas que tomé Douglas para que podamos hablar un poco sobre eso, ¿no? Bien, empecemos por lo primero que él habla y empieza a...
a exponer cuál es su pasado, cómo ha ido evolucionando, cuál fue su tarea dentro del lenguaje y
él habla el por qué está dando esta charla y de entrada eso me llamó la atención porque él menciona que aún los proyectos más exitosos tienen cosas que pudieron haber sido mejores. Entonces ya de entrada él en su charla habla que sí, él está muy orgulloso del lenguaje de programación, está muy
muy
orgulloso por como el proyecto ha crecido, la comunidad ha crecido, eso no significa que todo fue bien y listo, vamos a dormir. No, aún así hay cosas que aprender, aún así hay cosas que se pueden ir
mejorando. Y esto me trajo recuerdos, Douglas, con una de las pláticas que tuvimos hace tiempo, hace unos par de episodios atrás, donde hablábamos, en este caso eran sobre los post
y hablar cómo hacemos un recuento de lo que sucedió mal y vemos qué se puede hacer para evitarlo. En este caso es similar excepto que no es con las cosas que salieron mal, sino con las cosas que salieron bien, él las revisa y revisa qué cosas, ok, salió bien pero pudo haber sido mejor. Entonces ya de entrada para mí Douglas, esta es una persona que me muestra que su mentalidad es diferente
la de todos o la gran mayoría de los profesionales donde no se conforma con solamente estar bien. Él quiere siempre mejorar. Siempre siempre. Luego él empieza a hablar sobre el lenguaje de programación Go y habla como Go es un lenguaje que es un lenguaje de diseño para ingenieros. Y esto va ser un punto que tal vez
Douglas (09:29)
Claro.
Juan (09:49)
No lo voy a abundar tan a profundidad, porque Involucreía que supieramos un poco más sobre lo que es la sintaxis, de go y esto. que sí te puedo decir es que algo que a mí me ha mantenido dentro de este lenguaje es que no se trata de la sintaxis más ingeniosa que puedes hacer. No se trata de crear el algoritmo más elegante, como dicen muchos.
se trata de que con el lenguaje que tenés de Go vas a crear sistemas que sean robustos, sean resilientes y que estén bien diseñados. Entonces Go en su núcleo ya trae esta mentalidad de querer diseñar sistemas, no solamente programarlas, no diseñarlos. Y eso es algo que para mí me llamó mucho la atención y empecé a entender muchas cosas de cómo funciona.
haciendo un proyecto, un producto, nos interesa que haga una cosa en específico, en este caso si es un lenguaje pues que programen, pero ellos no, ellos desde el inicio iban más allá, iban con otra intención y me parece que eso fue un punto muy importante y que creo que le podemos ir, nosotros podríamos copiarle eso, Douglas, en el aspecto de no solamente quedarnos con el enfoque inicial, sino ir un poquito más
más allá ir un poco más allá con ellos no sé si en tu caso te pasa que a veces diseñas algo no vamos a decirlo tal vez una herramienta una herramienta y sabes que él se va a utilizar de una forma pero cuando la estás diseñando tal vez empiezas a notar creo que esto les va ayudar de esta otra forma voy a agregarles esta otra cosita
otro punto que tal vez no eran digamos obligatorio pero ya en tu experiencia ya en lo que has vivido y sabes cómo se va a utilizar ya empezás a agregarlo porque sabes que puede ir un poco más allá
Douglas (12:36)
Sí, sí me ha pasado Juan, tal cual como lo estás mencionando y me gusta esta aplicación, momento lo que ellos usaron o lo que ellos pensaron, el proceso de su pensamiento a la hora de diseñar y crear este lenguaje de programación que lo ha aplicado a nuestro día día. En efecto, ha ocurrido algo que puedo mencionar.
pueden ser los pipelines, CI-CD pipelines. Normalmente a las personas de operaciones nos dejan comenzar y estructurar el pipeline y en algún momento mencionamos de que todo es colaboración dentro de DevOps. para que pueda existir esa colaboración tiene que ser un diseño intencional. Me llama la atención que él está diciendo...
Juan (13:22)
Ok
Douglas (13:24)
de que no pensaron en que solo se desarrolla, no pensaron en loops, en if statements y lo típico de programación y que para que puedas hacer multiproceso y que bueno, sino que te dieron ya una estructura porque por cierto, no sé si te lo había mencionado, pero hace muchos años, yo no recuerdo cuánto, cinco años, seis años tal vez, yo estudié Golang.
Juan (13:35)
Ajá.
Douglas (13:47)
lo básico para entenderlo porque me llamó la atención. Al final me quedé con Python porque siento que me abre más dentro de la parte de operaciones y DevOps.
Juan (13:58)
un poco más rápido, me imagino,
el desarrollo, un script y listo.
Douglas (14:00)
Sí,
lo podéis como escribetear y aparte ya existen muchas otras librerías e integraciones que sería consumir lo que otros ya crearon comparado con Go pero esa es la razón por la cual terminé con Python.
Pero en Go pude ver que yo no tenía que preocuparme por cómo estructurar módulos o cosas por el estilo. Ellos ya tienen un diseño, ellos ya tienen el main function, ¿verdad? Y todo tiene que ir dentro de ahí. Yo no tengo que ponerme a pensar en eso. Lo cual me lleva a mí directamente a...
arquitectar una solución en lugar de ponerme a pensar cómo organizo cosas, organizo mis files, cómo nombro las funciones, me lleva de un solo arquitectar y entonces volviendo a tu pregunta, eso intencional cuando yo creo soluciones como un pipeline.
Juan (14:45)
exacto
Douglas (15:00)
En lugar de poner, por ejemplo, los comandos o procesos para el build de la aplicación en el file, ya sea en el GitHub Action, en el workflow o en GitLab, en el GitLab file, creo un folder dentro del directorio, ahí pongo los scripts.
donde van a hacer los builds y hago que el pipeline llame el script, ejecute el script en lugar de correr los comandos ahí. Pero ¿cuál es la intención de esto? De que un programador, cuando cambie su proceso de build...
Juan (15:28)
Ok, ok.
Douglas (15:37)
no tenga que entender, por ejemplo, GitHub Action si no lo hacen en su día a día, o no tengan que entender GitLab o Jenkins, sino que el script ya está estructurado con un folder, con un directorio, y ellos cuando hacen cambios al proceso de build...
Un bash script es una secuencia de comandos. Entonces para ellos es fácil, simple de entender y ven dónde ir a hacer los cambios. Igual están estructurados el proceso de deployment de la aplicación, el proceso de despliegue. Todo está bien estructurado y se integra dentro del repositorio de código de manera que sea fácil de crear esa colaboración. Entonces...
Juan (16:00)
Sí.
Douglas (16:26)
es algo que obviamente no tenía la menor idea que esta gente que creó Go pensó de la misma manera, pero es algo que sí implemento en mis soluciones.
cuando tengo la intención de colaborar, cuando tengo la intención de hacerlo bien. Algo tan simple, Juan, como... cuando no a veces haces a la carrera y buscas que resuelva, ¿verdad? Y como... Yo sé que me van a pedir a mí la próxima vez que lo haga y tal vez por la premura uno viene y hace algo rápido. Es parte de la vida, no es la mejor práctica, pero a veces ocurre, ¿no? En lo que tiene que ver con sistemas y con IT. Pero cuando sé que voy a estar colaborando...
Juan (16:43)
cuando no claro si
Sí.
Sí.
Douglas (17:08)
necesito esa integración justo esta semana, esta misma semana, me dieron una tarea de hacer mejoras a un pipeline donde con Composer, que es este administrador de paquetes de PHP, con Composer, descargar paquetes que están en repositorios privados de una organización de GitHub, de dos diferentes organizaciones de GitHub, perdón.
Juan (17:24)
de PHP.
Douglas (17:38)
las dos organizaciones son privadas y jalar paquetes de ambos lugares.
Juan (17:43)
siempre cuando hay repositorios privados
en mi experiencia siempre ha sido bien complejo. No sé si serán skill issues de mi parte, pero siempre ha sido así.
Douglas (17:49)
ahí es
No se vuelve complejo y realmente que puede ser una sola... aunque sea de una sola organización se complica pero lo puedes manejar. ¿Qué ocurre? Ya estaba instalando paquetes de una organización privada y con Composer vos le puedes dar un token de GitHub para que autentique ¿Verdad? Hay un comando Composer config y le das que con un token que autentique ¿Qué ocurre? Normalmente autenticas contra una organización.
Juan (18:19)
Sí.
Douglas (18:23)
¿Por qué? Y esta es la parte por la cual estoy dando este ejemplo. Yo pude haber usado un personal access token en GitHub y como mi cuenta personal tiene acceso a las dos organizaciones, mi personal access token lo hubiese hecho simple. Simplísimo porque yo tengo acceso a todo y ya Composer tiene un comando para correr y autenticar contra GitHub, hubiera usado mi cuenta y jala todo. Yo les entrego la solución.
Juan (18:40)
Sí. Sí, fácil.
Douglas (18:52)
no hay problema. Pero, ¿qué ocurre? Se vuelve un proceso dependiente de mí. Se vuelve un proceso de que si los esos toquen de igual manera expiran, entonces cuando expiren, el developer no lo va poder renovar, tiene que venir a buscarme a mí. Y cuando yo no trabaje para la compañía, o si los dueños de la organización deciden quitarme el acceso, hay tantas cosas que pueden salir mal si un proceso...
Juan (19:15)
o si te vas de vacaciones.
Douglas (19:17)
Exacto. Si un proceso automático depende de tokens o accesos personales de un developer o de un ingeniero, cualquier cosa puede salir mal. Entonces, ¿qué ocurrió? Me tocó, yo lo hice con un GitHub app, usando una aplicación.
se instala en cada una de las organizaciones, pero ¿qué ocurre? Aunque es el mismo app, genera un token para una organización y genera un token para otra organización. Son dos tokens diferentes. Entonces me tocó hacer lo que le llamamos un workaround, o una solución alterna, no sé cuál es el término correcto en español, pero una solución alterna con una de las organizaciones.
Juan (19:53)
Sí.
Douglas (20:00)
usar el comando de que Composer autentique con GitHub, con el token, y con la otra organización que son menos los repositorios, hacerles cambios directos al log file. Y me tomó una evolución. Inicialmente le hacía cambios al Composer.json, pero eso requería que en CI yo corriera Composer Update.
Juan (20:04)
Mm-hmm.
Douglas (20:23)
que el update, la forma que funciona el update, lee el Composer.json y luego modifica el log file. Entonces requería que ese era Composer Update en CI y toma más tiempo.
Juan (20:23)
Ok
Douglas (20:34)
toma más tiempo. hasta que encontré un workaround donde en lugar de hacer eso modificaba el log file y en lugar de correr Composer Update en CI, corría Composer Install y es mucho más rápido porque lee directamente el log file, el composer.log para quienes no entiendan. Y eso lo hizo súper rápido, fue una muy buena solución, me tomó como tres veces más.
de lo que la solución rápida hubiese tomado, pero cuando se los presento a los desarrolladores esta misma semana y les expliqué por qué tomé...
todos me agradecieron y me dijeron, gracias que estás tomando en cuenta la colaboración, estás tomando en cuenta el performance, la cantidad de horas a largo plazo, el hacer el build process rápido. Entonces, para aterrizar tu pregunta, sí, fíjate, trato de tenerlo presente que al momento de crear una solución...
tenga una estructura que permita esa colaboración para poder realmente empoderar a un developer en que una vez que el pipeline está establecido ellos puedan fácilmente hacer cambios si se agregaron un nuevo plugin y ese plugin necesita ser construido ellos fácilmente pueden agregar los nuevos directorios si el artifact necesita que expire antes ellos fácilmente pueden hacer todo este tipo de cosas porque no solo estoy haciendo un tam...
decimos aquí en la región en la que vos y yo vivimos un tamal, un workflow de GitHub Action o de GitLab con todos los pasos ahí mismo y que sólo yo entienda, en lugar de hacer eso es algo bien estructurado, toma un poquito más de tiempo al inicio.
pero la colaboración a largo plazo, es más, las personas con los programadores con los que trabajo comúnmente ya esperan ver ese tipo de estructura, ya documentan internamente ellos pensando en ese tipo de estructura para manejar el CI-CD Pipeline una vez que fue creada por nosotros los de operaciones.
Juan (22:39)
que curioso, ya tus soluciones ya se vuelve parte de la documentación de ellos y creo que vamos a tocar un tema similar a eso, me agrada mucho y bueno, muy interesante Douglas, me gusta tu... como lo has abordado en tu caso, por eso te mencionaba, a veces estas cosas que vamos a ver aquí de las que habla
más o menos rápidos el siguiente que tengo bueno él habla sobre gopher para los que no sepan gopher es la mascota de go y me causó mucha risa como él habla de todo el proceso para llegar a esta mascota y pareciera muy simple porque la mascota es bien simple su diseño es bien bien chistoso pero él menciona cómo fueron iterando
fue esa la primera que tuvieron la anterior era un poco más como desordenada tenían él también se queja de que tuvieron que haber hecho algunas algunos arreglos no con cómo manejar la licencia de esta mascota porque debido a cómo fue configurada desde el inicio si no me equivoco creo que no podés utilizar directamente el logo que ellos hicieron así que todo el mundo hace variaciones
personal lo veo de hecho incluso mejor ahora porque la mascota existe como en diferentes poses, trajes y cosas así. Pero bien, habla de eso, solo lo quería mencionar que también cosas que vemos simples toman mucho tiempo, desde el logo hasta abajo, eso.
Douglas (24:52)
Juan,
ya que mencionaste ese tema y yo he tenido la curiosidad y probablemente me ha faltado hacer un Google search para responder, pero ahorita que mencionaste de la mascota, en el nombre en sí del lenguaje yo he tenido la incógnita, ¿es Golang o es Go? ¿o Golang y se abre via Go? ¿cuál es el correcto? ambos son correctos ¿cuál es el nombre en realidad? porque yo suelo decirle Golang muchas veces.
Juan (25:19)
Sí.
Sí, la respuesta es todas las anteriores. En sí, el lenguaje es GO, así, tal cual, GO. Pero como es muy cortito y a veces en el lenguaje inglés se puede malinterpretar dependiendo del contexto, entonces muchas personas y no estoy seguro si el mismo equipo de GO lo suelen decir como GO lang del lenguaje. Entonces ya con eso ya se diferencia un poco más y para algunas personas
lo hace más fácil de interpretar. Pero de hecho el dominio de ellos es Go.dev. ese el lenguaje. La extensión de los archivos es Go. Entonces...
Douglas (26:05)
Mira que interesante que justo
esa es la razón por la cual yo suelo decir GoLang porque mucha gente, si no tenés el contexto suficiente, Go se interpreta como cualquier otra cosa menos como el lenguaje de programación y esa es la razón por la que yo suelo utilizar GoLang pero bueno, voy en el camino correcto, por eso quería aclararlo entonces.
Juan (26:16)
Sí.
Sí.
sí sí sí sí sí
está bien de hecho con otros lenguajes sucede igual con zig también he escuchado que hay gente le dice ziglang con rust mucho pero sí ciertos lenguajes a veces le agregan el lang no es como para hacerlo más fácil de entender
Douglas (26:45)
Sí, sí,
Juan (26:46)
Otro
punto que me llama la atención Douglas de lo que él habla es cómo ellos se tomaron el tiempo para primero hacer la especificación del lenguaje. Voy intentar dejar también este enlace en la descripción porque hoy en día podemos leer la especificación. La especificación no es nada más que lo que ellos imaginaron cómo tiene que ser el lenguaje y es una serie de reglas. Está la regla
de cómo se deben nombrar los archivos, cómo se deben nombrar los paquetes, qué tiene que tener un archivo. Por ejemplo, un archivo de Go ya ahora lo sabemos, pero en su momento no se sabía que tenía que tener el nombre del paquete, package, por ejemplo, main, luego los imports, luego las variables, las funciones, los métodos, las estructuras. Ellos mencionan todo en la especificación. Lo curioso de esto, Douglas, o al menos para mí, lo que me llama la atención
al escucharlo a él, es que ellos dedicaron todo el tiempo en crear la especificación y no se pusieron a programar los compiladores que iban a revisar el código y que iban a hacer todo esto. Ellos utilizaron otro compilador que ya existía, también uno de ellos, si no me equivoco, empezó a escribir un compiler inicial.
utilizando C y no se lanzaron de un solo a crear el compilador. De hecho él menciona pudimos haberlo hecho desde el inicio, pudimos haber hecho un compilador en C, perdón en Go para compilar Go. Sin embargo eso hubiese requerido que el lenguaje se hubiese especializado demasiado en compiladores y ellos tenían otra mentalidad para los que no están
al tanto de la historia de Go. Go fue creado dentro del equipo para el equipo de Google y fue pensado principalmente para todo lo que era la comunicación entre servidores de backend. que no querían ellos desviarse tanto de esa meta principal, por lo tanto empezaron a utilizar C para compilar Go. Así que me llamó mucho la atención Douglas porque
estoy seguro, bueno a mí me ha pasado, no puedo asegurar por lo demás pero a mí me ha pasado que me dan una tarea, necesito hacer una tarea y me lanzo de un solo a programarla y hacer las rutinas que tengo que hacer y empiezo a configurar todo, archivos por aquí, archivos por allá y a veces es mejor tomar un paso atrás, diagramar, hacer un diagrama de flujo, hacer un documento en Markdown, en Confluence
en cualquier lado y es necesario a veces hacer esta maqueta de lo que va a ser el programa o nuevo feature y eso nos puede ayudar a veces a identificar ciertas ciertos errores o cosas que hacen falta o cosas que se pueden hacer de otra manera sin necesidad de gastar tiempo en desarrollar porque podemos ser muy muy expertos en un lenguaje o en
una herramienta pero sea como sea necesitamos gastar tiempo en esta y de esa manera pues nos evitamos tener que hacer esto así que a veces me llamó mucho la atención porque con simplemente un documento una especificación ellos lograron hacer esto así que para mí esa fue algo muy interesante ⁓
Douglas (30:42)
Sí, bien interesante.
Me resulta a mí también, Y aquí pienso muchas cosas en diferentes ramas de esta misma práctica que ellos hicieron. Una de ellas puede ser, habla de disciplina y profesionalismo en tu rubro.
porque la realidad es que la mayoría de los que desempeñamos un trabajo técnico no nos gusta ir al pizarrón y comenzar a diagramar y a planificar. Nos gusta comenzar a ejecutar la parte técnica porque ahí nos sentimos bien, ahí nos sentimos cómodos, pero es ahí donde a lo largo del camino...
Juan (31:23)
Sí.
Douglas (31:29)
Luego nos topamos con cosas que no son la mejor y luego cuesta ir implementando fixes en el camino para hacerlo funcionar relativamente mejor y nos topamos luego que la única forma de hacerlo trabajar bien es refactorizar y esa es la razón, creo yo Juan.
Juan (31:48)
Sí.
Douglas (31:48)
de que existe tanto la palabra refactorización cuando se están planeando nuevos features. Si vos estás en el daily, daily scrum meeting de un proyecto o de un equipo y cuando preguntan los project managers o los jefes de cómo, ocupamos para hacer esto y terminamos escuchando refactorizar. Ocupamos refactorizar el componente, ocupamos refactorizar el módulo, etcétera. Y la razón...
Juan (32:14)
Mm-hmm.
Douglas (32:17)
Fue esa.
que yo me atrevería a decir que probablemente en el 99 % de los casos la razón fue que no se planificó, pero requiere disciplina de mi parte el hacer eso que a no me gusta. De igual manera, la documentación al final, no es lo que está mencionando, pero lo incluyo ahí, la documentación al final de hacer la parte técnica requiere disciplina porque normalmente no nos gusta. lo primero es eso, habla de disciplina probablemente.
Juan (32:25)
no es planífico.
Douglas (32:48)
y me gusta y me anima a eso. Yo te mencionaba al inicio de la conversación y vos me preguntaste si hacía en mi día a día cosas que tal vez normalmente hacía en el trabajo y he sido intencional y requiere disciplina. No es fácil, yo lo reconozco, no es fácil. Pero en todas esas áreas donde he puesto disciplina nivel personal sacado del contexto profesional en el cual, a Dios, me ha ido muy bien, comienzo a mejorar.
Juan (32:58)
Sí.
Douglas (33:16)
cuando tenemos esa disciplina, hay una, hay un... yo creo que no es suerte que el lenguaje Go ha tenido tanto impacto y tanto uso en la industria porque fue como lo estructuraron, yo te mencionaba que me gusta de ellos que ya está... no tengo que ponerme a pensar cómo nombro las cosas, dónde pongo qué.
sino que me pongo a pensar de un solo en la lógica de mi código y eso se logró gracias a ese tiempo que ellos pusieron para planificar. Otra cosa que me pone a pensar, Juan, ese mismo punto que estás dando, que si bien es cierto lo tenemos que poner en práctica, también, ¿qué tanto me va a permitir la empresa hacerlo? Y aquí es donde toca poner las realidades junto con las buenas prácticas.
Juan (33:46)
Claro.
Douglas (34:06)
porque si yo le digo al project manager o le digo al cliente que me dé dos semanas para planificar, normalmente no te van a decir que no. Pero esto pasa, y aquí quisiera yo agregar esto, Juan, esto pasa cuando nosotros mismos hemos contribuido a... ⁓
la pobre cultura, sí, nosotros mismos. mucha gente podrá decir, no, es que yo siempre voy y digo y no me dejan tiempo para investigar, no me dejan tiempo para pensar en la mejor solución. Y puede ser, puede que sea cierto, pero vayamos despacio. En el lugar donde yo trabajo, le damos tiempo de discovery, se le llama en esa etapa.
Juan (34:30)
a esa cultura.
Douglas (34:56)
puede ser una tarea simple, ser el cliente está pidiendo que agreguemos un nuevo tipo de blog post para su editorial, un tipo nuevo de posteo, de post, perdón, para su blog, entonces ¿cómo lo vamos a hacer? Dame ocho horas de discovery.
para yo ver cuál es la mejor opción, planearla, considerar los demás elementos, considerar lo que ya está corriendo, que eso no vaya afectar, no vaya a impactar ni rendimiento, ni disponibilidad, ni errores, ni conflictos, etcétera. Y luego la mejor solución para venir y ejecutarlo. La tarea pequeña que sea, muchas veces, no está documentada, aunque sea una hora de discovery, deberíamos de pedir.
deberíamos de pedir y entonces ¿cómo lo hacemos? Bueno, digamos, ok, no me vas a dar discovery, entonces yo creo que va tomar cuatro horas y en lugar de medio calculamos que iba a ser dos, digamos cuatro y nosotros internamente usemos esas dos horas o esa hora de discovery para
presentar la mejor solución. Si no nos dan ese espacio, si no nos lo quieren dar, entonces, inflemos un poco la tarea para incluir ahí. si al principio, lo que yo estoy haciendo, miren esto qué importante, si lo que yo estoy haciendo el Discovery, no me dejaron hacerlo, entonces, les dije que en lugar de dos horas que otra gente dice, yo dije cuatro horas, durante la primera hora en mi Discovery, me encuentro que no va a ser tan fácil como creía, si en esa primera hora...
Juan (36:08)
Team.
mmm
Douglas (36:34)
yo hago saber el inconveniente que va a haber, dando evidencia de por qué va a ser así, no va a recaer sobre mí un problema, por el contrario, me voy a ver como el bueno de la película, me voy a ver como el héroe que descubrió que eso...
y va a ser un problema a largo plazo y entonces van a empezar a considerar cada vez más mi opinión al momento de que en proyectos futuros o en tareas futuras yo diga antes de decirte cuánto me va tomar dame dos horas de discovery dame ocho horas de discovery dependiendo de la magnitud de la tarea pero también si bien es cierto debemos implementarlo yo trato de implementarlo si quiero poner la realidad juan donde muchas veces no nos dejan y es un trabajo nuestro
Juan (36:53)
Sí.
chance.
Douglas (37:22)
no contribuir con esa cultura y buscar la manera de sin salirnos de las reglas, siempre hacerlo para un mejor resultado.
Juan (37:31)
Sí, yo creo que un buen project manager tiene que acomodar un poco el tiempo para esta planificación inicial. En lo personal he aplicado esto en ciertas ocasiones, pero se me vienen a la mente dos, la primera es muy extrema. Nosotros trabajamos con un proyecto que era para la universidad, era un sistema de bolsa de empleo.
y no había un fecha límite.
los que estábamos ahí estábamos súper verdes veníamos empezando en todo este mundo de la programación así que ya teníamos cierta experiencia pero nunca habíamos hecho un proyecto desde cero y con la magnitud que necesita un proyecto de universidad o sea para la universidad así que estuvimos alrededor de casi un año entero diría yo que casi un año entero entre nuestro tiempo libre obviamente diseñando todo lo que era
base de datos. Ni siquiera estoy refiriendo a la...
a escribir la sentencia de la base de datos, sino a los diagramas, los ERDs que iban en la base de datos y con eso nosotros íbamos viendo si la estructura que hemos diseñado va a poder, qué tan flexible es para que en un futuro, cuando ya no estemos, puedan seguir agregando cosas, quitando cosas, nuevos features, etc. Y de nuevo nos estuvimos bastante tiempo, bastante extremo el tiempo que estuvimos, pero
de nuevo, éramos muy nuevos y al día de hoy me di cuenta que lo siguen utilizando. El sistema se le siguen agregando features y la estructura base que estaba ahí pues sigue estando, sigue funcionando. que valió la pena. El otro ejemplo que te quiero dar es más reciente, era una tarea que cuando la vimos y yo la empecé a revisar en el trabajo,
calculé que me iba tomar alrededor de un mes. En este mes yo estaba acomodando con cosas que ya conozco, tareas de agregar una nueva tabla, nuevos endpoints, Los c.r.u.d. endpoints de toda la vida y uno que otro ahí un poquito más complejo. Sin embargo, esto se fue complicando y complicando, luego hablando con otras personas dentro de la empresa me explicaban
lo que yo quería hacer, bueno ellos no sabían de las tablas, pero ellos me hablaban de los procesos que ellos hacían y yo empezaba a entender, ok, esto requiere que modifique la tabla. Por ejemplo, yo agregaba las propiedades de país, estado, ciudad, pero ellos me empezaron a decir que no, se necesita que hayan múltiples países, múltiples estados, múltiples ciudades. Requería que cambiara y que cambiara. Al cabo que todo esto duró más de dos meses.
lo que yo inicialmente. Entonces, ¿qué hice al final? Al final empecé a trabajar, ya dejé de programar en Go, dejé de hacer todo eso y me dediqué solamente a la base de datos. Y empecé a utilizar estas herramientas que te digo, de los diagramas, hacia las sentencias, las estructuras de las tablas y empezaba a ver los diagramas. se vale pedir ayuda, empecé a pedir ayuda a mis otros compañeros para revisar las cosas que se me estaban pasando por alto a mí. Pero todos empezamos a
con esto ya como te digo a este punto ya me olvidé de programar porque ya no valía la pena gastar tiempo en esto si luego yo iba a ir a como decía a refactorizar todo una vez que me dijeran que esto era de otra forma entonces eso es una experiencia que tuve un poco más reciente y me gusta porque estas personas que diseñaron el lenguaje programación son obviamente personas que tienen muchos más años en la industria y
son super inteligentes y lo ves desde el inicio, ¿no? Como ellos abordaron esto simplemente creando una especificación y con eso esa fue la pauta para todo y la especificación sigue ahí. La podemos ver el día de hoy y la puedes leer y ahí está. Lo cual me gustaría que me da pauta al siguiente punto que te quiero hablar Douglas, que es la compatibilidad que ellos tienen en Go. Y con esto
quiero dar un punto que tengo, opinión que tengo sobre el desarrollo de software actual en la industria. Para los que han utilizado Go o han sacado uno que otro curso de Go, saben que Go tiene una promesa de retrocompatibilidad con todas sus versiones, o la gran mayoría de sus versiones, la versión 1 existe. De hecho, al final de la charla alguien le pregunta a Rob Pike
si cuando va a salir la versión 2 de Go y el entre bromas le dice nunca porque ellos tienen esta promesa que siempre vas a tener tu versión 1 de Go y vas a poder actualizar el lenguaje de Go sin ninguna preocupación. En lo personal sólo una vez he tenido complicaciones actualizando las versiones de Go de los sistemas que utilizo.
Douglas (42:49)
No,
Juan (43:12)
y esto no era específicamente por el lenguaje no se rompía ninguna compatibilidad pero si una dependencia de terceros tenía un problemilla y entonces cuando pasamos a una versión mucho más alta estábamos pasando de la versión 1.18 a la 1.23 que es la más reciente bueno una de las más recientes en ese momento se rompía algo porque en una versión de go esta dependencia
dependencia presentaba un problema y es eso lo que voy ir, Esto es algo que hoy en día yo creo que ya no lo ni siquiera lo consideramos en el desarrollo de software en la industria actual el hecho de decir ok voy a desarrollar un sistema que si no lo toco va a seguir funcionando siempre. Creo que hoy en día tenemos demasiadas dependencias utilizamos demasiados servicios
y estos servicios cuando cambian algo nos obligan a nosotros a actualizar nuestro código y se vuelve algo que si bien es cierto el software hay que darle mantenimiento pero también se vuelve algo que es casi como estar malavariando me parece a mí con todas estas dependencias y en lo personal no sé cómo expresarlo si es me da tristeza no sé cómo decirlo pero
No me gusta cómo es el estado actual de la industria de desarrollo porque creo que antes cuando veías programas que estaban hechos para Windows XP y los instaladas y siguen funcionando ¿por qué no aplicamos esa misma mentalidad?
a sistemas que están en la nube y claro tiene su complejidad inerente, es muy difícil. Pero ya lo vemos con Go, Go es un lenguaje que está pensado para estos servidores de backend en la nube y el lenguaje como tal tiene una compatibilidad increíble, podemos actualizar y lo único que va a suceder en teoría es que nuestro programa va a ser más eficiente, no se va a romper nada, más bien se va a mejorar. Entonces, ese es un punto que a mí me
me vuela la cabeza siempre que lo veo en Go, como ellos tienen esta promesa y hasta la fecha no lo han roto, Douglas. La promesa de la compatibilidad hacia atrás.
Douglas (45:42)
Sí, es una promesa fuerte, es una promesa fuertísima. Eso está el compromiso matrimonial, cuando le dije que sí a mi esposa y me casó hasta la muerte. Y luego la promesa que hicieron ellos con Go.
Juan (45:46)
muy fuerte.
Así mero
sí.
Douglas (46:01)
así de fuerte es.
Yo he tenido, yo lo escuché hace mucho tiempo cuando empecé a estudiar Go, que te mencioné, he tenido la impresión de que en algún momento, de cierta manera, ellos van a romper esa promesa, pero...
pensando en lo exponencial que cada vez va a la tecnología en todo sentido, tanto hardware como software, sobre todo con lo de la inteligencia artificial y esas cosas. Sin embargo, se ven bien encaminados en mantenerla y es parte del punto anterior ese tiempo que se tomaron para diseñar, para asegurarse. Y la razón por la cual hay una gran diferencia de día y noche comparado con otros lenguajes, Juan, yo creo que es
Juan (46:38)
Sí.
Douglas (46:49)
dejarse llevar por la parte comercial.
¿En qué sentido? Podemos ver lenguajes como Node.js y no es tirarle hate a nadie. Estamos hablando de hechos, de facts alrededor de estas cosas. Node.js y sus diferentes frameworks incluso. Hay tanto acelere y si vos lo ves, la industria va alrededor desde hace más de una década, rapid development. Ese fue un buzzword por muchos años. Recuerdo yo rapid development.
Juan (47:09)
Sí.
Sí.
Douglas (47:22)
ser capaz de crear un nuevo feature de manera inmediata porque la industria, porque el negocio lo pide. eso, exacto, exacto. Y eso yo estoy muy a favor de ello, cien por ciento a favor de ello. Yo siempre he estado en pro de que nosotros los, personas técnicas nos vamos alrededor del negocio. Sin embargo, la base tiene que ser sólida.
Juan (47:28)
hay feature, feature, features
Douglas (47:47)
para que luego eso pueda funcionar sin crear mayor problema. Y me ha tocado tener que ajustar, incluso con Node.js, instalar una nueva versión de sistema operativo.
porque de Node 14, creo, a Node 18, no soportaba. El sistema operativo no soportaba. Node 18 no se dejaba. Él quería una nueva versión del sistema operativo. puedes imaginarte la gran diferencia que vi de ahí para allá en muchas otras cosas. Desde que partimos con tener que reinstalar o crear un nuevo clúster, prácticamente, y fue una migración entera por actualizar la versión 14 a...
18 y es que aparte de ello estos otros lenguajes estos otros frameworks hasta te anuncian el end of life
el último, la última fecha en que le van a dar soporte a esa versión en particular y hoy en día con todo lo que tiene que ver con seguridad salen patches constantemente para cuidarte en la parte de ciberseguridad lo cual es muy importante pero de nuevo lastimosamente yo lo comparto con vos es una promesa bien agresiva sin embargo esa fundación y eso es lo que quiero como que agarrar para mí que lo hago como
Juan (48:43)
Sí.
Douglas (49:11)
de manera sin pensarlo tan directo, como que sin decir me voy a tomar todo mi tiempo de planificar para luego compatibilidad o luego que esto sea más robusto. No es que se me ocurren todas esas cosas por la mente, pero ahorita que vos mencionas esto de esta charla, lo puedo aplicar de manera intencional y venir y decir, hey, el tiempo de planificar antes de implementar para que las cosas no salgan a la carrera.
para que las cosas no tengan que estar corriendo y toque constantemente estar refactorizando componentes, refactorizando funcionalidades, teniendo que instalar nuevas versiones de sistemas operativos incluso, solo porque necesitamos la nueva versión, de lo contrario me quedo sin soporte y por ende voy a estar expuesto a nivel de seguridad en la web. Un paquete vulnerable, una línea de código vulnerable puede ser gravísimo.
para una empresa hoy en día. creo que nos anima, nos exhorta a comenzar a planear nuestras soluciones de esa manera. De nuevo, respetando, hay un balance por el tiempo. En el capítulo anterior mencionaba yo, Juan, de que estas empresas grandes tienen el presupuesto para crear departamentos de prueba y de desarrollo.
Juan (50:06)
Sí.
Sí.
Nosotros no.
Douglas (50:33)
y
los demás no, ¿verdad? Entonces, Goldland nació en ese ambiente de privilegio, si lo queremos llamar de esa manera, en que ellos buscaban la solución adecuada y se pudieron tomar el tiempo. En nuestro día a día nos toca poner un poco más la balanza.
Juan (50:41)
Sí.
Douglas (50:53)
y ser un poco más considerados con el tiempo. Sin embargo, sí podemos llegar a un punto intermedio en el que no afectemos el rapid development, pero que no caigamos en eso de la industria que nos lleva acelerado, acelerado, acelerado, y que nosotros mismos venir y sugerir, instalemos la nueva versión de React porque tiene este nuevo componente. ¿Qué tanto te va a servir ese nuevo componente?
Juan (51:05)
Mm-hmm.
Si, y ya cuando ves esta nueva versión
de React no es compatible con como estabas utilizando los componentes en tu versión actual y te toca refactorizar y es todo un lío ahí la verdad.
Douglas (51:30)
Y muchas veces Juan,
es por un, como decimos, como se dice en inglés, es por un nice to have, es por una cuestión bonita para tener pero no es fundamental. Y pasamos por todo ese proceso de refacturización, proceso de instalar nuevas versiones de otro montón de paquetes y sistema operativo, por un nice to have. Entonces nosotros mismos tengamos esa mentalidad de poner el pie un poco en el freno.
Juan (51:36)
Vamos a
Sí.
Douglas (51:56)
verdad, o si no quieren frenar, mínimo soltemos el acelerador un rato, mínimo, para que el momento nos mantenga más estables, pensemos lo que vamos a hacer y tomemos, yo creo, yo a nivel personal lo voy a tomar de manera intencional, tomémonos ese tiempo de pensar bien lo que vamos a hacer para que tenga una solución más a largo plazo.
Juan (52:03)
Mm-hmm.
Sí, yo creo que, como decías, hay un balance y es bien difícil decir que nuestro sistema empresarial no va a romperse en algún punto, pero yo creo que deberíamos apuntarle a eso. Apuntarle a que si yo el día de mañana le agrego un nuevo feature, pues eso no debería afectar en lo más mínimo a lo que ya existe. Mínimo nosotros deberíamos apuntarle a eso. Creo que por eso, obviamente los microservicios tuvieron un boom.
contar otros factores, como los contenedores, etcétera. algo muy atractivo de los microservicios es el hecho de poder cambiar algo en una parte en específico sin preocuparnos de otras funcionalidades. bueno, y también en lo personal, Douglas, considero que tenemos dependencias muy fuertes con otros servicios que tal vez no son necesarios. Realmente necesitamos utilizar
todos los APIs de Zoho? No lo sé, no lo sé, tal vez sí, tal vez no.
Douglas (53:27)
Sí,
fíjate que en esa línea, igual por el tema que se tocó el episodio anterior, algunas personas me preguntaron, porque yo mencioné que Kubernetes es más usado en orquestradores, pero que hay algunos escenarios donde yo todavía recomiendo Dockerswarm. Y me preguntaron así como con ironía, o no sé en qué tono, como quien dice, en qué momento, en qué escenario es válido Dockerswarm.
Juan (53:45)
Sí.
con desprecio
Douglas (53:58)
dice ya no es válido para nada y en resumen yo le dije cualquier empresa que no va a utilizar estas bondades que ofrece Kubernetes o tal vez para ponerlo más fácil cualquier empresa que no se ve limitado por lo que ofrece Dockerswarm ¿por qué se van a meter a la complejidad?
de administrar Kubernetes si no le van a sacar beneficio a eso que va a dar. Solo por decir que usan Kubernetes van a complicarse y van a tener que tener recursos y personas dedicadas a la administración porque por más que usemos Kubernetes en la nube y sea administrado por tengamos el managed service del proveedor de nube, mantener Kubernetes toma tiempo. Diseñar soluciones para Kubernetes toma tiempo. Y vale la pena cuando utilizamos esas funcionalidades.
Entonces, si DockerSwarm te soluciona lo que tenés, ¿por qué te vas a ir a la complejidad? No se trata de caer, y por eso dimos el consejo al inicio de este punto. No se trata de caer en la moda, de caer en la industria. Se trata de la solución más rápida y más eficiente. Y he escuchado gente que dice, sí, lo que pasa es que si haces Docker Swarm y cuando la aplicación crezca...
Y esa es la excusa que todo mundo pone. Y crezca ¿cómo? En más tráfico, porque tráfico te aguanta el que querrás, le pones más servidores al clúster y ya. Cresca en complejidad. ¿Qué complejidad tenés? Tal vez es un sitio web con dos o tres funcionalidades. ¿Realmente va llegar a crecer hasta ahí? Entonces, lo mismo aplica con estas cosas. Si es algo...
Juan (55:27)
No,
Douglas (55:43)
que estamos implementando porque en realidad como el ejemplo que nos dices del proyecto en la universidad porque estás viendo que tiene que tener una buena base para que de ahí escale entonces ahí puede ser válido que agarremos en su momento la última versión de cada uno de los frameworks y paquetes que vamos a utilizar y arquitectarlo de esa manera de lo contrario escojamos lo necesario que haga el trabajo bien y no le agreguemos complejidad que no se necesita.
Juan (56:11)
sí,
correcto complejidad que luego va a ser muy difícil de mantener
Y en ese punto Go tiene algo muy interesante que podemos revisar que se menciona en esta charla y se ha dicho muchas cosas sobre esto pero igual me gustaría volverlo mencionar aquí en este momento y es el Standard Library o la librería Standard de Go como ellos tenían esto muy claro desde el inicio que Go debería tener todo listo desde el comienzo.
y ⁓
cuánto tiempo van a durar, puede ser contraproducente y Go te da las herramientas para que puedas crear cualquier cosa. No por nada Kubernetes está sobre Go, si no me equivoco. Docker está sobre Go, Traffic está sobre Go y muchas, muchas herramientas que son, que son tan cruciales dentro del ciclo de vida de aplicaciones grandes utilizan Go. De hecho hace muy poco
todo lo que es el stack de typescript, el compilador si no me equivoco está haciéndose con go, entonces ¿por qué? de entre dos de muchas cosas uno de los puntos a favor es la librería estándar y me encanta porque eso hace que como te decía no utilizar dependencias de terceros que no necesitamos realmente necesitas una dependencia para
agregarle ceros a un número no yo no lo creo no lo digo en burla porque obviamente en javascript estaba este famoso pad left y y se da mucho esto de descargar diferentes librerías para cosas muy triviales desde mi punto de vista muy triviales pero pero en Go lo tenían claro y yo creo que eso lo que les ha ayudado a mantener esta promesa de la compatibilidad ⁓
Douglas (58:25)
mmm
Juan (58:48)
Otra cosa que me llama la atención también es muy cortito es el GoFont, GoFMT y esto a me gusta Douglas porque con Go como decías no tenés que preocuparte por casi nada. No tenés que preocuparte por cuántos espacios vas a utilizar, por dónde vas a poner la llave si al final de la línea o en la siguiente línea que es de abajo, no te preocupas
por si tienes que poner punto y coma o no todas estas cosas ya lo hace el mismo lenguaje ya lo tiene incluido en una de sus herramientas así que ya no tenés que preocuparte por llegar a un consenso con tu equipo de cuál va a ser la sintaxis casualmente el día de hoy estábamos hablando con mi equipo de trabajo sobre lo que es SQL porque nosotros utilizamos no utilizamos un
un ORM, nosotros creamos nuestras sentencias SQL como toda la vida,
Y yo les mencionaba, bueno, con SQL no tenemos nada definido. Y empezamos a hablar sobre eso, Y me decía un compañero, es curioso cómo SQL se trata de estructurar los datos, pero acerca de las sintaxis no hay nada estructurado para SQL porque te permite poner mayúsculas, minúsculas, te permite hacer de todo, ¿no? Y en cambio con Go no tenemos eso. Nos quita.
Douglas (1:00:17)
Sí.
Juan (1:00:26)
de la mente toda esta carga mental de tener que preocuparnos por diferentes, ¿cómo se le llaman esto?, linters, ya viene dentro del lenguaje y esto me gusta porque al final del día, como decía, se enfoca en que los desarrolladores gasten su energía diseñando las aplicaciones, no en tomar decisiones que ya deberían estar tomadas.
Así que para mí, es un punto muy interesante Douglas, bastante trivial podríamos decir, pero me gusta porque nos muestra cómo ellos se están preocupando por el hecho de que su producto, en este caso el lenguaje de programación, ya tenga todo lo que necesitamos. Su producto ya nosotros nos enfoquemos en lo primordial. Creo que esa es la clave. Ellos se dieron cuenta que al
final del día el lenguaje de programación, lo atractivo, no es en sí programar sino las cosas que haces con el lenguaje. Así que ellos lo tenían claro desde el inicio y no se fueron por las ramas de una sintaxis así súper bonita y una sintaxis que te puedo decir compleja. Ellos simplemente se fueron por otro lado y eso es lo que hicieron.
Douglas (1:01:51)
Sí Juan, fíjate que en esas cosas que parecen tan pequeñas, me trae a mí enseñanzas combinadas con mi experiencia, lo que te mencionaba antes. Algunas de estas cosas o muchas de estas cosas, de cierta manera yo las hago en mi día a día y soy intencional en ellas, sin embargo no es que...
Juan (1:02:10)
mmm
Douglas (1:02:13)
le había dado una estructura directa o no es porque la saqué de idea de estas personas que crearon Goalan, pero ahorita con lo que vos nos estás compartiendo.
Juan (1:02:20)
Ok
Douglas (1:02:25)
le dan estructura en mi mente y me hacen volverme intencional con ellas. Y lo que decías, que parece tan pequeño como el Standard Library, y creo que por si alguien no sabe el Standard Library, y si yo me equivoco me corregís, pero es la cantidad de paquetes y funcionalidades que trae por defecto Golland al instalarse. La cantidad de comandos, funciones, etcétera, vienen ya integrados sin necesidad de importar un...
ocurre lo mismo en yo uso Python por ejemplo y Python trae integrado una librería para gráficos por ejemplo pero cuando la gente va a hacer una aplicación que requiera de una interfaz gráfica normalmente usa una librería externa con Golang no es así con el Standard Library viene pensado
Juan (1:03:01)
Mm-hmm.
Sí, en Go incluso las
librerías de terceros muchas veces son como wrappers mucho más intuitivos de lo que ya está en la Standard Library.
Douglas (1:03:29)
Sí, he visto esas cosas.
Pero lo que decía del Standard Library y lo del FMT, que me hace pensar con esto, Juan, aplicado a la práctica es, procuremos crear soluciones donde...
Juan (1:03:38)
Sí.
Douglas (1:03:47)
demos no necesariamente desde la concepción de una solución porque a veces no podemos pensar en todos los escenarios o no tenemos el tiempo de pensar en todos los escenarios, pero que eventualmente agreguemos, creemos soluciones que den soporte nativo entre comillas a los diferentes personas del equipo, a los desarrolladores, por ejemplo, en mi caso como alguien de sistemas o de operaciones.
Juan (1:03:54)
mmm
Douglas (1:04:14)
Y te voy a dar un ejemplo rapidito. Nosotros, en donde estoy actualmente, trabajamos mayormente con GitLab. mayormente hacemos build de aplicaciones o de WordPress o aplicaciones de Node.js y publicamos a lugares similares. Puede ser un manage hosting de WordPress como WordPress VIP, WordPress Engine, Pantheon, etcétera. O publicamos a Kubernetes o publicamos a VMs.
Juan (1:04:21)
Ok.
Douglas (1:04:42)
como que hay un set estandarizado de lo que normalmente tienen los clientes, en lugar de estar repitiendo las cosas, hemos creado algo que se llama el CI Library internamente, que son template jobs de GitLab que ya hacen eso. Entonces, solo llamas al Standard Library al principio de tu pipeline y para...
Juan (1:04:57)
Ok.
Douglas (1:05:09)
Build WordPress o Build Node.js solo llamas a ese template. Si tu aplicación tuviera algo muy custom, por medio de variables lo personalizas y listo. Y si quieres publicar a WordPress, VIP tiene una forma diferente, pero quieres publicar a WordPress Engine, llamas al template job que lo hace, le decís dónde están tus directorios y listos. O quieres publicar a Kubernetes, llamas al template job y lo hace y listo.
Pero eso estandarizó todo en la empresa y sabemos que está el mismo tipo de builds y el mismo tipo de de deploys para las diferentes aplicaciones que manejamos. Pero comenzaron a decirnos, hey, quiero hacer LinkedIn test, scanning de virus, ese tipo de cosas. ¿Queremos hacerlo? Y como que inicialmente es, de momento no está.
Juan (1:06:00)
Ok, sí.
Douglas (1:06:06)
hacerlo a tu manera. Entonces cuando vos le decís, hacelo a tu manera, algunos lo hacen eficiente, algunos lo hacen bien, muy bien, otros lo hacen a media, otros ni siquiera lo hacen. Eso es lo que vos decís, hacelo a tu manera, eso es lo que significa. Y mi manera no hacerlo, entonces no lo hacen. Pero ¿qué ocurre? Como ya teníamos una base establecida, se empiezan a agregar esos test.
Juan (1:06:11)
Sí.
Mi manera es no hacerlo.
Douglas (1:06:32)
esos jobs que son unos templates y entonces a cabo de un tiempo corto ya le empezamos a decir a los diferentes equipos, para los tests solo llamar a este template y ya lo empiezan ellos a agregar con el CI Library y para ellos el CI Library de nuestro GitLab es una solución íntegra de todo lo que tienen que, de todo lo que ellos necesitan para CI CD e incluso hoy en día estamos...
convirtiendo muchas de esas funcionalidades para GitHub Actions. Yo he mencionado en el pasado que he trabajado en dos Actions, dos GitHub Actions que son públicos, y vienen a raíz de estandarizar ese tipo de cosas, a lo que voy con ello es tomando este ejemplo de Go, donde todo viene nativo en su Standard Library o sus herramientas nativas, no tienes que preocuparte por cómo manejar la sintaxis, etcétera.
Juan (1:07:05)
Oh, ok, ok.
Mhmm.
Douglas (1:07:29)
Busquemos que nuestra solución sea íntegra y quitemosle la necesidad a los demás equipos, si es el arquitecto de software que está haciendo algo para que los demás manejen un componente o si vos como tal estás haciendo un componente, tratemos de hacerlo de manera que sea íntegro y quitemoslo en la medida de lo posible esa necesidad.
de que las personas lo hagan a su manera, entre comillas, porque entonces acabamos con un tutti frutti de diferentes, de diferentes, un cóctel de diferentes cosas en una misma solución. El simple hecho de usar una librería de terceros ya por sí depende no solo de inseguridad, depende de otro, también depende incluso de rendimiento.
Juan (1:07:58)
Sí, sí, sí. Un cóctel.
Douglas (1:08:16)
porque es otra librería, es otro código el cual no controlas y solo te toca confiar, ver quién es el desarrollador, qué equipo lo desarrolla, qué tanto lo está manteniendo, te toca confiar y el día que ellos cometen un error.
Juan (1:08:23)
No,
Douglas (1:08:30)
y lanzen una versión o con vulnerabilidades o con problemas de performance, de rendimiento, vos lo vas a jalar a tu propia aplicación. Entonces, eso por sí solo es tan preocupante y tedioso cuando tenés en mente el rendimiento y la seguridad. No digamos que lo dejemos a que hacélo a tu manera.
Juan (1:08:39)
Sí, sí.
Douglas (1:08:51)
Ya que si vas a usar librería de terceros, implementarlas de manera nativa entre comillas para dar una mejor experiencia y tener un mejor resultado final, a lo que Golang ha logrado a lo largo de los años.
Juan (1:09:06)
Exacto, exacto. Sí, sí, definitivamente esa es la idea y pues de esa manera lo han logrado ellos. Claro, ¿no? Al tener algo tan...
estandarizado, personas, esto es lo que yo he escuchado en internet, muchas personas se quejan que en Go siempre es lo mismo. Ya ahí es cuestión de gustos personales, supongo, pero a mí me gusta Douglas el hecho de poder ir a un proyecto super random en GitHub y si está hecho en Go yo muy probablemente voy a poder leer el código. Ya luego si son temas muy complejos que no entiendo,
eso es otra cosa pero en cuanto a la sintaxis no me voy a topar con algo que no entienda no es el caso por ejemplo de typescript yo manejo typescript hasta cierto punto pero luego yo veo unas declaraciones de generics en typescript que wow la verdad no
ni siquiera sé cómo se lee entonces con go no sucede eso y eso es intencional eso ellos lo hicieron de esa manera algo que también ellos hicieron de manera intencional y aquí se va a relacionar con lo que hablabas con el comentario de por qué utilizar Kubernetes y en vez de
de Docker Swarm es cuando Rob Pike empieza a sobre cómo ellos llegaron a la concurrencia. de los grandes, cómo se le dice el marketing de Go, uno de sus grandes bondades y fortalezas es la concurrencia con sus llamadas Go routines, los channels, todo esto. ellos hablan cómo en los
en los servidores de Google utilizaban mucho C++ y creo que algo de Java pero principalmente C++ sin embargo en ese entonces él habla que tenían casi casi prohibido utilizar threads no les gustaba la concurrencia y ellos lo miraban como algo malo aquí me falla un poco las referencias que él da él habla sobre no sé si es el autor de un libro o si es un manifiesto ⁓
ahí me faltó investigar un poco más él habla de esta persona llamada John Oosterhout y cómo esta persona habla de por qué son malos los threads sin embargo Rob Pike menciona que él se equivocaba en dos cosas principalmente la primera era que este señor generalizaba en el dominio
dominios que se entienda como los límites de lo que le interesaba a otras haut.
el apellido complejo entonces él miraba que los threads eran malos en una cosa y ya por eso él lo generalizaba y que también él se quejaba porque había unos paquetes que eran de low level y que eran muy malos menciona el nombre de un paquete lo olvidé para ser sincero entonces él Rob Pike menciona cómo él estaba malo y debido a que estaba
malo, la solución que en este caso la solución era no utilizar threads, por ende estaba mala. Rob Pike menciona que él mucho más antes ya utilizaba threads y utilizaba concurrencia para muchas cosas y él no le miraba el problema. Entonces por eso ellos se enfocaron mucho en este tema de la concurrencia con Go para que fuera fácil. Menciona que tal vez no fue algo tan intuitivo al inicio.
aquí me falta un poco porque yo cuando empiezo con el lenguaje de go ⁓ ya había madurado
lo suficiente como que para mí fuese entre comillas simple. Pero me llama la atención esto Douglas, cómo a veces tenemos una idea de algo, pero esa idea no quiere decir que esté bien, no quiere decir que perdón. Incluso a veces citamos a otras personas porque este autor, este authors out, era citado por otros desarrolladores dentro de los laboratorios.
de google y yo decía no pues mirar aquí este escribió sobre eso por ende es malo y él menciona como perdían de vista que la solución verdadera era invertir más tiempo en esto y hacerlo bien hacer bien el uso de los threads entonces mejor dicho la concurrencia y pues para mí eso me llamó mucho la atención porque a veces tenemos ciertas
preconcepciones sobre algunos temas, no te puedo dar un ejemplo tan claro pero tenemos preconcepciones sobre algunos temas y a veces nos quedamos con eso, nos quedamos con que lo escuché de algún influencer, lo escuché o lo leí en artículo y ya por eso ya así tiene que ser. El ejemplo que te puedo dar es un ejemplo no tan grave pero creo que va de la mano.
Yo siempre he trabajado con SQL, te mencionaba que hoy tuvimos una charla sobre SQL en mi trabajo y yo siempre he trabajado con la idea de, para el nombre de las tablas, utilizar plural.
Yo tenía el sesgo que todo el mundo trabajaba así. Porque en cierto punto investigué en internet y casi todos recomendaban eso. Sin embargo, en mi equipo donde estoy empezaron a decir, no, decían, para mí tiene que ser singular. Y pues se generó el debate y empecé a investigar y me di cuenta que no, realmente está muy dividido la comunidad en SQL sobre ese tema en específico.
Así que eso me hizo replantearme lo que yo consideraba que cómo era este tema en específico y empecé a investigar. Empecé a investigar cuáles eran los... o sea, por qué recomiendan plural, por qué recomiendan singular, qué es lo malo, qué es lo bueno. Y me dediqué a dedicarle este tiempo que antes no se lo había dedicado. Antes solo me fui con que la solución es utilizar plural y listo. Pero no, ahora...
me tomé el tiempo de realmente ver por qué y cuándo era necesario, cuándo no era tan recomendable. Y con esto en el equipo de mi trabajo pudimos tomar una decisión y ya me pude quitar como estas preconcepciones que te mencionaba. Y me llama la atención porque Rob Pike habla sobre eso, habla de cómo a veces tenemos una idea generalizada, que es también lo que pasaba con la persona que te hizo el comentario sobre Kubernetes y...
Douglas (1:16:32)
Mhmm.
Juan (1:16:32)
y
docker swarm tienen una idea pero realmente no se han dado a la tarea de investigar o incluso probar las otras soluciones que existen así que bueno si por eso lo quería mencionar en este momento porque me pareció muy interesante cómo él aborda este tipo de temas
Douglas (1:16:53)
Sí, ocurre un fenómeno,
fíjate Juan, yo lo he notado bien marcado dentro de la parte técnica, sistemas, desarrollo de software, pero es un fenómeno o un comportamiento humano y es que cuando yo no he podido con algo como una manera de auto engañarme y de hacerlo ver en lugar de venir y decir yo fracase, como que mi reacción es esto no se puede.
Juan (1:17:11)
No,
Douglas (1:17:21)
esto no es posible. Entonces, si yo fracase en algo, comienzo a decirle a la gente, no, eso no lo hagas, no sirve. Me pasó mucho y para dar un ejemplo fuera de desarrollo, porque es exactamente lo mismo que estás diciendo aquí, cuando recién me convertí en padre y había muchas cosas, por ejemplo, con mi esposa compramos un cochecito, una carriola para el bebé y los otros padres me decían, no, Stax, gastando el dinero.
Juan (1:17:22)
Sí.
Sí.
Douglas (1:17:50)
nunca ellos no quieren montarse en la carriola, la vas a tener de adorno y aquí y allá y el gran comentario. Sin embargo, nosotros vinimos y decidimos comprarla y con diligencia no nos costó mucho que nuestras hijas, comenzando con la primera, anduvieran en la carriola cuando salíamos. Cuando ya cumplieron seis meses, ellas pasaron y estoy contando cosas personales, pero quiero resaltar esta naturaleza humana.
Juan (1:18:06)
Sí.
Douglas (1:18:16)
que se aplica a nuestra profesión. Compramos, ellas dormían en su propio cuarto, en su propia cuna y compramos unos monitorecitos para monitorearlos en la noche, los estás viendo y los estás escuchando. Entonces recién los compramos lo mismo, empezaron por no, mi ave, está gastando el dinero, nunca los vas a poder sacar de la cama, duermen pegados a vos y que aquí y que allá. Y pues, por gracias de Dios los compramos y los pudimos implementar.
Juan (1:18:17)
Uh-huh.
sí sí sí sí
Douglas (1:18:44)
¿Qué aprendí yo de eso? Y yo lo comentaba con mucha otra gente y era de esa manera cuando yo de ese punto en adelante hablaba con nuevos padres. A mí me gustaría que los seres humanos dijéramos, fíjate que yo no lo pude implementar. Yo no pude hacer que mi hijo usara el coche. Pero mirá, yo intenté esto, esto, esto. Aquí sentí que iba bien, aquí sentí que fallé.
Juan (1:19:02)
No,
Douglas (1:19:09)
Usa esa información para tu plan a ver si le sacas algo productivo. Lo mismo con cualquier otra área. En lugar de decir que no es posible, si yo fracase en ella y miro que alguien lo va a hacer, en lugar de decirle que no es posible, porque de nuevo yo siento que esa es una reacción para justificar mi fracaso.
Juan (1:19:16)
Sí.
Douglas (1:19:32)
porque si digo que eso es algo imposible, entonces no estoy diciendo que fracasee, estoy diciendo que esa era una tarea imposible y nadie la puede hacer. Si estoy diciendo fracasee, me tomo el tiempo de corregir. Entonces, hagamos eso en todo sentido, tanto en lo personal como en lo de tecnología. Yo creo que hay ciertas cosas bien marcadas y hay que entender como que alguien quiere instalar un plugin vulnerable.
Juan (1:19:43)
Sí.
Douglas (1:19:59)
Entonces le puedes decir, mira, ve, estás instalando algo vulnerable, te va a ir mal. En tecnología hay ciertas cosas bien marcadas, pero fuera de ello, lo que tiene que ver con la forma de cómo hacer las cosas, seamos abiertos, porque lo que aplica para mí no necesariamente va a funcionar para el otro, porque si su aplicación es más sencilla que la que yo estaba manejando...
Juan (1:20:04)
No,
Douglas (1:20:22)
es muy probable que le funcione y para qué agregarle más complejidad o si yo lo quise hacer y a mí me falló era porque tenía un fundamento tal vez no tan bueno y él sí tiene un buen fundamento entonces mejor compartamos la experiencia de por qué me falló a mí, qué intenté para que esa persona lo pueda considerar yo entiendo por qué el multiproceso
no lo querían utilizar y es que si no está bien implementado te gastas los recursos de un servidor o de un cluster en un instante si no lo sabes implementar o incluso el resultado que querés porque hasta donde yo visto si vos querés devolver una lista en orden que comience desde el primero y termine con el último si lo haces en multiproceso pues es complejo porque luego de procesar todo tendrías que ordenar porque él va a ir tirando a medida lo agarró
Juan (1:20:54)
Sí.
Sí.
a
lo que salga primero.
Douglas (1:21:12)
a lo que
agarra lo que sacó primero, entonces existen retos. Nadie está diciendo que no, pero esa naturaleza humana se nos marca tanto en tecnología porque cuando hemos logrado hacer dos o tres cosas buenas nos comenzamos a sentir como los mejores y somos así tajantes y decimos no eso no sirve o no eso sí sirve o eso es más o menos pero yo que vos no lo usara.
Juan (1:21:38)
Sí, sí.
Douglas (1:21:38)
Seamos abiertos
y mejor compartamos. tanto valor en una historia y una experiencia de éxito en tecnología como en una historia de fracaso. Porque de ambas hay un aprendizaje grande y en ambas podemos poner a la persona uno o dos pasos adelante, ya sea para que repita algo bueno o para que no haga algo que es malo.
Juan (1:21:50)
Si
Mm-hmm.
Sí, sí, totalmente. Bueno, por ejemplo, en ese tema de la paternidad y los hijos hay tantas opiniones y muchas veces tenés razón. No son opiniones desde el punto de, te recomiendo esto porque a mí no me funcionó. Creo que eso sería lo más sano. Generalmente vienes de otro, con otra intención en los consejos que dan. Algunos, bueno, la mayoría son con muy buena intención, eso sí.
Douglas (1:22:33)
Sí.
Juan (1:22:34)
pero bueno pasa y sí me llama la atención lo que mencionas de que a veces no nos gusta admitir que fallamos y es cierto es totalmente cierto a veces es más fácil decir no lo hice porque no se puede a decir no lo hice porque no me salió y de hecho él Rob Pike él hace otro otro comentario siempre sobre las go routines concurrencia
Douglas (1:22:55)
Mm-hmm.
Juan (1:23:03)
él mencionaba que como él estaba tan seguro en que es algo que funciona y ya lo había hecho él siempre se mantuvo firme en su opinión de que esto tiene que ir dentro del lenguaje también menciona que era como este punto interesante para atraer gente nueva también lo reconoce pero él menciona que su idea de concurrencia estaba dada porque
cosas que él le hacía. Entonces también menciona que hubo muchos programadores que cuando le empezaron a utilizar se vieron sorprendidos porque esperaban tener una mejoría sustancial al empezar a utilizar estos procesos concurrentes y se dieron cuenta que no, que utilizaban las concurrencias, las go routines y el tiempo que les tomó hacer una tarea era casi la misma que si no lo hubiese
se han utilizado entonces se enojaban y se miraban como bueno y entonces para que lo utilizo y él menciona que si tu programa
los fundamentos de tu sistema no están hechos para correrlos en paralelo no le vas a sacar provecho por muchas go routines que le pongas si tu base de datos primero tenes que ir a una tabla y luego a otra para poder obtener la información pues eso no te lo vas a quitar si en tu programa como te digo tenes dependencias que tienen que ocurrir en cierto orden pues al final del día las go routines no te van a ayudar
a solucionar eso. de antemano aquí volvemos a lo que hablamos a un inicio, de planificar bien cómo vamos a solucionar estas tareas, cómo vamos a utilizar las herramientas que tenemos, en este caso el lenguaje es una herramienta, cómo le vamos a sacar provecho y alrededor de eso podemos nosotros estructurar la información, diseñar diferentes procesos, cómo se van a ir, en qué orden van a ocurrir,
etcétera etcétera entonces sí es muy interesante como tampoco es una bala de plata como como dice si necesitas diseñar tu sistema de cierta manera para poder sacarle el jugo pero pero bueno mucha gente al inicio como que no tenían tenemos que recordar que el inicio go fue muy revolucionario por ese aspecto de las de la concurrencia así que no está
muy acostumbrados los desarrolladores vamos a darles ese beneficio que no sabían cómo utilizarlo ⁓
Douglas (1:25:54)
Sí, y lo
típico, ¿no? Me falló, debe de ser alguien más o algo más, pero no yo. Y otra cosa es que probablemente mi aplicación no necesitaba. Sí, por bien estructurada que esté, si hacerlo normal o hacerlo con concurrencia, la diferencia no es mucha, entonces no ocupaba concurrencia, ¿no? Es verdad.
Juan (1:26:15)
Claro, totalmente.
Sí, no la necesitan. De hecho, como punto, como comentario aquí, personal, yo rara vez necesito hacer algo muy complejo con concurrencia. Si acaso varios llamados a lo base de datos, trato de optimizarlos con gorrutins, pero es muy, poco. Normalmente no lo necesito.
Douglas (1:26:40)
Sí, sí.
Juan (1:26:42)
Bien, vamos a ir terminando con los puntos que tengo por aquí, Douglas. La charla tiene un par de cosas más que no las incluí. Lo que me pareció interesante que él habló después de esto es sobre las interfaces. Las interfaces en Go tienen una peculiaridad respecto a otros lenguajes y es que, por ejemplo, en Java, nosotros necesitamos poner, cuando definimos una clase, también le
definimos qué interfaces implementa. ⁓
y esto ya viene definido en Go no es necesario hacer eso nosotros definimos una interfaz definimos una estructura de datos y luego si si si son compatibles las podemos utilizar y si no, no eso es todo él habla un poco sobre esto ⁓ y habla un poco más ciertos detalles un poco más técnicos pero a mí lo que me llama la atención es cómo él habla sobre este
en que ellos lo que querían favorecer con esta manera de utilizar las interfaces y las estructuras era favorecer la composición en vez de herencia ¿por qué? y eso es porque ellos notaron que en otros lenguajes utilizaban generics como te mencionaba como en typescript por ejemplo no sé si typescript creo que no existía en ese entonces
entonces
soy malo con las fechas, no estoy tan seguro pero lenguajes de programación ellos notaron, en diferentes lenguajes notaron que la gente abusaba de los generics y las cosas que podías hacer con el polimorfismo ellos notaron que la gente se empezaba a enfocar más en los tipos de datos y cómo hacer estos cambios más que en un diseño
El él menciona un diseño orgánico. Y eso para mí fue muy revelador, decirlo de alguna forma. es que yo he notado, desde que yo me pasea a Go, como mi lenguaje principal, yo definitivamente he notado que mi mentalidad ha cambiado en la manera en que yo diseño los programas y todos los sistemas en los que he trabajado. Ya no me preocupo, bueno, la palabra no es preocupar, pero ya no me
foco en crear todos estos procesos de polimorfismo, generics y crear estos procesos custom que voy a interceptar la excepción y en base a eso voy a triggear otra cosa. En Go te motiva a que los programas sean muy simples y sean casi secuenciales y esto fue a propósito. Esto a mí me llama la atención que todo
fue con una intención por detrás para que de nuevo no te enfocaras en los tecnicismos en los que te podes ver enredado a veces, sino que te enfocaras en el diseño de cómo solucionar un proceso. que para mí de nuevo, como las interfaces son utilizadas en Go sin entrar en mucho detalle, para mí es mucho más intuitivo hoy y por hoy que utilizar las interfaces
que
como se suele utilizar en otros lenguajes pero es por eso porque ellos con este con eso con ese cambio tan marcado ellos le dan favorecen más un diseño como él decía orgánico que todo vaya fluyendo y bueno hoy en día ya go tiene generics pero de nuevo son cosas que tampoco necesito tan tan seguido son cosas que he utilizado dos que tres veces
más cuando estás diseñando librerías, ⁓ ahí sí son beneficiosas, pero en el día a día de una aplicación de la empresa normalmente no las necesitas y con las interfaces que ya vienen en Go son más que suficientes. que para mí eso es de nuevo, ese es otro punto que quería traer que me parece muy, muy, muy potente de parte de ellos.
Douglas (1:31:10)
Me resalta
mucho Juan y bueno aclarando de que ofrecer una perspectiva técnica alrededor de este punto en específico se sale de mi pago, se sale de mis capacidades como para ofrecer algo realmente productivo, pero fíjate que quiero resaltar bastante que ha sido el patrón desde el inicio cuando hablamos cuando vos comenzaste con esta charla.
los puntos de esta charla de la planeación y todas las cosas y es que ellos parte de ello han tenido en mente a la hora de crear su producto si tomamos el lenguaje como producto en este caso al cliente final si lo queremos llamar de esa manera en el caso de un lenguaje de programación tu cliente final es el programador que lo va a utilizar pero podemos aplicarlo y me gusta como ellos lo hacen
Juan (1:31:57)
Sí, sí, sí, sí.
Douglas (1:32:07)
tienen en mente el cliente final de varias maneras. en algunos casos lo que saben que el programador normalmente quiere y necesita, en que quiere enfocarse. Pero un otro es en lo que ellos saben.
que el programador necesita para ser eficiente aunque el mismo programador no lo sabía o aunque el mismo programador no lo vea así o aunque inicialmente el mismo programador no lo prefiera pero yo han tenido en mente el cliente final desde el principio volverlo más eficiente y lo han logrado
Juan (1:32:29)
Sí.
Douglas (1:32:43)
Y si implementamos eso en nuestras soluciones y productos, vamos a entregar cosas que van a tener un mayor éxito y una mayor aceptación pensando en nuestro cliente final, ya sean nuestro otro departamento o los demás departamentos, otros compañeros o usuarios finales, tanto lo que sabemos que ellos quieren y prefieren como lo que sabemos que van a necesitar que inicialmente no se dan cuenta, pero que una vez que lo empiezan a hacer, el cliente dice, hey.
Juan (1:33:01)
Si
Douglas (1:33:12)
no sabía cómo pude vivir tanto tiempo sin esto. Y hacia ahí deberíamos de apuntarle. Tomando el ejemplo de estos creadores del lenguaje de Go, hacia ahí deberíamos de apuntarle a tener el cliente en mente al momento de trabajar en una solución porque ellos son los que lo van a utilizar. Y si el lenguaje es entretenido, bonito, retante, para mí, si la solución es bonita solo para mí, no va a tener un éxito porque los usuarios
Juan (1:33:28)
Sí.
Douglas (1:33:42)
que son los que en su día a día le van a buscar un uso, si ellos no están recibiendo el valor que quieren, no lo van a consumir y solo va a ser un algo bonito para mí o un grupo pequeño en lugar de algo bueno para las mayorías.
Juan (1:33:58)
No hay que perder de vista exacto cuál es tu público objetivo. Definitivamente sí. Y bueno, creo que podríamos ir cerrando esta plática del día de hoy, Douglas. Solo me gustaría un último punto, remarcarlo. es que, como te decía, mi lenguaje principal es Go. Así que de manera no objetiva, totalmente subjetiva, para mí Go
es el mejor lenguaje que yo puedo utilizar porque como que ya mi mente se acomodo a todas estas reglas y todo este idiomatic que ellos hablan bastante de cómo se hacen los programas en Go sin embargo el mismo creador de Go, él habla que no existe un lenguaje de programación mejor que otro verdad y para eso él lo ilustra de esta manera él menciona
que bueno antes no lo dice que él no lo decía abiertamente pero pues con el tiempo sí go la idea de hacer go era para reemplazar c++ dentro del equipo de google esa era la finalidad de hecho ellos cuando pensaban en un desarrollador de go pensaban en un desarrollador que venía de c++ así que ese era su objetivo final sin embargo
al final sucedió algo que no era lo que ellos esperaban los desarrolladores de C++ no les gusta Go porque no es C++ entonces hoy en día existen los dos equipos por decirlo así dentro de Google están los desarrolladores de Go que él menciona ha ido creciendo y cada vez utilizan más Go en los servidores de backend de Google pero siguen estando los programadores
Douglas (1:35:37)
Sí.
Juan (1:35:58)
de C++. Los dos equipos coexisten, no es necesario, eso no significa que uno es mejor que el otro, ambos son muy buenos lenguajes y ambos te van a...
te van a permitir hacer te van a permitir realizar las soluciones que necesitas para tu empresa, para tu producto, así que para mí me pareció muy humilde de parte de él ya que es el creador o uno de los creadores de Go y al final aceptar que o reconocer que no quiere decir que porque él lo hizo es el mejor todos los lenguajes con tal te permitan hacer algo son buenos lenguajes, claro hay muy buenas cosas que yo
hablar de Go, como te decía, su finalidad es que los desarrolladores sean buenos diseñadores de software, pero ya hablándonos en términos muy prácticos, eso lo puedes lograr con cualquier lenguaje de programación, entonces no hay que perder de vista eso a veces, no tenemos que encerrarnos en fanatismos diría yo, y bueno, el mismo Rob Pike lo admite, no hay un lenguaje mejor que otro.
Todos existen al mismo tiempo dentro de Google.
Douglas (1:37:13)
Sí, me gusta ese pensamiento porque nos hace ver fuera de nosotros mismos y es donde se centra el problema mayormente. Yo a nivel personal, Juan, me considero un muy buen usuario de herramientas, no un genio que las crea. Entonces, eso me hace...
Quiere tener la mente abierta y te puedo poner como ejemplo rapidito, yo si me preguntaba web server yo te voy a recomendar Nginx. En mi opinión es mi favorito, es el que yo uso, tengo un montón de razones para considerarlo más eficiente. Sin embargo, si alguien todavía usa Apache es un buen web server, no estás mal. Yo te pudiera dar un par de sugerencias de por qué moverte de Apache a Nginx. Sin embargo, si querés seguir usando Apache.
Juan (1:37:57)
funciona.
Douglas (1:38:05)
te va a cumplir la función y te la va a cumplir muy bien. No es que la va a cumplir más o menos, se la va a cumplir muy bien. Entonces tengo que ser de mente abierta y recordar de que no soy el único, que aparte de no inventar nada, sólo soy un buen usuario y me recuerda a estos. Me sale por ahí en redes sociales un trend de personas manejando y el texto dice los conductores que van más rápido que yo.
son unos locos, que no tienen respeto ni cuidado. Los que van más lentos que yo son unos mancos, son malos. Y yo dice, por supuesto, manejando la velocidad perfecta y de manera perfecta. Y así es, es nuestra perspectiva. Cuando vamos manejando es real y es nuestra perspectiva cuando estamos en estas cosas. Como son las herramientas que yo uso, me siento cómodo y le encuentro resultados, me parece que todo mundo tiene que utilizarlas.
Juan (1:38:49)
Sí.
Douglas (1:39:02)
Y no es así, no es así. Y creo que es un buen ejemplo de humildad, como decís, de este equipo de creadores de Golan, y que es algo que podemos o deberíamos de poner en práctica. Y yo siempre aconsejo, siempre aconsejo, tengamos mente abierta y tiene que haber demasiada evidencia en contra de algo, pero demasiada evidencia para que seamos rotundos en decir que algo no. De lo contrario, respetemos la preferencia de cada quien.
y mientras sea eficiente y mientras haga el trabajo en tiempo y forma respetémoslo.
Juan (1:39:38)
correcto.
Sí, correcto. Al final del día son preferencias. Como te dije, para mí es mi preferencia el hecho de utilizar Go. Pero eso no me ciega, no me hace estar cegado y ⁓ no quiere decir que te voy a recomendar que solo Go se debe utilizar. Ya ahí me parece mal. Pero bueno. Bien, Douglas, hemos llegado al final de esta plática. Me ha gustado poder hablar un poco de las bondades de este lenguaje que utilizo día
día con
sin nada de ningún fanatismo. igual quería traer esta plática a la mesa porque creo que podemos aprender un poco de los que son unos cracks en el mundo de la tecnología. Tal vez eso nos pega un poco a nosotros. Y bien, eso ha sido todo el día de hoy. Muchísimas gracias a todos. Douglas, no sé si quisieras despedirte de algunas palabras. Algo que quisieras decirle.
nuestra comunidad. amable.
Douglas (1:40:45)
Pues comenzar
a agradecerte a vos Juan, me gustó mucho, disfruté mucho esta conversación, gracias por poner, sacar estos puntos de estas pláticas en el cual podemos como dijiste aprender de estos cracks, yo a nivel personal me llevo una gran enseñanza y cosas a considerar a nuestra audiencia, espero que le hayan también sacado valor a esta conversación y agradecerles como siempre su apoyo y seguimiento.
Juan (1:41:12)
Excelente. Bueno, ya lo tienen amigos, así que muchas gracias por llegar hasta aquí y nos vemos a la próxima. Chao.