Rafa G. Blanes Blog

 

Utilizo Digital Ocean desde hace años para mis proyectos personales y mis webs basadas en Drupal. Estas son las razones por las que seguiré utilizando este servicio por mucho tiempo.

Digital Ocean fue inicialmente una plataforma para la gestión de máquinas virtuales (VPS) con almacenamiento SSD, cuando todavía los discos duros de estado sólido eran caros en el mundo cloud en relación a otros servicios de hosting. Además, tenían una concepción diferente con respecto a otros servicios similares, como Azure, AWS o Rackspace: extraordinaria sencillez en la admistración y orientado completamente a desarrolladores de software.

Con el tiempo, han ido añadiendo más datacenters y han ido pasando de ofrecer un servicio de plataforma como servicios (Paas) a infraestructura como servicio (Iaas), con balanceadores de carga, redes privadas, almacenamiento, gestión de DNS, etc., pero manteniendo la simplicidad como principio. Su panel de control (o dashboard), es asombrosamente sencillo y te da la información rápida y precisa del estado de los recursos que tienes contratados y del coste actual acumulado.

Un máquina virtual se denomina en Digital Space un droplet, que, a diferencia de una VPS tradicional, incluye monitorización de seguridad y de comportamiento por el mismo coste. Puedes crear un nuevo droplet en segundos partiendo de una instalación base de alguna distribución de Linux o alguna imagen preconfigurada con los paquetes software más populares (stacks LAMP, LEMP o MEAN, Docker, MySql, Wordpress, etc.), además de crear un droplet a partir de un snapshot de una de tus propias máquinas ya configuradas.

A continuación, recibes un correo con la contraseña del usuario root y la dirección IP de la máquina recién creada, y poco más, ya tienes acceso a tu nuevo servidor.

Aunque los precios para máquinas virtuales caen cada vez más, en Digital Ocean tienes un droplet con una distribución de Linux de 1Gb de RAM, 1 CPU, 25Gb de almacenamiento y 1Tb de transferencia por 5 dólares al mes..., suficiente para probar cosas o publicar aplicaciones sin demasiadas exigencias (dos de mis webs, ésta y www.gblanes.com, están en una máquina con esas características con un rendimiento más que suficiente). Por el momento, las imágenes bases son siempre distribuciones de Linux.

Digamos que Digital Ocean está evolucionando poco a poco a suministrar servidores virtuales a proveer verdaderamente de servicios cloud.

Como cualquier infraestructura hardware, las actividades de mantenimiento o actualización la informan con tiempo suficiente para que estés al tanto de que tus droplets pueden verse afectados (normalmente esto ocurre poco y la falta de servicio dura minutos). Algunas de mis máquinas virtuales llevan dos años funcionando ininterrumpidamente.

Por otra parte, una característica que me gusta especialmente de Digital Ocean es su enorme sección de tutoriales con una calidad extraordinaria, los utilizo frecuentemente para resolver algunos problemas o recordar cómo se hacía esto o aquello. Imagino que deben tener una política de calidad o algo similar, ya que me llama la atención que verdaderamente se trata de documentación cuidada, bien editada y clara.

Otro punto que me gusta mucho de Digital Ocean es que se incluye con el mismo coste un servicio de monitorización y de alertas para tus droplets (recientemente me avisaron que una de mis máquinas virtuales, al no tener actualizado Drupal a la última versión, estaba realizando un consumo de ancho de banda excesivo. Después descubrí aprovechando una vulnerabilidad de la versión no actualizada de Drupal, me habían instalado un minador de bitcoins..., ejem...).

Al igual que otros servicios similares, disponen de una API con la que se pueden programar la creación de recursos y gestionar su uso.

Si estás buscando un proveedor de máquinas virtuales para algún proyecto, Digital Ocean es una opción que te recomiendo.

Antes de comenzar una nueva fase de desarrollo, conviene dedicar algo de tiempo a mejorar todo lo que ya hay.

La construcción de una pieza de código de calidad es un proceso incremental y nunca, absolutamente nunca, lo primero que escribes, aunque funcione, tiene la calidad que debe tener para asegurar su mantenibilidad.

Es algo que comienza para mí a ser recurrente: encontrarme analizando proyectos que por alguna razón, terminan siendo difíciles o imposibles de seguir evolucionando. No importa la tecnología que se use, aunque hay algunas que tradicionalmente han provocado una mayor cantidad de proyectos muy corruptos, quiero decir, proyectos que terminan siendo reescritos desde cero. PHP, por ejemplo, tiende a esto, pero no por el lenguaje en sí, sino porque su curva de aprendizaje es tan fácil que en poco tiempo alguien que se inicia en el mundo de la programación consigue obtener algún resultado sin siquiera necesidad de programar orientado a objetos, y, con el tiempo, la aplicación va creciendo y creciendo sin consolidar principios de diseño, buenas prácticas, una gestión de la configuración correcta, código limpio y... O sea, una auténtica pesadilla. La orientación a objetos tiende a forzar un diseño algo mejor, aunque este tema da mucho de sí.

Se sospecha en un primer vistazo si el diseño ha sido cuidado y revisado (si es que existe "diseño" como tal, cuando no un sistema excesivamente monolítico), así como la estructura y calidad del código de cada método.

Ocurre exactamente igual que cuando escribes un relato: primero comienzas con un borrador (y sí, "funciona", en el sentido de que transmites la idea que quieres dar a conocer). Si le das una pasada vas a encontrar seguramente algún error de puntuación, ortográfico o gramatical, y con toda seguridad, leerás párrafos que en esa segunda lectura encuentras el modo de mejorarlos. En una tercera revisión vuelve a ocurrir lo mismo, hasta que llega un momento en que la intuyes que ya calidad de lo que has escrito está a la altura de tus expectativas, quizá en la quinta, sexta o décima lectura de correción, y más aún si son otros los que leen tu texto y encuentra typos sutiles que tú has pasado por alto.

En software es igual, con la diferencia de que estas revisiones afectan tanto a la estructura del código (diseño) como a sus defectos (excesivo acoplamiento, baja cohesión, duplicidades, violación de principios de diseño, código díficil de entender, pruebas insuficientes, etc.). La cuestión es, ¿para qué me debo preocupar de esto, si funciona mi aplicación? Mmmmm

Si desarrollas una aplicación que nunca va a tener que ser cambiada, hasta vale entregarla con todos los defectos que se te puedan ocurrir, pero esto rara vez ocurre, porque en la mayoría de los casos todos los proyectos sufrirán modificaciones en mayor o menor medida.

Cuántas aplicaciones he visto ya que son una simple extensión de un núcleo excesivamente monolítico... hasta que llega el momento en que ya no soporta más cambios y hay que tirarla a la basura y comenzar de cero, para frutración (o alivio, quien sabe) de los desarrolladores, y varapalo para el negocio que incurre en sobrecostes, y además algún responsable que tratará de escurrir el bulto como sea.

La forma de evitar esto es refinar continuamente la aplicación en la que se trabaja, tratando de mejorar todos aquellos aspectos que en ingeniería del software sabemos que aportan calidad al código. Hablo de calidad en el sentido de generar una aplicación mantenible, que soporta pruebas automatizadas y que es fácil de modificar y de incluir cambios.

Es sorprendente que algunos de estos refinamientos son triviales, sencillos, se realizan en poco tiempo; e igualmente sorprendente es el beneficio que reportan a medio y largo plazo. Por poner algunos ejemplos:

• Comprobar si el código cumple con todas las buenas prácticas de clean code (buenos nombres, indentaciones correctas, clases cortas, comentarios limitados a lo necesario).
• Comprobar la cohesión de las clases para generar un buen diseño.
• ¿Se cumplen correctamente los principios SOLID?
• Refactorizar pequeñas partes de la aplicación para mejorar su diseño y aumentar la simplicidad.
• Darle una vuelta a aquella lógica de negocio más compleja que se pueda simplificar en la medida de lo posible.
• Revisar si se puede mejorar aún más el procedimiento de despliegue.
• etc.

Es buena idea antes de comenzar una nueva fase de desarrollo, dedicar algo de tiempo a todo lo anterior; al hacerlo así, es más que probable que favorezca que necesitemos de menos tiempo para incorporar las nuevas características sobre las que tenemos que trabajar.

Desde hace unas semanas ya está disponible en modo beta 1 la primera versión de Picly, un servidor de imágenes con transformaciones al vuelo a través de la misma url. Han pasado ocho meses desde su primer prototipo y, aunque en unas semanas liberaremos la versión comercial, hemos comenzado a "comunicar al mercado" este nuevo producto por aquello de que si sales con demasiadas características, es que sales tarde... 

Hay muchísmo trabajo detrás de este proyecto en el que participa todo el equipo de desarrollo de Solid Stack, realizado en Node JS, usando una base de datos en Redis y mucho, muchísimo testing antes de liberar estar pimera versión.

¿He dicho "muchísimo trabajo"?

Se suele ignorar que detrás de una simple web comercial (que ya tiene lo suyo en diseño, usabilidad, calls to action, etc.), existe toda una infraestructura que le dá soporte para implementar todos los procesos de negocio.

Las personas no demasiado técnicas, incluso muchos desarrolladores que se lanzan a probar una idea, no tienen claro el enorme esfuerzo que existe para coordinar, desarrollar y, sobre todo, mantener, una infraestructura software y hardware para comercializar un producto que con el tiempo tendrá diferentes versiones y se podrá usar en distintas modalidades comerciales (gratuita, profesional y empresarial).

Me temo que no, que esto no es publicar una web atractiva y ya te pones a hacer caja desde el minuto uno...

Tan solo para poder lanzar una primera beta, resumo a continuación todo lo que necesitamos desplegar y desarrollar:

• Una web responsiva y con un diseño atractivo y comercial: www.picly.io
• Una aplicación web también fácil de usar y responsiva para el panel de los usuarios que se registran, lo tenemos publicado en account.picly.io
• Una API Rest para dar soporte a lo anterior, publicada ahora mismo en api.picly.io
• Y, claro está, el mismo producto descargable y listo para ser ejecutado en una máquina en local.

Tan solo para desarrollar todo lo anterior, nos ha hecho falta:

• Desarrollar el producto con la suficiente calidad como para poder publicarlo como beta 1 (con tests, pruebas manuales y exploratorias, etc.). Esto es, en sí, un reto, al tratarse de algo más o menos complejo a nivel técnico y que pretende ofrecer una solución de menor coste y mucho más flexible que servicios como Cloudinary.
• La gestión de la configuración y procedimiento de "compilación" de la versión requiere de un esfuerzo considerable: selección de los assets a publicar, ofuscación de las partes más sensibles del código, minificación de las librerías y css para las distintas web y el panel de control de Picly, etc.
• Conocer en profundidad las tecnologías y librerías que hemos utilizado: Node JS, Redis, Bootstrap, diseño de una arquitectura distribuida, Graphics Magick, OpenCV, etc.
• Poner en marcha un mecanismo de "inversión de control" para la incorporación de los plugins de Picly que son los que hacen las transformaciones al vuelo.
• Infinidad de reuniones para consolidar lo ya implementado y definir los próximos pasos.
• Integración de la pasarela de pago a través de Stripe.
• Integración de muchos otros servicios como Google Analytics, Hotjar, etc.

Todo esto parece abrumador al principio, y, en realidad lo es, sin embargo, lo importante es ir dando pasos continuamente poco a poco pero con la dirección clara hasta cumplir la funcionalidad mínima para salir y dar a conocer al mercado este nuevo proyecto.

Para mí, la esencia de un buen trabajo que parece enorme es el refinamiento continuo.

Y a partir de ahí, ¿qué?

A partir de este momento, el trabajo duro continúa pero en una fase diferente, ya que hay que poner en marcha lo que se denominan los procesos de negocio mediante procedimientos bien establecidos y ordenados, como los siguientes:

• Comunicación regular al mercado mediante noticias, tweets, etc.
• Campañas de divulgación, webinars, meetups, listas de correos, contacto directo a compañías como potenciales clientes, etc.
• Mecanismos para recoger, recopilar y analizar el feedback.
• Procedimiento de soporte.
• Auditorías internas de seguridad de toda la infraestructura creada y que soporta Picly.
• Tracking para las licencidas vendidas.
• Monitorización de la actividad de los usuarios.
• Procedimiento para la liberación de nuevas actualizaciones (tanto de las webs como del producto en sí).
• Definición de métricas no vanidosas para comprobar el impacto de cualquier comunicación al mercado.
• etc.

Todo esto es muchiíisimo trabajo, pero, que, estando bien definido y ordenado, se puede llevar a cabo con la disciplina necesaria para tener éxito con un producto como Picly.

Picly es un producto en el que se ha puesto mucho esfuerzo para mantener un diseño limpio, claro, con módulos sencillos soportados por tests, clean-code y todas las buenas prácticas para el desarrollo de un producto mantenible y evolucionable. Durante este tiempo, han surgido muchas anécdotas que iré contando poco a poco, como la razón por la que no hemos usado ningún framework como Angular, React, etc. para las distintas aplicaciones webs, por qué tomé la decisión de diseño de usar Redis como base de datos y muchas más.

Continuaré hablando de todo lo anterior, tanto a nivel técnico sobre Picly como todos esos procesos de negocio específicos que estamos poniendo en marcha ahora mismo.

En cualquier caso, animo a que descarguéis el producto y nos machaquéis con sugerencias y feedback!

