DEV Community: Maximiliano Burgos

A course on Automating boring staff

Maximiliano Burgos — Mon, 03 Jun 2024 16:53:08 +0000

I was navigating the confines of Udemy when I came across a Python course that powerfully caught my curiosity: Automate the Boring Stuff with Python Programming. It lasts about nine and a half hours, it's somewhat old, but it captivated me from the first minute.

Above, you can see my certificate, freshly minted and ready to show off on my LinkedIn profile. Many people with too much free time might object with something like, "but the course lasts less than 40 hours, it must be very bad or incomplete." To these types of individuals, I would say that a course is not worth more or less based on the amount of time it takes.

Sometimes there are 4-hour courses that explain everything in a concise and specific manner, and then there are those famous 60-hour courses where 10 are theory and 50 are excruciating practice. Halfway through the course, you realize that you're repeating most of the concepts. It's like those cartridges with 999 games, where 800 were the same but changed Mario's outfit color (yes, I also went through that golden era).

The course is basically a video and practice translation of the book of the same name. Although it is several years old (it uses a version of Python from 2015), it remains a gem to admire and is also great for taking the first steps in Python.

The content

It should be noted that the entire course is in English, but even if you don't have a strong command of the language, you can understand everything that is happening because Al Sweigart (the course creator) constantly executes commands in the console, demonstrating their results.

As for the course content itself, we have different sections covering all the fundamentals of Python:

Control structures
Conditional structures
Functions
Loops
Lists and Dictionaries
String Handling
File Handling
Debugging (it hurts a bit because he does it with the Python Shell)

After explaining the basics, the fun begins: Automation.

Web Scraping
Reading and writing Excel, Word, and PDF files
Sending and reading emails
Automating GUI

It is worth noting that at the end of the GUI chapter, he shows a script that plays a sushi preparation video game by itself.

Conclusions

The main reason I recommend a course that is already several years old is because of its quality. Al Sweigart explains with love and dedication in every line of code he writes. It is designed for people who want to get into development, but it can surprise even experienced individuals. I got it for free during some sort of sale, if you know about it, don't hesitate to mention it in the comments!

El auge y la caída del mercado laboral

Maximiliano Burgos — Thu, 30 May 2024 13:19:49 +0000

Preparen los ojos, que este artículo, por primera vez desde los ultimos 3 años, no fue creado mediante IA. Bienvenidos a la zona de "no soy un Top Voice y me encanta".

Está claro que el mercado se volvió más exigente en los últimos años. Tuvimos una pandemia que cambió las normas del trabajo presencial (por suerte) y generó puestos de trabajo por todos los horizontes, hasta donde no llega el sol.

Durante un período de gracia, los juniors/trainees tenían una entrada fácil; mientras que los seniors éramos dioses del Olimpo. Había fondos para todo el mundo: las startups chicas se potenciaron, y las empresas grandes explotaron.

Pero la pandemia terminó hace tiempo, y como toda buen época dorada, le sigue una devastadora: miles de despidos, acciones en bajada, bootcamps que prometieron oro y gente que llegó tarde al baile.

Al mismo tiempo, los requisitos técnicos empezaron a complejizarse: las empresas necesitan un desarrollador que pueda cubrir el rol de dos o tres personas para abaratar ese presupuesto que se detonó por la fluctuación pandémica.

Mucha gente esta plantéandose cambiar de profesión, otros quieren tomarse un período de tres a seis meses para esperar que el mercado se vuelva a estabilizar.

Como parte de este mar furioso, voy a intentar dar un poco de luz al asunto.

Planes de Acción

En primer instancia, no hay que desesperarse. Todos, repito, absolutamente todos estamos pasando por esta crisis. Si, incluso la gente con empleo perdió la opción de moverse porque el mercado esta parado para todos.

Por supuesto esto son generalidades, porque empleo hay siempre y búsquedas también. Pero esta claro que el gráfico tiende a la baja en los últimos períodos.

Trabaja en tu CV

Por otro lado, es un excelente momento para mejorar el CV. Y no hablo de tocar un par de detalles en la experiencia, sino trabajar realmente en un refactor del mismo. Pueden tomar el mío de referencia, lo copian y le cambian lo que necesiten.

Un consejo de oro que me dió un buen recruiter una vez es el siguiente: crea un CV distinto por cada rol al que postules. Esto no significa mentir en la experiencia, sino remarcar los puntos relevantes al entrevistador que te está contratando.

Casi nadie suele tomar este consejo, porque implica tiempo y dedicación hacia un documento que no implica la obtención del empleo de forma directa. Pero ten en cuenta que buscar trabajo, es un trabajo.

Caso de Uso

Piensa, por ejemplo, en una empresa estilo EdTech: se abre una búsqueda de un nuevo profesor y contenidista.

En tu caso, sos un desarrollador con muchos años de experiencia en Python. Eso está muy bien. Pero tus experiencias dicen cosas como:

Trabajé en el desarrollo de una app en Django que permite hacer compras online. Conjunto con mi equipo, integramos grandes funcionalidades que llevaron al producto a un nuevo nivel.

A ver, no está mal. Pero tampoco es relevante a la búsqueda que aplicaste. Quizá te sirve para una empresa de E-commerce, donde ven este tipo de detalles. Vamos a adaptarla para la búsqueda actual:

He contribuido en la implementación de una app en Django que permite hacer compras online, participando en el desarrollo; así como también en la documentación interna y externa, generando una mayor comprensión del producto a la hora de utilizarlo y seguir expandiendo sus funcionalidades.

Habrás notado que la diferencia radica en las palabras clave: contribuir, documentación, comprensión. Son detalles que busca una EdTech; que sepas comunicar tus ideas y crear contenidos claros, y sobretodo, útiles para quien los consuma.

Calma, que todo llega

En la primer semana que me desvincularon, estaba desesperado: el mismo día, una hora después, activé todas las búsquedas, actualicé mi CV y me armé un plan de estudios entre otras cosas que fui haciendo.

No me tomé un período de descanso, lo que me llevó a enfermarme a la semana siguiente. Esa misma semana, las propuestas seguían sin aparecer, y me empezaban a rechazar las solicitudes sencillas de Jobs en LinkedIn. No llegaban ni a conocerme.

Mi salud se iba deteriorando, y el estrés subía por las nubes. También odiaba leer a los "Top Voices" con sus ideas simplonas y posts generados por IA. Me enojaba ver cómo aprovechaban la ola de despidos para crear sus reflexiones sin profundidad. Nunca deja de sorprenderme el poder de usar párrafos enteros decorados de frases que no transmiten nada.

De hecho, me enojaba más leyendo los comentarios del estilo "excelente reflexión, estoy muy de acuerdo". Así que decidí tomar un poco de distancia de LinkedIn, y centrarme en lo que más amo: desarrollar.

La tercer semana me llovieron las propuestas. Y no fue ninguna de las que envié 🤣. Todas llegaron de recruiters que me encontraron. Hoy no me dan las manos para todos los procesos interesantes que estoy pasando.

Por lo tanto, si estás pasando una situación de "sequía laboral", tranquilo, es una cuestión de tiempo. Pero en el transcurso de ello, no te quedes sentado esperando: trabaja en tu "imagen personal". Oh no! Me he convertido en un top voice sin darme cuenta! 😢.

Pero en serio: tu perfil de LinkedIn, el CV, las rutas de aprendizaje que armes, la gente que vayas conociendo en el camino y todo lo demás, es importantísimo. Quizá encuentres trabajo en un mes o más tiempo; pero todo el proceso de crecimiento que tengas en el medio es la parte más importante de esto.

Las crisis nos destruyen, o nos fortalecen. Si, definitivamente me he convertido en un top voice.

Nos vemos en el siguiente artículo!

Un nuevo podcast ha nacido: En Código

Maximiliano Burgos — Wed, 08 Nov 2023 13:08:50 +0000

"Bienvenidos y bienvenidas a un nuevo episodio", es el inicio de un podcast que está conquistando el oído de cada oyente alrededor del mundo.

"En Código Podcast" es mi espacio personal para hablar de mis experiencias en mis 14 años trabajando en la industria. Un recorrido que incluso va más allá, llegando hasta mis primeros años del colegio secundario, momento en el cual se me ocurrió empezar un sueño que más tarde se transformaría en una vocación: desarrollar software.

Los números hablan solos: en cuestión de una semana, mi podcast ya alcanzó casi 200 reproducciones:

Todo esto explotó gracias a la comunidad r/devsarg en Reddit, por un post donde comenté la existencia de este podcast y mi proyecto con él.

Tuvo una aceptación inmensa, de tal forma que en el último episodio me tomé un tiempo para leer los comentarios más destacados y responder preguntas en vivo.

El futuro del podcast

Mi idea es traer invitados, mejorar el sonido en cada episodio, traer ideas nuevas y abrir debates sobre la industria y el desarrollo de software.

En este momento, "En Código" es un proyecto en pañales, y está empezando a dar sus primeros pasos. Se puede transformar y evolucionar en todo tipo de aspectos, pero lo más emocionante, es que ustedes van a estar ahí, acompañándome en esta gran aventura.

Pueden escuchar "En Código Podcast" en:

En Spotify es donde más estoy atento, por lo cual les recomiendo que si quieren dejar algún comentario, sea en esta plataforma.

También estoy publicando los nuevos episodios en Twitter (o X...).

Disfruten del podcast y ¡Hasta la próxima!

Diario de Python | #18. Un curso de Automatizar cosas aburridas

Maximiliano Burgos — Thu, 06 Jul 2023 20:06:56 +0000

Bueno, quizá no sea la persona más comprometida en esto de publicar a diario o semanalmente. Sepan disculpar nuevamente, pero básicamente estoy haciendo unas tres o cuatro cosas en simultáneo que involucran trabajar y generar contenido para ustedes.

Parte de la culpa, confieso, es del nuevo newsletter que estoy publicando en LinkedIn, el cual los invito a suscribirse. Mi objetivo es traerles nuevos contenidos sobre cosas que voy investigando y aplicando en mi día a día pythonista. Es más acotado que este diario, pero a su vez tiene muchos links, de esos que a ustedes les gusta clickear.

No obstante, insisto en mi plan de no abandonarlos (porque son geniales, cada uno de ustedes, queridos lectores) y trabajar en el contenido de este diario en todos los huecos de tiempo que encuentre.

Sin más preámbulos, vamos a sumergirnos en las historias de mi nuevo viaje. Tomen asiento y disfruten las vistas, porque el destino queda un poco lejos.

Un curso interesante

