La hora de JavaScript, a tomarlo en serio

Para muchos de mi generación, los que empezamos a programar en la web 1.0 allá por fines de los ’90 comienzos de 2000, Javascript nunca fue “algo serio”. En general uno no aspiraba a ser programador JavaScript. Uno podía definirse como programador de un lenguaje en particular: Java, Php, Visual Basic, C++, etc. y en todo caso si era necesario tiraba algunas líneas de JavaScript.

Claramente los tiempos han cambiando y también JavaScript. Y en un punto las cosas se han pasado de rosca, ahora tenemos gente que directamente se define como “programadores de un framework basado en JavaScript” (react developer, angular developer, etc.) y lamento decir que he visto algunos de estos programadores que apenas si dominan JavaScript y no tienen ni idea de la diferencia en JavaScript y ECMAScript. Ojo, no pretendo hacer un juicio de valor sobre esto, tal vez pueda resultar conveniente saber de React sin tener demasiada idea de JavaScript con el fin de manejar un mayor nivel de abstracción y bajar la carga cognitiva.

En fin, hoy en día JavaScript como lenguaje está en un estado, a mi parecer, bastante maduro. Sin embargo creo que el ecosistema JavaScript aún está medio inestable. Todo el tiempo están saliendo nuevas librerías/frameworks/componentes para resolver cuestiones recurrentes. Es así que a la hora de resolver una problemática hay varias opciones de componentes/frameworks. Esto puede parecer positivo pero es también un arma de doble filo. Cuando un programador experimentado se enfrenta a varias opciones es precisamente su experiencia una cuestión central para elegir la opción a utilizar. Pero ocurre que en el mundo JavaScript hay mucho programador sin demasiada experiencia y en esos casos el tener varias opciones puede resultar más riesgoso. Cuando digo “mucho programador sin experiencia”, lo digo en términos comparativos con otros lenguajes. Cuando vemos la oferta de bootcamps y cursos de programación para gente que se está iniciando en esta disciplina, vemos que la gran mayoría en la actualidad están relacionados a JavaScript y tecnologías de frontend en general.

Al margen de todo lo anterior, hoy en día tenemos herramientas JavaScript para construir interfaces de usuario web (angular, react, vue), aplicaciones móbiles (react native, flutter), y aplicaciones/servicios server-side (nodejs). Esto hace que empiece a sonar muy atractivo tener JavaScript como lenguaje de cabecera, ya que parece esta por todos lados. Sin embargo no hay que tomar esto a la ligera porque si bien estamos hablando del mismo lenguaje de programación, cada escenario implica un stack de frameworks y herramientas distintos. Personalmente, por mucho tiempo no le di mayor importancia a JavaScript y siempre que me lo cruzaba, veía puntualmente de resolver la cuestión inmediata que tenía entre manos sin profundizar demasiado. Pero ya desde hace un tiempo he comenzado a tomarlo más seriamente, estudiándolo más en profundidad.

Recursos varios para aprender Node/JavaScript

Como mencioné hace un tiempo, me he visto en la necesidad de meterme de lleno con Node/JavaScript. Para ello he echado mano de 3 recursos:

  • Libros: tengo una lista de libros que me recomendaron, pero por el momento solo he visto dos libros gratuitos de la gente de Syncfusion: Node.Js Succinctly y JavaScript Succinctly.
  • Tutoriales de nodeschools
  • Sesiones de pair-programming con ingenieros experimentados

Y obviamente mas allá de todo esto: práctica, práctica y más práctica.

Si bien aún me queda mucho por aprender, hay algunas cuestiones que ya tengo claras:

  • El lenguaje JavaScript en términos de sintáxis no me gusta
  • La experiencia de desarrollo es muy “suave”, muy parecida a la experiencia en Ruby e incluso mejor en algunas cuestiones.

Continuará…

Finalmente JavaScript

Como la mayoría de quienes hemos hecho desarrollo web, en algún momento tuve que tirar algunas líneas de JavaScript y sinceramente lo hice sin preocuparme demasiado por aprender seriamente el lenguaje. Hace un par de años, impulsado por NodeJS, JavaScript pegó un salto de popularidad que ameritó que uno  aprendiera JavaScript seriamente. Pero en aquel momento yo me encontraba trabajando en cuestiones de configuration management e infraestructura como código.