Hay algunas preguntas que me hago recurrentemente cuando llevo un tiempo desarrollando o dirigiendo un nuevo proyecto. Lo he hecho recientemente ahora que estamos a punto de lanzar Picly (web en pruebas aquí: http://stage.picly.io)

Uno de los elementos que caracterizan un buen equipo de otro que no lo es tanto, es la disciplina, a la hora de mantener en el día a día las buenas prácticas, los procedimientos establecidos. Esta disciplina, por lo general, suele venir impuesta por el responsable del equipo, y no por los mismos miembros de este que... bueno, no siempre todos están lo suficientemente motivados o interesados en generar un producto o proyecto mantenible y evolucionable.

En uno de los capítulos de El Libro Negro del Programador resumí en forma de setenta y ocho preguntas los indicadores más relevantes que tenemos que tener en cuenta para generar software de calidad. Son preguntas sencillas, directas, que nos indican en qué punto flaqueamos o qué podemos mejorar tanto para nuestro día a día como desarrolladores así como para mejorar en nuestro sector como profesionales.

Creo que en esas preguntas se resume lo más importante que debe tener en cuenta un equipo de desarrollo y su responsable, partiendo de la base de que ni hay super gurús (aunque sí egos inflados, me temo) ni equipos perfectos, ni falta que hace: lo único que importa es que el negocio para el que se trabaja pueda usar la funcionalidad que necesita entregada en tiempo y que desarrollemos con calidad y que además se puedan demandar más características sin que lleguemos a una solución espagueti que tengamos que tirar a la basura.

Hay muchas razones por las que el software se pudre (software rots). El concepto suena fatal, pero lo que viene a decir es que es casi natural que una solución evolucione de una forma tan caótica que sea imposible mejorarla o mantenerla, y entonces lo único que se puede hacer es tirarla a la basura. Hay razones para que esto ocurra y que abordaré en otra entrada aunque hay buenas referencias publicadas; lo que sí quiero remarcar es que si de las siguientes setenta y ocho preguntas la mayoría se responden afirmativamente, la probabilidad de que haya que tirar un producto o parte del mismo a la basura con el tiempo se reducirán notablemente.

Ahora bien, si conocemos bien las razones por las que esto ocurre, entonces nos esforzaremos sin problemas para evitar que ocurra, digo yo, aunque algunas de estas razones son bastante sutiles y tienen un efecto acumulativo difícil de apreciar a primera vista.

A continuación copio y pego este test que viene incluido en el capítulo de nombre "El test del desarrollador de software altamente productivo". Como se verá, muchas de estas preguntas no son de carácter técnico, sino acerca del entorno, del ambiente y de la forma de trabajar en el que nos desenvolvemos pero que afectan positiva o negativamente a nuestro trabajo:

1. ¿Está el código que generamos suficientemente respaldado por pruebas?

2. ¿Tiene el equipo en el que trabajamos una suficiente cultura de creación de pruebas?

3. ¿Dedicamos conscientemente algún tiempo a refactorizar?, esto es, ¿nos planteamos frecuentemente las preguntas de si algo se puede mejorar o simplificar?

4. ¿Vamos dejando en el código comentarios tipo «to do:…» que finalmente nunca se llegan a completar?

5. ¿Buscamos en nuestro día a día cómo aplicar principios S.O.L.I.D., KISS, etc.?

6. ¿Trabaja el equipo de desarrollo con la suficiente tranquilidad en un ambiente cordial y creativo?

7. ¿Existe suficiente cordialidad entre los miembros del equipo para cooperar en el proyecto?

8. ¿Tienen los proyectos en los que trabajamos que estar finalizados «para antes de ayer»?, es decir, ¿se trabaja siempre con prisas?

9. ¿Buscamos trabajar de cerca con la gente que mejor sabe cooperar y trabajar en equipo?

10. ¿Existen individualismos en el equipo o personas para las que les resulta difícil trabajar en grupo?

11. ¿Fomentan los managers o gestores el buen clima en el equipo de trabajo y ponen todos los medios para que este avance correctamente?

12. ¿Aplicamos intencionadamente principios de diseño cuando programamos?

13. ¿Tendemos a simplificar algo que ya funciona habitualmente?

14. ¿Sentimos la necesidad de llenar de comentarios internos las piezas de código que escribimos?

15. Cuando alguien retoma nuestro trabajo, ¿tiene que estar preguntándonos continuamente por detalles que no termina de entender?

16. ¿Buscamos la maestría en aquellas tecnologías que creemos que conocemos suficientemente?

17. ¿Aplicamos conscientemente las tácticas descritas en el libro de Martin Fowler sobre refactorings?

18. ¿Evaluamos correctamente las librerías y componentes externos que se usan en nuestro proyecto y tenemos en cuenta su grado de evolución, madurez, comunidad de usuarios, etc.?

19. ¿Aislamos adecuadamente las librerías y componentes externos en nuestra aplicación para no depender de ellos excesivamente?

20. ¿Somos suficientemente conscientes de que al proyecto en el que trabajamos se le pedirán más cambios y que estos estarán en proporción a su éxito?

21. ¿Tenemos la tendencia de usar siempre lo último «porque sí» sin considerar si su uso es adecuado (y seguro) en nuestro proyecto?

22. ¿Preferimos usar tecnologías muy maduras antes que tecnologías incipientes y de rápida evolución?

23. ¿Consideramos el riesgo de usar módulos, librerías o componentes relativamente nuevos en nuestros proyectos?

24. ¿Estamos dispuestos a modificar profundamente una pieza de código en la que estuvimos trabajando mucho tiempo?

25. ¿Intentamos mantener a toda cosa un trozo de código sabiendo que se puede mejorar?

26. ¿Somos honestos con nosotros mismos cuando llegamos a la conclusión de que es mejor comenzar algo desde cero que forzar de la manera que sea la incorporación de nuevas características?

27. ¿Permitimos incluir en el equipo más gente en momentos de crisis cuando se acercan las fechas de entrega y se ve que de ningún modo se va a completar el trabajo?

28. ¿Advertimos a nuestros responsables de la falta de recursos para ejecutar con calidad y éxito el proyecto en el que trabajamos?

29. Si somos responsables de equipos, ¿tenemos claro que cuando un equipo falla es nuestra responsabilidad?

30. ¿Sufrimos demasiadas reuniones improvisadas?

31. ¿Las reuniones terminan durando mucho más del tiempo establecido y se discuten más temas de los incluidos en la agenda?

32. ¿Hacemos siempre un trabajo que previamente ha sido planificado por el gestor del proyecto?

33. ¿Se pasa por alto la metodología o las buenas prácticas en momentos de especial estrés o crisis por llegar a las fechas previstas?

34. ¿Cambia el gestor de proyecto de criterio continuamente?

35. ¿Tenemos todos los medios necesarios para hacer un buen trabajo?

36. ¿Comenzamos un nuevo proyecto o fase de desarrollo resolviendo las partes más complicadas o que más nos inquietan?

37. ¿Aplicamos continuamente refactorings al trabajo realizado o sólo cuando nos acordamos?

38. ¿Trabajamos siempre con la idea de la calidad en mente, eso es, queriendo hacer siempre el mejor trabajo?

39. ¿Dominamos suficientemente bien las tecnologías que se emplean en el proyecto?

40. ¿Nos ceñimos fielmente a la metodología que se usa desde el principio hasta al final del proyecto?

41. ¿Abandonamos las buenas prácticas metodológicas cuando sentimos presión?

42. ¿Trabajamos en equipos con talentos descompensados, esto es, unos muy buenos y otros muy «malos»?

43. ¿Se trabaja estableciendo una arquitectura general rígida al principio del proyecto cuando aún no están claros todos los requisitos?

44. ¿Es la arquitectura general del proyecto suficientemente flexible para poder modificarla durante el desarrollo del mismo o es extraordinariamente rígida?

45. ¿Está sólidamente establecida la metodología que se ha decidido seguir o se ignora a primeras de cambio?

46. ¿Se percibe claramente la rentabilidad que se extrae de seguir correctamente una metodología?

47. ¿Se relegan siempre para el final las tareas más aburridas o rutinarias?

48. ¿Nos preocupamos lo suficiente en que nuestro producto software esté bien hecho y funcione y además que lo aparente?

49. ¿Ponemos suficiente énfasis en el diseño de interfaces de usuario ágiles, intuitivas, amigables y elegantes?

50. ¿Nos ocurre a menudo que diseñamos interfaces de usuario pensando más en los propios desarrolladores que en los usuarios finales?

51. ¿Conocemos muy superficialmente multitud de tecnologías pero muy pocas en verdadera profundidad?

52. ¿Nos centramos más en conocer algo de muchas tecnologías que en resolver problemas reales con nuestro software?

53. ¿Sentimos la necesidad de usar lo último de lo último en un nuevo desarrollo «porque sí»?

54. ¿Indicamos en nuestro currículum los problemas que hemos resuelto con nuestro software o bien una retahíla de tecnologías que conocemos superficialmente?

55. ¿Tenemos el trabajo planificado con tiempo de antelación?

56. ¿Es corriente llegar a la oficina sin saber exactamente qué tenemos que hacer?

57. ¿Nos marcan las tareas que debemos realizar sobre la marcha?

58. ¿Sufrimos continuamente interrupciones durante nuestro trabajo?

Desde hace mucho he usado Redis como una de mis utilidades favoritas para integrarla en mis proyectos. Para quien no lo conozca bien, Redis se ha considerado siempre un servicio de almacenamiento en memoria tipo clave/valor

Sin embargo, desde hace tiempo Redis es muchísmo más, soportando diversas estructuras de datos que lo enriquecen y que hace que se le pueda dar un uso mucho más amplio.

No es una aplicación que se utiliza únicamente como caché de métricas, sesiones de usuario, etc., sino que para determinadas aplicaciones cuya necesidad de almacenamiento de información no es necesariamente relacional, Redis se puede usar perfectamente como base de datos.

Existen servidores en memoria similares como Memcache. Sin embargo, en Picly.io (servidor avanzado de imágenes, proyecto en pleno desarrollo), hemos decidido usar como base de datos Redis; esto es una decisión importante de diseño y que, de algún modo, condicionará el despliegue y uso de ese servicio.

Lo que quiero recalcar es que perfectamente Redis puede sustituir en algunas ocasiones el uso de bases de datos como MySql, MongoDB, Sql Server, etc.

En este caso, estos son los argumentos que me han llevado a elegir Redis como repositorio de datos para Picly.io:

• El core de Picly debe ser pequeño pero muy robusto y eficiente.
• La necesidad de almacenamiento de información de Picly es relativamente sencilla: estructuras de datos planas y con relaciones muy simples.
• El rendimiento debe ser extraordinario para servir imágenes y su procesamiento y transformaciones lo más rápido posible.
• Redis es un producto de libre uso muy maduro, con mucha documentación y una comunidad muy amplia.
• La instalación es sencilla, como se puede ver en este artículo para un Ubuntu 16; su mantenimiento, también.
• Para grandes instancias de Picly (con millones de imágenes o requests de transformación de imágenes), Redis se puede escalar entre varios servidores y está soportado por diversos proveedores de servicios en cloud, como Azure Redis Cache

Y una cosa interesante: el rendimiento de Redis, el tiempo que va a tardar en devolver un objeto, es determinista, lo que no ocurre con una base de datos relacional salvo que se configure correctamente y usando muchos recursos.

Algunas de las estructuras de datos que soporta Redis son objetos clave/valor, hashes, listas, listas ordenadas con paginación, etc., lo suficiente para que una aplicación pueda apoyarse en este producto sin necesidad de usar un servidor de base de datos más pesado. Además, una incorporación desde versiones anteriores es la capacidad de utilizar scripts con Lua, permitiendo realizar consultas y procesos de cálculo más complejas.

Ahora bien, el uso directo de Redis mediante sus comandos básicos (como HADD, ZRANGE, etc.), puede enmarañar u ofuscar una aplicación de alto nivel que lo utilice.

Para ello, y puesto que Picly.io se está desarrollando con Node JS, estoy desarrollando una pequeña librería para encapsular cómodamente el uso de Redis por parte de una aplicación.

La he denominado Blue Entities y está disponible en Github; aunque se usa en Picly, todavía no me atrevería a decir que está lista para producción y tenemos pendiente incorporar bastantes mejoras en los próximos meses.

Blue Entities

Por poner un ejemplo, con esta módulo de Node, y a partir de un esquema como:

var schema = {
   name: "users",
   properties: [
      { name: "mail", type: "string" },
      { name: "password", type: "string" },
      { name: "active", type: "boolean" },
      { name: "age", type: "integer" }
   ]
}

, se pueden añadir entidades de esta forma:

var redisConfig = { host: "localhost", port: 6379 };
var blueEntities = require("blueentities")(schema, redisConfig );

var newUser = {
   mail: "info@solidstack.es",
   password: "123454321",
   active: true,
   age: 43
}

blueEntities.addEntity( "users", newUser )
	.then( function(id) {
		// User added!!!
	});

Y su recuperación de la base de datos es trivial (y a alto nivel, que es lo interesante):

blueEntities.getEntity( "users", id )
	.then( function(user) {
		// User retrieved!!!
	});

Internamente, las entidades son convertidas a objetos de Redis pero de forma transparente y eficiente para el cliente de Blue Entities.

Existen otros proyectos muchos más completos y a modo de ORM para Redis y NodeJS, pero me parecieron demasiado pesados para las necesidades de almacenamiento de Picly.io.

En cualquier caso, sugiero encarecidamente evaluar bien cómo encaja Redis en los proyectos que desarrollamos y considerarlo como una utilidad importante a tener en cuenta.

A menudo me encuentro con la necesidad de evaluar posibles proyectos en los que se hace una apreciación muy ingenua de la dificultad y esfuerzo que cuestan desarrollar ciertas cosas.

Estamos en un momento en que cada día aparecen nuevas apps, nuevos servicios, otros cierran y los medios de comunicación muestran continuamente el éxito millonario de la startup de moda.

Sin embargo, se obvia el enorme esfuerzo y la extraordinaria complejidad que hay detrás de cualquier aplicación que medio funcione, a nivel empresarial, organizativo y financiero.

Hay tres compañías que me gustan mucho y que sigo desde hace tiempo: Doodle, Etsy y Cloudinary.

Por si no los conoces, Doodle es una startup alemana cuya aplicación facilita la creación de eventos, tanto personales como corporativos.

Por su parte, Etsy comenzó hace muchos años cuando solo unos pocos hablaban de economía colaborativa; es un portal que permite vender a artesanos de todo el mundo sus productos a cualquier cliente que se encuentre en cualquier parte. Tú haces el producto, ellos se encargan de mostrarlo y de solucionar la logística de pagos y de transporte hasta el cliente que lo compra. Conozco a gente cercana que se gana su dinerillo con Etsy. Para mí un ejemplo a seguir por ese sesgo que tiene de favorecer la economía colaborativa.

Y, por su parte, Cloudinary es un servicio que montaron unos desarrolladores hartos de tener que tratar continuamente con el problema de la gestión de imágenes en sus proyectos. Ofrecen un servicio por el que una aplicación sube las imágenes que utiliza y Cloudinary se encarga de ofrecer mediante una sintaxis basada en la url de devolverla manipulada según tus necesidades, entre otras cosas, actuando también con CDN.

Tres servicios, en mi opinión, muy útiles y hasta ahora con éxito.

Pero, ¿qué tienen en común y por qué estoy hablando de ellos?

Lo que no se aprecia es que detrás de esos servicios no hay dos frikies trabajando en un garaje hasta las tantas de la noche para hacerlos funcionar, sino equipos con un montón de personas para que todo siga en marcha. Y no hablo solo de perfiles técnicos (front-end developers, Q&A engineers, etc.), sino también accounts managers, CEOs, marketing & community managers, etc.

En concreto, en los siguientes enlaces se puede ver algo de información sobre los equipos de Doodle, Etsy y Cloudinary:

• El equipo de Doodle está compuesto de más de treinta personas, con roles que van desde product managers, hasta ingenieros iOS juniors.
• ¿Cuántas personas crees que trabajan y permiten hacer que funcione Etsy? Échale un vistazo a la web, a sus servicios. Pues bien, más de cien personas colaboran para hacer posible que una idea como Etsy.com funcione en todo el mundo.
• Cloudinary ha sido para mí una gran fuente de inspiración, porque ya hace años me di cuenta de lo recurrente que es en los proyectos la gestión de las imágenes. Ellos lo han resuelto de una forma extraordinaria, ofreciendo un servicio de alojamiento y de CDN genial. Unas sesenta personas dan vida a Cloudinary, nada más y nada menos.

Hace un tiempo oí quejarse a alguien que usaba los cupones de Groupon por el tipo de comisión que se llevaban... Esta persona me decía que "total, eso es una web y ya está". Pues sí, ves el servicio en forma de web y también como aplicación móvil en el mejor de los casos, pero detrás existe una infraestructura software y hardware que le permite funcionar en todo el mundo, con legislaciones diferentes, distintos idiomas, una enorme cantidad de datos a tratar, etc.

De modo que cuando me tengo que encargar de evaluar una de esas propuestas felices que pretenden hacer rico a más de uno en dos días, simplemente, sonrío y me armo de paciencia.

¿Cómo conseguir que un proyecto software sea mantenible y que se pueda modificar con sencillez?

Esta pregunta tiene muchas respuestas, según la naturaleza del mismo proyecto, claro. No obstante, existen una serie de principios que, de seguirlos, la vida (y estructura) de un proyecto puede cambiar de una forma radical.

Demasiado a menudo veo proyectos, sin ir más lejos, muchos repositorios en GitHub, en los que es imposible discernir cómo se han implementado los principios de diseño más básicos en ingeniería del software, y no es que esté mal, claro, todo depende de la vida que vaya a tener ese proyecto.

No hace falta que conozcamos al detalle todos y cada uno de los patrones de diseño que más o menos son conocidos y aceptados por la industria y muy bien explicados en libros clásicos como este, pero, desde luego, si lo que queremos es que nuestro proyecto pueda ser mejorado continuamente sin demasiada dificultad, entonces sí que hay que seguir unas mínimas normas de desarrollo.

Aquí es donde entran los principios S.O.L.I.D.

Si tu proyecto tienen clases o funciones extraordinariamente largas del orden de cientos de líneas de código, si hay métodos con innumerables if o con muchos bloques anidados, o hay métodos o funciones con muchos parámetros, entonces tu aplicación camina hacia una solución espagueti difícil de mantener y evolucionar. 

Si es así, sigue leyendo...

¿Qué diferencia un principio de diseño de un patrón?

Mientras que un patrón es una solución técnica y clara a un problema particular, un principio es una guía que debe cumplir tu código a nivel de diseño. Los mejores frameworks de desarrollo son los que mejor cumplen con estos principios, y estoy pensando sin ir más lejos en Seneca, un framework que me gusta mucho para construir microservicios en NodeJS, aunque hay muchos otros ejemplos.

A grandes rasgos, los principios S.O.L.I.D. permiten diseñar una aplicación de un modo que:

• Tenga un alto grado de desacoplamiento entre sus partes funcionales.
• Se pueda extender en funcionalidad con sencillez, sin grandes cambios en la aplicación.
• Es testeable.
• Mejora la reusabilidad del código.

Aunque su implementación es más natural en programación orientada a objetos, se pueden aplicar en lenguajes funcionales. En el contexto de este artículo, hablaremos de entidades software para referirnos a clases, módulos, métodos, funciones, etc.

A continuación indico un breve resumen de estos cinco principios, junto con una técnica igualmente relevante, y que es la inversión de control.

Single-responsability principle (SRP o principio de responsabilidad única)

Una clase se debe dedicar a resolver un único problema, esto es, no se debe implementar una clase cuya funcionalidad mezcle ámbitos de la aplicación diferentes.

Si se utiliza bien este principio, entonces se podrán generar clases más o menos pequeñas y, por tanto, más reutilizables y fáciles de modificar y probar.

En el contexto de este principio, se entiende por responsabilidad como la razón para cambiar, esto es, si en una clase existe más de un motivo por el que puede cambiar, entonces es que no sigue este principo.

Quizá no sea simple de ver al comienzo, pero en este snippet de código indico un ejemplo sencillo (y algo académico), escrito en javascript para NodeJS.

Open-closed principel (OCP o principio abierto/cerrado)

Según este principio, una clase se debe diseñar de modo que sea fácilmente extendible sin modificar su funcionalidad actual. Fácil de describir, pero para implementarlo hace falta cierto grado de abstracción. Según la característica de la aplicación en la que se esté trabajando este principio se puede aplicar o no.

No niego que este principio sea algo sutil, pero si se entiende bien, en realidad lo que está indicando es que la entidad software debe abstraer al máximo el core de la funcionalidad que implementa.

Lo que persigue conseguir OCP es extender la funcionalidad de una entidad software sin modificar su código, y para ello, como digo, hace falta cierta abstracción.

En este otro snippet de código indico cómo aplicar este principio en el clásico ejemplo de validación de entradas de usuario.

Liskov substitution principle (LSP o principio de sustitución de Liskov)

Este es quizá el principio más sutil de entender, pero igualmente importante. Con LSP lo que se pretende es asegurarnos de que se implementa correctamente la herencia entre clases.

Entendemos como clase hija o extendida aquella que deriva de otra.

La definición es un tanto académica, de modo que haré una descripción más sencilla; lo que viene a decir LSP es que si un programa utiliza una clase, entonces deberá seguir siendo válido (= funcionará bien) si se la sustituye por una nueva clase que derive de ella. Si un programa utiliza la clase P, y en su lugar sustituimos P por O (donde O deriva de P), entonces, el programa deberá seguir funcionando correctamente.

Y aquí la definición de la autora (Bárbara Kiskov): si o1 es un objeto de tipo S, y o2 es un objeto de tipo T, si el comportamiento de un programa (función, método, etc.) basado en objetos T, usando o1 y o2 no cambia, entonces necesariamente S es un subtipo de T.

Puff..., en realidad está indicando cómo hay que implementar la herencia entre clases.

Sencillo de decir, no tan obvio de saber implementar, aunque con este principio nos garantizamos que la herencia se hace bien y además las clases base (padre) y sus derivadas (hijas) son más fácilmente testeables.

LSP está muy relacionado con el principio OCP, ya que establece también que una clase hija debe extender el comportamiento de la padre, no modificarlo.

Para implementar LSP hace falta un grado alto de abstracción de la solución que pretendemos resolver; si se rompe este principio en nuestro diseño, entonces es que no se está abstrayendo lo suficientemente bien.

Aquí dejo un ejemplo ilustrativo que cumple LSP.

Por último, una forma de forzar que se cumple este principio es usar diseño por contratos, en el que se especifican interfaces y las clases base las implementan.

Interface segregation principle (ISP o principio de segregación de interfaz)

Este principio pretende evitar la creación de interfaces extensas con métodos que no tienen nada que ver unos con otros, de modo que una clase que derive de ellas tenga que dejar sin implementar algunos de esos métodos porque no los necesita. 

Con ISP lo que se sugiere es dividir esta interfaz (fat interface) en interfaces más pequeñas y coherentes, de modo que las clases que deriven de ellas lo hagan porque necesitan todos y cada uno de sus métodos.

La consecuencia de este principio es que necesariamente las interfaces que se definen en el proyecto tienen un alto grado de abstracción y de granularidad.

En este otro ejemplo, se puede ver cómo aplicar este principio.

Dependency inversion principle (DIP o principio de inversion de dependencias)

Este principo es, quizá, el más popular de todos y el más fácil de implementar y en ocasiones se le confunde con la inyección de dependencias.

Lo que viene a decir es que nuestro código (en un módulo, una clase, etc.) debe depender de abstracciones, no de instancias concretas de las mismas.

Entendemos por abstracción la definición que debe implementar una clase concreta, lo que viene a ser lo mismo que clases abstractas e interfaces en OOP.

Con DIP conseguimos que el código esté más desacoplado y que las unidades de funcionalidad sean más pequeñas (y, por tanto, reutilizables y testeables).

Inversion of control (IoC o inversión de control)

La inversión de control no está dentro del conjunto S.O.L.I.D pero sin embargo está en la línea de conseguir código más desacoplado y mantenible, sin embargo; no es aplicable a cualquier tipo de proyectos.

Tradicionalmente, podemos decir muy simplificadamente que la implementación de un programa consiste en la ejecución de una llamada a un método o función tras otro. Sin embargo, a medida que este programa crece, es necesario estructurar la aplicación en módulos, entran en juego diversas arquitecturas, etc.

Es decir, el flujo habitual de una aplicación consiste en llamar a procedimientos (funciones o métodos) de una biblioteca.

Se implementa la inversión de control cuando se invierte ese flujo, esto es, cuando es la misma biblioteca la que llama al código del usuario que es el que implementa realmente la aplicación.

Parece enrevesado, pero hay multitud de ejemplos que implementan inversión de control y, además, es el enfoque natural cuando necesitamos que nuestra aplicación sea fácilmente extensible. Sin embargo, insisto en decir que no siempre es necesario implementar este mecanismo, depende de la naturaleza del proyecto.

IoC y DIP (inversión de control e inversión de dependencias) suelen ir de la mano, ya que es sencillo implementar IoC utilizando DIY:

El año comienza cargado de proyectos y de mucho, muchísimo por hacer. Tengo pendientes muchas lecturas por realizar, muchos hitos que cumplir, tanto en lo personal como en lo profesional, y, entre todo ello, una modernización de esta web en la que ya estoy trabajando y dos nuevos proyectos literarios (uno de ellos técnico).

Es estimulante comenzar el desarrollo de un nuevo producto. Siempre hago una distintación clara entre "productos" y "proyectos", ya que sus ciclos de vida no tienen nada que ver. Personalmente me gustan más los primeros, ya que tienes que pensar de otro modo para afrontarlos, considerar su mantenimiento de una forma radicamente diferente y, además, sabes que si se cierra bien, puedes pasar al siguiente, sin quedarte años trabajando en el mismo proyecto y, por suspuesto, habiendo dejado un nuevo producto para el catálogo de tu compañía. 

Otra cosa es todo lo relacionado con la rentabilidad; aunque esos son temas de desarrollo de negocio, sólo quiero apuntar algo que no me deja de sorprender. Hay demasiadas empresas de software empeñadas en captar proyectos, con el enorme esfuerzo comercial que eso supone, en lugar de apostar más por la creación de un conjunto de productos que, una vez hechos, se pueden vender una, diez o mil veces. ¿Se ve la diferencia? Al menos, integrar un modelo mixto entre productos y proyectos.

Hemos dado lo primeros pasos para el desarrollo de un nuevo producto, de nombre Smart TPL para el que además tenemos ya comprometidas la comercialización de varias licencias. Aunque lo que me interesa aquí es hablar más de cómo lo hacemos que lo que hace realmente. No obstante, aquí indico una breve descripción del mismo.

Smart TPL es una aplicación para móvil que se usará para la lectura en local de contadores digitales de tecnología PRIME. Esto es necesario ya que no todos los contadores que se instalan (ya sean de uso doméstico o industrial), tienen capacidad de telegestión, de modo que sigue siendo necesario que un operario se desplace al lugar de la instalación para obtener sus medidas, eventos, etc. Nota: los contadores de los que hablo con esos dispositivos que se instalan en la puerta de casa o en el cuadro centralizado de un bloque de viviendas para medir el consumo elétrico, entre otros muchos parámetros eléctricos.

¿Cómo vamos a realizar este nuevo producto?

De nuevo, no hay que inventar la rueda en el ciclo de vida, tan sólo seguir las buenas prácticas, que resumo a continuación.

Después de un tiempo en conversaciones con el primer cliente que nos has cumplido su adquisición, hemos intercambiado una serie de documentos con los que hemos consesuado las característias que debe cumplir el producto. De aquí se extraen los requisitos.

Estos requisitos software tienen que consensuarse con el cliente y, sobre todo, me tengo que asegurar que todo el mundo entiende el mismo lenguaje, es decir, todos entendemos igual ese dominio o ese universo particular relacionado con los problemas que resuelve la aplicación.

Esto parece una tontería, pero es vital para que después no termines cayendo en la clásica viñeta de la rueda y el "yo entendí"...

A continuación, se establecen fechas de entregas claras, que son tanto un compromiso personal para el equipo de desarrollo como una expectativa que el cliente espera que se cumpla.

Y, por supuesto, en esta fase, los requisitos, que ya son bien conocidos y están muy claros, se añaden a la herramienta ALM (application lifecycle managemente). En mi caso, no puede ser otra que nuestra suscripción al Visual Studio Online (antiguo Team Foundation Server) de Microsoft. En mi opinión, de las mejoras herramientas para la implementación de proyectos software que existen.

¿Y qué hay de las tecnologías a usar?

Puesto que conozco y el equipo conoce bien todas las tecnologías relacionadas con .NET Framework, está claro que nos debeíamos decantar por la plataforma Xamarin para el desarrollo de la aplicación móvil.  La decisión de esta elección no se hace por gusto, sino por un asunto de productividad. A expertos en C# les va a resultar muy fácil, e incluso natural, realizar aplicaciones en ese lenguaje aunque sea para otro framework o API diferentes.

Además, Xamarin ha sido adquirido por Microsoft, lo cual todo hace indicar que su presencia en el mercado se va a mantener durante muchos años y existe una gran comunidad alrededor de Xamarin.

¿Y cuáles son los siguientes pasos?

Puesto que implemento un acercamiento ágil al desarrollo de software, y este proyecto es un claro candidato para ese enfoque, definiremos un primer sprint de trabajo en el que montaremos el proyecto y cerraremos una funcionalidad sencilla del catálogo de requisitos (backlog items).

En este primer sprint:

• Generaremos una versión muy elemental de la aplicación, pero aunque sencilla, se podrá usar ya desde el terminal móvil elegido.
• Plantearemos un mock para el backend que el que debe conectar la aplicación móvil, y que estará basado en servicios REST que estarán accesibles dentro de una VPN.
• Tendremos un conocimiento mejor de Xamarin para la implementación de los siguientes sprints.

Y, sobre todo, nos divertiremos currando en este nuevo proyecto. 

Hablaré más adelante de su progreso a medida que vayamos cerrando sprints.

Hace muchos años leí un libro que me impactó: Como una novela, del francés Daniel Pennac, y no sólo me gustó porque estimulara a leer como una actividad esencial en la vida, sino porque me reveló la importancia también de estar en el otro lado, el de aquel que lee pero que también escribe.

Desde hace más años de los que me acuerdo, me ha interesado mucho la escritura creativa; incluso realicé un curso presencial al borde del siglo pasado (literalmente, creo que fue en el 98 o en el 99), con una escritora sevillana relevante. En aquella época recuerdo que estaba enfrascado totalmente en interfaces de usuario con Visual C++ (qué tiempos!)

Y, desde entonces, he escrito, con mayor o menor regularidad, no sólo mi proyecto de El Libro Negro del Programador publicado hace tres años, sino retalos cortos, intentonas de novelas que no terminé, otras cosas que sí terminé pero que no me pareció de la calidad suficiente como para darlas a conocer, posts en El Blog Alternativo, etc. Hasta este año pasado en el que terminé y publiqué lo que considero mi primera novela publicable.

¿Y qué hace uno hablando sobre novelas en un blog de software más relacionado con mi actividad profesional del día a día?

Porque aunque no lo parezca, hay muchas simulitudes entre escribir software y escribir una novela, entre comenzar un proyecto software y asumir un proyecto literario con una metodología.

Si quieres saber todas las cosas que he descubierto al respecto en estos años, sigue leyendo.

Este primer proyecto literario es una novela con un argumento un poco romanticón, pero que tiene una trama de desarrollo personal importante así como su propia intriga y ritmo propios. Tiene de título "Patricia: una nueva relación que lo cambiará todo". Puedes ver más al respecto en la web literaria en la que trabajaré para todo lo relacionado con mi lado novelesco ;-) (www.gblanes.com)

Ejem... que hay autores a los que admiro mucho por su actividad profesional como Raimón Samsó y que además tienen algunas novelas de corte romántico (que, por cierto, es el género que mejor funciona comercialmente...).

Y entonces, ¿qué relación hay entre un proyecto software y un proyecto literario?

Estas son las similitudes que encontré y que sin ninguna duda me ayudaron a completar un proyecto de cerca de cuatrocientas páginas y realizado a base de micro tareas durante unos ocho meses.

• En primer lugar, un libro no se escribe, se construye. Es un trabajo que tiene un proceso y, como siempre digo, es más importante el proceso que la tecnología a usar (o el texto a escribir). Cuando asumimos que algo se debe construir, nos damos cuenta de que ese algo tiene muchas partes independientes, que se pueden realizar a diferente ritmo.
• Al igual que un proyecto software con una metodología basada en sprints y entregas y que necesita de una planificación (porque esto lo tienes claro, no?), un proyecto literario también se planifica. Lo siento si acabo de poner en duda tu concepción del escritor sentado en una buhardilla mientras ve por la ventana un paisaje bucólico y esperando una inspiración para plasmarla en una hoja en blanco. De ninún modo, como dice Joanna Penn (escritora independiente a la que sigo), "un libro es 5% inspiración y 95% trabajo duro y planificación". Créeme, es así.
• Al igual que cuando escribimos código lo revisamos y aplicamos todas esas estrategias de refactoring, ocurre igual con un texto, un capítulo o sección: una vez escrito, se revisa en busca de typos, errores ortográficos, tipográficos o gramaticales, cuando no mejoras esta frase o eliminas algo para rehacerlo. Se dedica más tiempo a revisar y corregir que escribir. Esto siempre resulta sorprendente para quienes no conocen bien el trabajo de un escritor.
• Se distingue entre avanzar y mejorar. Del mismo modo que nos centramos para cerrar una funcionalidad software (aunque después se refactorice y mejore), en una novela ocurre igual: hay una fase de escritura, que algunos autores aconsejan incluso que sea rápida para cerrar la sección o el capítulo cuanto antes, y otra fase muy distinta de revisión. Puesto que mucha gente comienza a escribir pero la mayoría no terminan el trabajo, hay quien sugiere terminar un borrador del texto lo antes posible, aunque tenga muchos fallos e incongruencias que después se pueden corregir. Aunque haga falta revisarlo, al menos tienes una primera versión y esto te anima mucho. Tiene sentido.
• Como digo, los capítulos se revisan hasta la saciedad, y es sorprendente cómo después de varias vueltas, uno sigue encontrando detalles que mejorar (¿a que esto resuena en nuestras mentes de programadores?). Porque la igual que no hay ningún proyecto software perfecto, tampoco hay un libro perfecto, y nunca lo podrá haber, porque el ideal de perfección es demasiado subjetivo..., aunque sí hay otro tipo de elementos que se pueden medir (complejidad ciclomática / ritmo literario, tamaño de métodos / subtramas, etc.)
• ¿Funciona el software? Quiero decir, respaldamos el código con pruebas unitarias, de integración, etc. ¿Y un libro? Pues igual, se plantean preguntas que el libro debe responder con éxito: ¿está bien descrito este personaje?, ¿no es demasiado pesada esa subtrama?, ¿es coherente a lo largo del libro la historia familiar de los protagonistas?, ¿se usan los tiempos verbales correctamente y de forma coherente? Es decir, tests, tests y tests.
• Un proyecto software se despliega, se publica, al igual que un libro, para lo que hay que compilar el texto para generarlo en formato pdf, epub o mobi junto con sus portadas, contraportadas, etc. (Nota: en la herramienta Scrivener, se incluye el concepto de "compilar" el texto, que no es más que generar el libro en el formado configurado y parametrizado. Dicho así parece sencillo, pero tiene un trabajo importante).
• Y todo ello debe estar bajo el marco o paraguas de una metodología. En el caso del libro (al igual que hice con El Libro Negro del Programador), me creé mi propia metodología adaptada a la disponibilidad que tenía para escribir: división en tareas pequeñas, sesiones de una hora, definición de cada sección del texto (antes de empezar a escribir, me hice un guión con unas ochena secciones), etc.
• Pruebas de validación: ¿para qué sirven si no los beta-readers? Le di el manuscrito a mi pareja y a una amiga cuando yo ya lo di por terminado (y, por supuesto, me indicaron bastantes mejoras).
• Te documentas leyendo un montón de libros y blogs, como suelo hacer cada vez que me interesa una tecnología en particular.
• Y mucho, muchísimo compromiso por alcanzar cada semana los hitos que yo mismo me planteaba (y que no siempre conseguía).

Cuando menos, interesante.

Por cierto, si planeas escribir un libro, no utilices Word, por favor, merece la pena gastarse unos eurillos en una herramienta como Scrivener.

Puff..., casi siempre al comenzar el año el que más o el que menos hace una lista de buenos propósitos, de objetivos para los próximos doce meses. En cierta medida, yo lo también lo hago, pero sobre todo me gusta mirar un poco atrás y ser aún más consciente de dónde vengo (por eso de saber mejor hacia dónde voy).

Y desde luego, puedo decir que ni he tenido un trabajo rutinario desde que terminé la carrera ni que me he mantenido en el mismo tipo de rol. ¿Podría haber sido de otro modo? Pues ni idea, seguramente sí, ya que yo mismo he sido responsable de mis acciones y decisiones. ¿Quién si no?

Echo la vista atrás y ojalá los próximos diez años sean igual de intensos y productivos.

Me gusta Haruki Murakami y me le ha acompañado desde que cayó en mis manos casi por casualidad uno de sus libros allá por el noventa y pico.

A modo de resumen...

Terminé la titulación de Ingeniería Superior en Informática por el 2001, después de presentar un proyecto fin de carrera que me llevó casi un año. Se trataba de una aplicación hecha con Visual C++ y librerías MFC/ATL, para la creación de interfaces de usuario de un producto Scada que realizábamos por aquélla época en la compañía para la que trabajaba. Entonces pertenecía a lo que se denominaba el Grupo de Desarrollo de Software (nada original, por otro lado).