Estaba navengando por los confines de Udemy cuando me crucé con un curso de Python, el cual atrajo poderosamente mi curiosidad: Automate the Boring Stuff with Python Programming, o en español "Automatizá cosas aburridas en Python". Dura unas nueve horas y media, es algo viejo, pero me conquistó desde el minuto cero.

Arriba pueden ver mi certificado, recién salido del horno y listo para presumir en mi perfil de LinkedIn. Mucha gente con exceso de tiempo libre puede objetar algo como: "pero el curso dura menos de 40 horas, debe ser muy malo o incompleto". Para este tipo de seres, les comento que un curso no vale más o menos por la cantidad de tiempo que implique. A veces hay cursos de 4 horas que explican todo de forma condensada y específica; y otras tenemos esos famosos cursos de 60 horas donde 10 son de teoría y 50 de prácticas insufribles. En la mitad del curso te terminas dando cuenta que estás repitiendo la mayoría de los conceptos. Es como esos cartuchos de 999 juegos, donde 800 eran iguales pero cambiaban el color del atuendo de Mario (si, yo también pasé por esa época dorada).

El curso es básicamente una traducción a modo de video y prácticas de su libro con el mismo nombre. Si bien tiene sus años (usa una versión de Python del 2015), no deja de ser una joya para admirar; y también dar los primeros pasos en Python.

El contenido

Cabe aclarar que todo el curso esta en inglés, pero incluso aunque no tengan un dominio del lenguaje, pueden comprender todo lo que está ocurriendo porque Al Sweigart (creador del curso) ejecuta constantemente comandos en consola, demostrando sus resultados.

En cuanto al contenido del curso en sí, tenemos distintas secciones que abarcan todos los fundamentos de Python:

Estructuras de control
Estructuras condicionales
Funciones
Bucles
Listas y Diccionarios
Manejo de Strings
Manejo de Archivos
Debugging (duele un poco porque lo hace con la Python Shell)

Luego de explicarte las bases, empieza lo bueno: Automatizar cosas.

Web Scrapping
Leer y escribir archivos de Excel, Word y PDF
Enviar y leer mails
Automatizar GUI

Cabe destacar que al final del capítulo de GUI, muestra un script que juega solo a un videojuego de preparar sushi.

Conclusiones

La razón principal por la cual recomiendo un curso que ya tiene sus años, es por la calidad del mismo. Al Sweigart explica con amor y dedicación en cada línea de código que escribe. Esta pensado para gente que quiera introducirse en desarrollo, pero puede sorprender a más de un experimentado en la materia. Yo lo conseguí gratis en alguna especie de rebaja, si la conocen, ¡no duden en escribirla en los comentarios!

Por cierto, estoy preparando unos materiales muy interesantes para el próximo capítulo del diario, ¡estén atent@s y nos vemos en el siguiente!

El desafío de la educación en sistemas

Maximiliano Burgos — Mon, 26 Jun 2023 16:39:24 +0000

Hace un tiempo que no creaba uno de esos artículos de opinión que tanto me pide la comunidad. Vengo trabajando en artículos técnicos, los cuales no suelen tener una llegada tan amplia como los anteriores; dado que somos animales sociales: podemos estar discutiendo semanas sobre la modalidad de trabajo remoto, pero cuando hay que estudiar el comportamiento de una función, no hay debate.

Como Jasnah Kholin en El Archivo de las Tormentas, sueño con reunir mentes brillantes y establecer debates que sean fructíferos para potenciar el progreso y nos permitan trazar los próximos pasos de un futuro que puede ser espectacular o lamentable en partes iguales.

Este tipo de debate es el que traigo a mis clases, y a veces, por al menos un par de días, logro generarlo. Sentarse sobre un algoritmo y entender por qué las cosas funcionan de determinada manera, es solo la meta. El verdadero gozo está en el problema: los métodos, las suposiciones, la conjetura o cualquier herramienta que nos permita avanzar hacia una solución. En este camino del proceso cognitivo es donde se puede potencial el verdadero aprendizaje.

Por eso habrán notado que muchos profesores no entregan una solución, sino que esperan a que el alumno logre indagar en la misma. Preparan el camino y dejan que sus estudiantes lleguen a la conclusión por ellos mismos.

Y esto, mis queridos lectores, es el desafío de la educación.

Procesos educativos

Los profesores nos dividimos en dos categorías básicas que me acabo de inventar por el beneficio de la trama:

Académicos: son los que estudian una carrera docente y se dedican puramente a enseñar.
Informales: son los que se especializaron en un area por años, y tienen experiencia tanto en el campo de la aplicación como en la educación; pero no estudiaron una carrera docente.

Yo entraría en el tipo informal, aunque digamos que sí hice un par de cursos para elaborar estrategias académicas y entender cómo transmitir el conocimiento hacia un estudiante.

Mucha gente cree que puede enseñar sólo porque sabe de un tema, y esto es un grave error: así como cada persona es única y se distingue por sus propios aspectos de su personalidad, también lo es su método para asimilar conocimientos.

La palabra "asimilar" es extremadamente importante: no somos máquinas que absorben información. Nuestra memoria tiene un límite, y el cerebro trabaja mediante "atajos" para evitar un consumo elevado de energía. Si, efectivamente nuestra mente optimiza la información, la "indexa" todo el tiempo.

Por esta razón, cuando hablamos de asimilación, nos referimos a la acción de transformar determinada información del exterior y procesarla con nuestros conocimientos actuales. Así funcionamos desde que tenemos uso de razón: la mente relaciona conceptos y crea mapas de comprensión. Entonces cuando recurrimos a la memoria, podemos hacer uso de palabras claves que nos lleven a recuerdos almacenados más complejos. Como ven, todo lo que inventamos en materia de informática no es más que una simulación de nuestros procesos cognitivos.

El problema

Con todo lo que expuse anteriormente, puedo definir que, para mi, enseñar es garantizar las herramientas necesarias para que el proceso de asimilación de conocimentos se genere de forma eficiente y correcta.

El problema radica en que cada persona aprende de maneras distintas y viene con conocimientos anteriores que son (a veces, o casi siempre) muy distintos entre alumnos.

No es lo mismo enseñar a programar a un estudiante de universidad que uno de secundaria. Además, la edad influye de forma significativa: a los 20 años tenés una energía y un potencial de aprendizaje mucho más amplio que a los 30. Mucha gente insiste en que estudiar de joven es lo más conveniente, y tienen razón: asimilamos mucho más conocimiento porque nuestra sinapsis es más eficiente.

Siempre se trata de lo mismo: aprender lo suficiente en una edad temprana y así optimizar los procesos cognitivos en el futuro. Sobre esto, quiero aclarar un punto crítico al respecto: mientras lees este artículo y tenes, supongamos, 30 o 40 años, debes estar conteniendo cierto enojo o desesperanza. Dejame explicarte que empezar a aprender algo de cero en tu edad, es perfectamente posible. La diferencia quizá radique en que simplemente te cueste un poco más que a personas más jóvenes. Pero aún así, incluso aunque no exista una relación directa, muchos conocimientos que ya tenés van a ser aplicables a tus nuevos estudios, sea sistemas u otra rama.

Volviendo al problema inicial, mi experiencia como profesor me permite saber si una clase me esta siguiendo en el contenido que estoy exponiendo. Soy consciente de que tengo un tiempo establecido donde voy a explicar algo; y que cada alumno va a tener otro tiempo completamente distinto en el que va a entender dicho concepto.

Entonces, haga lo que haga, me encuentro con una clase que aprende con cierta disparidad: algunos saben mucho, otros pocos. En la búsqueda de una solución, he creado estrategias que hoy día sigo poniendo en práctica para equilibrar la balanza.

Ejercitación y liderazgo

Al ser un profesor de tipo informal, conozco el terreno laboral. Esto afecta a mis clases de forma positiva: yo no veo un aula, sino una oficina, un equipo de trabajo. Con esta idea en mente, cada ejercicio en realidad es una tarea de proyecto; por lo cual los alumnos ven un objetivo claro y tangible.

Esto implica que a la hora de proponer un ejercicio, no se aplica el típico modelo individualista de resolución "secreta" y que genera copias y plagios entre alumnos. En mi formación, yo fomento el trabajo en equipo. Si un alumno va más lento que otro, se potencia al trabajar con alguien que tiene mayor velocidad. Se crea lo que llamo una retroalimentación de conocimientos. Entre ellos aprenden mucho más que rompiéndose la cabeza solos.

Además de mejorar la balanza del conocimiento general, también empiezan a crearse líderes que pueden sacar el máximo potencial de cada alumno, porque trabajan sobre la idea de sacar un requerimiento adelante sin recurrir al individualismo de ser "el mejor alumno".

Remover la idea de reprobación

En mis clases no existe la "reprobación" como tal. Por supuesto, evalúo cada alumno y tiendo a ser más exigente que otros profesores en general; pero transmito la idea de "llegar al aprobado". Esto significa, pedirles cambios hasta que las cosas estén bien hechas.

Siento que reprobar es rechazar: cuando estudiaba en la universidad y no aprobaba un parcial, esto representaba una derrota. Me separaba de otros compañeros que si aprobaban y me resultaba frustrante. En mi rol como formador, quiero evitar este tipo de efectos negativos.

A fin de cuentas, en un trabajo no te "reprueban" un requerimiento, sino que te "piden cambios" para llegar al objetivo planteado. Este es exactamente el funcionamiento de GitHub y sus Pull Requests.

Romper la brecha profesor - estudiante

Este probablemente sea un punto de inflexión en muchos de mis colegas: un profesor que pretende la igualdad, perdería el respeto por falta de jerarquía.

En mi caso personal, nunca me llevé bien con el asunto de las jerarquías: ya aprendimos leyendo 1984 que la obediencia deja secuelas y afecta las libertades personales. El progreso se ve pausado y se enseña a través del miedo. Esto es eficiente para crear sociedades alienadas; y si consideramos que yo adoro el pensamiento crítico, esto es completamente incompatible.

La cuestión es que podemos evitar la jerarquía y aún así tener ese respeto. Por supuesto, siempre hay gente que se quiere aprovechar de esto y romper el clima, pero se puede charlar de forma individual (o incluso grupal) para subsanar este comportamiento, que probablemente venga de un problema más profundo que la clase en sí misma.

Si rompemos la brecha, desaparece el nerviosismo: un alumno no tiene miedo a preguntarle a su par acerca de un problema que encontró. Lo mismo se puede aplicar al profesor si lo ve como una persona accesible, y no una figura de autoridad inalcanzable.

