En el post resumen del 2015, Alfredo comentaba que echaba en falta una mención a las tecnologías que había adoptado y abandonado, y tiene razón. Suelo focalizar el post de resumen en lo que ha pasado en el blog en lugar de hacer una retrospectiva más amplia.

Aprovechando la idea de Alfredo, en este post quiero hacer un pequeño repaso de tecnologías a las que les he cogido más cariño y las que se están quedando más rezagadas dentro de mis preferencias.

OJO: Esto no pretende ser el Technology Radar de ThoughWorks, ni mucho menos. La elección de la mayoría de estas tecnologías tiene detrás una historia y un contexto que es tan importante o más que los méritos puramente técnicos.

En este resumen me centraré en las tecnologías usadas a nivel profesional, porque son a las que más horas he dedicado y de las que puedo ofrecer una experiencia más real. Antes de nada, quiero reseñar que profesionalmente me dedico a desarrollar productos, no proyectos, y son productos que llevan años en el mercado y (espero) duren años en el mercado, por lo que no siempre es fácil saltar a la última tecnología de moda y se arrastran (para bien y para mal) decisiones del pasado.

Las dos plataformas con las que más trabajo son .NET y Javascript. El peso de Javascript es cada vez mayor y eso se nota. Al tratarse de un lenguaje que usamos más en nuevos desarrollos, todavía tenemos menos decisiones acumuladas del pasado y podemos experimentar más.

.NET

En la parte de .NET ha habido menos experimentación, pero tuvimos un par de desarrollos web en los que teníamos más libertad. En uno decidimos no usar WebAPI y desarrollar directamente sobre el pipeline de Owin, y en otro reescribimos una aplicación para quitar ASP.NET MVC y utilizar Nancy.

Seguramente suene extraño para los que trabajáis mucho con .NET porque son las dos opciones por defecto para todo el mundo, pero en nuestro caso, aparte de que personalmente no me guste mucho su diseño, tampoco necesitábamos la excesiva complejidad que introducen esos frameworks.

Nuestra filosofía en los últimos años ha sido intentar utilizar soluciones más simples y estas decisiones van en esa línea: si podemos implementar nosotros en un tiempo razonable algo básico que cubre nuestras necesidades, preferimos empezar por ahí en lugar de asumir una dependencia enorme desde el principio.

Nancy me ha gustado. Aunque tiene sus particularidades, en general me gusta mucho más su enfoque que el de ASP.NET MVC, que me parece excesivamente complejo para muchas aplicaciones.

Como he dicho en alguna ocasión, cada vez estoy más convencido de que una aplicación web se ajusta mejor al paradigma funcional que al paradigma orientado a objetos, y los frameworks de Microsoft (WebAPI y MVC) no ayudan a implementarla de esa forma.

En uno de esos proyectos utilizamos Massive para el acceso a datos (que no me acaba de gustar, sinceramente) y en el otro hemos mantenido NHibernate con lecturas a través de consultas SQL generadas a mano.

Nuestro stack de liberías «por defecto» a las que recurrir siguen siendo NHibernate como ORM, Castle Windsor como contenedor IoC, NUnit para tests y log4net para logging. No es que las usemos en cada desarrollo, pero si hay que usar alguna de esas cosas, es la primera opción que consideramos. Hoy en día existen muchas alternativas a ellas, algunas más potentes, más rápidas, o más modernas, pero después de analizarlas no hemos encontrado tampoco incentivos suficientes para cambiar.

Javascript

Aquí la cosa ha estado más movida.

Seguimos firmes en nuestro propósito de evitar AngularJS y, aunque mantenemos una aplicación desarrollada con (una versión muy personalizada de) AngularJS, cada vez que hay que tocarla nos entran ganas de migrarla a otra cosa.

Con ReactJS, sin embargo, empezamos a trabajar a finales del 2014 y estamos muy contentos, nos resulta muy cómodo, agradable y productivo (de momento). De hecho, aprovechamos para rehacer una aplicación desarrollada con jQuery Mobile y Knockout (errores de juventud, de todo se aprende) con ReactJS y material ui. Lo de material ui reconozco que no me tiene muy convencido, pero nos ha permitido tener un diseño razonablemente bonito sin complicarnos demasiado.

Otra librería de ReactJS que estamos usando y me plantea ciertas dudas es React Router. Al principio me gustó mucho, pero al utilizarla en la vida real ha habido algunas cosas que me han gustado menos, y el hecho de que en la versión 1.0 cambiaran todo el API no me ha gustado nada.

En los sistemas de compilación, empezamos el año con grunt, probamos gulp en un proyecto, y acabamos eliminando gulp por npm. A día de hoy me decantaría por usar npm mientras sea viable y pasar a grunt/gulp sólo cuando no quede más remedio. Entre esos dos, no tengo una preferencia muy clara, aunque diría que grunt me gusta un poco más.

Aprovechando que ahora Facebook recomienda usar Babel para trabajar con ficheros JSX, hemos dado el salto a ES2015. Me gustaba más la compilación de JSX que hacían las react-tools porque respetaban mejor el formato del código original y no había que andarse con source maps, pero poder aprovechar algunas cosas de ES2015 está bien. En especial, const, let, arrow functions y destructuring ayudan a escribir código más legible. Hay otras cosas, como la sintaxis de clases, que no me gusta nada y no estoy usando.

A nivel de testing, al dejar AngularJS, se caen Karma y Protractor y entran Mocha+chai y Nightwatch. Los tests de extremo a extremo con nightwatch son más complicados de montar, pero al final todas las liberías hacen más o menos lo mismo y es más una cuestión de encontrar una que tenga los reporters adecuados para el servidor de integración continua que estés utilizando.

Una cosa que he introducido en mi flujo de trabajo este año han sido las herramientas para recarga automática de las páginas cada vez que hay cambios. Aunque no llego al nivel de figwheel para ClojureScript, que es capaz incluso de mantener el estado de la aplicación, herramientas como live-server o Browsersync (algo más potente y complejo) agilizan mucho el desarrollo de la aplicación, especialmente en las fases de prototipado de UI, y más si tienes simultáneamente enganchados varios browsers (móviles y de escritorio) para ver cómo van quedando los cambios.

Herramientas

En lo relativo a herramientas más generales, no ha habido muchos cambios. Seguimos con Visual Studio 2013 para .NET y editores varios para Javascript y HTML5. Sí, ya sé que se puede usar Visual Studio para todo, pero me resulta mucho más cómodo utilizar emacs y herramientas de línea de comandos.

Aunque nos planteamos migrar nuestra infraestructura de control de versiones e integración a git y Jenkins, respectivamente, al final seguimos con Subversion y CruiseControl.NET (con versiones actualizadas, eso sí). Con git hay algunas cosas que necesitamos resolver (la gestión de binarios, principalmente), y el cambio a Jenkins, por ahora, no nos aporta lo suficiente como para que merezca la pena migrar lo que ya tenemos funcionando en CruiseControl.NET.