Introducción
Con este llamativo título, Michael Woloszynowicz escribía recientemente una entrada en su blog a modo de llamada de atención para los desarrolladores Javascript.
Al estilo del artículo Los programadores que no programan, Michael denunciaba que muchos desarrolladores están engordando sus currículums afirmando ser expertos en lenguajes que realmente no conocen. Esta preocupante tendencia parece agudizarse cuando nos referimos a la familia de lenguajes web: HTML, CSS y, especialmente, Javascript.
La falsa sensación de dominio total
El motivo de todo esto es doble: por un lado, los lenguajes web están de moda y todo desarrollador debe ser capaz de programar sin dificultad en cualquiera de ellos; por otro, suelen ser considerados lenguajes fáciles y muy asequibles: en realidad, tanto HTML como CSS podrían no considerarse estrictamente como lenguajes ya que apenas participan de una lógica computacional seria. Con tan solo un puñado de palabras reservadas y estructuras repetidas hasta la saciedad, es relativamente sencillo construir un sitio.
Pero nada más lejos de la realidad. Conocer el marcado HTML y la semántica que hay detrás no resulta tan trivial como le puede parecer a quien se acerca por primera vez: con solo ojear el código fuente de cualquier proyecto web, podremos ver cómo las normas más básicas o recomendaciones del W3C son pasadas por alto. En cuanto a las CSS, el argumento es similar: aquellos que realmente las dominen sabrán la complejidad que algunos maquetados (desgraciadamente) encierran. En definitiva, es extremadamente raro encontrar a un desarrollador web que haya reparado en leerse las especificaciones de los lenguajes que utiliza a diario…
En el caso de Javascript, el error no puede ser mayor: la mayoría de los programadores necesitan recurrir a este lenguaje en uno u otro momento. Cuando apenas se conocen sus conceptos básicos, la tendencia más común es lanzarse a buscar ejemplos de códigos (snippets) que puedan ser implementados ràpidamente a través de un sencillo copy/paste. Dada la gran flexibilidad de algunos scripts, esta técnica suele funcionar, especialmente cuando se trata de plugins para bibliotecas tipo jQuery o Mootools. El principal problema de esta metodología de aprendizaje es que realmente no se llega a comprender el comportamiento que hay detrás de cada uno de esos bloques de código dando una falsa sensación sobre nuestro dominio del lenguaje.
Cuando llegan los encargos para construir aplicaciones complejas, los tutoriales en la web comienzan a mostrar conceptos exóticos como módulos, herencia prototípica, patrones de diseño, delegación, constructores o clausuras y con ellos, nuestra falsa idea inicial de dominio del lenguaje comienza a difuminarse.
Comienzan así las pruebas a ciegas donde echamos mano del patrón copy/paste; pero ahora las piezas no encajan: los errores se multiplican, nuestros conocimientos en otros lenguajes como por ejemplo Java o PHP no sirven pues la naturaleza de Javascript es diferente y la aplicación no funciona como se espera. Terminamos maldiciendo al lenguaje y comentándole al cliente que su proyecto no es consistente, que Javascript no ofrece la potencia, flexibilidad o seguridad necesaria para llevarlo a cabo y tratamos de sugerir alternativas en las que nos sintamos más cómodos… Y es que, por supuesto, es difícil terminar admitiendo que no conocemos el lenguaje: Javascript es un lenguaje web y, como tal, tiene que ser fácil y debemos dominarlo sólo por el hecho de haber implementado alguna vez un plugin jQuery con un bonito slideshow…
Niveles de conocimiento
Para poder crear un rasero con el que medir nuestro conocimiento real del lenguaje, podemos dividir sus conceptos en tres niveles diferentes: básico, intermedio y avanzado.
Cada una de estas categorías recogería las siguientes habilidades:
Un nivel básico de Javascript requiere:
- Conocer la sintaxis básica de programación: bucles, condicionales, try/catch, etc…
- Entender cómo se declaran las funciones (incluyendo las diferentes formas posibles para hacerlo así como las llamadas funciones anónimas).
- Entender los principios básicos de los distintos ámbitos (scopes): ámbito global vs ámbito de objeto. Excluímos aquí las clausuras.
- Entender el rol de los distintos contextos y el uso de la palabra reservada this en cada uno.
- Entender las diferentes maneras de declarar o instanciar un objeto así como las formas de convertir las funciones en éstos.
- Entender los operadores de comparación Javascript como ‘<‘, ‘>’, ‘==’, ‘===’; valores falsy y cómo funciona la comparación entre objetos y cadenas así como el cambio de tipos (casting).
Un nivel intermedio debería requerir:
- Entender los tiempos de ejecución, cómo funcionan, y cuándo/cómo pueden ser útiles. También incluimos los métodos de ejecución asíncronos.
- Conocimiento profundo de los callbacks y de los métodos call y apply para controlar el contecto y los argumentos que se envían a las funciones.
- Comprender en profundidad la notación JSON y el funcionamiento de eval.
- Entender las clausuras, cómo afectan al rendimiento del código, y cómo pueden ser usadas para crear variables privadas mediante el patrón módulo.
- AJAX y serialización de objetos.
Un nivel avanzado de conocimiento incluye:
- Conocer el valor arguments y cómo puede ser utilizado para sobreescribir funciones: recursividad.
- Clausuras avanzadas como los patrones memoization, curry y aplicaciones parciales.
- Prototipos, cadena prototípica y cómo usar estos conceptos para minimizar el tamaño de nuestro código.
- Tipos de objetos y el uso de instanceof y typeof.
- Expresiones regulares.
- Qué expresiones no deben utilizarse (bad patterns)
- Y, finalmente, cómo combinar todo lo anterior para construir aplicaciones sólidas, limpias, rápidas, mantenibles y compatibles.
El punto final, es especialmente importante porque puede darse el caso de que conozcamos los anteriores en mayor o menor medida pero no la forma de integrarlos en un todo. Este aspecto es el que finalmente denominaríamos arquitectura Javascript y corresponde a los cimientos en los que tiene que asentarse todo proyecto serio. Es el camino opuesto a un código tipo spaghetti realizado sin ninguna planificación previa.
Conclusión
Como puede comprobarse a través de todos los aspectos mencionados anteriormente, Javascript es algo más que manejar eventos con nuestra biblioteca favorita o validar un formulario. Es cierto que podemos solventar muchos de estos puntos utilizando nuestro tradicional copy/paste; sin embargo, con esta técnica, podemos llegar muy fácilmente a un callejón sin salida donde continuar avanzando resulte simplemente imposible.
La mejor garantía para afrontar un proyecto de envergadura es, como con cualquier otro lenguaje, conocer el comportamiento de las herramientas que utilizamos lo mejor posible. De este modo, si no encontramos el snippet adecuado o tenemos que modificar el comportamiento de uno concreto, estaremos en disposición de hacerlo nosotros mismos sin mayores problemas.
Al final, todo es cuestión de tiempo y dinero. He visto ya algún que otro proyecto que empieza con un planteamiento correcto o casi correcto de Javascript y luego a medida que avanza, se piden tal cantidad de cambios y en ocasiones en tampoco tiempo que es cuando se empiezan a hacer modificaciones independientemente si sea la más adecuada o no… ya que la cuestión es que acabe funcionando.
un saludo
Cuanta razón, pero creo que es algo que pasa mucho en este mundo, no sólo a nivel web si no en cualquier lenguaje o tecnología.
Yo por mi parte considero que tengo una nociones intermedias del lenguaje, y la verdad es que leyendo la clasificación que comentas, se confirma, pero he visto mucho casos de desarrolladores «front» que están sólo saben copypastear y que al mínimo problema se vienen abajo y empiezan a quejarse de JavaScript como si fuera lo peor del mundo, cuando la realidad es que no saben como usarlo (yo reconozco que me faltan muchos conocimientos, pero lo se e intento entender las cosas y mejorar en vez de quejarme) y como bien dices no sólo JavaScript, también HTML, CSS pueden ser malentendidos si no sabes como funciona, aunque sea muy pesado, hay que leer las especificaciones de los lenguajes para conocerlo realmente.
De todas formas bien es cierto que JavaScript es un lenguaje complejo y con muchas cosas mal implementadas, acabo de terminado de leerme JavaScript: The Good Parts y ahí se pueden leer muchísimas de las cosas que están mal o deficientemente implementadas (imagino que lo mismo pasa con muchos otros lenguajes). Lo bueno del libro es que te explica cuales son, como evitar lo problemas, y cómo usar la mejores «partes» del lenguaje.
Un saludo.
yo creo que es un problema de formacion, te imaginas que a un medico le dijesen: mañana operas a alguien de corazon, como no sabes, busca algo en internet y aprende sobre la marcha…
Pues a mi eso me pasa un dia si y otro tambien, cosas imposibles, en plazos ridiculos, solo porque el comercial de turno queria su comision del mes.
Es cierto que es muy facil no saber cual es tu nivel real con respecto a la media, pero…¿quien es la media? porque yo he trabajado para carnicerias con un monton de licenciados (en fisica, quimica, historia) y daba risa, tambien he trabajado en empresas que «solo» aceptaban informaticos con carrera (bueno sin contarme a mi que me quede en segundo 8) ) y si, sabian mas de matematicas que yo, pero seamos serios, el nivel de programador que te dan 5 años de carrela lo cojes programando 8 horas al dia en 1 año
Jo que agusto me he quedao, bueno lo importante, si yo quisiese comprobar mi nivel ¿como lo hago? ¿me gasto 6.000€ en un papel que dice tienes un master?
porque la verdad soluciones pocas, leer libros llega un momento en el que no progresas mas, y en el trabajo tampoco es que puedas experimentar mucho rato, con los plazos que se manejan como para andar practicando ¿en casa? como que paso de sacrificar mi vida social
¿sugerencias?
Pues no queda otra que hacerlo por nuestra cuenta Guzmán; no se trata de sacrificar nuestra vida social sino de ser responsables para/con lo que hacemos. Siguiendo tu ejemplo, ¿te imaginas a un médico que no leyera los artículos más recientes de su disciplina? ¿o que desconociera cuáles son las nuevas técnicas para operar ese corazón con el menor riesgo para el paciente?
Creo que la clave es siempre la autoformación: leer libros, artículos y estar siempre al día. Con lo aprendido una vez no vale. El trabajo no es un buen escenario para experimentar porque siempre sueles tener plazos y criterios de calidad que no podemos comprometer por querer aplicar el patrón de diseño más puntero. Las pruebas hay que hacerlas en casa, con calma…
Al menos yo es así como lo hago: cada día (o dos) reviso la actualidad mediante los canales de noticias y las páginas que las recogen; miro qué es interesante y qué no. Luego trato de aplicarlo o al menos retener la idea por si la puedo necesitar más adelante.
Con respecto a todo lo demás que has comentado, estoy plenamente de acuerdo.
Un saludo y gracias por tu interesante aportación!
muy buen articulo, yo antes toqueteaba con javascript y en si era un lenguaje que odiaba, me parecía que estaba mal diseñado (en realidad si tiene problemas de diseño) que era limitado y no servía para proyectos grandes, asi que cuando escuche de nodejs me parecío un poco ilogico que se usara javascript.
con el paso del tiempo he aprendido nodejs y he tenido que aprender javascript, la verdad es que es un lenguaje mañoso aunque con el tiempo se le agarran los trucos y es magnifico, si bien tiene algunos «errores» de diseño, es un lenguaje muy flexible, bastante expresivo y con mucho potencial, las cosas que odiaba antes de javascript ahora son casi las que mas me agradan y las que mas encuentro utiles.
El problema es que javascript es el lenguaje menos entendido del mundo, en realidad no es un lenguaje orientado a objetos aunque tiene objetos, no es un lenguaje funcional aunque tiene características de este, a la final es una mezcla bastante rara de ideas diferentes, el problema viene cuando alguien con solo conocimientos de orientación a objetos intenta usarlo, entonces se da cuenta que no tiene orientación a objetos sino algo similar aunque a primera vista, menos poderoso y mal implementado, lo mismo pasa si vienes de un lenguaje funcional como lisp, donde encuentras cosas muy buenas de lenguajes funcionales pero le faltan otras cuantas, a la final para entender bien js necesitas conocer muchos paradigmas…
algo que es bueno destacar es que javascript es mas que un lenguaje para manipular el DOM, creo que una de las desventajas que ha tenido javascript es que se le relaciona solo con esto, además existen muchos libros de mala calidad donde ofrecen a enseñarte javascript, cuando en realidad solo te enseñan las cosas básicas y como manipular el DOM, para manipular el DOM, ahora que javascipt tambien esta del lado del servidor, donde toda la logica del sitio se tiene que escribir en puro js…es cuando la mayoría notará que sus conocimientos de js no eran tan solidos, además espero que aparezcan libros mas completos donde se adentren en la construccion del lenguaje….
¡Que titulo!, desde el principio sentí que el articulo era dirigido a personas como yo. Yo solía, y todavía lo hago (honestamente), el recurrir al «copy & paste» para completar proyectos, aunque actualmente ya he estado metiéndome a las entrañas de JavaScript; aprendiendo todo lo que debe ser aprendido sobre este útil lenguaje en la web. Ciertamente el recurrir a la pedaceria de código, se tiende a conseguir aplicaciones lentas, llenas de errores y aveces hasta de difícil mantenimiento.
Suscribo casi cada palabra de GUZMAN:
Solo quiero enfatizar que lo de ser autodidacta está muy bien cuando eres estudiante y gozas de más tiempo libre; pero cuando estás trabajando diez horas para una empresa ni se me pasa por la cabeza ponerme a aprender por mi cuenta, simplemente por satisfacción personal de generar buen código para que luego se aproveche la empresa de turno y esta ni siquiera te dé las gracias, porque no sabe distinguir un buen código de una mierda pinchada en un palo. Los que curramos seguro que tenemos el culo pelado de que nos digas «me da igual cómo lo hagas, solo quiero que funcione».
Las empresas deberían considerar que realizar cursos de reciclaje y formación no solo ayudan al trabajador, sino a la empresa.
Mi opinión personal es que el trabajo y sus exigencias no son excusa para no continuar la formación. Yo lo veo como nuestra obligación profesional siempre que realmente te guste lo que haces.
Yo he trabajado a esos ritmos y con una carga de criticidad que podríamos considerar extrema. De hecho, si ojeas el artículo Programando para la Administración Pública, entenderás que no se trata de un relato ficticio.
No se me ocurre peor escenario que el dado en un Ministerio: tiempos de entrega absurdos con la peor calidad de código imaginable. Pero aún así, sacaba tiempo para continuar investigando en los ratos libres.
Gracias a eso, hoy por hoy ya no trabajo ahí, sino donde yo he elegido hacerlo.
Creo que la recompensa compensa el esfuerzo, pero es solo mi opinión 😉
La tuya me parece también correcta y en nada reprochable.
Saludos!!
Excelente artículo.
Es cierto que hoy en dia existe la sensación de dominio del lenguaje por muchas personas que a duras penas pueden entender el API de jQuery.
Siendo honestos, hay que reconocer que (por desgracia) el 90% del desarrollo web existente no requiere mucho más que eso.
Disiento en los requisitos que planteas para hablar de nivel avanzado, el cual en mi opinión requiere un mínimo conocimiento de la especificación, base fundamental para poder entender el detrás de escena de las interacciones que se dan en nuestro código.
En cuanto al nivel de analísis y coherencia del código a nivel proyecto, tengo que admitir, que en mi experiencia llegue a cumplir todos los requisitos que definís para un nivel avanzado sin llegar a determinar un modelo de sistema claro. Lo cual demostraba que lo que yo no sabía no era JavaScript, sino conceptos básicos (y no tan básicos) de programación y analísis.
Saludos.
Hola Valentín!
Haces una reflexión muy interesante que ciertamente habría que destacar: en la programación avanzada, muchos de los requisitos exigibles a un desarrollador no son tanto conceptos del lenguaje en sí, como ideas generales de programación y análisis.
Es por esto que además lenguajes concretos, tenemos que estudiar y manejar conceptos como patrones de diseño, arquitectura de software y otras materias generales de programación que son siempre aplicables.
Saludos!
Excelente post, tenes mucha razón.
Ya te estoy siguiendo en mi reader!
Saludos,
Jonathan
Simplemente genial! Seguiré este blog.
Tienes razón en que el método copy-paste no es el mejor para comprender realmente un lenguaje. Hace que uno se meta en jardines complejos sin haber entendido realmente lo básico. En mi caso conozco partes de los 3 niveles que mencionas pero no domino ninguno de ellos al completo y eso me lleva a situaciones de confusión al programar o al analizar el código de otras personas.
¿Cuándo vas a escribir un libro sobre JS? Podrías estructurarlo en esos tres niveles y explicando los conceptos esenciales de cada uno… Así no tendría que ir saltando de un artículo a otro 🙂
Gracias y un saludo,
Diego.
Creo que tienes razón, solo basta utilizar algún motor de búsqueda, casi cualquier tema y verificar el código de alguno de los Sitios Web o incluso de aplicaciones Web y se encuentra errores de validación de HTML, XHTML, etc. O en las Hojas de Estilo en Cascada (CSS) en su mayoría la versión 2.1, en las cuales incluyen atributos que no son parte de esa versión o no son ni siquiera una recomendación del W3C. Y que solo se agrega por los efectos visuales, irrumpiendo las reglas de los Estancares Web: Lo cual causa la falta de Accesibilidad, Usabilidad, Internacionalización, Independencia de dispositivo, entre otras.
En lo que es JS, es raro que se utilice puro, casi siempre se usan las derivaciones como Jquery, prototype, mootools. Y creo que esta bien pero no excederse solo por crear efectos bonitos, si no para darle mejor Usabilidad a los Sitios y Aplicaciones Web.
En lo personal, no utilizo las cosas solo por ahorrar trabajo, prefiero analizar los códigos, para ver como se usa el lenguaje, leo las guías y las mejores practicas e investigo que ventajas y desventajas tiene el uso del cogido. Por ejemplo cuando uso Jquery, analizo la manera de agregar lo pero sin que comprometa las funciones del Sitio y/o Aplicación Web, es decir, si me deshabilitan JavaScript (JS) debería de poder seguir usando las funciones.
De entrada, muchas felicidades Carlos Benítez por un estupedo blog, y por fin encuentro el gurú que he andado buscado, y no me decepcionas con el «utliza los framework q ya estan echos», en cambio me invitas y me demuestra el poco conocimiento que tengo de JS, bueno en realidad no es poco, creo que le tiro a medio avanzado, trato de hacer experimentos en mis proyecto y de implementar lo que leo en cuanto lo descubro. Llegué a tu blog tratando de buscar como se llama JSLit y te encontré por tu artículo de JSHint, estuve vagando por tu blog y me pareció excelente y encotré una persona que merece mi respeto profesional como colega….
Ahora.. a tratar el tema, en lo personal trabajo en desarrollo web desde el 2005, lo estudio desde el 2002, en mi carerra técnica(conalep), SOLO me enseñaron C y un poco de C++, mi especialidad es en PHP, JS y Java, ¿quién me los enseñó? en definitiva no lo aprendí en una escuela lo aprendí de Internet, blog, libros, practicar, tomar esto como un hobbie mas, no como una tarea o un trabajo, hoy trabajo en mi hobbie, me da $$$ y eso está de lujo y económicamente no me puedo quejar… creo que el «no me lo enseñaron en la escuela no cabe», nunca saldrás preparado para todo, «las novedades» no son tan nuevas, solo que los verdaderos desarrolladores llegaron a JavaScript, estas técnicas no soy de hoy ni de ayer, son de hace años pero apenas se están conociendo y aun hay muy pocos manejan JS de manera decente, la gran mayoría utilizan jQuery y de mas herramientas y ya se sienten gurus U.u.. que no está mal, pero creo que tampoco es el mejor camino, sobretodo cuando quieres llegar al nivel avanzado o experto, no ser un usuario de jQuery si no un partner alguien que aporta y propone, no solo el que consume.. últimamente me he divertido desmenuzando jQuery =D..(es algo interesante).
y por último creo que el decir, no tengo tiempo, ¿y mi vida social?, son sacrificios, y aun así se puede combinar, yo me tomo una o dos horas de mi día laboral (cuando hay tiempo) para leer las novedades o libros y busco la forma de implementarlo inmediatamente en el próximo proyecto o incluso en el que se está realizado, proyecto a proyecto he tenido mis prácticas y mi codificación ha evolucionado, hoy no tiene nada que ver el JS que hago con el que hacía en mi primer trabajo.. además que JS lo aprendí solito sin un profe, solo leyendo y practicando… creo que es el camino y el compromiso profesional que tenemos con nuestra carrera, un profesional no solo es pasar las materias en la universidad y salir a «trabajar» y ganar dinero.. es una carrera de todos los días…. vamos es una Carrera… que termina cuando te retiras…
se java y se lo que es la orientación a objetos desde C++, y creo que JS es orientado a objeto, solo que bajo distinto paradigma (el prototipado), pero es clásico que el que viene de java y C diga que JS no es orientado por que lo quieren ver con el paradigma de OOP con Clases y no aquí se manejan Prototipos(es casi lo mismo, pero no es lo mismo).. algo que con la practicas y al entender que estas en JavaScript y no en otro lenguaje se llega a comprender y te das cuenta que puedes hacer casi todo lo que te propones en cuanto a OOP se refiere… si falta algunas cosillas pero… no por que Java carezca de Herencia múltiple ya no es un lenguaje Orientado a Objetos…
Maestro… sinceramente es todo tal cual comentas en el artículo, además tus conocimientos son realmente dignos de admiración.
Como especialista en performance y luego de haber trabajado en muchas mepresas grandes de la web te puedo decir que aca hay una razon a medias. Me paso a explicar, generalmente los programadores no deciden que hacer, sino como y es facil pensar «nosotros decidimos el ‘como’ entonces lo hacemos bien, planificado, pensado sin que se nos escape nada!» ERROR, nosotros decidimos el ‘como hacerlo’ pero estamos condicionados por una variable, el tiempo/dinero y eso esta en otro ‘scope’… el que pone la plata decide que recursos tenes y uno se tiene que adecuar a lo que el que manda dice; logicamente el que tiene la plata no sabe nada de sistemas y quiere primero que ande y luego nos llama a los que vivimos haciendo refactorings para que lo arreglemos todo y lo hagamos rapido y seguro.
Basicamente, las empresas funcionan asi porque mientras un producto les deje dinero no les importa nada, solo se dan cuenta que algo falla cuando la billetera adelgaza.
Saludos desde Buenos Aires!
Creo que el “patron copy paste” deberían incluirlo en el articulo de wikipedia sobre patrones de diseño XD
La razón del control C perezoso tal ves se deba a los malos “tutoriales” que hay en la web. Donde en su mayoría solo extraen algo de la documentación oficial de (digamos jquery) y lo suben a su blog para sentirse bien por los comentarios
Lo único que les faltaría ponerles es “Les aclaro que no probé el código”
Algo parecido pasa últimamente con node.js, donde todo lo que encontramos son 2 cosas (repetidas en TODOS los artículos) al buscar en google:
1- node.js es lo mejor que le paso a la web, y todo lo que has usado hasta ahora es mierda, especialmente php
Titulo que debería transcribirse como:”nunca uso ni usare node.js mas allá del copy paste. De hecho no he trabajado en proyectos en php mas interesantes que crear un theme wordpress, y si por casualidad se me da la gana de usarlo, instalare el modulo Express.js y haré mas copy paste porque realmente no necesito un app en la capa de servidor pero se me da la gana de que sea así y…”
-bueno, creo que se entendió XD
2- introducción a node js
Lo que debería transcribirse como: otra ves Control C en node.js|| otra ves zopa (y por cierto, no probé el código)
Por mi parte, cada vez que alguien me consulta sobre como debería hacer tal o cual cosa, nunca escribo código ni pseudo código. Todo lo que hago es crear un diagrama y explicárselo, y lo hago de ese modo puesto que si escribiera algo que pudiera copiar y pegar, la persona tardaría mucho mas en entender realmente como funciona. De hecho, cuando yo era estudiante, necesitaba quitar líneas de código en los programas de ejemplo que encontraba por ahí, para ver su resultado y saber realmente que es lo que pasaba
En otras palabras, se debe enseñar a resolver una situación de manera abstracta, para que el aprendiz pueda identificar y encarar el problema independientemente del lenguaje usado. Cosa que con frameworks no se logra
Pero en fin. Todavía existe gente que se dice profesional, pero también dice “no importa como funcione mientras funcione”
Saludos
Tengo un poco más de 6 meses estudiando Javascript un poco más a profundidad y me he dado cuenta que la validación de formularios y otras cosas minusculas con javascript es solo la punta de iceberg. Está bien explicada la manera cómo, en este artículo, se dividen los niveles de conocimientos.
Definitivamente una lectura para recomendar.
100% de acuerdo. No hay excusas, salvo saber ingles y entrar al material gratuito de udacity.com alli enseñan las mejores tecnicas y puedes ver los videos una y otra vez hasta que entiendas. De verdad que me ha cambiado la vida.