De hecho, si aplicamos bien la regla, podemos obtener admiración. La clave está en mantener el sentido de la autoridad implícita: los estudiantes saben que tienen que seguir tus consejos y cumplir con las entregas en clase. Si tenés que aclararlo, es posible que empieces a abrir esa brecha y separarte de la estrategia inicial que te acabo de plantear.

El ego es peligroso

Las personas más atrayentes en la sociedad son aquellas que no se andan regodiando de sus logros, o hablan de si mismas todo el tiempo. Irónicamente, la mayoría de la gente alza su ego al cielo y demuestra que su opinión es increíble y nadie lo pensó antes.

Es cuestión de entrar a LinkedIn y encontrarse recomendaciones de "gurús" que te van a explicar cómo vivir tu vida; gente convencida de que el trabajo en X tecnología es lo único que genera dinero; personas que emiten una opinión y cuando querés armar debate porque expresas oposición, te responden con "no comparto, pero es tu opinión".

Me exaspera este intento de alzar imperios basados en visiones subjetivas. Es un mar de dogmatismo que no ayuda a nadie; y confunde a mucha gente que luego lleva esas ideas como una nueva religión.

El pensamiento crítico que fomento se basa en cuestionar las ideas y formar las propias. Pero si vos expresas una opinión y yo te doy un contra argumento, espero un debate.

Por supuesto, también afecta al sector docente. Muchos profesores creen que los métodos por los cuales ellos aprendieron son los mejores; y esto es muy lógico: les resultaron eficientes y lo quieren aplicar al resto. Pero a su vez, es erróneo: enseñar es como aplicar el método científico. Es partir de una hipótesis y experimentar hasta llegar a convertirlo en una teoría que quizá sea derribada en el futuro.

Debemos reconciliarnos con la idea de que todo esta sujeto al cambio. No casarse con un método de enseñanza, sino ponerlo todo a prueba. Rechacemos el dogmatismo y abracemos el pensamiento crítico.

La gente no lee

Si llegaste a esta parte de mi artículo leyendo todo, te felicito, pertenecés al 5% de la población mundial que lee. El foco de atención cada año es más reducido; y sin una obligación, la gente no lee casi nada en general.

Entiendo que puedo parecer un exagerado en este momento, pero intenta hacer la prueba: compartí este artículo en tus redes y fijate cuántos opinólogos van a darte sermones por el título sin entrar al artículo. Te invito a comentarme el experimento.

En una clase pasa algo similar: si generas un manual que sea opcional, el famoso "contenido complementario", menos de la mitad lo va a leer voluntariamente. Muchos probablemente no lo abran. Esto se debe a que nos atrae más lo visual que lo textual.

Por eso las publicidades funcionan: te invaden con colores vivos y atenuantes, acompañados de una frase muy corta, al estilo "me encanta" de McDonalds. En NetFlix entras al contenido de una película o serie porque reproduce el trailer previamente, pero seguramente no leas la descripción del costado.

Nos encantan los estímulos visuales, fuimos programados así por defecto. Entonces como profesores deberíamos poder jugar con esto, no luchar una guerra que no podemos ganar. Una forma que personalmente me gusta y estuve viendo en LinkedIn, es armar una serie de slides (diapositivas) estilo "apuntes de clase" con muchos colores y con una tipografía que simula la escritura manual.

Este tipo de contenidos alienta a leer, mirar gráficas, y aprender en el proceso. Te lo explico con gatitos es el claro ejemplo de estímulo visual atrayente. Se explican conceptos con un texto corto y gatos preciosos en pantalla. Cumple su función: enseña y entretiene.

Conclusiones

El desafío de la educación nos invita a mantenernos despiertos como profesores: debemos buscar soluciones constantes al trabajo de introducir conocimientos nuevos en distintos estudiantes. Trabajar en el proceso de asimilación y automatizar tareas (como la retroalimentación) es parte de nuestro trabajo diario.

Diario de Python | #17. un paseo por Flake8

Maximiliano Burgos — Wed, 21 Jun 2023 16:36:30 +0000

Antes de preparar una clase, investigo a fondo los temas, incluso aunque ya los conozca. Siempre se pueden encontrar nuevas formas de hacer y pensar las cosas. Por eso cuando empecé con Python y me crucé con la PEP8, descubrí que para encontrar las formas correctas no había que irse muy lejos. Esto fue lo que me llevó a encontrarme con un corrector duro, pero justo, llamado Flake8.

¿Qué es la PEP8?

La PEP8 es una guía que indica las convenciones estilísticas a seguir para escribir código Python. Se trata de un conjunto de recomendaciones cuyo objetivo es ayudar a escribir código más legible y abarca desde cómo nombrar variables, al número máximo de caracteres que una línea debe tener.

De acuerdo con Guido van Rossum, el código es leído más veces que escrito, por lo que resulta importante escribir código que no sólo funcione correctamente, sino que además pueda ser leído con facilidad.

Fuente

Por lo tanto, tenemos un documento que nos indica cómo escribir nuestro código de forma convencional y legible; sin tener que estar rompiéndonos la cabeza o generando nuevos estándares en el proceso.

Veamos un ejemplo del mismo documento. Aquí tenemos las formas correctas de trabajar con funciones:

# Aligned with opening delimiter.
foo = long_function_name(var_one, var_two,
                         var_three, var_four)

# Add 4 spaces (an extra level of indentation) to distinguish arguments from the rest.
def long_function_name(
        var_one, var_two, var_three,
        var_four):
    print(var_one)

# Hanging indents should add a level.
foo = long_function_name(
    var_one, var_two,
    var_three, var_four)

Y aquí las formas incorrectas:

# Arguments on first line forbidden when not using vertical alignment.
foo = long_function_name(var_one, var_two,
    var_three, var_four)

# Further indentation required as indentation is not distinguishable.
def long_function_name(
    var_one, var_two, var_three,
    var_four):
    print(var_one)

Los comentarios explican las razones de cada implementación; y podemos observar que las buenas prácticas generan código más limpio y legible.

Otro ejemplo interesante, las importaciones:

# Correct:
import os
import sys

# Wrong:
import sys, os

# Correct:
from subprocess import Popen, PIPE

Cuando se trata de módulos separados, debemos agregar un "import" por cada uno separado por saltos de linea. Salvo que tengamos un paquete, el cual deberá importar una serie de módulos que esta vez sí serán escritos en la misma linea.

Podría armar un artículo kilométrico sobre cada buena práctica que figura en la PEP8; y seguramente más de uno debe estar preocupado por la cantidad de cosas que debe tener en cuenta a la hora de escribir un buen código. No se preocupen, porque existe una solución.

¡Flake8 al rescate!

Flake8 es un linter de tu código. Se asienta sobre la PEP8; y esto lo convierte en la mejor opción a la hora de ahorrarnos trabajo intentando seguir las buenas prácticas desde el método tradicional.

Implementamos un proyecto sencillo en Python, arrancando el entorno (VirtualEnv) en la carpeta del mismo (desde la terminal):

python -m venv venv

.\venv\Scripts\activate

Luego instalamos la dependencia de flake8

pip install flake8

Ahora vamos a escribir un script muy sencillo, pero con todas las malas prácticas que podamos 🤣:

import os, sys

name="Max" 

if name=="Max":
    print("ok")
else:
    print("wrong")

Me duelen un poco los ojos. Bastante. Pidámosle a flake8 que nos ayude a mejorar este...script:

flake8 --exclude=venv

Agregamos el comando "exclude" para que evite evaluar el código de la carpeta "venv". Parece mentira, pero éste tiene muchísimos warnings y no nos servirá solucionarlo. Corremos el comando y nos devuelve esto:

En un vistazo podemos notar que primero nos indica el archivo implicado (main.py) y luego la línea y la columna de código (2:1). Luego nos indica un código (F401) que podemos buscar en este listado de reglas de la PEP8 si hace falta para entender a que hace referencia esta advertencia. Luego nos da una descripción del error: 'os' imported but unused. Tomé como ejemplo la primer linea para explicarlo porque todas las demás siguen el mismo patrón.

Analicemos cada error, punto por punto:

F401: Las dependencias "os" y "sys" se importaron pero no se utilizan.
E401: Hay múltiples imports en una sola línea.
E225: El operador del condicional no tiene espacios.
W291: Luego de la variable name, hay un espacio adicional.
E225: No hay espacios entre la variable name y su asignación.
W292: No hay un salto de línea al final del script.

Gracias a Flake8 podemos notar todos los warnings de una sola pasada. Vamos a arreglar el script y correrlo de nuevo. El objetivo es que nuestro comando no arroje ningun error, por lo tanto quede vacío. El código quedará así:

name = "Max"

if name == "Max":
    print("ok")
else:
    print("wrong")

Pueden notar un cambio muy positivo, desde la legibilidad del código hasta su acotamiento. Si nos mantenemos en los principios del PEP8 y utilizamos linters, podremos seguir las buenas prácticas sin apenas despeinarnos.

Conclusiones

Soy consciente de lo duro que es desarrollar correctamente: a veces la falta de tiempos y la planificación nos impulsan a resolver todo antes que dejarlo bonito. No obstante, hacer las cosas correctamente desde el principio, nos va ahorrar tener que trabajar el doble para arreglarlas en el futuro. Una guía de estilo como PEP8, conjunto de un buen linter como Flake8, nos facilitan la vida a corto, mediano y largo plazo.

Si quieren ver un ejemplo más real aplicado, pueden analizar este commit que hice a mi repositorio de prácticas en Python, donde apliqué Flake8 y cambié muchísimos scripts.

Cookie Clicker en Godot

Maximiliano Burgos — Thu, 08 Jun 2023 17:52:10 +0000

Antes de leer este artículo, te recomiendo pasarte por uno más introductorio donde explico las razones que me llevaron a elegir Godot como motor de juegos favorito:

Viaje al centro de Godot

Maximiliano Burgos ・ Jun 5 ・ 8 min read

#spanish #godot #gamedev #devjournal

Sin mas dilación, ¡comencemos!

Todo empieza con una galleta

Para entender Godot en su máxima expresión, decidí volver a replicar el clon de Cookie Clicker que ya había hecho en otras tecnologías.

Este motor funciona por escenas, pero a diferencia de Unity, cada scene es como un objeto en si mismo, con sus propiedades y métodos. Empecé por armar una escena "Cookie" que tiene como nodo principal un Button y dentro un TextureRect, el cual contendría la imagen png de la galleta:

Esto puede parecer extraño, pero tendrá sentido en los próximos párrafos. Al botón le armé un script para manejar los eventos del click. Vamos a ver paso a paso qué hace cada parte.

@onready var cookie_texture_rect: TextureRect = $CookieTextureRect

