Sobre el rol del director en el trabajo final de carrera

Como ya he mencionado en varias ocasiones es habitual que en la carreras de informática/sistemas los estudiantes tengan que hacer un trabajo final aplicando los conocimientos obtenidos durante la carrera.

Dependiendo de la carrera, el trabajo final suele tomar distinta forma. En algunas carreras ese trabajo final suele ser un trabajo de investigación (tipo «tesis») mientras que en otras carreras ese trabajo suele plantearse como un proyecto de desarrollo de software. Pero en todos los casos, ese trabajo final requiere de profesor que auspicie de director o tutor (el nombre del rol también suele variar de una carrera a otra).

Muchas veces se cree que el director/tutor debe ser un especialista en la temática del trabajo final. Yo personalmente no comparto esa idea, al menos no en forma general. El objetivo del trabajo final es que el alumno demuestre que ha adquirido los conocimientos para ejercer su profesión y en ese sentido es el alumno quien debe ser (o mejor dicho convertirse) en especialista en el tema en cuestión. Entonces ¿Cuál es el rol del director? Podemos debatirlo, pero sin duda el director debe «allanar» toda la cuestión administrativa que conlleva la realización del trabajo. Obviamente esto implica que el director esté familiarizado con el reglamento del trabajo final y el reglamento de la carrera en forma más general.

En lo personal creo que el director debe jugar un rol entre coach y project manager ayudando a los alumnos a mantener el foco y buscando que el trabajo sea completado en tiempo y forma.

Una situación particular puede darse cuando la idea del trabajo final surge del director, en ese cosas el director juega un rol adicional de Product Owner, definiendo funcionalidad y priorizándola.

Si el trabajo es de investigación, entonces uno esperaría que el director tenga cierta experiencia en investigación. De mismo, modo si el trabajo es desarrollo uno esperaría que el director tenga experiencia en desarrollo. La duda en ambos casos es cuánto debe conocer el director del dominio del trabajo, o sea, si estamos desarrollando un aplicación financiera ¿debería el director ser experto en el dominio financiero? Yo creo que creo. Tampoco creo que el director deba ser experto en blockchain si el trabajo se tratara sobre un tema de investigación relacionado a ello.

Para cerrar hay que mencionar que en algunas carreras el director es el encargado de evaluar el trabajo realizado por sus dirigidos, mientras que en otras carreras la evaluación está a cargo de un jurado que no incluye al director. En este segundo caso, uno esperaría que el director hiciera todo lo posible para asegurar el trabajo de los alumnos y que el jurado pueda calificarlo con la mayor nota.

Cierre de otro cuatrimestre particular en Ingeniería de Software @ UNTREF

Particular no solo por ser en modalidad online sino también porque participaron del curso estudiantes externos a la carrera. Esto último es parte de una iniciativa de «abrir la universidad» que comenzamos hace ya un tiempo.

Algunos números descriptivos de este cuatrimestre:

  • Comenzamos con 10 estudiantes y terminamos con 9
  • La nota promedio de aprobación fue 8
  • Tuvimos 35 tareas individuales incluyendo videos, lecturas, cuestionarios y ejercicios de programación
  • Hicimos un trabajo grupal que duró 5 semanas trabajando en equipos de 3

Luego de 15 semanas de clases online, la última clase la hicimos en modo mixto: parte del curso reunido presencialmente y parte del curso en forma online. En 4 cuatrimestres de pandemia es la primera vez que hacemos una clase en esta modalidad y esta experiencia confirmó mi sospecha: es preferible estar todo el curso en un mismo medio, ya sea online o presencial, pero todos juntos.

Para la reunión presencial, a pesar de estar todos vacunados, seguimos algunos protocolos básicos: todos con tapabocas, ventanas abiertas, etc.

Como de costumbre la última clase estuvo dedicada a una actividad de cierre tipo retrospectiva. De esa actividad sacamos 3 accionables:

  • Armar una base de conocimiento (con una wiki o documento compartido) donde docentes y alumnos vayan colaborando con preguntas/respuestas frecuentes.
  • Enviar el checkpoint con las tareas semanales apenas terminada la clase.
  • Grabar las clases que sean más «teóricas»

Finalmente algunos números de las encuestas de fin de curso:

  • Evaluación general de la materia: 9.4 / 10
  • Conocimientos de los docentes: 5 / 5
  • Dinámica de las clases: 4.9 / 5
  • Materiales de estudio: 4.6 / 5
  • Dedicación semana promedio extra clase: 7.6 horas

