Bajo mi punto de vista la plataforma usada marca de forma importante la experiencia tanto para el profesor como para los alumnos. En algunas formaciones he usado GoToMeeting, Appear.in o Google Hangouts. En estas plataformas la formación se realiza “enseñando” la pantalla a los alumnos. Eso permite mostrar una presentación, un entorno de desarrollo, o una página web. El problema principal es que los alumnos no te ven la cara, tus expresiones, tu movimiento de manos… eso dificulta la transmisión de la información y el alumno “desconecta” con más facilidad. En otras ocasiones he usado GoToWebinar, y esta herramienta si permite enseñar el monitor y también la cámara. Una pena que no sea compatible con linux, lo que me obliga a buscar otra máquina en las formaciones en las que estoy obligado a usar esta herramienta.

TRUCO 1: Si la plataforma de videoconferencia que estás usando no permite emitir la cámara y la pantalla a la misma vez, se puede hacer un poco de trampa y conectarnos como dos usuarios diferentes. Uno para emitir la cámara y otro para emitir la pantalla. Para evitar acoplamiento en el audio, uno de los usuarios tiene que mutar su micro y además silenciar a todos los demás usuarios de la videollamada. Lo sé, un poco cutre, pero funciona ;) (eso sí, si los alumnos están compartiendo su vídeo, los strems de vídeo de los alumnos se descargan por separado).

TRUCO 2: Otra alternativa es compartir la pantalla y mostrar la cámara con una aplicación en la propia pantalla (en una esquina por ejemplo). Aunque esta opción limita la posibilidad de que el alumno controle de forma independiente el tamaño de la cámara y la pantalla. En linux se puede hacer con la herramienta vokoscreen, usada para grabar screencasts. Permite mostrar la cámara en cualquier posición de la pantalla y sin el menú de la ventana.

De igual forma que es importante que los alumnos vean al profesor cuando explica, también es muy importante que el profesor pueda ver a los alumnos. Habitualmente el único feedback que tengo de los alumnos cuando doy clase online son los mensajes que ponen en un chat. Además, dependiendo de la tecnología usada, el chat llega con varios segundos de retraso, lo que dificulta mucho tener una mínima conversación. Dar una clase en esas condiciones es muy complicado porque no sabes si tus explicaciones se entienden, los alumnos están interesados, aburridos, asienten, ponen cara de WTF!… Si hay pocos alumnos la solución es sencilla, basta con que todos los alumnos se conecten a la videoconferencia. En appear.in sólo se pueden conectar 4 usuarios simultáneos, si el profesor comparte cámara y pantalla eso deja “hueco” a sólo 2 alumnos. Con la versión de pago se puede llegar a 12 usuarios conectados = 10 alumnos. Con Google Hangout se pueden conectar hasta un máximo de 15 usuarios en la versión gratuita, 25 en la de pago. Si la cámara se envía integrada con la pantalla (ver truco 2), esta puede ser una solución razonable. Pero si la cámara y pantalla se envían como dos usuarios distintos (ver truco 1) podemos tener inconvenientes. Las aplicaciones genéricas de videoconferencia muestran a todos los usuarios con el mismo tamaño (pantalla de profesor, cámara del profesor y alumnos). O bien, muestran en grande un único usuario y el resto con el mismo tamaño. Es decir, podrías ver la pantalla en grande, pero la cara del profesor se vería igual que la del resto del compañeros, que podría no ser lo mejor con muchos alumnos.

Si conseguimos usar un software de videoconferencia estándar, tenemos otro problema para que el profesor pueda ver a los alumnos. En el caso de que el profesor tenga un único monitor, si está presentando contenido a pantalla completa o tiene el IDE maximizado, ¿cómo ve a sus alumnos? Tendría que estar cambiando constantemente a la web donde están los alumnos, pero eso es bastante molesto para el profesor y los alumnos. La solución obvia consiste en disponer de dos monitores (el del portátil y uno externo). De esa forma, se emite un monitor y en el otro monitor se puede ver a los alumnos, el chat, etc. Pero no podía ser todo tan bonito, en linux no es posible compartir únicamente un monitor (cuando existen varios) con aplicaciones vía web. Estas aplicaciones usan la tecnología WebRTC y por lo visto hay un bug en Chrome que impide compartir un único monitor. En windows y mac no pasa ;)

