Mis tecnologías del 2015

Juan María Hernández hace en su blog un resumen de las tecnologías que ha ido incorporando a su arsenal como así también de aquellas que va abandonando o que le han dado menores resultados en su trabajo como profesional del desarrollo de software, y me ha parecido una muy buena lectura pero sobre todo una buena idea el resumir algo de la experiencia de nuestro día a día, nuestras elecciones con sus aciertos y errores. Así que acá va mi resumen.

En lo profesional

En primer lugar aclarar que mi trabajo actual consiste más en formar equipos y asistirlos hasta que maduren y no me necesiten más, y aunque muchas de las decisiones tecnológicas recaen sobre mi, el trabajo dentro de una entidad financiera no es de lo más excitante en materia tecnológica. No obstante, creo que he cometido suficientes errores como para que alguien más pueda aprender algo y no repetirlos.

En cuanto a tecnologías .NET tenemos un proyecto con MVC, Clientes WCF y Cache AppFabric como proveedor de sesiones que si bien se configura de manera muy sencilla y funciona a la primera, lograr la sintonía fina o realizar un troubleshooting es un parto y la documentación a mi gusto es muy escasa. Como SCM utilizamos SVN (cada dev usa el cliente que le resulta más amigable) y debo decir que no me simpatiza en lo absoluto. Como servidor de CI utilizamos un Hudson el cual si bien cumple con su cometido, tampoco me convence demasiado. Para los unit test utilizamos NUnit y Moq, FxCop para el análisis estático de código y Sonar por requerimiento del cliente.

En otro proyecto que corre en unas terminales táctiles ubicadas en las sucursales del cliente tenemos una SAP desarrollada con Knockoutjs y jquery, cosa que a diferencia de la experiencia de Juan María, a nosotros sí nos resultó porque se trata de una aplicación no muy compleja en la que solo queríamos bindear un modelo con el DOM y eso es precisamente lo que obtuvimos. En cuanto al código del cliente lo codificamos con Coffeescript ya que brindaba muchas facilidades que consideramos convenientes como OOP, solución al problema del scope de this, menos código y más legible,  y una sintaxis mucho más declarativa. Hoy esto parece ser un error luego de ES6. Así que ni a quedar pegados con estos dialectos javascript ni a frameworks dictatoriales como angularjs porque el mundo js está muy loco. Los tests, también escritos con coffeescript utilizan jasmine y son corridos con chutzpah ya que se integra a VS y muchos devs .NET tienen problemas con todo lo que no esté en VS.  En cuanto al lado del servidor tenemos WebAPI retornando tipos anónimos (lo más simple y flexible) también Autofac, log4net y poco más.

Lo único quizás más interesante han sido los proyectos relacionados con bitcoin en los cuales utilicé NBitcoin, BouncyCastle y la implementación de referencia de Bitcoin core, OpenAssets y tecnologías afines las cuales estoy seguro no les interesan a nadie que lea mi blog. Solo comentar que en este proyecto utilizamos git, bitbucket, github, travis-ci y teamcity (dependiendo si el repo es público o privado),  lo que es simplemente fantástico para mi.

En lo personal

En lo personal no utilizo más .NET ya que casi todo lo que me interesa está primero y con menos fricción en linux, no obstante seguí manteniendo mi proyecto Open.NAT y otros aún menos importantes. Luego de pasar por el mundillo de nodejs, express, mongodb y miles de paquetes npm que en su gran mayoría son simplemente basura, debo decir que una cosa es que te digan que node es rápido y otra cosa es experimentarlo en persona, simplemente vuelva. No obstante, npm para las dependencias del lado del cliente todavía no está (es simplemente mi opinión personal), no se puede especificar otro directorio para las módulos que no sea el node_modules por lo que el moverlas a otras carpetas es un trabajo sucio ha realizar con grunt (o lo puede haber estado haciendo mal). Nodemon para reiniciar el servicio ante una modificación, forever para asegurar la continua ejecución de la aplicación en producción y passport para loguearse con facebook, twitter, goggle y otros… en fin, todo muy estandar.

Si bien me encanta nodejs, creo que es parte de una comunidad algo alocada que no ataca problemas que llevan años sin resolver como debugging y tracing que si bien están en el roadmap, todavía no hay nada. Los módulos son viejos y abandonados, cuando no simplemente triviales. No sé, algo no va bien allí y se siente. Por esto es que pienso pasar algunos proyectos a golang no sin antes hacer un piloto portando Open.NAT a Go.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *