Avanza el verano y en breve me tomaré unas semanas de vacaciones. Es como una especie de parón en tu día a día, en el trabajo, en la rutina familiar.
¿Cómo ha ido en un sentido general esta primera parte del año? No puedo evitar hacerme preguntas de este tipo. Así que, aunque no soy muy dado a compartir reflexiones introspectivas en mi web, haré un resumen de este agitado año, al menos desde el punto de vista profesional y técnico, de todas las cosas y temas con los que he tratado.
Durante esta primera parte del año hemos cerrado proyectos importantes y abierto otros nuevos; trabajamos en la realización de un prototipo de software con el que vamos a preguntarle al mercado qué interés puede haber en él y planteamos ya una revisión profunda de uno de los productos que comercializamos.
Del mismo modo, he avanzado en varios proyectos personales (he registrado mi primera marca) y por fin hemos puesto la primera piedra, como se suele decir, en otro proyecto después de tres años de planos, arquitecto, licencias, etc.
Lo que me pregunto es cuánto hay de mi forma de gestionar los proyectos de software que dirijo en todos esos proyectos que, digamos, se gestan fuera de mi horario laboral, y al revés. En definitiva, creo que para cualquier actividad valen los conceptos de definición de roles y que en todas es mucho mejor la colaboración que la imposición. Es liberador saber que no tienes que llevar siempre la razón y que el mundo se modela a medida que haces cosas y resuelves problemas.
Lo que sí sé es que en todos esos proyectos, sean del tipo que sean, se avanza resolviendo problemas. No hay más. Emprender en algo consiste en resolver los problemas que van surgiendo de la forma más ágil posible. En realidad, cualquier problema es algo que tienes que aprender y sólo la carga emocional negativa que le quieras dar es lo que lo convierte en un problema. En fin, que divago.
A continuación escribo sobre lo más significativo para mí de esta primera parte del año.
JavaScript y librerías relacionadas
Parece ser que estamos viviendo un gran auge de un lenguaje que tiene muchos años: puesto que se está imponiendo la web en casi todo lo que hacemos y afortunadamente vamos convergiendo hacia estándares, JavaScript tenía que jugar un papel muy importante.
En mi opinión, esto será aún mejor cuando se popularice la revisión del lenguaje ECMAScript 6, que le aporta una mayor madurez y contiene características que los desarrolladores acostumbrados a otros entornos siempre hemos echado en falta. ES6 es como el hermano mayor de JavaScript con el que irán convergiendo todos los entornos (NodeJS), librerías (AngularJS) y frameworks que usan este lenguaje.
No obstante, me sorprende que exista cierta cultura de clean code y de refactorizaciones continuas, pero que, por alguna razón, ésta siempre se aplique a lenguajes como C# y Java y no siempre a los desarrollos de JavaScript. Así, es muy fácil encontrar código en este lenguaje verdaderamente sucio por todas partes; no hay más que husmear desde Firebug o las DevTools de Chrome en cualquier web y descubrir cosas realmente significativas y curiosas en sitios que reciben miles de usuarios diarios. Hay mucho por hacer…
AngularJS
Comencé con AngularJS en 2014 y desde entonces lo he usado en todos los proyectos que he dirigido con interfaces web.
Aunque es más apropiado para SPA (single-page applications), se puede sacar provecho de esta librería en cualquier aplicación web. Sin ninguna duda, una solución intensiva en código JavaScript es más rápida de escribir y, si se cuida bien la organización de los assets, queda muchísimo mejor estructurada de cara a su mantenimiento y evolución.
Como todo: un buen uso de AngularJS da lugar a una solución clara, limpia y bien estructurada; un mal uso puede generar una solución realmente sucia y difícil de seguir.
Me encantan las directivas de AngularJS; recientemente estoy viendo más y más publicaciones sobre Polymer, una librería para crear componentes web que aún no conozco del todo y que es similar a las directivas de AngularJS.
Flujos de trabajo para casi todo
Cualquier trabajo no es sólo una cuestión de realizar una tarea concreta con un comienzo y un final: ésta tiene que estar enmarcada en un procedimiento o flujo de trabajo que ordene cómo realizar las tareas.
Del mismo modo, cualquier trabajo que se tenga que repetir y que pueda ser más o menos complejo debe organizarse para que, cuando se repita, se haga correcta y eficientemente. Esta primera parte del año me ha tocado definir flujos de trabajo en distintos contextos. Lo más relevante de esto es que veo que casi nadie se preocupa por formalizar este tipo de procedimientos para que no haya que repensar una y otra vez cómo hacer las mismas cosas (perdiendo un tiempo precioso en el camino).
A nivel técnico, he usado intensamente Grunt para una aplicación web en la que trabajo desde hace un tiempo y he escrito varios procedimientos acerca de su despliegue ordenado, validación, etc.
Igualmente, hemos comenzado un proyecto (ajeno totalmente al software) que consiste en la construcción de unos alojamientos rurales, después de varios años de proyecto, planos, permisos, etc. Puesto que somos varias las personas implicadas —los dueños, el arquitecto, el aparejador, el constructor, etc.—, he definido lo mejor posible el rol de cada uno para que a cada paso que haya que dar no tengamos que hablar todos con todos, bloqueando la toma de decisiones del día a día y suponiendo una carga de trabajo adicional (e innecesaria). Esta es la única forma de avanzar en los distintos proyectos que tienes en tu vida profesional y personal, o eso espero, ¿?
Git no sólo para código
Me encanta Git, ¿a quién no? Este año he comenzado a usarlo no sólo como herramienta de control de versiones y repositorio para código, sino también para otro tipo de documentos, como los dos libros en los que estoy ya trabajando.
Aunque existen herramientas visuales para Git y vengo del mundo de Microsoft, llega un momento en que aprecias la comodidad de usar la consola para muchas tareas: sencillamente termina siendo más eficiente. Escribiendo esto se me viene a la cabeza ese magnífico y clásico libro de Neal Stephenson titulado En el principio… fue la línea de comandos. Genial y de obligada relectura cada ciertos años.
Optimización y rendimiento web
Al haber trabajado muchos años en el backend, he dedicado mucho tiempo a la optimización de código (a veces por necesidad y otras por puro placer, esa es la verdad). Esta primera parte del año he profundizado muchísimo en la optimización, no sólo de los flujos de trabajo de una aplicación web profesional, sino también de todos los assets necesarios para navegar con el frontend: ficheros HTML, CSS, imágenes, fuentes, minificación, técnicas de caché avanzadas, análisis en profundidad de los requests que realiza el navegador, buen uso de los selectores CSS, frameworks de layout más eficientes, el overhead que puede suponer obsesionarte con que tu aplicación sea responsiva, retraso intencionado en la carga de recursos y un larguíííísimo etcétera.
Curiosamente, apenas hay literatura en español sobre este tema tan importante, dado que el mundo web está creciendo exponencialmente y pocos desarrolladores conocen al menos las técnicas más relevantes.
La clave está en ejecutar todas estas técnicas de optimización sin ofuscar la solución.
Sobre desarrollo web he mantenido muchas conversaciones interesantes acerca de lo poliédrico que puede ser el desarrollo de un portal web: además de la elección de las tecnologías correctas, no se pueden obviar las técnicas de optimización, tampoco ignorar estrategias SEO/SEM, integrar analítica web, etc. De modo que cuando leo un currículum en donde se pone «desarrollador web», la verdad es que no sé qué pensar…
Nginx y Redis
Para el proyecto que estoy a punto de publicar he usado por primera vez Nginx y Redis, dos proyectos que me parecen fantásticos. Nginx juega un papel muy importante en la arquitectura de despliegue de un sistema muy escalable (muchos usuarios concurrentes accediendo a un portal web), al tiempo que con Redis se puede jugar muchísimo para conseguir enormes mejoras de rendimiento en distintos tipos de aplicaciones.
Visual Studio 2015
Hemos comenzado a usar Visual Studio 2015 estos meses atrás y a adentrarnos de lleno con ASP.NET 5 y DNX, la nueva revisión de Entity Framework, etc. Sorprende cómo se han ido adoptando las formas de trabajar con proyectos open source en este nuevo tipo de proyectos con Visual Studio 2015 y esta nueva revisión de ASP.NET.
Desarrollo para la nube
Hemos seguido usando Microsoft Azure intensamente para nuestros clientes, con mucha satisfacción. Afortunadamente, el número de suscripciones que vamos creando va subiendo y los clientes van viendo normal el planteamiento de soluciones en la nube a las que se conectan por una VPN y que incluso en algunos casos pagan como un servicio.
Emprendimiento lean y gestión del trabajo
He leído todo lo que ha caído en mis manos acerca del enfoque lean de proyectos y no sólo he saciado mi curiosidad, sino que estoy a punto de publicar un proyecto con esta metodología.
Ahora que echo la vista atrás, sorprende lo productivo que puede ser uno cuando se para un momento una vez a la semana y define un conjunto de microtareas, del tipo que sea, que no lleven más de una o dos horas cada una. Gestionándolas con aplicaciones como Wunderlist (ya hablé sobre herramientas de gestión de tareas en este post), pasa la semana y te das cuenta de la cantidad de cosas que puedes hacer (y aprender) sacando huecos por las noches, esas tardes en las que a lo mejor tus hijas ven una peli, un rato durante la hora de la siesta los fines de semana o un momento durante el trayecto de tren Sevilla/Madrid, etc.
Si es que es una cuestión de constancia y disciplina: la mayoría de la gente comienza muchas cosas y termina muy pocas (y pasa la mayor parte del tiempo hablando sobre ellas en lugar de dedicarse a ellas, me temo); esa es la realidad.
Estos meses me he seguido interesando mucho por la gestión del trabajo y la optimización del tiempo, leyendo varios libros relacionados. En el fondo, todos vendemos nuestro tiempo, de modo que lo tenemos que optimizar, ¿no?
El Libro Negro del Programador
Las ventas de El Libro Negro del Programador han subido sustancialmente en este primer semestre del año, lo cual no me hace más feliz por los royalties que pueda recibir, sino porque me gusta ver que el libro realmente ayuda a crear mejores desarrolladores de software. Del mismo modo, digo yo que unos eurillos extra también gustan de vez en cuando…
En ocasiones ha sido marcado por Amazon.es como el número uno en ventas de libros dentro de la categoría de Programación y Desarrollo de Software.
Lecturas, lecturas y más lecturas
No entiendo vivir sin leer. ¿Cómo podemos progresar, en el sentido que cada uno le dé a esto, sin conocer las experiencias de otros?
He leído mucho y sobre temas muy diversos: libros técnicos, de organización del trabajo, de marketing, de sabiduría oriental y perenne, etc.
Ahora bien, de nada serviría leer lo que sea si no tiene algún tipo de impacto en tu vida. ¿Para qué profundizar en un libro de AngularJS sin hacer un proyecto con esa librería? ¿Para qué leer sobre Vipassana si nunca dedicas un minuto a meditar?
¿Para qué tanto leer, aprender y tanto hacer? Vale, no voy a defender ahora la vuelta al pueblo, al huerto o a esa vida tranquila y apegada a la naturaleza que defendía Thoreau en Walden (libro que, por cierto, recomiendo).
Leemos para aprender, pero sobre todo para tener un sentido de humildad ante nuestra profesión, ante la vida en general.
Me apena la gente que se queja continuamente, sobre todo para tapar su propio nivel de incompetencia, pereza o pusilanimidad. Lo siento, pero a mis 41 años, si algo he aprendido es que cuanto más se queja la gente, más incompetente es realmente. Las mentes creativas y dinámicas no necesitan escudarse en la queja para nada.
Leemos porque tenemos la responsabilidad de mejorar todo lo que hacemos o tocamos en nuestro ámbito de responsabilidad. Un barrendero debe dejar la calle tan limpia con el mismo rigor con el que un ingeniero de la NASA investiga cómo llevar una sonda a Plutón. Sólo así el resultado llegará solo. No obstante, la cultura de la queja, de lo mío y del yo primero, nos ofusca y nos impide progresar en una mejor dirección.
¿Y entonces?
La cuestión no es plantearte «qué voy a hacer hoy por mí», sino «qué puedo hacer por los demás», porque sólo puedes progresar personalmente cuando ayudas a los demás, en el sentido que sea. No hay más. Si lo piensas, ahí está el secreto de todo lo que funciona: un empleado ayuda a su jefe y a su empresa a obtener unos resultados, un proveedor ayuda a un cliente con algo que necesita, un padre ayuda a sus hijas a crecer, etc.
¡Ea!, pues después de esta reflexión tan budista, os deseo un gran verano.