Después de investigar un poco, he encontrado algunas soluciones.

TRUCO 3: Como se pueden compartir aplicaciones individuales, una posible solución al problema del bug de Chrome, sería buscar una aplicación que muestre lo que sale por el monitor que se quiere compartir. Lo sé, suena un poco recursivo, como cuando enfocas con la cámara a la televisión que está reproduciendo la cámara, pero funciona. Yo lo he conseguido hacer con GStreamer. El siguiente comando lo hace:

$ gst-launch-1.0 ximagesrc startx=0 use-damage=0 ! video/x-raw,framerate=30/1 ! ximagesink

El único “pero” que tiene esta solución es que la aplicación no se puede minimizar y que su tamaño tiene que ser exactamente igual al monitor (o región) que se quiere transmitir.

Intenté otras alternativas. Una bastante prometedora consistía en hacer que un monitor (o una región de la pantalla) se convirtiese en una especie de cámara virtual. Todo funcionó bien, salvo que los navegadores, tratan de forma diferente el envío de una cámara y el envío de la pantalla. Una cámara es más “comprimible” que una captura de pantalla. En concreto, noté una bajada de la resolución que dificultaba la lectura para los alumnos. Una pena porque parecía una solución relativamente razonable… pero descartado.

TRUCO 4: Si tienes un único monitor y quieres ver a tus alumnos a la vez que compartes la pantalla, puedes usar el truco de enviar únicamente parte de la pantalla. Así puedes poner en la parte que no emites la web de videoconferencia y ver a tus alumnos y el chat mientras que ellos no lo ven. Lo que pasa es que es bastante tedioso estar ajustando las ventanas de las aplicaciones para que se muestren completas en la zona “de emisión”. Lo ideal sería que esa zona “de emisión” se comportara como si fuera un monitor “virtual”, de forma que las aplicaciones se pudieran maximizar, poner a pantalla completa (para las slides), etc. Después de investigar un poco he encontrado una forma de hacerlo con FakeXRandR. Es una herramienta que sirve justo para eso, para dividir un monitor real en 2 o más monitores “virtuales”.

Como habéis podido ver, dar clases online requiere usar las herramientas adecuadas para que la experiencia de los alumnos (y del profesor) sea la mejor posible. Todavía no he encontrado la herramienta que se ajuste completamente a mis necesidades, pero con estos trucos, cada vez estoy más cerca.

Tengo pendiente echar un vistazo a herramientas de videoconferencia orientadas directamente a la docencia como por ejemplo BigBlueButton, a ver si mejoran la experiencia de las herramientas de videoconferencia “generalistas”. De todos modos… es cuestión de tiempo que acabe implementando mi propia herramienta con OpenVidu.

• ElasTest: Proyecto con financiación pública europea
• Lernim: Proyecto con financiación pública nacional
• Cloud4BigData: Proyecto con financiación pública de la Comunidad de Madrid
• OpenVidu: Plataforma open source para vídeo en directo
• Tareas docentes en la universidad: Desarrollo de Aplicaciones web y Ampliación de Ingeniería del Software
• Formación en abierto y a empresas: Angular, Spring, git, Jenkins, Docker, Kubernetes, XP, Testing, Cloud Computing, Integración Continua…
• Investigación: Publicaciones científicas
• Charlas y talleres en meetups y conferencias.
• Consultoría y colaboración con empresas: TwoToForty, RatedPower, Latinia, Ericsson…

En 2019 seguiré con estas tareas, pero voy a dedicarme más intensamente a algunas de ellas y quiero empezar a hacer cosas que ahora tengo olvidadas:

• Viabilidad comercial de OpenVidu: Llevo unos 5 años participando en proyectos de software libre relacionados con las videoconferencias basadas en WebRTC. Este 2019 hay que dar un buen empujón a la parte comercial, para que OpenVidu sea sostenible sin “empujones” de financiación pública. Tenemos mucho que aprender y nos equivocaremos… pero lo vamos a intentar.
• Bootcamp/Máster: En CodeURJC tenemos experiencia e impartimos cursos relacionados con el cloud computing, backend services, escalabilidad, CI, testing... Para Septiembre de 2019 tenemos previsto lanzar un Máster / Bootcamp / Curso de Experto en estas temáticas. Os pediré feedback sobre formato y temario. Estas atentos a mi cuenta de Twitter.
• Meetup Code Madrid Suroeste: Nos gusta compartir lo que hacemos con los demás y nos gusta escuchar batallitas de camaradas del metal, pero trabajando en Móstoles y viviendo en Torrijos (un pueblo de la provincia de Toledo) ir a meetups en el centro de Madrid nos cuesta muchos family-points. Vamos a ver si este año somos capaces de montar el meetup de developers de Madrid Suroeste. Lo primero que tenemos que hacer es pensar en un mejor nombre ;)
• Leer más y mejor: Suelo estar bastante al día de las novedades de la profesión: Lenguajes, tecnologías, librerías, buenas prácticas, metodologías, arquitecturas... sobre todo en backend, que es donde tengo más experiencia. En frontend tampoco quiero quedarme atrás, aunque lo tengo menos controlado. El problema es que saco poco tiempo para leer libros y eso no me permite llegar al nivel de profundidad que me gustaría en ciertos temas. Espero encontrar la excusa que me “obligue” a leer más y mejor, quizás montando un club de lectura asociado al meetup podemos hacer algo.

Pero no solo tengo propósitos relacionados con la profesión. También hay otros más personales:

• Seguir disfrutando de mi familia, tanto de mi peque y mi pareja como de mis padres, hermanos y familia política.
• No dejar de salir con la bicicleta siempre que tenga oportunidad. Llevo unos meses bastante parado… pero el otro día volví a salir una rutita tranquila. Espero salir en 2019 lo mismo que en 2018… y con un poco de suerte, igualo a lo que salí en 2017. Además, ahora con Strava puedo llevar el control

Micael Gallego on Twitter

Hoy ha tocado MTB. 35km en 2h y media. Tranquilito para desengrasar...

Pues eso amigos… que el objetivo es seguir jugando y a ser posible compartiendo lo aprendido con los demás y de una una forma “económicamente sostenible”.

Nos vemos en las redes…

Propósito 1: En 2016 me tendría que haber puesto a mejorar mi inglés. Siempre ha sido mi asignatura pendiente, y aunque a lo largo de mi vida he hecho esfuerzos activos por mejorar (he ido a la Escuela Oficial de Idiomas, leo todo el día artículos técnicos en inglés e incluso veo charlas y escucho podcasts…), estoy muy lejos de un nivel “razonable”.

Propósito 2: Aunque he participado en bastantes eventos con la comunidad, me he quedado con ganas de más. No he sido muy asiduo a estos eventos anteriormente, quizás porque vivo en un pueblo de Toledo y eso lo complica todo, pero cuanta más colegas de la profesión conozco, más me gusta y más me quiero implicar. De hecho, si pudiera hablar con mi yo de hace 10 años, le diría que se involucrara más en la comunidad de “developers”.

Propósito 3: En este sentido, pero en otro plano, me gustaría generar más contenido de valor para los compañeros: blogs, tutoriales, podcasts, etc. He cogido la costumbre de subir mis slides a SlideShare, creo que es un buen comienzo. También he publicado un curso de Angular2 y TypeScript, y creo que ha gustado bastante, pero siempre se puede hacer más. El problema es que me cuesta mucho trabajo ser constante porque tengo siempre 20 fregados abiertos y un niño de 2 años. Al menos en el 2017 intentaré escribir unos cuantos posts de calidad.

Propósito 4: La investigación es el gran punto que necesita mejorar del 2016. A los profesores universitarios se nos evalúa periódicamente por las contribuciones científicas que hacemos, y cada vez se ponen más exigentes. Este año me he focalizado en la docencia y en la colaboración con empresas, y he dejado de lado la investigación. Para el año que viene ya hemos definido una estrategia, desarrollar sinergias dentro de CodeURJC para aumentar los resultados científicos.

Propósito 5: Que CodeURJC se convierta en lo que Patxi y yo hemos tenido siempre en la cabeza, un equipo de desarrolladores software e investigadores que se divierten y que aportan valor a los alumnos, la sociedad y los clientes. Pero para CodeURJC tengo que hacer otro post exclusivo, para que todos sepáis de lo que hablo.

Ahora si, mi retro y propósitos, todo en uno. Contento Jose?

Durante 2016 he estado dedicado a mis tareas docentes en la Universidad Rey Juan Carlos. Llevo ya algunos años impartiendo una asignatura de Programación Concurrente y otra Desarrollo Web en diversos Grados de Informática. La de Concurrente tiene un perfil más teórico, aunque nunca dejo de lado la aplicación práctica de los concetos y técnicas vistos en clase. Nos centramos sobre todo en el modelo de memoria compartida “mutable” y en Java. Aunque damos un repaso general a otros modelos de concurrencia: STM, Actores, Funcional, CSP… y también vemos las arquitecturas de diferentes tipos de aplicaciones desde el punto de vista de la concurrencia: Interfaces gráficos de usuarios, aplicaciones web, bases de datos. La asignatura de Desarrollo Web es muy diferente. Aquí el objetivo es que los alumnos se enfrenten a todos las fases del desarrollo de una web, o más bien, a un producto implementado como una web: Definición, Diseño de interfaces, implementación, etc. Es una asignatura que estoy puliendo todavía. El año pasado apliqué la técnica docente de “Aprendizaje basado en Proyectos”. Este año también quiero incluir la “Clase invertida”. Aquí tienes más información sobre este cambio metodológico y sus motivos.

Aunque esas son mis dos asignaturas principales, también realizo otras actividades docentes: Comparto con otros compañeros la asignatura de Computación en la Nube del Máster en Data Science de la URJC. También he impartido una asignatura online sobre Ingeniería del Software. Por otro lado, imparto las asignaturas de Programación Extrema y parte de la asignatura de Virtualización y Computación en la Nube del Especialista en Arquitectura y Desarrollo Software de la Universidad Politécnica de Madrid. Y también están los cursos de CodeURJC que impartimos Patxi (@fgortazar) y yo: Desarrollo backend con Spring, Desarrollo front con Angular2, etc. Como puedes ver, tengo motivos para definirme como profesor, no lo vamos a negar ;) Ah, se me olvidaba. He presentado una propuesta de mejora docente junto con mi compañero Patxi y nos han dado un premio y todo. Cómo mola ;)

Las retrospectivas no tienen como objetivo simplemente enumerar lo que has hecho, sino más bien reflexionar sobre lo que has conseguido. He de decir que la docencia me hace sentir muy bien. Lo primero porque es la excusa perfecta para aprender algo que te interesa, y ya te digo yo que lo aprendes de forma muy profunda, porque lo tienes que entender para poder explicarlo. Y por otro lado está la parte humana. Aprender para poder hacer la vida más fácil a los demás, para poder ayudarles en su proceso de aprendizaje. No hay nada más gratificante de ver la cara de un alumno que disfruta aprendiendo cosas nuevas. Un pena que no todos lo hagan ;)

El que me conoce sabe que no me conformo con la docencia. Me apasiona enseñar, pero también me considero desarrollador software y me gusta desarrollar. Pero no sólo hacer programas para preparar las clases, me gusta formar parte de un equipo de desarrollo creando un producto software que la gente use. Es decir, me gusta participar en la priorización de la funcionalidad ofrecida (quiero decir las historias de usuario ;)). Me gusta enfrentarme a los retos que supone hacer software “real”, es decir, libre de bugs, cumpliendo las planificaciones, colaborando con compañeros, discutiendo sobre arquitectura software. Y además de gustarme, creo que es mi responsabilidad como profesor de estas materias, conocerlas de primera mano, y no sólo por los libros. En mi faceta de developer formo parte del equipo de desarrollo de Kurento, una plataforma para implementar aplicaciones de videoconferencia vía web con WebRTC. Estoy en el stack de Java del producto. Este año me he dedicado sobre todo a trabajar con clientes y servidores de WebSockets, SpringBoot, AWS, Hazelcast para implementar ElasticRTC, un Kurento as a service en Amazon Web Services, autoescalable, tolerante a fallos, mágico ;) He aprendido mucho técnicamente sobre sistemas distribuidos tolerantes a fallos, pero sobre todo he aprendido a darme cuenta de lo importante que son los tests para garantizar un mínimo de calidad en tu trabajo y lo que marca la diferencia tener una buena herramienta para ayudarte en tu día a día. Por ejemplo, aunque usámos ElasticSearch para guardar los logs del sistema distribuido, Kibana no me parece adecuda para analizar problemas. Menos mal que los jefes nos dejaron implementar el Kurento Log Manager. En Septiembre Kurento fue comprado por Twilio, una startup americana. Como es un proyecto libre, en realidad “compraron” a casi todo el equipo y la parte privativa. A mi me ofrecieron también incorporarme a la plantilla de Twilio, pero tendría que dejar la universidad y los cursos. Estuve sopesando la idea, pero decidí quedarme en la universidad. Con la marcha de gran parte del equipo, Kurento no ha seguido desarrollándose estos últimos meses, pero en 2017 eso va a cambiar, os daré más detalles en otro post.