Finalmente hace un par de semanas empecé a trabajar en un nuevo proyecto con la gente de Auth0 y eso me llevó a que me ponga a aprender JavaScript seriamente. Es por esto que en futuros post iré compartiendo capítulos de mi camino de aprendizaje JavaScript.

Continuará…

El fenómeno JavaScript

Si bien JavaScript tiene unos cuantos años, desde el auge de la web 2.0 su popularidad ha ido constantemente en ascenso. En los últimos años han aparecido diversas herramientas y frameworks que permitieron a JavaScript ir más allá de los navegadores web.

Como efecto colateral, ya no importa si uno se consideraba programador Java, C# o Ruby, hoy por hoy todo el mundo debe tener cierto manejo de JavaScript.

Personalmente nunca me gustó JavaScript pero a pesar de eso no dudo en usarlo cuando creo que es la opción apropiada para una determinada solución. Eso me llevo a trabajar con jQuery y Node.js.

Recuerdo que hace dos o tres años, mientras que en el mundo JavaScript empezaban a surgir diversos frameworks y herramientas, en el mundo de los Sysadmins empezaban a popularizarse herramientas de automatización de infraestructura. Justamente en el aquel momento me encontré en un contexto en el que tuve que elegir trabajar como desarrollador FrontEnd con JavaScript o bien tomar un rol de SysAdmin/DevOp y meterme con las herramientas de automatización. Precisamente fue esta última opción la que elegí. Creo que profesionalmente aquella fue una elección muy acertada pues el manejo de herramientas de automatización me permitió participar en diversos proyectos muy interesante. Pero hace un par de meses me rendí, siendo consciente que ya no es posible escapar de la marea JavaScript me puse a aprender AngularJS y agregué a mi backlog Meteor y React.

 

JavaScript en OLX

Este semana estuve participando de un entrenamiento en JavaScript organizado por la gente de OLX con quien vengo trabajando desde hace casi un año.

El entrenamiento fue dictado por Kyle Simpson (@getify) y estaba titulado “Advanced JavaScript”. Cómo dijo el propio Kyle durante la apertura, un nombre mejor podría haber sido “JavaScript Foundations”, pues justamente el foco estuvo en cuestiones básicas, de “bajo nivel” en cierto punto, que en mi opinión la gran mayoría de la gente que escribe JavaScript desconoce.

El entrenamiento me pareció muy interesante, me enteré de cosas de las que no tenia ni idea. Ojo, también debo admitir que nunca le puse muchas pilas a aprender JavaScript. He escrito código y aprendido lo poco que sé a base de “prueba y error”. A pesar de esto soy consciente que cada vez es más necesario para todo programador, manejar cierto nivel de JavaScript.js_at_olx

Una cosa que confirmé en el entrenamiento es que nunca voy a llegar a un nivel avanzado en el uso de JavaScript, pues resulta que el lenguaje tiene tantas particularidades/características que llegar a dominarlas me llevaría un tiempo tal que no estoy dispuesto a invertir.

Le agradezco a David Grandes y Santiago Villa del equipo Mobile de OLX por haberme invitado.

Javascript tests running on Jenkins

Nowadays, no matter what technology you use to build your web application, it is almost sure you will need to write some JavaScript code. At the same Javascript script code is not only used to animate the web pages, it is also used to handle validations and application flow. Because of this, everyday is more needed to write unit tests for the Javascript code.

There are several unit testing frameworks for Javascript. In my case I choose Qunit, that is testing framework developed by the jQuery guys.

Of course that in order to be able to write unit tests for your code, you will need to follow some design guidelines, but that is part of another post. Let’s suppose you followed that guidelines and now you want to write some test, these are the steps you should follow to run your tests:

  1. Download qunit.js
  2. Download qunit.css
  3. Write your tests in a javascript file
  4. Create a html page referencing the 3 previous files

With these 4 steps you are almost done, open the html file and you will have your tests executed.

What is missing, is how to run these tests in the build server. The interesting point here is that to run Javascript t tests we need a Javascript engine. In a develop machine, it is not a problem, you can use your browser, but in the build server is not so easy. The approach I took was to use PhantomJS, a tool that among other things, can run Javascript without needing a browser.

So using PhantomJS and MSbuild I was able to have my Jenkins running my Javascript tests.

Here you can download a running example.