Recursos sobre Persistencia Objeto-Relacional

Persistir Objetos en una base de datos relacional es una problemática muy común sobre todo en el desarrollo de las denominadas «aplicaciones enterprise». Los desafíos de esta cuestión han sido caracterizados con nombre propio: «Impedance Mismatch«. Hoy en día esta problemática ha sido resuelta por diversas en herramientas entre las que a mi entender se destacan Hibernate(Java) y ActiveRecord(Ruby).

En MeMo2 trabajamos con Ruby pero evitamos el uso de ActiveRecord de la manera tradicional pues resulta intrusiva en el modelo de objetos, ya que obliga a que las clases a persistir deban heredar de una clase de ActiveRecord. La intención en MeMo2 es implementar lo que desde una perspectiva Domain-Driven Design suele denominarse «Persistence Ignorance», esto es que el modelo de objetos permanezca «ignorante» de la tecnología de persistencia. Si bien es importante que los alumnos entiendan los desafíos de esta problemática, no esperamos que implementen un ORM pero si que respeten la idea de «Persistence Ignorance». Es por ello que a lo largo de varios cuatrimestres hemos provisto a los alumnos con ejemplos de implementación de persistencia basados en la idea de Repositorios y utilizando distintos frameworks. Basados en el feedback que los propios alumnos nos han dado, este cuatrimestre agregamos un ejemplo de implementación basado en Sequel y una serie de video que explican la problemática y algunas técnicas de diseño.

El primer video explica conceptual el problema de guardar objetos en una base de datos relacional.

El segundo video explica desde los distintos modelos con los lidiamos en el desarrollo de una aplicación y como es la relación entre ellos a la hora de implementar la persistencia.

Finalmente, el tercer video menciona una seria de recomendaciones para implementar la persistencia de forma trasparente utilizando el patrón Repositorio.

Sobre la presentación de la nueva gestión del Departamento de computación de FIUBA

El pasado viernes fue la presentación de la nueva gestión del Departamento de Computación de Facultad de Ingeniería de la Universidad de Buenos Aires. Este departamento se encarga de la gestión de las materias del área de computación, no de las cuestiones de «informática/tecnología» de la facultad, eso está en manos de la Subsecretaría de Tecnologías de la Información y Comunicaciones.

Esta nueva gestión está encabezada por la el Lic. Manuel Camejo en el rol de director del departamento. Según me comentaron es un nombramiento interino pero no puedo asegurarlo, la única información formal que recibí sobre este cambio fue el mail de despedida del director anterior hace menos de un 1 mes.

Este cambio viene en principio con cambio de imagen y estrategia de comunicación. Hay un logo y presencia en Twitter, Twich e Instagram. Al mismo tiempo me parece interesante el hecho de que hayan realizado una presentación de la gestión y que la hayan transmitido en vivo por redes.

Respecto de lo que se habló en la reunión de presentación hay algunos puntos que me parece interesante destacar:

  • La intención explícita de que el departamento sea un proveedor de servicios a la carreras.
  • El foco inmediato en reestructurar la asignación de recursos del departamento dado que hay materias del comienzo de la carrera con una relación de 1 docente cada 30 alumnos y materias del final de la carrera con una relación de 1 docente cada 4 alumnos. Creo que esto puede ser un desafió interesante y tengo mis dudas hasta que punto puede corregirse.
  • La información que comentó Rosita respecto de el rumbo de los planes 2020 que por la pandemia terminarán siendo los planes 2022.
  • Como parte de la presentación, también habló el Ing. Pablo Deymonnaz, el reciente director de la carrera de Ingeniería en Informática. Entre las cosas que mencionó Pablo lo que me resultó más interesante es el foco que tendrá la carrera de ingeniería con el nuevo plan. Claramente se apunta a una formación muy técnica con contenidos de matemática aplicada/ciencia de datos, system programming y sistemas distribuidos entre otros. Con esto queda muy clara para mi la diferencia entre la Ingeniería Informática y la Licenciatura en Sistemas. La licenciatura queda posicionada como una carrera de Ingeniería de Software, no es que la Ingeniería no vaya a tener contenido de Ingeniería de Software, sino que dicha temática será tratada con mucho mayor profundidad en la Licenciatura.
  • Se presentaron también dos colaboradores externos que justamente estarán colaborando con la dirección del departamento. Uno de ellos es Javier Brugues, egresado de la casa y con quien tuve la oportunidad de compartir algún proyecto hace unos años. El otro es Federico Carrone, un ex-alumno de la casa que abandonó la carrera.