Almaceno una referencia al TextureRect para no tener que llamarlo cada vez que lo necesito.

func _ready() -> void:
    pressed.connect(_on_pressed)
    button_down.connect(_on_button_down)
    button_up.connect(_on_button_up)

Este método es el primero que va a correr cuando se instancie el nodo. Las señales (signals) pressed, button_down y button_up son los eventos que nos permitirán controlar estados en el botón.

Con el método "connect" podremos crear un trigger con eventos creados y controlados por nosotros:

func _on_button_down():
    update_scale()

func _on_button_up():
    update_scale()

func _on_pressed():
    Globals.cookie_counter += 1

El método _on_pressed va a dispararse en el momento que se presione el botón. En este caso utilizamos una variable global definida en un archivo llamado "globals.gd":

var cookie_counter: int = 0:
    set = set_cookie_counter

signal cookie_counter_changed(new_value: int)

func set_cookie_counter(new_value: int):
    if cookie_counter != new_value:
        cookie_counter = new_value
        cookie_counter_changed.emit(new_value)

En este caso podemos acceder a cookie_counter, como también modificarlo. Cuando cambia de valor, se llama al método setter set_cookie_counter, el cual verifica que no se trate del mismo valor; y luego de cambiarlo, llama a una señal "cookie_counter_changed". Esto lo hacemos porque en otras partes del juego estamos esperando que esta señal cambie para reescribir su valor en pantalla. De esta manera nos ahorramos tener que escribirlo constantemente, como podría ser mediante el uso del método "_process" que se ejecuta frame a frame.

Animación del click

En el momento en que se presiona el botón, se llama a las señales "button_down" y "pressed". Cuando se suelta el click, se invoca "button_up". Para animar el botón, utilizo los métodos "_on_button_down" (disparador de button_down) y "_on_button_up" (disparador de button_up). Estos comparten la llamada a un método "update_scale", el cual posee la siguiente lógica:

func update_scale() -> void:
    var pressed_scale: Vector2 = Vector2(0.7, 0.7)
    var normal_scale: Vector2 = Vector2(1, 1)
    animation_tween = create_tween()

    if button_pressed:
        animation_tween.tween_property(cookie_texture_rect, "scale", pressed_scale, 0.2).set_trans(Tween.TRANS_SINE)
    else:
        animation_tween.tween_property(cookie_texture_rect, "scale", normal_scale, 0.2).set_trans(Tween.TRANS_SINE)

Mi intención era animar a cookie_texture_rect (contenedor del asset de la galleta) para que se reduzca un 30% de su tamaño (vector 0.7 en x) al hacer click en el botón. Utilizo el método create_tween(), el cual me permite armar una animación con un estilo TRANS_SINE, el cual me permitirá cierta suavidad en la transición de una escala de 0.7 a 1 (pressed_scale a normal_scale y viceversa).

En el caso de "button_pressed", simplemente se trata de una variable booleana (propia del botón) que devuelve el estado del mismo.

La tienda

Armé otra escena para crear la tienda (shop) que listará las mejoras y permitirá comprarlas para aumentar los CpS (cookies per second). Utilicé un todo ItemList y le asigné un script. En el mismo establecí una lista de mejoras en un array de diccionarios:

var shop_list = [
    {
        "name": "Click",
        "cost": 1,
        "give": 1,
        "method": "M"
    },
    {
        "name": "Cursor",
        "cost": 1,
        "give": 1,
        "method": "A"
    },
(...)
]

A continuación, detallo cada uno de los atributos:

name: nombre de la mejora.
cost: costo en cookies de la compra.
give: cantidad de cookies por segundo que brinda.
method: La letra A indica "Auto" y M sería "Manual". En el primer caso, el atributo "give" aplica a CpS, mientras que en el segundo es el valor por click manual incrementable.

Luego recorrí dicha lista y cargué un único asset para los iconos de cada item:

func _ready():
    var icon = ResourceLoader.load("res://granny.svg")

    for item in shop_list:
        var name_format = "%s | Valor: %s cookies | Genera %s CpS"
        var item_name = name_format % [item["name"], item["cost"], item["give"]]
        add_item(item_name, icon)

Finalmente armé un trigger para la señal "item_selected":

func _on_item_selected(index):
    var item = shop_list[index]

    if Globals.cookie_counter >= item["cost"]:
        Globals.cookie_counter -= item["cost"]
        Globals.cookies_per_second += item["give"]
    else:
        print("Galletas insuficientes!")

La función se trae el índice de la lista, el cual equivale al índice de mi array; por lo cual obtengo el item y luego valido que la cantidad de cookies sea mayor o igual al costo del item en si. Luego resto su valor (cost) y también aumento otra variable llamada cookies_per_second, la cual podemos encontrar en globals.gd nuevamente:

var cookies_per_second: int = 0:
    set = set_cookies_per_second

signal cookies_per_second_changed(cookies: int)

func set_cookies_per_second(cookies: int):
    if cookies_per_second != cookies:
        cookies_per_second = cookies
        cookies_per_second_changed.emit(cookies)

Como ven, la lógica es muy similar a la variable global cookie_counter.

La escena principal

Ahora que tengo la escena de la tienda y la galleta, las instancio en mi escena principal:

Utilizo un nodo VBoxContainer para manejar un label que reflejará el estado de las galletas y la instancia de la escena cookie. También tengo otro nodo igual para el título de la tienda y la lista de mejoras. Pueden notar que se encuentra vacía porque se llena en tiempo de ejecución. Finalmente tengo un HBoxContainer que contiene a los dos VBoxContainer y genera este acomodamiento horizontal de columnas.

Luego tenemos un nodo Timer que contiene un script muy sencillo para actualizar cookie_counter por segundo:

func _on_timeout():
    Globals.cookie_counter += Globals.cookies_per_second

El método "_on_timeout" esta conectado a una señal llamada "timeout", y se ejecuta una vez por segundo dado que lo establecimos en los parámetros del nodo (Wait Time):

Como el atributo "Autostart" esta activo, el contador inicia apenas se activa el nodo Timer, lo cual ocurre cuando nuestra escena principal arranca, y esto es en el momento en que empieza a ejecutarse nuestro juego.

Conclusiones

Si llegaron hasta aca leyendo todo el artículo, los felicito por haber soportado el nivel de tecnicismos que utilicé en cada apartado. Soy consciente de que puede ser muy pesado para mucha gente, pero esto es la naturaleza de desarrollar un videojuego.

No obstante, Godot simplifica y organiza como ninguno, por lo cual una vez entienden las bases y mantienen las buenas prácticas, todo se vuelve mucho más ágil.

Es muy probable que me dedique a sacar más artículos sobre videojuegos y este engine, así que si disfrutaron de este contenido, ¡compártanlo para que llegue a más gente!

Mis seguidores crecen, la comunidad toma fuerza

Maximiliano Burgos — Wed, 07 Jun 2023 16:23:23 +0000

Hoy traigo una gran noticia sobre el crecimiento constante de mi blog:

¡Ya son 706 seguidores! Quiero agradecerles enormemente por este gran logro, el cual se nota en las visitas que tiene cada artículo. Por eso, les voy a comentar tanto para los nuevos como los más veteranos, la historia detrás de estas publicaciones y el futuro del blog.

Bienvenidos al Maxiverso

En principio la idea era fusionar mi nombre con la palabra "universo", pero suena horrible. Sigo trabajando en el tema, no me reporten.

Este blog es, en realidad, la continuación de un proyecto que venía trabajando en Medium, otra plataforma de blogging excelente pero con limitaciones para aquellos que quieren consumir contenido gratuito.

Previo a DEV.to, desarrollé mi propio blog con su respectivo dominio y duró unos meses en la nube. Pero no tuvo mucho éxito: me llevaba mucho trabajo mantenerlo, y el tráfico era apenas aceptable. Además pagaba mes a mes un servicio de AWS llamado LightSail, porque tenía un WordPress montado y era la solución más económica. Pero aportar a la comunidad en tiempo y dinero sin recibir nada a cambio, era una locura.

Así llegué a esta increíble comunidad, DEV.to. Ya la tenía en el radar hace un tiempo, pero me preocupaba no poder establecer mi ecosistema porque no existían secciones como tal. Luego de meditar y rearmar mi estructura de cada artículo, migré todo lo que consideraba relevante de Medium a DEV.to.

Series, muchas series

Esta plataforma tiene dos características que, bien utilizadas, pueden mejorar cualquier artículo que escribas: los tags (o etiquetas) y las series.

En el primer caso, se trata de tags como los que utilizamos en Twitter para relacionar un tema con nuestro tweet, pero aquí es mucho más importante. Los tags de DEV.to son las categorías en si. Esto implica que si estás escribiendo un artículo sobre Python, deberías utilizar el tag correspondiente para aparecer en la sección de este lenguaje. Por otro lado, los que escribimos en español (dado que la comunidad fue pensada inicialmente para contenido en inglés) tenemos nuestro propio tag. Podés verlo aquí.

En el caso de las series, se trata de una forma de agrupar artículos por "episodios". Imaginalo como un podcast, donde cada entrega sea un capítulo dentro de Spotify. Esto es lo mismo, y fue la razón que facilitó toda la migración de las categorías de mis artículos.

Mis series más importantes

A este punto quería llegar: a medida que fui creciendo en contenido y gente interesada en el mismo, armé unas series especializadas en cada tema:

Opinión: Se trata de un conjunto de artículos que cuentan experiencias que tuve en sistemas y en mi vida personal; pero siempre desde la mirada técnica.
Diario de Python: Los diarios son mis series favoritas, porque me permiten expresar todas las sensaciones que voy experimentando a medida que aprendo algo nuevo o emprendo proyectos interesantes. En este caso, se trata de Python.
Diario de Kotlin: Probablemente no actualice esta serie, porque pertenece a una época donde trabajaba activamente con Android y Kotlin. No obstante, lo dejo como un buen material de estudio para los que quieran empezar en este mundo.
Patrones de Diseño: Esta serie se centra en explicar distintos patrones de diseño aplicados desde la teoría. Es probable que en el futuro, cuando empecemos las prácticas, se realicen en Python.

Conclusiones

Mi idea central con este artículo es empezar a darle cierta forma al ecosistema que estoy armando en torno al contenido generado. Pero también quiero que vean todo lo que ya existe, porque se que los artículos nuevos tienden a hacerle sombra a los viejos con el tiempo. Quiero generar cierta atemporalidad, dado que todos mis artículos se pueden leer en cualquier momento del año, o en su defecto, de la década.

¡Nos vemos en los siguientes!

