1701
2017

Comenzando un nuevo producto - Smart TPL

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 digPRIME logoitales 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.

0901
2017

Como una novela...

Patricia - cubierta

Como una novela - portadaHace 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?

0101
2017
El Libro Negro del Programador

2006-2016 Una retrospectiva

Haruki Murakami - El fin del mundo y un despiadado país de las maravillasPuff..., 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...

1309
2016

Cómo usar repositorios de datos

Best Practices

Artículo disponible en epub y pdf:

Cómo usar repositorios de datosCómo usar repositorios de datos epub

Me llama mucho la atención cómo a lo largo de los años puedo haber trabajado en aplicaciones con .NET en C#, con javascript utilizando Angular y NodeJS, y también con PHP cuando estaba más centrado a hacer módulos en Drupal, y cómo con todos esos lenguajes con sus respectivos entornos de desarrollo se pueden aplicar las mismas buenas prácticas.

Hay veces que éstas se refieren a procedimientos de trabajo o al modo de estructurar un proyecto, otras hacen referencia a aplicar patrones de diseño e incluso antipatrones para detectar precisamente lo que no se hace bien. En otras ocasiones, son sencillamente prácticas habituales que hace la mayoría de la gente que usa una tecnología en particular (de ahí, por ejemplo, los proyectos de scaffolding).

Un buen proyecto software debe oler a buenas prácticas, de principio a fin, desde la arquitectura del mismo hasta la evolución de las funcionalidades que se le van añadiendo poco a poco.

Nada peor que una aplicación, proyecto o sistema en el que no se pueda ver claramente cómo están implementadas esas buenas prácticas.

Y es que además tienen algo en común: la mayoría de ellas son fáciles de implementar.

Y como me gusta escribir... pues voy a ir hablando de ellas, de aquellas con las que yo directamente he visto que tienen más impacto en la mejora de la calidad de un proyecto software.

Un aviso a navegantes: en muchas ocasiones los beneficios de estas recomendaciones no se ven claramente, ni siquiera en el corto plazo, y su impacto positivo a medio y largo plazo es más una cuestión sutil que sólo se aprende cuando has cometido todos los errores posibles y entonces se hace la luz y dices algo como, "ahora sí que lo entiendo".

Para mí la implementación de repositorios de datos es una de las prácticas más útiles en cualquier proyecto software.

1808
2016
Coaching para desarrolladores de software

El hábito de procedimentar

No me gusta repetir trabajo ni tareas pesadas que se hacen una y otra vez y que de algún modo se pueden automatizar o al menos indicar lo pasos a realizar para que la siguiente vez no pierdas tanto el tiempo en recordar cómo se hacía ésto o aquéllo. Si te encuentras en esta situación a menudo, que sepas que puedes evitarlo.

Si es verdad que debemos poner el foco en aquello que aporta valor, en las tareas verdaderamente creativas y productivas, entonces tenemos que encontrar la forma de no tener que reinventar la rueda continuamente. No estoy hablando de tareas que hay que hacer sí o sí (como un parte de trabajo) y hablo en sentido general, no sólo desde el punto de vista del desarrollo de software, sino de hacer todo lo posible para que estas tareas ocupen el menor tiempo posible y, sobre todo, no tengamos que pensar reiteradamente cómo se hacían.

