Me atrajo NodeJS desde un principio, cuando oí eso de código de servidor escrito en javascript. Después de aprender las nociones básicas hace un par de años, integrarlo con multitud de módulos y estar a punto de terminar un proyecto completo con este framework, en el que he estado trabajando en el último año, puedo decir que aún viendo sus pros pero también sus contras, sigue siendo para mí una maravillosa plataforma sobre la que construir aplicaciones escalables y mantenibles.

Framework, plataforma, tecnología... se mezclan un poco los conceptos: NodeJS te ofrece el coreframework esencial sobre el que construir aplicaciones, junto con un modelo de programación basado en eventos y una serie de módulos básicos pero muy importantes.

Lo que le da vida realmente a un proyecto con NodeJS es el enorme y vasto ecosistema de módulos que existe a su alrededor, que fueron apareciendo desde el primer momento en que NodeJS salió a escena y que hoy día siguen creciendo y evolucionando.

Esto es algo típico y la tendencia natural en software, como Drupal, Wordpress o el recién salido del horno ASP.NET 5 como framework de aplicaciiones web, sin cuya constelación de módulos que extienden o mejoran su funcionalidad no serían lo que son hoy en día.

Pero no es sólo cuestión de elegir e integrar un conjunto de módulos: es necesario utilizar un grupo de herramientas para una correcta gestión de la configuración de tu proyecto y para la puesta en marcha de los flujos de trabajo que hayas definido, además de aplicar continuamente buenos principios de desarrollo, clean code y una refactorización siempre presentes.

En este proyecto web con un backend bastante pesado en el que llevo trabajando un año he tenido oportunidad de usar NodeJS en profundidad, leyendo multitud de libros, muchos posts y artículos sobre buenas prácticas y buscando y analizando los módulos más populares o maduros para incorporar toda la funcionalidad.

A continuación cuento un poco mi experiencia que básicamente se basa en la pregunta recurrente de cómo hago estoahora cómo hago esto otro aún mejor y así hasta que el proyecto comienza a alcanzar cierta madurez, cuando todo el trabajo realizado comienza a converger en algo más palpable y empieza a verse un proyecto que ofrece cierta utilidad, o eso es al menos lo que esperas.