Ojalá este cambio en la gestión sea para mejor. En un par de meses les cuento que tal.

Ser proveedor del (¿ineficiente?) estado Argentino

Este año por primera vez que fui proveedor directo de un par de organismo de la administración pública del estado Argentino, en todos los casos por cuestiones de capacitación IT y es justamente en estas experiencias que están inspiradas estas líneas. Pero hay que destacar, que casualmente (o no tanto), estas experiencias coinciden con tantas otras experiencias que me han comentado varios colegas.

Antes de continuar me parece importante aclarar que esto no es una crítica a la administración actual (ni a la anterior), o mejor dicho: no es una crítica a ninguna administración en particular al mismo tiempo que es una crítica a todas las administraciones por no haber solucionado la cuestión.

Reescribí estas líneas varias veces de cara a intentar que la lectura sea lo más fluida posible y que al mismo tiempo sea fácil de entender. Primero describo el flujo y luego entro en los detalles e implicancias de cada paso.

  1. El estado requiere contratar capacitación para lo cual hace un convocatoria. Dependiendo de la envergadura del presupuesto esa convocatoria puede ser más o menos formal, más o menos burocrática.
  2. En cualquier caso, uno termina presentando una propuesta.
  3. El estado evalúa las propuestas recibidas y elige una.
  4. El proveedor adjudicado realiza la capacitación de acuerdo a lo pactado.
  5. El estado verifica que la capacitación fue efectivamente completada de acuerdo a pactado y da intervención al área encargada de pagar, la cual coordina con el proveedor para que presente la documentación pertinente.
  6. El proveedor presenta la documentación correspondiente que típicamente incluye una factura entre otras cosas.
  7. Finalmente el estado realiza el pago

Este flujo es bastante genérico y no resulta muy distinto a lo que ocurre con empresas grandes (en las empresas chicas el flujo suele resultar más simple porque del lado del contratante suele haber menos áreas/personas involucradas). Ahora bien, el tema central aquí es el tiempo calendario. Desde la presentación de la propuesta hasta la adjudicación de la misma y de ahí hasta el dictado de la capacitación, pueden pasar varios meses. Más aún, una vez finalizado el dictado de la capacitación puede que el pago no sea inmediato. Esto tiene especial impacto en contextos altamente inflacionarios como los que habitualmente se viven en Argentina. Esta situación «obliga» a los proveedores a «inflar» los valores. O sea, si la capacitación tiene un valor X al momento de la cotización, pero se sabe que será cobrada N meses después, el proveedor presenta un presupuesto Z (bastante mayor X) para estar cubierto por las variaciones inflacionarias. Pero la cuestión no termina ahí, si el proveedor es una empresa chica (o directamente una empresa unipersonal) puede que su estructura financiera no le permita afrontar los largos tiempos que típicamente se toma el estado para concretar los pagos. Resumiendo: los largos plazos de pago del estado provocan que:

  1. Los pequeños proveedores queden fuera de juego por no tener la espalda financiera para hacer frente a los largos plazos de pago
  2. El estado termine pagando más caro por el servicio por el colchón que pone el proveedor para cubrirse del pago retrasado

A esto, alguien podría agregar que contratar empresas más grandes, implica pagar precios más caros pues los costos operativos de la empresa grande son más caros que los de una empresa pequeña sobre todo en el rubro capacitación IT. Yo no estoy tan seguro de esto y por ello no voy a profundizar en este punto. Por eso quiero volver a los puntos (1) y (2). Una consecuencia de esto es que al dejar afuera a los pequeños proveedores, se genera una mayor concentraron en las grandes empresas, algo que a mi parecer el estado debería intentar evitar. Puede que aquí esté influyendo cierta cuestión política/ideológica, pero dejemos al margen el rol del estado regulador/justiciero. Si las pequeñas empresas pudieran convertirse en proveedores del estado, eso podría incentivar un ecosistemas más diverso de proveedores, promoviendo la competencia y ayudando a los pequeños emprendedores. Pero no termina aquí, en algunos escenarios es aún peor, el estado pide ciertos «avales» para que el proveedor pueda presentar su propuesta. Esto parece razonable para ciertos proyectos de gran envergadura, pero sin duda para cuestiones de IT hay convocatorias en las que perfectamente podrían obviarse esos «avales» que muchas veces las empresas chicas no tienen y que las dejan fuera de la convocatoria.