Viaje al centro de Godot

Maximiliano Burgos — Mon, 05 Jun 2023 15:33:26 +0000

Antes de empezar, debo aclarar que el nombre del título hace referencia al libro Viaje al centro de la Tierra de Julio Verne.

Punto de inflexión

El mes pasado estuve trabajando a fondo en desarollar mis habilidades en React, Tauri, Rust, entre otros. El clicker de pre-proyecto salió bien, pero cuando me senté a armar el proyecto real (CraftClicker) empecé a notar ciertas carencias.

La idea de progresión en mi clicker iba de la mano de construir un pueblo, consecuencia de vender recursos y crafteos y comprar edificios.

En el momento en que me puse a trabajar en el proyecto, me di cuenta de la complejidad de capas que necesitaba: generación de terrenos, tilesets, drag and drop, entre otros tantas características que me llevarían a la locura si intentaba trabajar sobre un sistema de etiquetas divs y componentes en React.

Este fue el resultado al que llegué antes de desistir de la tecnología:

La barra de abajo permitiría comprar edificios nuevos, mientras que arriba tendría la ciudad (o pueblo) que podría editar a mi antojo.

Luego de meditar un buen tiempo, me di cuenta que iba a luchar más por crear componentes que no fueron pensados para juegos que desarrollar el proyecto en sí. Algunos pensarán: muchos desarrolladores crearon herramientas de cero en lenguajes que no estaban pensados para eso, y les fue bien. Lo cual es cierto, pero no todos estamos dispuestos a dedicar un volumen tan alto de tiempo y energía a una tarea de esa magnitud.

Ya con la decisión tomada, ahora debía trazar el nuevo camino: no volvería a Unity porque nunca me gustó su sistema de componentes y la facilidad con que un proyecto puede terminar volviéndose muy dificil de mantener por las libertades de poner scripts en cualquier lado. Así que la ruta final sería Godot.

Oh dios mío, no de nuevo

No es la primera vez que me lanzo a los brazos de Godot Engine buscando refugio en una lluvia constante de motores que aparecen cada año. La variedad es buena, pero puede ser un infierno si queremos probar todo. Lo digo, especialmente, por experiencia propia.

Marian, uno de los dev en Godot más experimentado que conozco (al momento de la salida de esta publicación está trabajando en un emulador de NES) fue víctima de soportarme noches enteras armando prototipos de juegos que nunca vieron la luz. Recomiendo seguirlo porque nunca conocí una persona con más paciencia para enseñar y ayudar.

Por eso cuando le expliqué la semana pasada que volvía al ruedo, estoy seguro que por dentro pensó exactamente esto:

En este momento muchos se estarán preguntando: ¿pero por qué lo dejaste antes? La respuesta es confusa, incluso para mí: nunca me llevé bien con el apartado artístico y me desmotivaba desarrollar algo mediocre. Conozco mucha gente que le pasa, incluso tengo un amigo que contrata diseñadores que le hacen todos los assets antes de empezar incluso el prototipo, porque cuando desarrolla se motiva al ver que su forma estética sigue los lineamientos que tenía en su idea original.

Por otro lado, en el pasado no me convencía GDScript (lenguaje de programación basado en Python, oficial del motor) porque justamente no sabía nada de Python. También tenía cierto rechazo a la física y las matemáticas, lo cual fue cambiando cuando me metí con análisis de datos.

¿Pero qué cambió ahora?

Bueno, en principio hay un motivante financiero: compré la licencia de 100usd en Steam ($20.000ars en su momento), lo cual como argentino me duele bastante. Esto implica que si no publico un juego, habré perdido dinero.

Luego está el legendario objetivo incumplido: desde que empecé a escribir mis primeras líneas de código, quiero desarrollar juegos. Las vueltas de la vida me llevaron a estudiar y trabajar en otros ámbitos, pero como expliqué en otro artículo, en cada tecnología nueva que asimilo a mi vida, intento crear uno o más videojuegos. Pero siempre tuve cierto miedo a sacar algo real: los bugs, las mejoras constantes, los consumidores que a la mínima te bajan la calificación si algo no les gusta, el marketing y la publicidad, el tiempo invertido y muchos otros factores de peso, eran suficientes razones (o excusas) para evitar publicar algo.

Y después falleció Lupe, mi chihuaha de 2 años de edad. Y fue la tragedia de lo cambió todo.

La vida es una función rand() con seeds aleatorias

Lupe era la perra más saludable que pueden imaginar. Se dedicaba a romper prejuicios como que los chihuahas no podían subir escaleras; comía de todo y no se enfermaba; tenía un carácter amigable y nunca destrozó nada.

Pero un día, tiramos una palmera de esas enanas que vienen de Japón, y cayeron unas semillas que nunca se podían acceder, porque pertenecían a la parte de arriba, donde crecían sus nuevas hojas. Resulta que su ingestión provocaba necrosis y fallos digestivos. Y Lupe, como siempre, se llevaba cualquier cosa que pareciera un juguete a sus refugios repartidos por toda la casa.

Y, como quien tira un dado, ese evento tan fortuito, tan aleatorio, se llevó a nuestra cachorra de 2 años de edad (los chihuahas tiene una esperanza de vida de 14 años). Un martes estaba jugando con ella, y al siguiente estaba usando una pala, con una caja al lado.

En una semana, se había perdido la luz de la casa. En algún lugar, se ejecutó una función rand() y nos tocó perderlo todo.

Ahí fue cuando tuve una especie de revelación: me estoy preocupando por cosas que no puedo controlar, además de que realmente no tengo nada que perder. Cualquier asunto, incluso el trabajo, pasó a segundo lugar. El grado de importancia y prioridad de todo lo que no estaba relacionado con ese momento que estaba pasando, decrementó completamente. Porque si el universo funciona por eventos aleatorios, no existe algo como una balanza divina. No hay un sistema de castigos y recompensas; y probablemente ni siquiera exista un sistema como tal. Intentamos dar sentido a cosas que no lo tienen, y creamos nuestro propio sistema con sus reglas. Mi objetivo final fue destruir toda la estructura, y empezar de nuevo.

Entre la planificación y la locura

Asumir que la mayoría de mis preocupaciones carecían de valor, me quitó el miedo a emprender proyectos. Quizá lance el juego y no tenga éxito; pero no importaba porque lo había lanzado. Mis logros, en realidad, se establecían bajo mi criterio: publicar el curso de Python con Django fue un logro en si mismo, aunque la gente no lo compre tanto. Disfruté el proceso de hacerlo sin pensar tanto en el futuro del mismo.

Por lo tanto, publicar un videojuego pasó a ser un objetivo obligatorio: otra forma de demostrarme a mi mismo que no importaban los resultados, sino el hecho de lanzar este, y quizá otros juegos más. Cerrar el ciclo del "quiero y no puedo".

Mi plan inicial mutó constantemente, a tal punto de que ya lo estoy considerando como una parte más del proceso: ahora el clicker pasó a ser un RPG de un hombre que debe ganar dinero desde cero (a tal punto de dormir en los bancos de la plaza) hasta volverse un magnate que tiene varias empresas a su cargo. Planifico como un loco porque un cambio puede significar la reconstrucción casi completa de la estructura. ¿Por qué? porque puedo, y si mañana perezco de una forma extremadamente aleatoria (algo como atragantarme con un te de burbujas en el Barrio Chino de Belgrano, CABA), todo valió la pena porque hice lo que quería desde el principio, sin restricciones.

Etapa de aprendizaje

Creo haber entrado en esta zona más de tres o cuatro veces en lo que va del año, pero prometo que esta vez será definitivo. Para aprender Godot (ya en su versión 4), empecé con este youtuber que descubrí y no puedo dejar de ver en cada video que lanza:

Me gusta como enseña, y la verdad tiene una calidad altísima que envidio sanamente (o no) en cada uno de sus videos.

Por otro lado, decidí armar el mismo clon de Cookie Clicker que hice en React, pero en Godot. Les dejo el repositorio que armé y sigo manteniendo, pero seguramente en el próximo artículo explore más a fondo cada detalle del armado. Nuevamente, gracias Marian por despejarme las dudas de los nodos correctos para crearlo.

En paralelo, estoy siguiendo otro curso para armar un RPG tipo Zelda:

Este me sirve para complementar características fundamentales de Godot tales como Tileset, Tilemaps, animaciones, sprites, UI, controles, entre otros. Por supuesto, a medida que voy realizando el tutorial, también estoy publicando los cambios en un repositorio de GitHub. No estoy copiando todo como en el curso, sino que me voy tomando atribuciones en ciertas partes por otros videos o documentación complementarios.

Otra herramienta interesante es esta web, la cual te enseña visualmente GDScript. Todavía no me metí de lleno, pero planeo hacerlo esta semana. Si no tienen nociones en programación, es un punto de entrada excelente antes de meterse con el engine de Godot.

Conclusiones

Espero que sepan disculpar mis cambios constantes de tecnologías, pero tengan en cuenta que es probable que les pase a ustedes también, si es que no lo están sufriendo ahora mismo.

Una idea por si misma no tiene valor alguno, sino que su ejecución y la conversión a algo "tangible" es lo que realmente le da un significado.

Mi idea inicial del juego cambia a medida que voy aprendiendo nuevas cosas de cada tecnología, pero va tomando cierta forma final. Este proceso de iteración es natural, y si ustedes están pasando por algo similar, les aconsejo que no se frustren y continúen iterando hasta llegar al proceso final.

Hoy Godot es la solución a mi proyecto, y planeo sacarle mucho jugo en los siguientes meses. En los próximos artículos hablaremos mucho de este motor que esta conquistando devs que antes no se movían de Unity.

¡Nos vemos en el próximo artículo!

Hice un clon de Cookie Clicker en React

Maximiliano Burgos — Mon, 29 May 2023 15:36:01 +0000

Antes de empezar a leer este artículo y por motivos de contexto, te recomiendo leer la historia que me llevó a terminar tomando las decisiones para crear este clon. Lo podés encontrar acá:

Creo que me convertí en un desarrollador en React y Typescript

Maximiliano Burgos ・ May 16 ・ 5 min read

#webdev #spanish #typescript #react

Aclaro que este artículo va a profundizar mucho en los aspectos técnicos que me llevaron a armar el proyecto, por lo que sería recomendable que tengas nociones básicas de desarrollo (web preferentemente) para entenderlo.

Como he mencionado anteriormente, pueden encontrar el repositorio con el código completo aquí.

Primeras decisiones de arquitectura