Voy a poner varios ejemplos:

  • El proceso de publicar una nueva noticia en la web, ya sabes, crear el contenido, fijar bien la url, revisar el contenido, comprobar la estructura del mismo, revisar faltas de ortografía o de expresión, pedir la aprobación del mismo si es necesario, etc. Son varios pasos, sí, pero si este trabajo lo haces una vez cada varios meses, terminar olvidándolo y preguntándote ¿cómo había que poner el formato de las url?
  • Si mantienes varias webs, como es mi caso, y además todas con Drupal, y dado que no las actualizo continuamente (actualizaciones de módulos, mejoras de diseño, etc.), puedes encontrarte con que cada vez que vas a actualizar una, tienes que volver a investigar cómo se hacía esto o aquello, como por ejemplo, cómo y dónde guardar una copia de seguridad, cómo etiquetar la nueva versión de la web en GIT o similar, cómo comprobar que la nueva actualización no ha roto nada, cómo desplegar para que no te quede ningún cabo suelto, comprobar la seguridad, etc.
  • Llevo dos años usando la herramienta Scrivener para la creación de libros. Su proceso de compilación genera un fichero en format eBook, pdf, docx, etc. Sin embargo, después de generar el fichero tienes que comprobar varias cosas según tu flujo de trabajo y el propósito que tengas. Por ejemplo, si generas un eBook para Kindle, tienes (o deberías), revisar que el epub pasa las pruebas de validación con una herramienta como epubcheck, después tienes (o deberías) abrirlo con la herramienta Kindle Previewer y revisar página a página, y no digamos le proceso de publicación en Amazon.

En fin, son trabajos que realizas que requieren de varios pasos para su realización. Salvo que tengas una memoria prodigiosa, cada vez que los vayas a enfrentar algo se te quedará en el tintero.

¿Resultado? No se terminará del todo bien y se tardará más en realizarlo, aparte de lo tedioso que resulta tener que investigar algo porque lo has olvidado... Y si te fijas bien, parte de tu trabajo lo pasas realizando tareas que bien podrían estar bajo el paraguas de un procedimiento.

3006
2016
Software Project Management

Frameworks corporativos

No es la primera vez que me encuentro ante un nuevo proyecto en el que el cliente te exige utilizar ciertas tecnologías para sus desarrollos internos. Se trata de una compañía que tiene su propio departamento para satisfacer las necesidades software de la empresa (web corporativa, intranets, canal de pedidos, gestión de tickets e incidencias, etc.); ahora necesitan externalizar algunos trabajos.

No es que usen esas tecnologías porque sí, sino que es la misma política de empresa la que en su día decidió apostar por ellas y no salir de ahí salvo por un motivo bien justificado. De ese modo, todas las aplicaciones internas tienen cierta coherencia.

Esa decisión puede ser muy arriesgada: ¿y si basamos todos los desarrollos en este motor de base de datos que termina cayendo en desuso o cuya licencia sube de precio escandalosamente? ¿Y si usamos este framework para las interfaces de usuario web y con el tiempo surgen otros mucho mejores y productivos?

¿Acaso alguien tiene una bola de cristal y puede predecir las necesidades de la empresa a años vista? Puff...

Trabajar realizando proyectos software que deben tener una vida muy larga es en ocasiones gestionar muchísima incertidumbre en cuanto a la elección de las mejores tecnologías para ese proyecto.

Yo lo digo a menudo, y no me cansaré de repetirlo: es casi más importante usar bien una librería o framework que usar todo lo último porque sí

Por poner un sencillo ejemplo, me encanta Angular, es increíblemente productivo y te permite desacoplar muchos elementos de las interfaces de usuario para poder crear tests sobre ellos. Sin embargo, la nueva release Angular 2 es un mundo aparte en relación a la anterior versión y por tanto, si has hecho algo en los últimos años con Angular 1.x, pues ya sabes que o tendrás que continuar con ello mucho tiempo o tienes que plantear una migración, si te interesa, a la nueva versión. Y cómo no, desde el punto de vista empresarial, esa migración cuesta dinero...

Si el éxito de una compañía consiste, en parte, en mitigar y reducir riesgos, entonces definir el conjunto de tecnologías que usa para sus desarrollos internos puede tener sentido. Este enfoque no es único para grandes corporaciones, de ningún modo, cualquier organización de cualquier tamaño puede implementar esta política.

1504
2016
Coaching para desarrolladores de software

Principios sólidos

No, no voy a hablar de nada relacionado con los principios de desarrollo S.O.L.I.D., que, en cualquier caso, recomiendo a cualquier programador conocer en profundidad y, sobre todo, ponerlos en práctica.

En los últimos meses he tenido que leer bastante documentación sobre licitaciones y también he estado inmerso en propuestas de nuevos proyectos en colaboración con otras compañías.

