Cómo aprender JavaScript y no morir en el intento

Mientrás más pasa el tiempo, más creo que JavaScript es un lenguaje amado y odiado por muchos.

Eso no quita que piense en lo interesante que es, gracias a la cantidad de cosas que puedes hacer tanto en el cliente como en el servidor. Y con esto último no solo estoy hablando de [Node.js]

Estos meses me he propuesto reforzar mis conocimientos en JavaScript, así que decidí escribir este post a manera de resumen de lo que voy encontrando. Espero que sea algo así como un punto de partida para todos aquellos que no nos consideramos expertos en el lenguaje.

Pues bien, aquí las preguntas que tenemos que hacernos antes de entrar a este nuevo mundo:

  1. ¿De qué trata JavaScript? [Este video de casi veinte minutos] lo explica muy bien y está en español-humano :D. Con esto quiero decir que no hay ningún requisito para entenderlo y lo más importante; incluye teoría y ejemplos con código en vivo. Mi recomendación aquí es que le dediques mucha atención y si gustas, podrías seguir paso a paso [las instrucciones que van indicando]
  1. ¿Puedo aprender de manera interactiva? Hasta el momento he encontrado tres lugares con esta metodología de enseñanza. Yo sugiero practicar en al menos dos de estas:
Workshopper (tutorial interactivo de nodeschool). Fuente: Archivo personal
  1. ¿Con qué libro debo empezar? Si quieres contar con un libro de cabecera, te recomiendo que busques [JavaScript: The Good Parts] (Douglas Crockford, 2008). Si bien es cierto no lo he terminado –y para algunos es algo viejo–, hasta el momento me ha sorprendido. Entiendo que hace poco el autor publicó [How JavaScript Works] (2018) pero no lo he revisado. Sinceramente no me sorprendería que sea tan bueno como la primera publicación.
Fuente: [Amazon]
  1. (Bonus) ¿Qué más podemos hacer? Sin ánimo de caer en un posible ataque de [infoxicación], he encontrado material muy interesante que dejaré a su elección:
    • Este [video] de los amigos de FreeCodeCamp es de 3 horas (y no terminé de verlo) pero explica paso a paso el tutorial ofrecido en su web.
    • Este [tutorial de JavaScript], siempre y cuando busques una –extensa– referencia adicional.
    • Estos videos del buen Douglas Crockford en los que habla de [The good parts], [The better parts] y claro, un link a [la sección de videos] que tiene registrados en su blog.
    • Por último (y no menos importante) consideren la opción de buscar ayuda o mejor aún, aprender en conjunto. Para esto les comento que los amigos de NodeSchool brindan esa opción y aquí en Lima hay una reunión una vez al mes. Aquí [la cuenta de twitter] por si están interesados en los próximos eventos 🙂

Como podrán notar hay mucho por estudiar, pero gracias a la cantidad de recursos disponibles, cada vez es más fácil poner en práctica nuestros conocimientos.

Les sugiero que no pierdan las ganas con este lenguaje, pues tiene mucho potencial a pesar claro, de la relación amor-odio que les comenté al iniciar esta publicación. Esto lo comprenderán con el paso de las líneas de código que vayan escribiendo 🙂

Un abrazo,

3 recursos para aprender Docker

Si bien es cierto esta tecnología lleva [más de cinco años en el mercado], he notado que todavía es novedad para muchos desarrolladores de software. Yo creo que no tendría sentido crear contenido explicando a dealle [¿qué es Docker?] o [en qué se diferencia con tecnologías de máquinas virtuales], pues ya hay mucho de ellos en la red. En vez de eso podríamos reflexionar y hacernos las siguientes preguntas:

  • ¿Tenemos problemas para preparar un nuevo ambiente de desarrollo? Quizá esto se puede hacer pero requiere mucho tiempo y revisar un manual que pocos logramos comprender.
  • ¿Tenemos un programa que solo funciona en la máquina de un desarrollador? Es decir, ni siquiera en la máquina de otro desarrollador.
Fuente: [Geek Republic]
  • ¿Tenemos problemas de instalación por las dependencias entre aplicaciones o versiones de librerías?