He utilizado una aproximación lean al proyecto, esto es, voy a cerrar un conjunto de funcionalidad muy bien definida y después es el mismo proyecto el que va a validar con los usuarios (los primeros son siempre tus amigos y familiares) si es de alguna utilidad..., si hay que seguir (;-), pivotar (;-| o comenzar otra cosa distinta (;-(.

Me fascina la aproximación lean, ya que en realidad construyes experimentos que después el mercado valida. Si no sabes qué es la aproximación lean de proyectos, comienza leyendo el libro clásido de Eric Ries.

En cuanto a los módulos que estoy usando, los agruparé funcionalmente.

Wunderlist sampleComo muchas veces he cometado en este blog, trabajar bien, generar un resultado de calidad en tiempo y sin necesidad de que los equipos de trabajo estén estresados continuamente, es más una cuestión de organización que de excesos de horas delante del ordenador. Cuando las horas extras dejan de ser puntuales y pasan a ser crónicas, evidencian un problema grave de planificación y productividad, no hay más.

No obstante, veo continuamente cómo se sigue abusando del correo electrónico para gestionar tareas con una lista interminable de replies y cómo se usa el Outlook o el Gmail como almacén documental; también veo a menudo cómo se usa el excel como herramienta para planificar el trabajo...

Digamos que aunque hablamos mucho de la sociedad del conocimiento y que todos tenemos acceso a ordenadores, portátiles, smartphones, etc., ciertas cosas se siguen haciendo igual que en los noventa, es decir, que apenas se sale del correo electrónico y el paquete ofimático de turno.

A estas alturas, gestionar las tareas de un equipo usando exclusivamente el correo y hojas en excel, no es que esté obsoleto, sino que revela una falta de productividad o una inercia total de la gente que los usa abusivamente sin querer encontrar opciones más apropiadas y más ágiles. Lo siento si tu jefe o manager se organiza así, toda su desorganización terminará afectándote de un modo u otro.

Hay que sustituir el uso (abuso) de esas herramientas por otras cuyo propósito es el de gestionar proyectos o tareas y además tienes que definir tus propios flujos de trabajo. El uso de cualquier herramienta para gestionar tareas viene después de que tengas claro cómo organizas tu trabajo (flujos de trabajo).

La cuestión no es en realidad qué tareas hacer en cada momento o en los próximos días o semanas, sino de qué modo gestionas tu tiempo.

Me gusta aplicar conceptos de desarrollo personal y coaching a mi trabajo como desarrollador de software y director del departamento que dirijo.

O pasamos tiempo teorizando, divagando y leyendo sobre esto y aquello (y seguramente llenando la cabeza de mucha información), o bien intentamos integrar en la acción todo eso, en el día a día, en las cosas que realizamos; si no lo hacemos así, en mi opinión perdemos el tiempo a no ser que te tomes esa avalancha de información como simple ocio: puedes leer un libro magnífico de lo que sea, no sé, como este en el que estoy ahora enfrascado sobre metodología lean en experiencias de usuario, pero si no aplicas lo que lees, no llegarás nunca a ningún tipo de conocimiento.

El conocimiento surje de aplicar lo que has aprendido. Generalmente confundimos verdadero conocimiento (experiencia) con una saturación total de información que nos impide realmente centrarnos y profundizar en nada.

Me temo que pasamos demasiado tiempo llenando la taza de información inútil y muy poco tiempo consiguiendo ese verdadero conocimiento que es el que nos resulta útil y práctico para hacer cosas. Yo siempre lo digo, no nos pagan para aprender cosas, tarea, por otra parte, infinita, sino por hacer cosas. Hay que leer, asistir a cursos y seminarios, claro, pero eso no basta; hay que aplicar en proyectos, sean profesionales o personales, todo eso para realmente adquirir ese conocimiento y experiencia.

Me encanta la teoría de la última milla: alguien que practica jogging y que quiere superarse cada vez más, conseguir mayores distancias, no lo consigue de un día para otro, sino paulatinamente; una vez has alcanzado la distancia que te has propuesto, no pares ahí, sigue, continúa aunque sean quinientos metros más o un kilómetro. En otras palabras, cuando ya has conseguido el objetivo que te has propuesto, continúa un poco más.

Ese poco más es el que te diferencia del resto, de los demás, de la competencia, y es lo que te permitirá superar tus limitaciones personales.

La excelencia o el trabajo bien hecho no consiste en un único aspecto que hay que cuidar, sino en todo lo que conlleva ese trabajo, desde la documentación, la calidad de las pruebas, incluso la calidad de las noticias en la web que hablan de ese proyecto. Como leí una vez, "como haces algo, así lo haces todo".

¿Cómo podemos aplicar la teoría de la última milla en nuestro trabajo como desarrolladores o en nuestro día a día laboral?

A continuación sugiero algunas de las cosas que yo hago, que no es que las haya leído y ahora me sirva para escribir esto o quedar bien con mis amigos o los clientes a los que intentamos vender algo, no, es lo que practico casi a diario desde hace años.

En software ocurre que no hay una misma respuesta para cada situación, para cada proyecto en el que cambia el número de personas involucradas en el equipo, la complejidad del mismo proyecto e incluso las tecnologías usadas. No obstante, lo que sí es cierto en todos los casos es que si se deja para el final el despliegue del sistema en un entorno lo más parecido o idéntico al de producción, nos encontraremos con muchos, muchísimos problemas.

Hay que desplegar en un entorno de producción lo más parecido al del cliente final tan pronto como se tenga alguna funcionalidad terminada pero completa, aunque sea simple.

Incluso si contamos con un entorno de integración fantástico y una gestión de la configuración para él magnífica, esto no nos garantizará que todo funcionará de maravilla en producción. Se podría escribir un libro entero sobre este tema, dependiendo de la naturaleza del proyecto e incluso del equipo, aunque me temo que casi nunca se tiene en cuenta el despliegue final hasta... ¡el final!, momento en el que nos podemos llevar muchas sorpresas.

Si no lo hacemos así, si no pensamos en el despliegue desde el principio, la brecha que nos encontraremos al final del proyecto cuando creemos que lo tenemos todo casi terminado, no hará más que agrandarse.

Un caso extremo de esto es cuando desarrollamos el proyecto en la misma máquina del cliente final..., llegando al caso de que fuera de él el proyecto requiere de una auténtica reingeniería (...) Esto, en software, es casi un pecado capital, al igual que probar contra bases de datos en producción o dispositivos que están en clientes finales. Vale sí, si hay que hacerlo, pues se hace cuando no haya más remedio, pero al menos tengamos en cuenta las consecuencias que puede tener.

Estas son las razones por las que opino que hay que publicar el proyecto en un entorno, llamémosle de pre-producción, lo antes posible.

Quizá por el entorno laboral en el que me muevo o por el tipo de productos software específico en el que trabajo, veo desde hace unos años una tendencia imparable; sí, ya sé, ni la nube es algo nuevo y tampoco es una moda que todo el mundo olvidará dentro de unos años. Lo que quiero decir es que más allá de titulares y opciones disponibles para desarrollar software, comienzo a ver en el día a día un interés real sobre todo lo relacionado con soluciones en cloud entre los clientes y las empresas que les proveen de soluciones software.

La razón de esto es sencilla: costes más reducidos y plataformas de servicios en la nube muy maduras que comienzan a ser bien conocidas por las empresas que desarrollan software.

Tenemos actualmente clientes que utilizan nuestros productos en modo Saas (software as a service) desplegado en la plataforma de computación en la nube de Microsoft, Azure, y la verdad, la experiencia desde hace dos años es extraordinaria.

Realmente estamos viviendo un cambio de paradigma en el desarrollo de productos software, muy real y muy a tener en cuenta entre aquellos que ahora mismo se están formando para esta profesión, aunque lo que quiero destacar aquí es que contrariamente a lo que algunos creen, programar para la nube no tiene en absoluto nada que ver con programar una solución para su despliegue en equipos locales en los que tú mismo o alguien de tu empresa administra.

Programar para la nube es además poder usar una serie de servicios que sólo están disponibles en esa infraesctructura y que afectan a la naturaleza de tu aplicación.

Es verdad que una aplicación para escritorio o con una interfaz de usuario web la puedes desplegar en una infraesctructura en la nube (con Azure, Amazon AWS, Rackspace, etc.); sin embargo la nube ofrece muchísimos más servicios para el desarrollo de aplicaciones. Utilizar los servicios que todos esos proveedores te ofrecen no es sólo tener un medio sencillo para hostear tu aplicación, es muchísimo más.

Si decides comenzar un nuevo sistema desde cero teniendo en cuenta algunos de esos servicios, la anatomía de tu aplicación será muy distinta que si usaras otro tipo de infraestructura.

Esta es una de las cosas más difíciles de resolver cuando afrontamos la creación de un nuevo proyecto: distinguir claramente entre qué debe hacer de cómo se debe hacer.

El "qué" está relacionado con requisitos, especificaciones, historias de usuario, todo aquello que nos haga entender lo que el cliente quiere, su problema a resolver.

El "cómo" tiene que ver con las tecnologías que van a resolver ese problema que el cliente nos plantea, en otras palabras, el cómo abarca desde las tecnologías a usar, metodología, evidencias a entregar hasta dónde se desplegaría el proyecto final.

Hay una confusión tremenda entre esa separación de conceptos, hasta el punto de tener que forzar o usar mal tecnologías mal elegidas para el propósito indicado en una sencilla especificación (cuando no se le dice a un cliente que "eso no se puede hacer").

Si ya es difícil extraer al comienzo todos los requisitos y conseguir que estos estén descritos con buena calidad y que sean entendibles, más complicado aún el elegir ese cómo a partir de todo lo anterior.

De cómo se gestione esto y las decisiones que se tomen en ese momento dependerá en gran medida la calidad del proyecto que se entregue, su coste final y su facilidad de mantenimiento y evolución. Errores en esta fase hacen que el proyecto termine en un completo fracaso o haya que tirarlo al cabo de algunos años.

Lo peor de todo es que en muchas ocasiones confundimos requisitos objetivos, indicados o no por un cliente o intermediario, con aquellas tecnologías que nos gustaría usar porque sí o bien porque son las únicas que conocemos bien y no queremos salir de nuestra zona natural de confort. 

Traducido al desarrollo de proyectos software, esto viene a ser algo así como empezar la casa por el tejado: si antes de afrontar un nuevo proyecto, sea del tipo de que sea, ya estamos diciendo que lo vamos a hacer con una base de datos en SQL Server, ya estamos levantando paredes en el laberinto que se formará durante su desarrollo, o dicho en otras palabras, en lugar de solucionar, estamos poniéndonos a nosotros mismos obstáculos.

Este no es que sea un error más, el confundir qué se tiene que hacer con cómo se debe hacer, sino que es un error paradigmático de una profesión tanto si a ella llegan gente titulada con uno u otro título académico o intrusos sin formación formal relacionada (sin ánimo de menospreciar a nadie, al fin de al cabo sólo valen el talento de cada cual y el trabajo bien hecho).

No hace mucho he tenido que retomar un desarrollo que comencé hace año y medio y que después continuó uno de mis compañeros. A veces programamos pensando que nos vamos a acordar de todos y cada uno de los detalles de lo que hacemos cuando la realidad es que a los pocos días se nos olvidan sin poder evitarlo y a los meses casi ni reconocemos que esto o aquello los hiciste tú mismo. 

Para cada clase incluimos una sección de comentarios indicando el autor de la misma y su propósito, como manera rápida de identificar esa información; en ocasiones me cuesta mucho recordar que una clase concreta la comencé yo mismo... No es mala memoria (que también, quién sabe), aunque me consuelo diciéndome que es el efecto de haber escrito miles de líneas de código en los últimos años.

Con frecuencia se cae en el error de programar para solucionar algo ahora y sin tener en cuenta que hay que solucionarlo para siempre. Pero, ¿cómo medir más o menos objetivamente que algo está mejor resuelto para el largo plazo? O nos interesamos por los resultados a corto plazo o a largo plazo, el resultado en uno y otro caso no tienen nada que ver.

Al retomar aquel proyecto pude comprobar una vez más cómo escribir software de manera limpia, clara, sencilla y con una buena cobertura de pruebas te puede salvar de malgastar días y semanas de trabajo sencillamente retomando aquello que hiciste hace mucho tiempo. Lo contrario es acumular deuda técnica que te pasará factura tarde o temprano, o lo que es peor, tendrás a un compañero acordándose de tus propias chapuzas; sí, seguramente sea ese que cuando te lo cruzas viniendo del office te mira con mala cara, quién sabe.

Del mismo modo no siempre he podido trabajar tanto en el detalle, en encontrar la mejor solución y sé de sobra el resultado: malos trabajos que se entregan y que terminan empeorando con el tiempo.

Llamamos deuda técnica a todos esos detalles que vamos dejando de lado sin resolver del todo bien pero que cuando se acumulan, terminan en una solución difícil de evolucionar y mantener. Es algo malo, muy malo, como eso de acumular karma negativo... Es la pesadilla de cualquier desarrollador: el tener que asumir un proyecto que ha hecho otro y que no hay quien lo entienda, que está cogido con pinzas.

Ahora mismo se está viviendo una auténtica ola sobre el emprendimiento en mi país; no sé si en otros lugares está sucediento lo mismo. Lo que debería ser una actitud que se les enseña a los niños desde parvulario, ahora parece que lo estamos aprendiendo a marchas forzadas (por la urgencia de la crisis económica y financiera que llevamos arrastrando desde hace tiempo).

Revistas y publicaciones, programas de radio y televisión, másters y mucho libro de autoayuda para el desarrollo personal y coaching así como programas de apoyo al emprendedor están ahora por todos sitios.

Para mí todo esto es bueno porque supone que dejamos de pensar que los demás nos van a dar un trabajo y tomamos la responsabilidad de pensar por nosotros mismos, lo que en algunos círculos llaman el empoderamiento personal. Esta misma actitud es también muy positiva como empleado de una compañía, lo que se llama intraemprendedor, es decir, aquella persona que trabajando en una empresa innova o aporta ideas desde su ámbito de responsabilidad manteniendo una actitud proactiva continuamente, con él mismo y con todo lo que le rodea.

Los desarrolladores de software quizá tengamos más facilidades que otros profesionales para emprender en un momento en que todo el mundo mira a Internet y el paradigma económico impulsa la eficiencia y el uso masivo de dispositivos siempre conectados. De ahí que muchos desarrolladores tengan continuamente ideas que poner en marcha con las que intentar emprender un proyecto empresarial.

Programar bien y dominar tecnológicamente ciertas plataformas, no tiene nada que ver con emprender un buen proyecto que funcione comercialmente. Para esto hacen falta muchas otras habilidades que, por supuesto, se pueden aprender.

Lo que no es nada bueno es que se ignoren todas esas habilidades y conocimientos necesarios para montar comercialmente un proyecto. Me preguntaron no hace mucho qué pensaba yo al respecto y cuáles podrían ser los primeros pasos para pasar de la idea al producto, de modo que en esta ocasión me voy a extender un poco más de lo habitual y aportar mi granito de arena para al menos indicar todo lo que hay que tener en cuenta.

Hay cientos de libros, seminarios, cursos y hasta másters que cubren este tema, que, además, evoluciona igual que las tecnologías software. Por tanto, este post viene a ser algo así como una introducción acelerada al emprendimiento con proyectos software.

Vivir con menos (Albert Cañigueral)Hace poco he terminado de leer este maravilloso libro de Albert Cañigueral y de título Vivir Mejor con Menos, descubre las ventajas de la nueva economía colaborativa y, como me ocurre a menudo, no puedo evitar poner gran parte de las cosas que leo en relación a mi actividad como desarrollor de software y gestor de proyectos. 

Por decirlo en pocas palabras, me siento entusiasmado por toda la información que ofrece Albert en su libro y por las enormes oportunidades que se están abriendo ya en este nuevo paradigma económico que sutilmente se está abriendo paso poco a poco. 

La economía compartida (o sharing economy), por definirla brevemente, consiste en mantener una relación distinta con los objetos que consumimos y usamos: pasamos de relacionarnos con ellos en forma de propiedad a considerarlos como un servicio de intercambio, de ahí lo de consumo colaborativo.

Los paralelismos entre este concepto y Saas, Paas y Iaas (software / plataforma / infraestructura como servicio) son evidentes. De hecho, uno de los productos que comercializamos en la compañía para la que trabajo se ofrece como servicio con suscripciones periódicas y lo más sorprendente es que todos los clientes usan esta modalidad. No compran el producto, sino que pagan periódicamente por su uso.

Cuando se habla de economía compartida a uno se le viene a la cabeza Bla Bla Car o Airbnb (plataformas muy populares en mi país); no obstante, eso es sólo la punta del iceberg; lo más interesante de todo es que es una renovación de viejas formas de organización, quizá ancestrales, pero que con Internet como palanca su efecto es infinitamente mayor. Cuando hablamos de Internet, lo hacemos de software...

Trabajar en distintos ámbitos tiene algo de fascinante, terminas dándote cuenta de cómo lo que haces en uno enriquece los demás y al revés.

Ahora mismo estoy trabajando en un proyecto basado en MEAN que al mismo tiempo me está permitiendo sentar las bases de un proyecto de I+D que estamos realizando en la compañía para la que trabajo y que desarrollaremos durante 2015 y 2016; este proyecto consiste en un sistema de detección y diagnóstico de incidencias para el despliegue de cuatro millones de smart meters, de la mano de una compañía de distribución eléctrica nacional. Big-data con Hadoop, su despliegue en la nube con Azure, el análisis y explotación de esos datos más una capa de servicios que consumirán terceros sistemas serán las partes esenciales del proyecto y en cuyas tecnologías nos vamos a meter de lleno en los próximos meses.

¿Qué puede garantizar que tendremos éxito en ese nuevo proyecto reconociendo que algunas de las tecnologías que vamos a usar son relativamente nuevas para nosotros?

Si crees conocer muy bien la tecnología X, ¿qué te hace pensar que serás capaz de sacar provecho a otra totalmente distinta?, ¿te asegura acaso que vas a tener éxito con un nuevo stack que debes usar para un nuevo proyecto cuya naturaleza no tiene nada que ver con lo que has hecho hasta ahora?

Para un responsable de proyectos, ese es un riesgo que hay que considerar a fondo.

Un desarrollador de software o un equipo de trabajo sólo pueden tener éxito en cualquier proyecto si son capaces de mantener firmemente una serie de principios de desarrollo y métodos que se pueden aplicar a cualquier tipo de tecnología.

Por tanto, aún teniendo valor, me da siempre qué pensar cuando escucho afirmaciones del tipo "soy experto en C#", "nivel avanzado de administración de Sql Server", o "desarrollador front-end con AngularJS", etc, cosa que se suele ver en todos los currículums que me llegan (y por qué no, en el mío propio hasta hace pocos años). Todo eso es fantástico, pero no suficiente...

Si dominas una serie de principios serás bueno y tendrás éxito en cualquier proyecto software independientemente de las tecnologías que se usen.

Páginas

¿Por qué leer El Libro Negro del Programador?

Adquirir desde:
Amazon (kindle eBook / papel)
CreateSpace (papel)
PayHip (epub / mobi / pdf)

El libro negro del programador.com
Segunda Edición - 2017

Archivo

Trabajo en...