En un punto es un círculo vicioso: la operatoria del estado deja fuera a los pequeños proveedores, concentrando las contrataciones en las empresas grandes, haciendo que cada vez sean menos los potenciales proveedores. Cuanto menos oferta, más caros son los precios. Al aumentar los precios aumentan los presupuestos y el riesgo financiero que afecta cada vez más a los proveedores y achica la cantidad de potenciales proveedores. Y esto concentra cada vez las contrataciones en las grandes empresas y disminuye la oferta…

Docencia: entre satisfacciones y frustraciones

Desde hace más de 20 años que trabajo en docencia. Actualmente ejerzo la docencia en distintos ámbitos. Por un lado dicto dos materias en universidades públicas y por otro lado dicto capacitaciones «informales/no académicas» en el ámbito privado.

Una de las principales diferencias que percibo en estos dos contextos es la motivación/predisposición de los estudiantes. En general, la gente que participa de mis cursos «informales/no académicos» lo hace por motivación propia (aunque de vez en cuando hay gente que es enviada por su empresa, es un número muy reducido). Al mismo tiempo, quienes cursan mis materias en la universidad lo hacen obligados por el plan de estudios ya que se trata de materias obligatorias en las que mi curso represente la única opción (siendo preciso, hay un pequeño porcentaje de alumnos que tiene la posibilidad de hacer la materia en otro curso, pero esto no cambia mucho la discusión en este artículo). Esto hace que en general los alumnos vengan en primera instancia con un objetivo: aprobar la materia. Para algunos alumnos ese es el único objetivo mientras que otros, más allá de aprobar, quieren aprender. Desde mi perspectiva docente, mi objetivo es siempre, independientemente del contexto, que el alumno aprenda. En el contexto académico, dada la forma en que están organizadas mis materias, si el alumno aprende es seguro que también aprueba.

El proceso de enseñanza-aprendizaje no es lineal, es un proceso con ideas, vueltas y roscas. Y muchas veces para alcanzar un objetivo hay que dar algunas vueltas que pueden resultar a simple vista sin sentido pero que tienen su razón de ser. Respecto de este proceso me gusta citar la película Karate Kid, donde Daniel quiere aprender Karate y el Maestro Miyagi lo pone inicialmente a encerar autos, pintar cercas, etc. Inicialmente Daniel no dice nada y sigue las instrucciones de Miyagi, pero luego de un tiempo Daniel empieza a desconfiar de Migayi hasta que en un punto se revela. Es ahí cuando Miyagi le hace ver a Daniel como es que el pulido no es más que una forma de entrenar un técnica central de defensa de Karate. Este es exactamente el flujo en mis materias, durante mitad de la materia los alumnos se la pasan «puliendo autos» para en segunda mitad construir software de manera metódica y profesional a partir de las técnicas de «pulido de autos» que estudiaron en la primera mitad.

En ocasiones uno se encuentra con estudiantes comprometidos, dedicados, que se nota claramente que quieren aprender. Eso resulta una motivación para el docente. Pero también hay estudiantes que solo quieren aprobar y casi que cualquier cuestión que no ven directamente relacionadas con su objetivo de aprobación se convierte en una queja o desconformidad. Hay algunas situaciones donde esto queda muy en evidencia, una de ellas son las retrospectivas. En las dos materias que dicto la retrospectiva es una de las prácticas que estudiamos, pero al mismo tiempo es una práctica que utilizamos para mejorar la materias. Entonces tenemos como un 2×1, al hacer una retrospectiva de la materia estamos identificando mejoras para la materia pero al mismo tiempo estamos mostrando a los alumnos «desde dentro» cómo es una retrospectiva.