Fruto de este proyecto (que creo que sigue en producción en algún centro de operación ferroviario), fue este artículo que ya en su día publiqué en CodeProject y de título Improving ATL-ActiveX Serialization y mucho, muchísimo profiling y escribir código optimizado. Y ahora que lo pienso, ese artículo fue lo primero que me dio por publicar! Y por cierto, veo que tengo que actualizar la información con la que me registré en CodeProject, portal que sigue siendo para mí referencia hoy día.

Lo más interesante de aquéllo fue que en esa aplicación integré VBA (Visual Basic for Applications), toda una novedad en aquel momento, y también un gran reto técnico.

Acostumbrado a C++, todo el nuevo entorno de .NET framework junto con C#, creó una gran expectativa que abrazamos casi todos en el departamento desde el primer momento. De hecho aún conservo un libro que me regalaron en un evento sobre esa nueva tecnología y que creo que sería de lo primero que se publicó entonces.

Siempre he estado muy ligado a tecnologías de Microsoft, y también siempre me han parecido infantiles y no profesionales las comparaciones y dilemas un poco tontos y muy de nuestro sector entre esto o aquello. Toda tecnología tiene sus luces y sus sombras. Punto.

Sin embargo, desde hace unos años trabajo muy de cerca con Azure (la plataforma de cloud computing de Microsoft y de enorme crecimiento) y sigo con detalle todos los movimientos de esa compañía hacia una visión más "open" del software. De hecho, no en vano, .NET Core y la liberación de algunos productos tradicionales de Microsoft para su funcionamiento en Linux (como Sql Server, nada más y nada menos) es una muestra más de esa mayor amplitud de miras. Y no digo Azure por capricho, es que tengo clientes que funcionan desde esa plataforma con un éxito rotundo.