En esas licitaciones, algunas para gobiernos autonómicos de mi país, llama la atención la falta de rigor en las especificaciones. Es más, concretamente en alguna se indicaba que "las tareas a realizar se plantearán con exactitud cuando el proyecto sea adjudicado al licitante". En otra, decía que el licitante debía adaptarse a las metodologías de trabajo más comunes, y mencionaba CMMi, Métrica 3, etc. En fin...

Al mismo tiempo, la mayoría de esos proyectos consisten en evolucionar aplicaciones que ya están funcionando en consejerías o departamentos de esas regiones.

¿Cómo poder estimar el esfuerzo para evolucionar algo sin ver su estado actual? ¿Estará la solución hecha unos zorros? ¿Será el típico proyecto espagueti o en cambio todo se habrá hecho con conciencia, mejoras continuas, limpieza de código, etc.?

Miedo me da encontrarme con algo así. 

En esos proyectos se hablaban de tecnologías que ya existían hacer quince años y que siguen muy presentes aunque bajo revisiones más recientes.

En otro, que no tiene nada que ver con los anteriores, se hablaba de trabajar a muy bajo nivel con cierto tipo de dispositivos, empleando el protoloco DLMS.

Y para variedad, estoy trabajando como colaborador externo para una magnífica compañía nacional, líder en su sector, y de nombre Altafonte. Utilizan un sistema basado en PHP, base de datos MemSQL, etc. A sus desarrolladores los considero unos héroes, por haber sabido avanzar en la solución, la base y el core de su negocio, mientras éste crece con multitud de nuevos requerimientos continuamente.

Pensando en todos esos proyectos, ¿qué es lo que pueden tener en común?

1202
2016
Coaching para desarrolladores de software

¿Requisitos? ¿Y eso qué es?

Question woman

Este es un tema tan manido en nuestra profesión, tan pesado, pero al mismo tiempo tan importante, que seguimos años y años hablando de lo mismo y sufriendo las mismas consecuencias una y otra vez.

¿Están bien especificados los proyectos? ¿Se parte de un grupo de requisitos suficientemente amplio? Es cierto que en software ágil ya se da por sentando que los requisitos pueden cambiar, porque de hecho cambian, es lo natural, pero lo hacen a partir de entregas, y esto es bueno y es precisamente lo que resuelven de manera magnífica todas las prácticas y principios de lo ágil.

Sin embargo, el peor vicio de nuestra profesión consiste en no saber o no querer esforzarse lo suficiente en establecer correctamente un documento con el catálogo de requisitos o especificaciones que indiquen qué es lo que hay que hacer. Es de sentido común dejar claro lo que el cliente quiere, ¿no?, sin embargo...

Muchas veces, el que tiene que tomar los requisitos, no sabe cómo hacer ese trabajo, me temo, pero en otras ocasiones, es la pura pereza de hablar con el cliente lo suficiente lo que impide que el equipo del proyecto sepa con más exactitud lo que hay que desarrollar.

Existe una ley universal que deberíamos tener siempre presente:

Cuanto más esfuerzo se dedica a especificar, menos tiempo se emplea en el desarrollo del proyecto.

Esto es una obviedad, una sandez decirlo, pero en el día a día, metidos en la vorágine del trabajo, reuniones, visitas, etc. se nos suele olvidar este principio.

Así de sencillo, así de simple. 

0701
2016
Coaching para desarrolladores de software

Cuidado con lo que lees...

"...no vaya a ser que cambie tu modo de pensar". Leí una vez en un libro de esos de desarrollo personal.

Comienza el año y después de tanto Rosco de Reyes (dulce típico en España y que pone fin a las navidades), te das cuenta de que ya es enero, vuelves al trabajo y esa enorme lista de propósitos y proyectos que alegremente hacías en diciembre, ahora la tienes delante y es hora de empezar a hacer cosas.

O sea, lo de siempre, comienza el camino para que al final del año, si nos seguimos acordando de esa lista, nos demos cuenta de que no hemos conseguido ni la mitad de la mitad. Es más, yo creo que esas promesas de mejora para el nuevo año entrante son más bien un tirar hacia delante y una excusa para justificar lo difícil que nos resulta actuar y hacer lo que debemos y queremos hacer. ¿O no?