Si hemos tenido al menos uno de estos casos, quizá le tenemos que dar una oportunidad a Docker, tecnología que nos permite aislar nuestro entorno de trabajo de nuestras máquinas, haciendo que nuestros desarrollos sean más portables.

Arquitectura Docker, fuente: [XenonStack]

Debido a que hay muchos caminos para aprender esto sugiero que nuestro punto de inicio considere lo siguiente:

  1. Este [video de 12 minutos], que si bien es cierto está en inglés, lo explica todo de una forma tan sencilla que hasta te da ganas de entrar a la línea de comandos y empezar a trabajar 🙂
  1. Este [tutorial que explica paso a paso] lo mínimo indispensable de Docker y este [con una explicación sencilla] de cómo crear una aplicación real 🙂
  1. La [documentación oficial], si bien es cierto fue una de las primeras cosas que revisé cuando empecé a experimentar con Docker, les recomiendo que primero revisen los dos puntos anteriores luego de jugar un poco sigan los ejemplos recomendados en su sección [get-started]
  1. (Bonus) Si por algún motivo, razón o circunstancia (jaja, esa frase es lo máximo) no pueden instalar Docker en sus máquinas, pueden practicar en [este lab]. Para ello solo necesitan una cuenta en Docker y listo 🙂
Play with docker, fuente: archivo personal

Espero que estos recursos sean de utilidad, por mi parte pondré en mis pendientes traducir los tutoriales del punto #2, me parecen muy buenos y creo que con eso eliminaríamos la barrera del lenguaje. Ahora, si alguno ya empezó o se anima a hacerlo, bienvenido sea!

Un abrazo,

10 aspectos a considerar si te interesa la arquitectura de software

Hace mucho que esta idea ronda por mi cabeza:

¿Qué necesito para ser un arquitecto?

Creo que es la consecuencia de tantas conversaciones con mis amigos o conocidos en eventos de tecnología.

Por mi parte –como apreciación personal– les comparto que he tenido la suerte de haber trabajado como arquitecto en más de un proyecto de tecnología y que este tipo de experiencias me ha ayudado a diferenciar entre las funciones que debería realizar un arquitecto y encontrarme con algunos malosentendidos a consecuencia del rol.

Consecuencias de una mala arquitectura
[Code Complete, Steve McConnell, 2004]

Con “malentendidos” me refiero a que me he topado con frases como “nuestro proyecto no necesita un arquitecto” o “ese rol no debería existir” o “los arquitectos no saben programar”, y la verdad es que, así como hay buenos profesionales, también los hay de aquellos que no saben hacer bien su trabajo y que por lo general son los responsables de muchos inconvenientes.

Lo bueno de estas experiencias es que –casi siempre– logramos conseguir –gracias a la apertura del equipo con el que estaba– que el trabajo se pueda realizar de manera exitosa.

En fin, desde mi perspectiva, creo que cada rol existe gracias a una necesidad en particular y de ser así, debería cumplir con algunos criterios fundamentales. El rol del arquitecto no es una excepción, así que he preparado algunos aspectos que me gustaría compartir con ustedes:

1. Saber programar: No hay que ser un experto en programación pero es importante contar con la experiencia suficiente para entender el código del equipo de trabajo, hablar su idioma y claro, participar en los code review.

2. Enseñar con el ejemplo: Si bien es cierto este es un criterio básico de liderazgo, aquí se debe reforzar a nivel técnico, pues todo diseño o presentación debe ir acompañado con código de ejemplo. Sí, con esto me refiero a “la demo” y claro está, no tiene que ser algo completamente funcional pero debe demostrar la factibilidad de nuestra propuesta.

3. Conceptualizar: Esta capacidad será complicada de adquirir si creemos que un arquitecto tiene que ser un programador con mucha experiencia. La clave para acortar el camino, es dejar dejar de pensar en líneas de programación para hacerle un espacio a los componentes y sus tipos de integración.