Para el que no lo sepa, Cookie Clicker es un juego desarrollado puramente en web, con HTML para dar la estructura, CSS para los estilos y finalmente Javascript para la parte lógica de programación. Seguramente tenga algunas librerías que desconozco, pero en escencia, esos son sus pilares principales.

Desarrollar un juego web otorga ciertas facilidades con respecto a la adaptabilidad, dado que la parte responsiva, por ejemplo, nos resuelve que éste sea compatible en múltiples resoluciones.

Por otro lado, la curva de aprendizaje de las tecnologías web (en general) es bastante baja: en un mes ya estás dominando los fundamentos de JS, por ejemplo. Por supuesto, hay conceptos más complejos como patrones reactivos, infraestructura o incluso maquetar una web y que todo funcione sin romperse en múltiples navegadores, sistemas operativos y versiones.

Pero a fin de cuentas, cualquier tecnología explorada en profundidad se vuelve compleja: hay años, incluso décadas de desarrollo detrás de cada una. Es normal que vos, Jose Perez, sentado en tu PC, no logres entender por donde empezar y qué terminar siendo ante la gran cantidad de información que ronda por ahí.

Por eso hay que sentarse y trabajar en el stack de tecnologías acorde a las necesidades que tengamos en base a un proyecto, o una serie de ellos. En este caso, consideré que seguir los pasos de Cookie Clicker era lo más acertado.

Por supuesto, estamos hablando de un videojuego que lleva más de una década en desarrollo: las formas de programar cambiaron mucho desde entonces, y la idea era quedarse con la cáscara, pero descartar la yema del huevo.

Tecnologías involucradas

Por esta razón, este juego y los siguientes van a apoyarse en desarrollos web, pero con algunas librerías adicionales.

Por un lado tenemos a React y Typescript, conjunto de ViteJS para inicializar el proyecto. En realidad esto último es una mentira a medias, porque el que creará todo será Tauri, el cual se apoya en Vite para concluir el armado, con configuraciones adicionales de Rust.

React sigue el paradigma reactivo, lo cual nos permite trabajar con componentes independientes que se pueden comunicar entre ellos y reaccionar mediante eventos. Este tipo de comportamientos esta reflejado en cualquier motor de desarrollo de juegos que utilicemos, tal como Unity, Unreal o Godot, por nombrar algunos.

Typescript es un "must", porque nos da una estructura sólida y evita el tipado dinámico. En un ecosistema donde van a existir muchísimos tipos de datos interactuando mediante componentes, es necesario establecer orden y evitar que un entero ocupe el lugar de un string, y viceversa.

Tauri es mi alternativa a ElectronJS. Dediqué unas dos semanas a Rust para entenderlo, aunque no es necesario que hagas lo mismo que yo. Podés compilar un ejecutable en utilizando esta librería simplemente creando el proyecto web que necesites; incluso migrando uno. Yo lo aprendí por cualquier eventualidad, o si en algun momento quería armar algun complemento para Tauri.

Estructura de componentes

En principio tenemos el típico main.tsx de toda la vida, envolviendo al componente App:

ReactDOM.createRoot(document.getElementById("root") as HTMLElement).render(
  <React.StrictMode>
    <App />
  </React.StrictMode>
);

En el mismo, también estoy incluyendo la librería de Bootstrap:

import 'bootstrap/dist/css/bootstrap.min.css'
import 'bootstrap'

Dentro del componente App, tengo varias cosas:

function App() {
  const [cookieAmount, setCookieAmount] = useState(0);
  const [inventory, setInventory] = useState<InventoryType[]>([])

  return (
    <CookieContext.Provider value={{cookieAmount, setCookieAmount}}>
      <InventoryContext.Provider value={{inventory, setInventory}}>
        <div className='d-flex flex-column min-vh-100 justify-content-center align-items-center'>
          <div className="row">
            <div className="col">
              <Cookie />
            </div>
            <div className="col">
              <Shop />
            </div>
          </div>
        </div>
      </InventoryContext.Provider>
    </CookieContext.Provider>
  )
}

Por un lado, utilizo un useState para trabajar con la cantidad de galletas en el juego. Estas requieren un manejo global, por lo tanto tengo un CookieContext encargado de llevarlo a cualquier componente que lo requiera:

const CookieContext = React.createContext<CookieProps>({
  cookieAmount: 0,
  setCookieAmount: () => {},
});

También tengo un useState para el inventario, responsable de almacenar las mejoras compradas en el juego:

const [inventory, setInventory] = useState<InventoryType[]>([])

Tal como pasa con las galletas, también tiene su contexto:

const InventoryContext = React.createContext<InventoryProps>({
  inventory: [],
  setInventory: () => {},
});

La única diferencia es que maneja un tipo específico para manejar los items del inventario:

export type InventoryType = {
  shopItem: ItemType;
  amount: number;
};

Luego, dentro del diseño en dos columnas, tenemos el componente de la galleta y la tienda de mejoras.

Componente Cookie

En el caso de la galleta en si, se maneja un estado para generar la animación de click que tiene el juego original:

const [isAnimating, setIsAnimating] = useState(false);

const incrementCookie = () => {
  if (!isAnimating) {
    setIsAnimating(true)

    setTimeout(() => {
      setIsAnimating(false)
    }, 100);
  }
};

<img onClick={incrementCookie} />

Por otro lado, armamos un estado para manejar el valor de un click manual. Por defecto es 1, pero a medida que compramos mejoras de clicks, va incrementando:

const [clickerUpgrade, setClickerUpgrade] = useState(0)

Estas mejoras las traemos en el momento en que se genera el componente así como también en cada cambio del inventario:

useEffect(() => {
  setClickerUpgrade(getTotalGiveInventory(ItemMethodEnum.M))
}, [inventory])

Puede que la función getTotalGiveInventory te resulte desconocida, y es porque armé un hook personalizado para manejar el inventario con métodos específicos:

const { inventory, getTotalGiveInventory } = useInventory();

En este caso particular, obtenemos el total de clicks mejorados por el tipo de mejora:

const getTotalGiveInventory = (method: ItemMethodEnum) => {
  const inventoryByMethod = inventory.filter((inv) => inv.shopItem.method === method)

  return inventoryByMethod.reduce((accumulator, inv) => {
    return accumulator + (inv.amount * inv.shopItem.give)
  }, 0)
}

Para entender esto, necesito explicarles los dos tipos que manejo:

Mejoras manuales (ItemMethodEnum.M): son aquellas que se otorgan cuando hacemos click en la galleta.
Mejoras automáticas (ItemMethodEnum.A): corren cada segundo, se les suele llamar "autoclicks".

Por otro lado, para comprender los cálculos involucrados tanto en filter como reduce, les muestro dos mejoras que existen en la tienda:

const items: ItemType[] = [
    {
        name: "Click",
        icon: HiCursorClick,
        cost: 1,
        give: 1,
        method: ItemMethodEnum.M
    },
    {
        name: "Cursor",
        icon: BsHandIndexThumb,
        cost: 1,
        give: 0.01,
        method: ItemMethodEnum.A
    },
    (...)
]

El atributo give es el valor que se sumariza en nuestra función según el tipo de item (manual o automático). A continuación, les muestro las estructura de ItemType para ilustrar mejor este ejemplo:

export type ItemType = {
    name: string,
    icon: IconType,
    cost: number,
    give: number,
    method: ItemMethodEnum,
}

Este comportamiento se refleja en el momento de llamar a la función incrementCookie del componente Cookie, cuando actualizamos el valor de CpS (cookies por click):

setCookieAmount(cookieAmount + 1 + clickerUpgrade)

En el caso del manejo de CpS automáticos, tenemos al componente CookieCounter, el cual tiene un comportamiento similar a Cookie:

useEffect(() => {
  const intervalId = setInterval(() => {
    setCookieAmount(cookieAmount + giveInventory);
  }, 100);

  return () => clearInterval(intervalId);
}, [cookieAmount]);

Como cookieAmount cambia constantemente, esto entra en un bucle infinito donde siempre estan aumentando las galletas. El que define cuántos deben ser los CpS automáticos es otro useEffect:

useEffect(() => {
  setGiveInventory(getTotalGiveInventory(ItemMethodEnum.A))
}, [inventory])

Y finalmente en la parte visual, hacemos un redondeo porque a veces las compras o ventas pueden generar decimales:

return (
  <div>
    <h1>
      {Math.floor(cookieAmount)} galletas
    </h1>
    <h2>{giveInventory.toFixed(2)} g/s</h2>
  </div>
);

Componente Shop

Este componente es muy sencillo porque contiene la lista de mejoras, pero en otro componente distinto, con el fin de separar las responsabilidades de cada uno.

const Shop: React.FC = () => {
  return (
    <div className="text-center">
      <h1>Tienda</h1>
      <div className="row">
        <ShopItemList />
      </div>
    </div>
  );
}

Con ShopItemList ocurre algo similar:

const ShopItemList: React.FC = () => {
  const itemList = items.map((item, index) => (
    <ShopItem key={index} shopItem={item} />
  ));

  return <>{itemList}</>;
}

Recorremos una lista de items que se carga desde un archivo que se encuentra en data/shop_items, el cual se pudo observar cuando estudiábamos el manejo de mejoras manuales y automáticas:

import items from "../../data/shop_items";

Por cada item de la lista, renderizamos un componente ShopItem que se lleva por parámetro el item en sí. En este componente, hay varios aspectos observables:

const itemSellingCost = shopItem.cost / 2;

La constante itemSellingCost nos permite vender el item a la mitad del costo de compra. Es una forma sencilla que encontré para definir valores de venta.

const { inventory, getItemInventory, setAmountItemInventory } = useInventory();

Volvemos a hacer uso del hook que definimos para inventory, pero esta vez nos llevamos getItemInventory para obetener un item del inventario, y setAmountItemInventory para modificar la cantidad del item existente. Para entender esto en mayor detale, podemos ver la estructura de un item en el inventario:

export type InventoryType = {
  shopItem: ItemType;
  amount: number;
};

Podemos observar que shopItem es de tipo ItemType, lo cual nos indica que podemos tener un item que sale de shop_items. Por otro lado, tenemos un campo numérico amount, el cual va a manejar la cantidad de "shopItem" que poseemos. Gracias Typescript por tanto, y perdón por tan poco.

Siguiendo con la exploración de nuestro componente ShopItem, tenemos un useEffect que va a obtener el item del inventario y luego setearlo en un useState para que se actualice en tiempo real:

useEffect(() => {
  const itemInventory = getItemInventory(shopItem);
  setItemAmount(itemInventory.amount);
}, [inventory]);