Este año también he sido un poco más activo asistiendo a eventos con compañeros de la profesión. Cada vez me gusta más hacerlo, porque aprendo mucho a nivel técnico y a nivel personal. Asistir a estos eventos me ha ayudado a darme cuenta de hay vida más allá de las cosas con las que habitualmente trabajo. Siempre he tenido a PHP como un “mal lenguaje”, pero he visto a gente de mucho nivel y que usan PHP como su mother tongue. Eso me ha ayudado a ser mucho más humilde en mis opiniones y ha declararme oficialmente torpe para poder contar las bondades que para mi tiene TypeScript, porque entiendo que para otros sólo aporta una complicación innecesaria. Siempre que puedo (y me la aceptan) me apetece dar alguna charla a los eventos que voy. Es mi forma de dar una pequeña parte de lo que recibo. Este 2016 he participado en unos cuantos “saraos”: MadridJUG+MadridJS, MadridJUG, Codemotion, T3chfest, PanelSistemas, Google Campus, Programa de Radio3 UNED. Y lo bueno es que he conocido a gente super maja y muy interesante, sobre todo en el Codemotion.

Y se me olvidaba. Un profesor universitario también tiene que investigar, publicar artículos, libros, asistir a conferencias de investigación, etc. La verdad es que este año he tenido esa faceta un poco aparcada para poder dedicarme a todas las demás que he contado. Aun así, he podido publicar un paper en el área de la optimización metaheurística y otro relacionado con Kurento. También ha habido contribuciones a congresos nacionales e internacionales. No está nada mal para ir al “tran tran” ;)

En resumen, 2016 ha sido un buen año a nivel profesional. El año 2017 viene con muchos retos, pero si todo sale bien, tiene pinta de ser mejor incluso que el 2016. Pero para el 2017, mejor otro post.

Básicamente dice que después de usar TypeScript a tiempo completo durante varios meses en un proyecto, no le ha ayudado a ser más productivo ni a programar con menos errores.

Según Eric, las anotaciones de tipos crean más ruido sintáctico, y eso hace que el código sea más difícil de leer y de mantener. Es bastante curioso que diga esto porque precisamente ayer actualizaron una propuesta para incluir inferencia de tipos en Java y la gente se quejaba de que si no ponías el tipo en la declaración de las variables, el código era más difícil de leer y de entender, y por tanto de mantener ;) Como parece que hay controversia en la utilidad de los tipos todo se reduce a opiniones, mi opinión es que los tipos ayudan a entender y mantener el código.

Eric indica que escribir código TypeScript es más lento que en JavaScript. Concretamente dice que las siguientes construcciones son más complejas:

• Generic functions & polymorphism
• Higher order functions
• Object composition

Efectivamente escribir funciones genéricas en TypeScript es más costoso que en JavaScript porque especificar el tipo de las funciones implica que tienes que conocer cómo hacerlo y mantener esas definiciones de tipos. Lo bueno de TypeScript es que no tienes por qué hacerlo. Puedes usar el tipo “any” cuando la cosa se complica. Tu decides el precio que pagar por la ayuda que obtienes. Si quieres que TypeScript te ayude, tú le tienes que explicar las cosas con más cuidado. Si en ciertos casos consideras que no merece la pena el coste para la ayuda… no uses tipos en ese punto concreto. Programarás como en JavaScript. Por tanto, una parte opcional no puede ser un problema. Y si usas constantemente funciones genéricas, entonces te merecerá la pena leer la documentación para saber cómo especificar el tipo de las funciones ;)

También indica que con TypeScript no tendrás menos bugs. Totalmente de acuerdo. Si eres un buen programador y no eres un torpe como yo, TypeScript no te ayudará mucho. A mi me ayuda porque me avisa cuando me equivoco al escribir, sin tener que esperar a ejecutar para obtener el feedback de runtime. Es cierto que en JavaScript habría detectado el mismo error al ejecutar el programa, pero con TypeScript simplemente voy más rápido porque soluciono mis torpezas nada mas cometerlas, no al cabo de un rato.