4. Ser estratégico: Lo “fácil” de esto, es diseñar soluciones flexibles (fáciles de modificar o extender). Lo complicado viene cuando olvidamos los objetivos del negocio y sus respectivas restricciones. Esto implica que tengamos la facilidad de conversar tanto técnicamente, como en términos del giro del negocio. Luego de superar esta barrera, debemos proyectar lo que podría ocurrir en el futuro.

5. Presentar efectivamente: Como regla general, toda propuesta de arquitectura debe ser concreta, de fácil entendimiento y claro, con una “demo” que evidencie la factibilidad de nuestro trabajo. Esto pasa a segundo plano cuando tenemos que enfocarnos en ser concretos y convincentes al momento de explicar nuestras ideas.

6. Ser humilde: Debemos eliminar cualquier tipo de barrera a consecuencia del “poder que llevas por tener este rol”. Una forma de acortar distancias es dejar el ego a un lado para escuchar sugerencias, aceptar nuestros errores y si se da el caso, pedir disculpas de la única forma en la que se deberían pedir, con honestidad y sin condiciones.

7. Estudiar y poner en práctica: Además de reforzar nuestros soft skills, necesitamos entender la importancia de la [construcción de software], la [programación orientada a objetos], los beneficios del [código limpio], comprender los [patrones de diseño], averiguar sobre los [tipos de arquitectura] que existen en el mercado, las [nuevas tendencias de arquitectura] y claro, debemos [programar] en nuestros ratos libres.

8. Leer: Los líbros técnicos tienen que ser algo normal en nuestras vidas, pero también debemos incluir cualquier otro tipo de lecturas. El tópico queda a nuestra elección.

9. Preguntarnos ¿qué más podríamos hacer? Esto aplica al diseño en el que estamos trabajando, pero tiene más sentido cuando lo revisamos en nuestra vida profesional (pues lo natural es que evolucionemos a arquitectos empresariales) y ¿por qué no? también deberíanos hacernos la pregunta a nivel personal.

10. Sentido común: Yo creo que esto es algo que se puede entrenar y que podría tomar más tiempo del que pensamos, no por algo dicen que termina siendo “el menos común de los sentidos”. Pero no nos desanimemos, tomemos un momento para respirar y revisar si estamos construyendo un [homeromóvil] cuando lo que realmente necesitamos es algo tan simple como un skate.

Desde un punto de vista netamente personal, creo que cada aspecto tiene muchos requisitos y restricciones que se deben ir superando en el camino y si llega el momento en el que te das cuenta de que no te estás divirtiendo, pues es posible que tengas revisar otra vez si te gusta lo que estás buscando, o mejor aún, no presionarte pues nadie es perfecto y menos, un excelente arquitecto.

Un abrazo, JD

¿Qué aprendí luego de haber liderado un programa de entrenamiento?

Al culminar la universidad, se me ocurrió la –¿genial?– idea de dictar un curso de programación. Creo que era muy joven –e inocente– para lanzarme con esa aventura y la verdad es que no sabía lo que me esperaba.

Fuente: [Archivo personal]

Recuerdo que inicialmente eramos dos personas interesadas en dictar el curso. Mi primera tarea fue preparar el temario de las clases (que serían semanales y durarían al menos dos meses) e invitar a todos los alumnos que estuvieran interesados (aún recuerdo que imprimí y pegué muchos anuncios en mi querida facultad). Mi compañero de proyecto –o locura– se encargaría de conseguir un aula con las respectivas herramientas (proyectos, computadoras, etc) y luego de esto, nos repartiríamos el dictado de las clases.

Fuente: [Archivo personal]