En 2006 ya estaba trabajando en Suecia en un proyecto de muchos millones de euros; mejor dicho, el proyecto tenía un montante de cien millones de euros pero la parte software, aunque, residual, era crítica: sin ese pilar, todo el proyecto se caía y las penalizaciones económicas por parte del cliente podían poner en riesgo la viabilidad misma del proyecto. Había mucha presión, teníamos que trabajar con prisas, cumpliendo hitos literalmente con la lengua fuera, además de toda la presión de los cambios que supone trasladarte con tu familia a un país muy diferente a España.

Pero aprendí, y muchísimo; fue para mí, a pesar de las crisis que viví junto con mis compañeros, una de las etapas más fértiles de ese periodo. Recuerdo alguna noche entera realizando una actualización de uno de los sistemas en los que se basaba el proyecto.

No había metodología, sólo tirar hacia delante del modo que fuese. Curiosamente, todos mis compañeros que entonces participábamos en ese proyecto para una compañía eléctrica sueca (Vattenfall), ya no están en la misma empresa, incluido yo mismo. Todos fuimos saliendo poco a poco encontrando (o buscando) mejores oportunidades laborales y profesionales.

De aquel proyecto me quedó muy claro la extraordinaria importancia de mantener una mínima metodología y orden en los desarrollos (abajo no había orden porque en el nivel ejecutivo ni lo había ni se fomentaba). Y también de la enorme importancia de un diseño pulcro y eficiente de la base de datos, ya que la aplicación era muy data-centric. La base de datos crecía a razón de millones de registros a diario, de modo que continuamente nos encontrábamos con nuevos cuellos de botella (tanto a nivel de software como de hardware). Todo un reto que finalmente pudimos estabilizar (nos llevó más de un año).