Luego, en el maquetado del item, tenemos dos botones (para compra y venta) y cada uno va a la misma función transaction, la cual maneja un action "B" (buy, compra) y "S" (sell, venta):

<div className="col">
  <button
    className="btn btn-success"
    disabled={cookieAmount < shopItem.cost}
    onClick={transaction("B")}
  >
    <h5>${shopItem.cost}</h5>
  </button>

  <button className="ms-3 btn btn-danger" onClick={transaction("S")}>
    <h5>${itemSellingCost}</h5>
  </button>
</div>

Dentro de la función transaction, validamos dos casos:

En el caso de la compra, restamos la cantidad de galletas al costo del item (la validación de la cantidad que podemos comprar está determinada por el disabled del mismo botón) y luego llamamos al método setAmountItemInventory, que se encargará de manejar el agregado o modificación del item en el inventario.
En el caso de la venta, sumamos a la cantidad de galletas el costo del item dividido dos, como vimos al principio.

const transaction = (action: "B" | "S") => () => {
  if (action == "B") {
    setCookieAmount(cookieAmount - shopItem.cost);
    setAmountItemInventory(shopItem, "B");
  } else {
    setCookieAmount(cookieAmount + itemSellingCost);
    setAmountItemInventory(shopItem, "S");
  }
};

Con esto tenemos todo el manejo del juego resuelto, dado que cookieAmount es parte de CookieContext, así que modifica las galletas globalmente. Y en el caso del inventory, nuestro hook se encarga de modificar mediante determinados métodos la cantidad de elementos en el inventario.

Compilación

Para compilar este juego en un ejecutable, gracias a Tauri, no nos lleva más que un simple comando en consola:

npm run tauri dev

Y lograremos obtener una ventana como esta:

Conclusiones

Este juego me desafió en muchos aspectos, desde lo técnico hasta el diseño y maquetado de cada aspecto visual. Me permitió fortalecerme en tecnologías que ya conocía, así como también aprender nuevas que no esperaba introducir a mi stack este año, como Rust.

Recomiendo plantearse proyectos como éste cuando quieran dominar tecnologías nuevas, porque no solo es entretenido, sino también extremadamente complicado (se tenía que decir, y se dijo). Esa dificultad es la que realmente va a marcar la diferencia entre seguir un tutorial, y hacer algo realmente desde cero.

Y, como consejo final: terminar el proyecto, no dejarlo a medias, es la parte más importante de este proceso.

¡Nos vemos en los próximos artículos!

Un pequeño paseo por Rust

Maximiliano Burgos — Sat, 27 May 2023 23:15:58 +0000

Antes de comenzar, quiero aclarar que no es para nada sencillo escribir casi a diario. Cada vez que lo intento, termino inmerso en una nueva investigación que me lleva semanas, o incluso un mes entero. Este fue el caso de Rust.

¿Pero cómo llegué acá?

Es una pregunta que me hago probablemente desde mi nacimiento, pero en este caso fue un poco más extraño: si leyeron mi artículo anterior, mi plan en muy resumidas cuentas, era aprender React y TypeScript. Mi felicidad estaba llegando, dado que terminaría mi fase de estudiante eterno para introducirme finalmente en el momento de empezar el bendito proyecto del clicker, hasta que llegó esto:

Tauri es un duro competidor de ElectronJS, y da bastante miedo: he visto varias comparativas y supera con creces a éste último. El punto más fuerte de Tauri es que compila en código de máquina; no como Electron que hace una especie de paquete con NodeJS y arma un ejecutable híbrido, además de ensuciar bastante el proyecto. Pueden encontrar mis repositorios con el clicker implementado en Electron y Tauri.

Encontré en Tauri una solución más limpia y robusta, pero existía un pequeño (gran) detalle: estaba desarrollada en Rust.

Otro viaje de aprendizaje, el último, espero.

En el mundo del desarrollo, Rust es sinónimo de un "señor lenguaje de programación". La gente lo adora, especialmente en las vastas tierras de StackOverflow. Siempre me dió cierta curiosidad, pero en esas épocas mi objetivo era especializarme en Android y Kotlin.

Si bien se puede desarrollar una aplicación web con Tauri, y dejar que sus componentes hagan su trabajo como una caja negra; mi necesidad de saberlo todo no me dejaba en paz: tenía que conocer Rust, de la misma forma que todos los conductores deberíamos saber mecánica para entender cómo funciona un vehículo por dentro.

Como siempre, me dediqué a buscar artículos y videos de youtube. Dejo una lista de aquellos que me parecieron más interesantes:

Por qué tienes que aprender Rust
Rust esta mejorando el desarrollo web
Rust 101 Crash Course: Este recurso en particular me encantó, nunca vi alguien que explicara tan bien los conceptos.
¿Salvará Rust el mundo? Parte 1: En el final del artículo esta el enlace a la segunda parte.
¿Qué es Rust?

Luego de estudiar un par de días, me di cuenta que Rust era extremadamente difícil.

Rust es difícil

Me encontré en una situación compleja: Rust se me antojaba esotérico a ratos, con una sintaxis muy propia del lenguaje que no había visto desde que dejé de programar en C o C++. Por ejemplo, esto es un "Hello World" con variables:

fn prints() {
    let mut name: &str = "Tomas";

    println!("Hello, {}!", name);

    name = "Max";

    println!("Hello, {}!", name);
}

En este caso, "let mut" define a name como una variable mutable, y "&str" es algo parecido a un tipo String. Luego, "println!" tiene un signo de admiración porque se trata de una macro (la cual es distinta y parecida a una función, al mismo tiempo) y debemos utilizar llaves para representar valores por cómo funcionan los tipos.

Vengo de lenguajes de tipado dinámico (salvando quizá, Kotlin y Java), por lo cual encontrarme con lo que vamos a llamar "tipado muy fuerte", que al mínimo pasaje incorrecto deja de compilar, fue una pesadilla inicialmente.

La curva continuó subiendo a medida que aprendí sobre otros conceptos, como operadores:

fn ops() {
    // Addition, Subtraction, and Multiplication
    println!(
        "1 + 2 = {} and 8 - 5 = {} and 15 * 3 = {}",
        1 + 2,
        8 - 5,
        15 * 3
    );

    // Integer and Floating point division
    println!("9 / 2 = {} but 9.0 / 2.0 = {}", 9 / 2, 9.0 / 2.0);
    println!("9 / 2 = {}", 9f32 / 2f32);
}

Donde una división de enteros no podía generar un flotante, entonces necesitabas definirlo previamente (9 flotante de 32 bits).

Por otro lado, las tuplas eran similares a Python, pero muy extrañas en su definición:

fn tupla() {
    // Tuple of length 3
    let tuple_e: (char, i32, bool) = ('E', 5i32, true);

    // Use tuple indexing and show the values of the elements in the tuple
    println!(
        "Is '{}' the {}th letter of the alphabet? {}",
        tuple_e.0, tuple_e.1, tuple_e.2
    );
}

El tipo "char" implica un valor de un solo caracter; mientras que "i32" implica un entero sin signo de 32 bits.

Estaba claro que Rust era un lenguaje de bajo nivel que tenía características que comparten otros lenguajes más contemporaneos. Esto me resultaba preocupante, dado que no manejaba este nivel de complejidad.

Por otro lado, Rust no maneja el paradigma orientado a objetos. Esto me dejó un poco atontado, porque venía trabajando con esta forma en todos los lenguajes que me he cruzado. Aquí estamos frente al uso de los paradigmas imperativo y funcional. Si queremos algo similar a los objetos, necesitamos utilizar cosas como struct e impl:

enum Color {
    Brown,
    Red,
}

impl Color {
    fn print(&self) {
        match self {
            Color::Brown => println!("brown"),
            Color::Red => println!("red")
        }
    }
}

struct Dimensions {
    width: f64,
    height: f64,
    depth: f64,
}

impl Dimensions {
    fn print(&self) {
        println!("width: {:?}", self.width);
        println!("height: {:?}", self.height);
        println!("depth: {:?}", self.depth);
    }
}

struct ShippingBox {
    color: Color,
    weight: f64,
    dimensions: Dimensions,
}

impl ShippingBox {
    fn new(weight: f64, color: Color, dimensions: Dimensions) -> Self {
        Self {
            weight,
            color,
            dimensions,
        }
    }

    fn print(&self) {
        self.color.print();
        self.dimensions.print();
        println!("weight: {:?}", self.weight);
    }
}

fn main() {
    let small_dimensions = Dimensions {
        width: 1.0,
        height: 2.0,
        depth: 3.0
    };

    let small_box = ShippingBox::new(5.0, Color::Red, small_dimensions);
    small_box.print();
}

En este ejemplo, ShippingBox es una estructura de datos que posee su propia implementación, así como también pasa con Color. Es probable que los que estén más familiarizados con C, encuentren esto muy razonable; pero yo me crié (laboralmente) con lenguajes que aplicaban la POO, conjunto de sus patrones de diseño y buenas prácticas.

Finalmente descubrí donde estaba el amor.

Si bien mi subtítulo es aplicable al título de una novela rosa, o un relato de Wattpad; la realidad es que finalmente encontré la clave de tanto amor a Rust: El concepto de Borrow, o "prestar".

A diferencia de C/C++, donde teníamos que manejar la memoria a mano, Rust nos ofrece un sistema inteligente de préstamo de recursos. Por ejemplo:

fn main() {
    let nums = vec![10, 20, 30, 40];

    for n in nums {
        match n {
            30 => println!("thirty"),
            _ => println!("{:?}", n),
        }
    }

    println!("Number of elements: {:?}", nums.len());
}

Aquí podemos ver cómo recorro un vector de números mediante un bucle for. En un lenguaje tradicional, pedir el número de elementos luego de recorrerlo no sería un problema; pero en nuestro caso va a fallar en la compilación.

Esto es porque la variable nums, luego de ser procesada en un bucle (o pasada por una función), se destruye. Por supuesto, en este caso deberíamos evitarlo, y lo hacemos mediante el símbolo "&":