El uso de retrospectivas con los alumnos nos ha ayudado ha mejorar varias cuestiones de la materia. Al mismo tiempo resulta muy gratificante ver que algunos alumnos valoran positivamente ciertas cuestiones respecto de la forma de dictado de nuestra materia. Pero no todo es color de rosa y algunos otros utilizan la retrospectiva como un espacio de queja. Caso típico: alguien escribe anónimamente un post-it diciendo «hay videos que están desactualizados», entonces preguntamos qué videos y nadie dice nada, esa no es una crítica constructiva, es solo una queja que no resulta útil para la mejora. Tenemos más de 20 videos, algunos de ellos sobre el uso de herramientas las cuales suelen evolucionar haciendo que algún video pueda quedar desactualizado. Si el alumno realmente tuviera una intención de aportar a la mejora, mínimamente nos indicaría cuál es el video que considera que está desactualizado. Otra situación típica en las retrospectivas de la materia son las opiniones contradictorias: algunos creen que deberíamos dar menos videos y más lecturas mientras que otros prefieren menos lecturas y más videos. Estas cuestiones ya responden a gustos personales y se repiten respecto de distintos temas: lista de correo vs. discord, ruby vs. python, etc.

Otra situación gratificante es cuando vemos a los alumnos haciendo consultas que evidencian que entendieron un tema.

En los tiempo que corren, que las clases son virtuales, resulta muy frustrante dar una clase para más de 20 alumnos y ver apenas un puñado de alumnos participando de la clase y aún menos con cámaras encendidas. Uno siente que está hablando al aire, haces una consulta y nadie responde, ni Si, ni Ok, ni No, ni Jodete. Solo silencio.

Algunos de los que hacemos docencia los hacemos por gusto, no por necesidad. Particularmente en el rubro software, la industria ofrece sueldos incomparables con los de la academia. Es por ello que la mayoría de los docentes de las carreras de informática vivimos de nuestros ingresos de la industria y hacemos docencia por motivos no económicos. Típicamente, muchos de nosotros trabajamos en la industria la mayor parte del día y damos clases por la tarde/noche luego de un intenso día con situaciones no siempre amistosas, pero intentamos dejar «la mochila» a un lado y entrar a clase con la mente en blanco de cara a ofrecer a los alumnos la mejor experiencia de aprendizaje posible. Lamentablemente esto no siempre es valorado por los alumnos. Por momentos tengo la sospecha de que algunos alumnos se conectan a la clase, no encienden la cámara, apenas enciende el micrófono al comienzo de clase para dar el presente y luego se van a hacer otra cosa. Más aún, en alguna ocasión me ha pasado de terminar la clase un poco más temprano de lo habitual y ver que algún alumno sigue conectado a pesar que la clase terminó, los alumnos se desconectaron y «el aula virtual» está vacía y en silencio.

Si bien al ver la balanza la satisfacción de dar clases supera las frustraciones, por momentos tengo la sospecha de que sería mucho más positivo si dictara una materia optativa, en la que los alumnos no se anoten estando obligados sino por una motivación de estudiar el tema de la materia. Esta es una idea que me viene dando vueltas hace un tiempo y que cada vez me suena con más fuerza. Sumado al hecho de que hay ciertos temas avanzados de ingeniería de software que me resultan muy interesantes pero que exceden por mucho mis materias actuales, es posible que dentro de un par de cuatrimestres pida un cambio de materia.

Sobre mi charla de Pull-Requests en Agiles2021

El jueves pasado di mi charla «No Pull-Requests» en el contexto de Agiles2021. El título de la charla tenía cierta intención de «provocación», pero la realidad es que yo mismo utilizo pull-requests porque creo que en ciertos contextos son una herramienta muy conveniente. Pero obviamente no creo que su uso sea conveniente en todos los contextos. Particularmente cuando tengo un equipo chico, trabajando en forma sincrónica, en un ambiente de confianza y con una intención de entrega continua, me parece que el uso de Pull-Requests puede convertise en un obstáculo. Sobre todo en contextos de «poca disciplina» donde los pull-requests tienden a acumularse. Mi intención con la charla no era criticar el uso de Pull-requests sino compartir algunas estrategias y consejos ya sea para no utilizar pull-request o bien para utilizarlos de una forma que no resulte incómoda/problemática para el equipo.

Me gustó mucho armar la charla porque me permitió ordenar varias ideas y experiencias personales en torno a este tema. Previo a la charla hice una breve encuesta en redes sobre el uso de Pull-Request y luego en la charla utilicé las respuestas para ir presentando mi ideas y propuestas. Por otro lado, al comienzo de la charla hice algunas preguntas a la audiencia las cuales revelaron que:

  1. La mayoría de la audiencia utilizaba Pull-Request
  2. La mayoría de los que utilizaba Pull-Request no tenia explícitamente documento qué debía revisarse al revisar un Pull-Request.

