Hace tres años, a petición de Alfredo, escribí un resumen de las tecnologías que había usado profesionalmente a lo largo del 2015. El año pasado convertí en tradición ese post con mis tecnologías del 2016, y este año toca seguirla, como me recordaba Paco.

Como no espero que nadie se lea los posts anteriores, vuelvo a empezar con pequeño recordatorio del contexto en que escribo este post.

Se trata de repasar las tecnologías que uso profesionalmente, es decir, no incluyo cosas que me puedan gustar más o menos, o parecer más o menos interesantes, pero que no uso en el Mundo Real™. Esto descarta automáticamente considerar este post como una especie de radar tecnológico o similar de esos que les gustan a algunos.

Además, y esto es importante, me dedico a desarrollar productos, no proyectos. Estos productos son, en su mayoría, desplegados en decenas de miles de clientes de forma intencionadamente manual (a veces los modelos de negocio pueden resultar curiosos). Están pensados para durar años y es importante mantener compatibilidad hacia atrás. Eso implica que las decisiones que tomamos están condicionadas a conseguir y mantener una estabilidad en el tiempo y no podemos andar cambiando de plataforma o reescribiendo aplicaciones en el último framework de moda tanto como nos gustaría.

Las plataformas sobre las que trabajamos son, básicamente, .NET para aplicaciones de escritorio (Windows Forms) y servidores, y unas cuantas aplicaciones web en formato SPA desarrolladas con Javascript o TypeScript.

.NET, servidores y escritorio

La parte de .NET es la que menos cambia. En parte, porque nuestro objetivo a medio plazo es alejarnos al máximo de esta plataforma, y en parte porque es la que supone un mayor coste para actualizar dentro de nuestro parque instalado.

Seguimos utilizando .NET Framework 3.5 SP1 en muchas aplicaciones, lo que nos limita la adopción de algunas nuevas funcionalidades, pero desplegar una versión nueva del framework en un parque tan disperso como el nuestro no es trivial. Si a eso le unimos que todavía hay muchos equipos ejecutando Windows Embedded POSReady 2009, una versión de Windows XP SP3 (y con soporte extendido hasta 2019, por si alguien se lo pregunta), actualizar a «lo último de lo último» no es sólo una decisión técnica, sino también comercial.

Dentro del objetivo de alejarnos de .NET este año hemos dado algunos pasos, reescribiendo una de las aplicaciones Windows Forms en TypeScript y lanzando un nuevo desarrollo basado en Java con Sprint Boot, experiencia, por cierto, bastante satisfactoria.

Para los desarrollos que mantenemos en .NET, que siguen siendo parte fundamental de nuestros productos, mantenemos nuestro clásico stack basado en NHibernate, Castle Windsor, log4net y NUnit. También usamos NancyFX (sobre .NET 4.5) en algún proyecto, aunque tendemos a trabajar directamente con un HttpListener, o incluso un TcpListener + protobuf cuando necesitamos rendimiento extra.

Donde sí nos hemos permitido un salto hacia adelante ha sido en la parte de base de datos. Tras un montón de años, nuestra base de datos por defecto ha pasado de ser SQL Server Express 2005 a SQL Server Express 2014, fundamentalmente por necesidades de aumentar el tamaño máximo de la base de datos. Aun mantenemos compatibilidad con ambas, pero algo hemos avanzando. Tal vez resulte raro que no hayamos pasado a la versión 2016 o 2017, pero desgraciadamente no tienen soporte para Windows 7, que es el sistema operativo preferido por nuestros clientes.

Clientes web

En la parte web tenemos más flexibilidad porque tenemos menos años de desarrollo acumulado que mantener, pero también porque a la hora de desplegar un cliente no necesitas desplegar ningún runtime, así que podemos usar lo que queramos en desarrollo, que a la hora de la verdad es sólo contenido estático servido desde una de nuestras aplicaciones hecha en C# o Java.

Todavía tenemos una aplicación con AngularJS (versión 1.algo infernal), pero todo lo demás está desarrollado con ReactJS. Las versiones de javascript varían dependiendo de la aplicación, desde ES5 hastas ES2015, y en las últimas dos aplicaciones hemos utilizando TypeScript.