En el artículo menciona la relación entre el duck typing de los lenguajes dinámicos y la compatibilidad de tipos estructural y nominal. Como TypeScript tiene compatibilidad de tipos estructural, que se asemeja al duck typing, no entiendo exactamente el problema que tiene. Dice que es un problema en Java y C++… y a mi qué me cuentas??? ;)

Eric dice que el 99% de la ayuda que te proporciona TypeScript te la podría proporcionar Flow que analiza tu código JavaScript estándar. Esto me parece bastante curioso porque creo que es mucho más del 1%. Creo que todo depende de lo torpe que seas… a mi me ayuda mucho más del 1%, sobre todo cuando llamo a funciones y declaro el tipo de los parámetros, cosa que flow no infiere por ti (creo).

Respecto al refactoring, Eric indica que Tern.js y Flow te pueden ayudar mucho con la refactorización. Cosa que me sorprende si no especificas el tipo de los parámetros de una función en una librería porque no sabría qué valores potenciales puede recibir. Pero quizás no conozca Tern.js y Flow lo suficiente. Lo que más me mola es lo que dice de que puede contar con los dedos de la mano el número de veces que ha tenido que hacer refactorizaciones en las que haya tardado más de algunos pocos minutos y que realmente le hubiese ayudado un lenguaje con tipado estático. Definitivamente somos programadores diferentes. Aquí es donde se nota mi torpeza. Yo me siento muy poco cómodo refactorizando código JavaScript por la falta de red seguridad que tengo sin el “compilador” de un lenguaje con tipado estático. Hay gente que se siente super cómoda y con sus tests puede considerar que el compilador es redundante, pero mi cerebro no es así. Desde luego admiro a los desarrolladores que son más productivos con lenguajes dinámicos. Yo es que soy bastante torpe y a mi el compilador, como primera línea de apoyo, me ayuda mucho.

Respecto al autocompletar, indica que con Tern.js o Flow todo se autocompleta. Pues entonces será que yo no soy capaz de configurar un mísero plugin de Tern.js o Flow. Aunque me extraña que me autocomplete los métodos de un objeto que recibo como parámetro cuando todavía no he usado esa función en ninguna parte del programa… me leerá la mente?

Menos mal que en la sección de conclusiones ya me dice lo que yo estoy pensando, que en TypeScript las herramientas son mejores y los errores son mucho más descriptivos que en Tern.js o en Flow. Según él, porque los IDEs de Tern.js y Flow simplemente están peor implementados, porque que podrían estar a la par perfectamente. Cosa que no comparto. En TypeScript los errores dan más información porque tienen más información sobre el código.

Al final acaba diciendo que la curva de aprendizaje de TypeScript es importante (totalmente de acuerdo) y que hay equipos que a lo mejor no tienen los recursos para afrontarla. Cosa que puede ser razonable. Pero no sé yo qué curva será más pronunciada, si la de un programador JavaScript que tiene que aprender TypeScript o la de un programador Java/C# que tiene que aprender JavaScript. Yo creo que es más pronunciada la segunda. Es más, para un desarrollador Java/C# posiblemente TypeScript les parecerá un lenguaje más fácil de usar que JavaScript. Por tanto este argumento depende mucho del contexto.

En resumen, se pregunta si TypeScript merece la pena por el coste que tiene su uso frente a las nimias ventajas. Para mi si merece la pena porque yo creo que me ayuda mucho más que ese 1% que él indica.

Mi propia conclusión es que mira que me extraña que Tern.js y Flow sean capaces de ofrecerte lo mismo que te ofrece TypeScript sin tener que poner el tipo por ningún sitio. Si eso fuera cierto, yo me pregunto… entonces los de TypeScript son tan torpes como yo que no han podido copiar a Tern.js y a Flow? Porque sería bastante absurdo complicar las cosas innecesariamente por el placer de complicarlas si todo se puede hacer con código JavaScript estándar, no?

Lamentablemente, de nuevo parece que es muy complicado hablar de las bondades de una herramienta de forma completamente agnóstica al usuario que la va a usar. Posiblemente para Eric TypeScript no merezca la pena… pero para un programador torpe como yo, cada segundo invertido en especificar el tipo, lo gano con creces por tener la compañía del compilador ;)