Vale, sí, yo soy el primero que uso esas listas, las uso desde hace mucho con mayor o menor éxito. Uno de mis propósitos para este año se seguir leyendo más y mejores libros de todos los temas que me interesan, muchos de ellos de tecnología, otros de desarrollo personal, etc. 

¿Es que puede ser de otro modo? ¿Puede existir cualquier negocio o profesión que no avance sin seguir aprendiendo? Todo evoluciona, si no lo hacemos al mismo ritmo que todo lo demás, podemos terminar intentando vender algo a clientes de un mercado que desapareció o se transformó hace mucho.

2412
2015
Coaching para desarrolladores de software

Green Kiwi Games

Green Kiwi GamesGreen Kiwi Games © es un proyecto en el que he ido trabajando muy poco a poco en los últimos meses y que constituye lo que se llama un producto mínimo viable (MVP), esto es, un producto o proyecto que muestra la esencia de algo y que se expone para validar su propuesta de valor (o sea, si a la gente le resulta útil o no).

Si una cosa he aprendido en los últimos diez años, y no exagero, es que tu día a día como profesional termina reduciendo tus habilidades a un conjunto de tecnologías, las que usas lógicamente en la compañía para la que trabajas. Y esto no es bueno más aún cuando el cambio en nuestra profesión es vertiginoso. No obstante, en tecnología en general y en software en particular, las posibilidades son tremendas y la cantidad de tecnologías consolidadas y stacks maduros que existen te obligan a tener que estar al día si en unos años no quieres estar más obsoleto que el T-800 de Terminator.

Pues bien, Green Kiwi Games ha sido para mí la forma de profundizar en el stack MySql+Express+AngularJS+Nodejs (lo que se suele llamar MEAN, pero en esta ocasión sin MongoDB...).

Ya he hablado en alguna ocasión brevemente sobre cómo enfocar proyectos de emprendimiento desde el punto de vista del software, campo en el que he tenido mis éxitos pero también mis fracasos. Es un tema muy amplio y lamentablemente muchos proyectos fallan no por falta de una idea que pueda funcionar, sino por la ejecución del mismo proyecto y falta de disciplina para llevarlo a cabo en el tiempo. Buena ejecución, tenacidad y disciplina en el trabajo, esta es la receta en mi opinión.

En cualquier caso, todo parte de una idea que termina siendo lo que nos anima a seguir adelante porque de algún modo creemos en ella. Ahora bien, ¿cómo saber si los demás también la ven útil? Desde luego no es contándola, sino creando algo que lo muestre, algo que se pueda tocar y evaluar. De ahí lo del producto mínimo.

Pero, ¿cómo surgió la idea y qué es Green Kiwi Games? Pues bien, hace un tiempo me encontré con ciertas personas que hacían por su cuenta juegos de cartas, pero con un esfuerzo tremendo al no dominar ninguna herramienta informática y de forma totalmente manual. ¿Por qué no habilitar una web en donde el usuario subiera las imágenes y que la aplicación web se encargara de generar un pdf con las cartas listo para impresión? Sencillo, nada de otro mundo. Una idea, para ser buena, se tiene que poder explicar con muy pocas palabras. La innovación no trata de generar productos cercanos a la ciencia ficción, en cosas sencillas y banales se puede innovar también; es más, la mayor parte de la innovación pertenece a este último grupo. Tendemos a mitificar la innovación.

Eso es Green Kiwi Games, un sencillo portal que le permite a un usuario crear juegos de cartas de manera muy fácil, casi a golpe de clic. En un mundo en el que va dominando el do-it-yourself, descubrí auténticas comunidades dedicadas a hacer juegos de cartas personales y de distribución fuera de los canales habituales comerciales.

Si embargo, no hay dos sin tres, de modo que aproveché este mini proyecto para meterme de lleno en tecnologías que me apasionan, de modo que puedo decir que he pasado por todos los elementos que debe dominar un full-stack-developer y que describo a continuación.

Páginas