Empezamos el año pasado a trabajar en serio con TypeScript y de momento seguimos con él. No sólo eso, si no que hemos convertido una de las aplicaciones principales, que era una aplicación de Windows Forms, en una aplicación web desarrollada con React y TypeScript.

En ese sentido, algunos de los problemos originales que tuvimos con TypeScript, especialmente los relacionados con las versiones de librerías y typings, se han minimizado con el tiempo. Realmente no sabría decir si es porque ahora los typings están más actualizados, porque tienen menos fallos, o porque una vez que montamos todas las dependencias hemos tratado de no tocarlas. Probablmente esto último influya mucho.

Para compilar las aplicaciones web tenemos una mezcla de tecnologías que reflejan la evolución de las modas en el mundillo del frontend. Empezamos con grunt, tuvimos algún gulp que nos acabamos cargando, mucho script npm sencillo y, en los proyectos con TypeScript, webpack.

Cuando no usamos webpack, solemos utilizar browserify como bundler, que sigue siendo una opción excelente por su simplicidad y rapidez. Webpack nos viene bien por la gestión completa de recursos (css, imágenes, código, etc.), pero el precio que se paga en complejidad y en lentitud es muy alto. Actualmente hemos llegado a un punto en que para no desesperarmos tenemos quitados incluso los sourcemaps de TypeScript para que la compilación incremental sea medianamente viable tras aplicar todos los trucos habidos y por haber.

Para la parte de testing en frontend existen muchas estrategias, pero al final a nivel de librerías tiramos de las típicas: jasmine, mocha, chai, protractor y karma (para la parte de angular), nightwatch para tests de extremo a extremo con React. Enzyme, que empezamos a usarlo el año pasado para algunos tests de react, se va cayendo poco a poco (ya lo suponíamos) porque el tipo de test que fomenta no es un tipo de test que nos resulte muy útil.

A nivel de interfaz de usuario, después de utilizar material-ui y las omnipresentes alternativas basadas en bootstrap, últimamente me siento más inclinado a utilizar soluciones de tipo utility first css. No es que usemos ninguna librería concreta para ello, pero que en un mundo orientado a componentes tiene cada vez más sentido frente al css «semántico».

Teniendo en cuenta que usamos React en bastantes aplicaciones y desde hace ya unos años, puede parecer que lógicamente también usamos React Router, del que he escrito bastante, y alguna librería tipo flux o redux, pero lo cierto es que no. En el caso de React Router, acabamos apostando por minimal router, algo razonable teniendo en cuenta que lo diseñamos para nosotros, y en el caso de flux/redux, nos parece que introducen uan complejidad excesiva y un grado de indirección (o desacoplamiento, si prefieres) muy elevado que hace complicado entender procesos simples. No digo que no sean patrones muy útiles en otros escenarios, pero en nuestro caso utilizando prácticas básicas de reutilización de código en react y tratando de mantener las cosas simples nos está yendo razonablemente bien.

Herramientas varias

En la sección de herramientas, pocas novedades, por no decir ninguna. Youtrack, Subversión y CruiseControl .NET lanzando scripts de msbuild coordinando todo (compilación .NET, compilación web, todo tipo de tests, documentación, instaladores, etc.). Sí, es todo viejuno, pero seguimos sin tener incentivo suficiente para asumir el coste de migración a otras herramientas más modernas (y que además son las que muchos usamos fuera del trabajo).

Para .NET, Visual Studio 2013, que es bastante estable, y para todo lo demás, emacs. Seguramente emacs sea uno de los motivos por lo que tampoco hay mucha variedad de editores en mi vida en los últimos años, ya que en lugar de saltar de un editor a otro, cada vez voy conociendo mejor éste y sacándole más partido.

Conclusión

Visto este post, y especialmente si se considera también el del año pasado, puede parecer que a nivel profesional seguimos haciendo lo mismo de siempre. Nada más lejos de la realidad. Este año ha supuesto un salto importante en nuestra estrategia de producto que ha implicado resolver un tipo de problemas al que hacía tiempo no nos enfrentábamos.

El hecho de haber utilizado tecnologías en las que nos sentíamos cómodos y con las que podíamos ser productivos no es más que un reflejo de eso: tratar de sacar el máximo rendimiento a un contexto determinado. A veces resolver problemas complejos no implica utilizar tecnologías novedosas (y mucho más entretenidas) sino, simplemente, ser capaz de buscar una solución adecuada.