Después volví a España y comencé a interesarme por todo lo ágil y clean-code. Fue una época de lecturas frenéticas de toda la literatura relacionada que encontraba interesante (los libros, cómo no, de Martin Fowler, Robert C. Martin, etc.) y poco a poco fui confirmando ciertas intuiciones acerca de los pilares con los que construir buen software. 

Y como consecuencia natural, muy pronto comencé a darme cuenta de que no todo el mundo entendía igual el concepto de buen software, y que apenas se le prestaba atención a asuntos tan importantes como la organización de un equipo de trabajo, las dinámicas de grupo, la ausencia del concepto de jefe o gestor como aquel que facilita el trabajo de los demás, etc., cuyo resultado termina generando un producto bueno o malísimo.

Continuaba escribiendo software de un modo u otro, a veces con buenas condiciones y casi siempre en muy malas condiciones (exceso de reuniones impuestas, tareas no planificadas para hoy, etc.).

Entre 2008 y 2009 hice mi primera tentativa emprendedora. Y fue un total fracaso, pero me permitió meterme de lleno en Drupal. La idea era buena, pero somo se suele decir, la ejecución lo es todo. Por aquélla época comencé a leer mucho sobre emprendimiento e intraemprendimiento. Siempre digo que dejé esa compañía en la que mantenía un contrato fijo y con buen sueldo porque ya llevaba años preparándome mentalmente para probar otro tipo de cosas. Y es que nos centramos demasiado en la acción, pero se nos olvida una verdad trascendental: no es el hacer sino el ser (lo que somos) lo que provoca cambios verdaderos. Bueno, que enrollo en temas de desarrollo personal...

Entre pequeños proyectos de I+D y el mantenimiento del sistema que montamos en Suecia, tenía tiempo de comenzar a interesarme por otras tecnologías fuera del ecosistema de Microsoft. Comencé a hacer mis primeros proyectos web y a leer todo lo que podía sobre Drupal. Y, por supuesto, abracé NodeJS desde el primer momento. Entre otras cosas.

Tanto fue mi entusiasmo por Drupal que terminé participando como ponente en dos sesiones (esta y esta otra) en la Drupalcamp de 2011 en mi ciudad. Descubrí ese ecosistema y una comunidad muy implicada y estimulante.

Comencé a hacerme cargo de la gestión de equipos de trabajo sobre el 2009. Y no tenía ni idea de qué iba aquello, así que leí muchísimo al respecto y lo intenté hacer lo mejor posible.

La empresa para la que trabajaba entonces (la ingeniería Telvent Energía, ahora propiedad de Schneider Electric), no se puede decir que fuese una de esas cárnicas, pero lógicamente, la presión de sacar proyectos era alta. Como en todo, hay momentos buenos y malos, pero todo lo que quiero recordar de aquel periodo (trabajé en esa compañía desde el 2000 hasta el 2012) es bueno y hasta excepcional, y considero que no todo el mundo tiene la suerte de caer en una empresa y tener las experiencias nacionales e internacionales como tuve en Telvent, asistiendo a eventos importantes, etc. Viajé varias veces a USA (estuve en semana asistiendo a TAP program de Microsoft en Seattle, toda una experiencia viendo, oyendo y hablando con auténticos gurús, de los de verdad), así como viajes a diferentes ciudades de Suecia, Holanda, Eslovenia, etc. y hasta una semana en Beirut.

Pero el ciclo se fue acabando y comencé a interesarme por otras cosas y otras posibilidades laborales. Digamos que dejé de verme en un futuro lejano trabajando para la misma compañía.