Aquí están las diapositivas que utilicé durante la charla.

La charla fue grabada así que supongo que en algún momento será publicada en YouTube pero al margen de eso creo que escribiré un artículo resumiendo (o mejor dicho profundizando) lo que compartí en la charla.

Para cerrar comparto el resultado de algunas de las respuestas que logré colectar.

El alumno con el faso en la clase de Zoom

Era la tercera clase del cuatrimestre. Debido a la pandemia estábamos dictando la materia de forma virtual. Como de costumbre sólo un puñado de alumnos tenían la cámara encendida y participaban activamente de la clase. Llevábamos unos 40 minutos de clase cuando uno de los alumnos con cámara encendida, cómodamente sentado en un sillón, enciende lo que a mí pareció un faso (término usualmente utilizado en Argentina para referirse al cigarrillo marihuana). Inicialmente me sentí muy sorprendido, dudé sobre cómo actuar. Finalmente no hice nada, solo continué con la clase como si nada hubiera ocurrido.

Situaciones de este tipo nos llevan a reflexionar sobre las implicancias de las clases virtuales. El hecho de que fuera o no un faso es anecdótico, la discusión es igualmente válida si se tratara de un cigarro de tabaco. En una clase presencial creo que a nadie se le ocurriría encender un faso, ni siquiera un cigarrillo de tabaco. Pero en una clase virtual el alumno no está en las instalaciones de la institución, sino que generalmente está en sus propias instalaciones: su casa. Personalmente en clase suelo tomar mate o café, ya sea cuando estoy en el aula física en la universidad o también cuando estoy en el aula virtual desde mi casa. Debo admitir que en más de una ocasión, estando en un clase virtual, estuve tentado de destapar una cerveza pero finalmente no lo hice. Supongo que por una cuestión de «ética»: virtual o presencial estoy en un aula. De todas formas esta situación me hizo repensar el tema, aunque por ahora sigo limitándome a consumir café y mate durante las clases.

¿Qué piensa la audiencia?

No Pull-Request o Interfaces fluidas

Me invitaron a dar una charla en el track de Software Crafters de Agiles 2021 y no aún no tengo decidido de qué voy a hablar.

Tengo 2 temas posibles:

  • No Pull-Request: este es el título «marketinero», pero siendo más sincero el título podría debería ser «Alternativas a los Pull-Requests». La cuestión es más o menos así: el uso de Pull-Request es una práctica muy extendida en la actualidad pero su uso no siempre resulta positivo y al mismo tiempo que algunos equipos padecen de la acumulación de Pull-Request. Por otro lado el uso de Pull-Request y feature branches puede resultar un impedimento para la implementación de la práctica de Integración Continua. En esta sesión veremos técnicas alternativas que pueden darnos los beneficios que los Pull-Requests pero sin algunos de sus inconvenientes.
  • Diseño de Interfaces fluidas y DSLs: el uso de interfaces fluidas y DSLs ayudan a mejorar la legibilidad del código y en muchos casos también a reducir la cantidad de código repetido. Sin bien varios frameworks y librerías ofrecen DSLs y/o interfaces fluidas, su uso no es tan habitual en el desarrollo de aplicaciones. En esta sesión veremos algunos conceptos y técnicas para su implementación.

Ambas sesiones son de índole técnica pero la segunda incluye código y es justamente eso lo que me hace dudar dado que parte de la audiencia de la conferencia es gente que no necesariamente viene del mundo de la programación.

De todas formas, para tomar la decisión decidí publicar una encuesta en twitter, los invito a votar.

Nota: si bien la conferencia es paga, entiendo que el video de la sesión quedará disponible en YouTube.

Y un día elegí JavaScript

Resulta que tenemos que implementar cierta lógica para generar código HTML. Esa lógica podríamos codearla server-side con Python o bien client-side con JavaScript. Personalmente prefiero Python que JavaScript pero en este caso codear server-side con Python implica tener que tocar código de una aplicación Django mientras que en el caso de ir por el camino client-side/JavaScript estaría trabajando en un código completamente nuevo.

Mis compañer@s de equipo no parecían muy convencidos, estimo que porque se sienten mucho más cómodo en Python que yo, pero finalmente me dieron un voto de confianza. ¡¿Quién lo hubiera dicho?! Yo «vendiendo» JavaScript.

Continuará….