for n in &nums {

Con este pequeño cambio, estamos pidiéndole a la función main (actual dueño de nuestro vector nums) que preste al bucle for dicho vector. Ésta técnica podría compararse con un pasaje de datos por referencia.

Cuando nuestro bucle termina de utilizar su vector, lo devuelve a main() y se continúa su ejecución. Con este sistema de borrowing, podemos liberar memoria cuando realmente no necesitemos los recursos. Esto claramente es un digno competidor de los punteros en C; y supera con creces el Garbage Collector de lenguajes como Python, Java, C#, entre otros.

Éste es el verdadero potencial de Rust. Y no, no somos dignos de esta maravillosa tecnología.

El trayecto final: La implementación.

Con el fin de aplicar todo lo que aprendí, me propuse armar un proyecto sencillo y que ya esta publicado en GitHub: Rust Hero Game. Este proyecto utiliza Rust para acceder a la API de Hero Game desarrollada en Django y DRF.

En primer lugar, definí los recursos que iba a utilizar: tenía una API, y el endpoint más sencillo era "/api/players/", un GET que obtenía los jugadores sin pedir autenticación:

[
    {
        "id": 1,
        "name": "maxwell",
        "hp": 50,
        "money": 99,
        "score": 5,
        "owner": {
            "id": 1,
            "username": "admin",
            "is_author": true
        }
    }
]

Encendí el servidor y me puse a trabajar en un archivo llamado api.rs:

const BASE_URL: &str = "http://127.0.0.1:8001/api/";

async fn make_api_request(url: &str) -> Result<serde_json::Value, Error> {
    let resp = reqwest::get(url)
        .await?
        .json::<serde_json::Value>()
        .await?;

    Ok(resp)
}

Definí una constante BASE_URL, la cual se explica por sí misma, y armé un método make_api_request, el cual toma un endpoint y devuelve un enum Result que se lleva serde_json::Value (si la cosa fue bien) y Error (si salió algo mal).

Utiliza async y await para detener los procesos en cada paso, pero seguir trabajando en los eventos asincrónicos como el llamado a la API y la conversión a json.

pub async fn get_all_players() -> Result<Vec<Player>, ApiError> {
    let url = &format!("{}{}", BASE_URL, "players/");

    match make_api_request(url).await {
        Ok(resp) => {
            match serde_json::from_value::<Vec<Player>>(resp) {
                Ok(players) => Ok(players),
                Err(e) => Err(ApiError::from(e)),
            }
        }
        Err(e) => Err(ApiError::from(e)),
    }
}

Luego, mi función get_all_players llama a make_api_request, pero procesa la respuesta para serializar el json en un struct Player:

pub struct Player {
    hp: i32,
    id: i32,
    money: i32,
    name: String,
    score: i32,
    owner: Owner
}

De esta manera, en main podemos trabajar con cada atributo como si fuera un "objeto":

async fn main() {
    match api::get_all_players().await {
        Ok(players) => {
            for player in players {
                println!("Jugador: {:?}", player);
            }
        }
        Err(e) => {
            eprintln!("Error al obtener los jugadores: {}", e);
        }
    }
}

Dentro de cada player del for (devuelve un array de players en json, vector en Rust) podríamos acceder a propiedades como el dinero mediante player.money.

Si corremos por consola el programa, obtendremos un resultado similar a este:

Finished dev [unoptimized + debuginfo] target(s) in 0.82s
Running `target\debug\hero-game.exe`

Jugador: Player { hp: 50, id: 1, money: 99, name: "maxwell", score: 5, owner: Owner { id: 1, is_author: true, username: "admin" } }

Conclusiones

Creo que Rust es un excelente lenguaje de programación, creado bajo una muy buena idea acerca de cómo manejar los recursos en memoria. Al mismo tiempo, admito que no tengo las capacidades suficientes para dominarlo: puedo llevar un proyecto a cabo, pero he notado un grado de complejidad que me sobrepasa.

Actualmente, no logro comprender en detalle los errores que lanza, y casi todo el tiempo me encuentro preguntándole a ChatGPT qué estoy haciendo.

No obstante, esto también me sirve como una lección de humildad: todos los lenguajes que venía estudiando, los dominaba al mes. Hoy me cruzo con un gigante, y entiendo que parte de aprender se basa en la idea de admitir que no sabíamos todo; y que a veces hay que volver hacia atrás para tomar un envión más fuerte.

Quiero aclarar que no tengo quejas con Rust, sino más bien observaciones comparables a mis otros aprendizajes. Y por supuesto, entrará en el stack que implica hacer este juego.

En el próximo artículo, les contaré en detalle, a nivel mucho más técnico, sobre el clicker que me impulsó a aplicar Tauri y React.

Creo que me convertí en un desarrollador en React y Typescript

Maximiliano Burgos — Tue, 16 May 2023 15:51:41 +0000

Entiendo que el título puede sonar extraño, y claramente lo es: no era mi intención 🤣. Acompañame a este viaje que inició hace casi un mes, fruto de las necesidades de mis proyectos personales.

Desarrollar juegos será divertido, decían. La vas a pasar muy bien, decían.

Siempre estoy desarrollando un juego en mis tiempos libres, sea por incluirlo en una de mis clases o simplemente porque así le saco todo el potencial a la herramienta que estoy utilizando.

Eric Barone quería aprender C# y como excusa creó Stardew Valley. A mi me pasa lo mismo con cada lenguaje o tecnología con la que me enfrento: desarrollar un juego es el equivalente a dispararte el pie. Tres veces.

No se desesperen queridos/as lectores, en unos minutos me voy a poner serio. O no.

La cuestión es que aprendí muchísimo mediante esta técnica, y la sigo aplicando con éxito. El problema es que me lo tomé en serio.

Maldito Cookie Clicker

Esto no es una imagen que encontré por ahí: es mi partida actual, en el momento en el que estoy escribiendo este artículo.

Cookie Clicker es y será el mejor clicker incremental de la historia, sin discusión. Es un clásico que sigue en desarrollo continuo por nueve años.

Y también es un tipo de droga que no fue registrada porque nadie quiere admitir que no hay tratamiento alguno. Este es el resultado de unas 287 horas y contando. Por supuesto, la mayoría son en segundo plano, mientras hago mis cosas.

La cuestión es que decidí meterme en el género y crear mis propios clickers. La idea es innovar en una industria que no para de sacar ideas nuevas cada segundo, por lo cual va a ser un desafío interesante. Pero hablemos de la parte técnica.

Clon de Cookie Clicker

Antes de meterme en un proyecto gigante, quería ahorrarme las frustraciones y crear un MVP de un juego ya creado, el cual tenía algunas de las mecánicas principales que iba a implementar en mis propios proyectos.

Este es el resultado final! 💩

En mi cabeza sonaba mejor. Aún así, lo considero un proyecto bañado en oro, por eso del famoso efecto IKEA. Lo hice con amor, sudor y sangre.

También lo hice para ustedes, hermosa comunidad, y lo pueden clonar desde mi repositorio en GitHub!

Los motivos

Cuando nos juntamos con Fran para empezar a darle forma al primer proyecto que vamos a desarrollar, sorteamos varios engines como Unity y PyGame.

Pero nos encontramos con un problema fundamental: en ambos no teníamos tanta libertad para manejar el aspecto visual en un layout. En el caso de PyGame, los layouts en si no existen, es puro código y hay que acomodar cosas por axis. En el de Unity, tienen su propio sistema y una gestión un poco extraña de la UI. Además de que es un engine enorme para el tipo de juego que queríamos armar.

También Godot fue un motivo de conversación, pero Fran lo detesta por alguna razón que todavía no descubro. Aún así, en este engine existe un metalenguaje llamado GDScript, el cual es similar a Python; y no me convencía tampoco.

También probamos Tkinter y PyQT. El problema eran las animaciones, las cuales no ibamos a poder manejar como queríamos, conjunto de la optimización.

La presencia de Python en nuestro stack era importante porque lo tomamos como el lenguaje core del juego. En este punto, decidimos que Django funcionaría como un administrador y generador de un dataset en SQLite, el cual contendría una serie de tablas que vendrían a definir gran parte de las reglas de nuestro clicker.

Pero la parte frontend seguía siendo un tema complicado: hasta que se me ocurrió apuntar a web.

React fue mi primer opción

Antes que nada, quiero aclarar que jamás toqué React y tengo un gran rechazo a Javascript. Aún así, no estoy ciego, y veo como el mercado pide más desarrolladores React de los que pueden nacer en el mundo.

Además el paradigma reactivo y los videojuegos se llevan muy bien, dado que estos son un gran conjunto de eventos que interaccionan entre sí todo el tiempo.

Por otro lado, yo empecé desarrollando web, por lo cual tenía un roadmap mental de la dirección que debíamos tomar.

El plan

Antes de iniciar un proyecto, hay que armar un plan para entender los alcances y los pasos necesarios para progresar sin encontrar sorpresas muy grandes en el camino. Este era el plan:

Aprender Javascript (Fran)
Comprender React a fondo
Usar Electron para generar un ejecutable
Crear una cuenta de desarrollador en Steam
Publicar en Steam
Mantener este juego por unos 8 años

Con las bases del plan definidas, empezamos el viaje.

Etapa de aprendizaje y adopción

Voy a contar mi camino, y quizá en el futuro, Fran escriba un artículo sobre el suyo.

Como ya sabía Javascript, salté directamente a la librería de React. Miré muchos videos en YouTube, pero considero que aprendí mucho más con este:

Pude entender parte de su potencial; y armé algunos proyectos simples para asentar las bases. Luego investigué sobre Electron y empezaron los problemas.

Electron es la librería que permite generar un ejecutable en base a un proyecto web. El problema es que soporta una versión más antigua que no tiene este tipo de facilidades:

from algo import './un_archivo.js'

Entendí que la clave era cambiar las importaciones. Intenté hacerlo, pero el error persistía. Por supuesto, mucha gente había pasado por esto, y brindaban varias soluciones utilizando templates.

Decidí probar uno, pero me di cuenta que estaban en TypeScript. No conocía este lenguaje, así que tuvimos que agregarlo a nuestro plan y buscar cursos.

Me vi estas 8 horas de video en dos o tres días, y luego empecé a practicar en el editor Visual Studio Code. Al principio no me sentí muy cómodo con este lenguaje de programación (que en realidad es un superset de Javascript), pero luego de utilizarlo en un proyecto con React, me empezó a gustar.

Su fuerte tipado evita los desastres que se podían cometer en Javascript; al mismo tiempo ayuda al editor a entender cuáles son los atributos de un determinado tipo y también a advertir errores si estamos pasando valores erróneos.

Luego de la comprensión, llegó la unión de conceptos, y pude crear un proyecto con un template de Electron, Vite, TypeScript y React. Fue un Hello World, pero estaba feliz porque todo se había encastrado y funcionaba perfecto.

Conclusiones

Considero que este artículo me está quedando gigante, y voy a dejar el desarrollo en detalle del clon de Cookie Clicker para una segunda parte. No obstante, espero que les haya podido trasmitir mi experiencia en el camino del desarrollo y puedan tomarlo de ejemplo para sus emprendimientos.

Si les gustó, compartan, y déjenme un comentario, los leo!