Al finalizar la primera clase, mi amigo me dijo que no tendría tiempo para continuar. Escuché sus palabras y acepté lo que en adelante se convertiría en una de las aventuras más interesantes de mi vida. De eso me gustaría escribir con más detalle pero aquí algunas lecciones que aprendí en ese camino.

  1. Preparar clases con –mucha– anticipación: Es importante separar un horario de preparación de clases. En este revisaba toda la información que quería compartir y si me daba el tiempo, practicaba lo que iba a hablar (al menos una vez)
  2. Si hay laboratorios o “hands-on”, se deben probar con anticipación: Tienes que encontrar una forma de probar tus laboratorios. En mi caso imprimía el material y lo ejecutaba paso a paso. Al encontrar observaciones, las anotaba y luego actualizaba el documento. Esto lo hacía al menos una vez.
  3. Ser paciente: No todos los alumnos conocían lo que yo hubiera esperado. Es por ello que ahondé en los fundamentos y modifiqué el contenido de las clases planificadas.
  4. Ser empático: Entender la causa de algunas preguntas y el comportamiento de los alumnos fue una habilidad que fui ganando con el paso de las clases.
  5. Ser sincero: Hubo situaciones en las que las que la clase no me salía como esperaba, o en las que no podía responder todas las preguntas. Antes estos casos siempre funciona el “faltó tiempo para prepararme” o el muy difícil “no lo sé”, con la promesa de averiguar al respecto. El ego no funciona.
  6. Promover la diversión: Esto no solo involucra hacer bromas en clase. En mi caso buscaba que haya participación de los alumnos. Para esto preparaba casos que resolvíamos en clase, a veces hacía preguntas como si fuera un juego de trivia y –ok, lo admito– otras veces solo hacía bromas.
  7. Promover la competencia: Casi todos los inicios de clase, hacía preguntas sobre las clases anteriores. En algunas ocasiones dejaba tareas para que los alumnos trabajen en conjunto y presenten algo al respecto. En otras tomaba algún examen y compartía la solución o promovía la conversación o el debate.
  8. Ser transparente: En cada clase compartía los puntajes por alumno, en esa época usaba excel e indicaba cómo se movía el tablero de posiciones. De haber un problema con el avance del curso, también lo compartía con los alumnos.
  9. Pedir ayuda: Hubo un momento en el que ya no pudimos usar el salón que nos había prestado, así que recurrí a la empresa en la que trabajaba pues ellos tenían una sala que nos vendría –y nos vino– muy bien.
Fuente: [Archivo personal]

Si bien es cierto, de todo esto ya ha pasado mucho tiempo y fue duro –y a veces triste– trabajar practicamente solo, pero aprecio todo lo ocurrido y claro, admito que mi ego hizo que cometiera errores. Por suerte el balance general arrojó un grupo de chicos muy inteligentes que poco a poco logró conseguir un empleo y que de alguna forma ese curso impactó en sus vidas.

Fuente: [Archivo personal]

En mi caso, la empresa en la que trabajaba me pidió que lidere un segundo programa de entrenamiento (y lo que en el tiempo formaría parte del trainee de la compañía), pero ya con presupuesto que ellos admistrarían. Este también fue un capítulo que aprecio bastante y al igual que el anterior, forma parte de uno de los proyectos que cambió mi vida personal y profesional.

Me gustaría terminar esta publicación agradeciendo a todos los que participaron en ese sueño, y claro, también recordando que una noche, ya caminando hacia la salida de la universidad, uno de mis amigos (y también alumno) me preguntó por qué dictaba el curso. Aún recuerdo lo que le respondí “es que no tenía opción, ya habíamos empezado y no quería dejarlo así”, no sé si estuvo mal responder eso, pero me alegra mucho haber participado en sus vidas.

Un abrazo,

Fundamentos, fundamentos, fundamentos

Si hay una de las tantas cosas que aprendí del gran [Randy Pausch], es que, si no entiendes los fundamentos de lo que sea que estés haciendo, terminarás haciendo cualquier cosa.

Lo gracioso es que, por más simple que parezca, esa enseñanza se puede aplicar a cualquier ámbito de nuestras vidas. Personalmente me ha servido en muchos rubros, incluyendo en el extraño –y amado– mundo de la tecnología.

Todo esto me vino a la mente pues hace unos días terminé de leer (una vez más) [The Last Lecture] (Pausch, 2008) y solo puedo decir, muchas gracias Randy, tengo pendiente por escribir tantas cosas sobre tus enseñanzas, pero de momento quiero publicar este pequeño detalle.

Aquí un [video] que es una de las razones por la que es mi héroe (además claro, de mi mamá)

Sin más me despido, un abrazo, JD

new beta release in process