Rafa G. Blanes Blog

Hace unos dos años, comencé a interesarme por una disciplina de la que no tenía ni idea en aquel momento, pero cuyo nombre me llamaba mucho la atención.

En pleno hype de la IA (al menos en mi feed de LinkedIn, la saturación es total), me llama la atención que un sector emergente y en pleno desarrollo y con un potencial tan extraordinario y aún imposible de medir, esté pasando tan desapercibido, sobre todo entre ingenieros informáticos.

Recuerdo que me compré un par de libros sobre física cuántica, de divulgación, nada académicos, y fue en uno de ellos donde descubrí este campo en expansión de la computación cuántica, así que fui poco a poco tirando del hilo.

Me di cuenta de que esto no es una tecnología que te lees con un par de libros, algunos articulillos y varios videos en youtube y ya sabes hacer algo, para nada, así que después de leer mucho y hacer pequeñas pruebas de concepto un poco a ciegas, seguía sintiendo que muchas cosas se me escapaban, y que necesitaba una formación específica mucho más profunda.

Me surgió cierto interés a partir de las lecturas de esos dos libros y decidí comprarme uno específico de computación cuántica, Dancing with Qubits, de Robert S. Suton:

En este libro, esperaba encontrar quizá algo así como una nueva forma de programar estos dispositivos, con librerías específicas, etc. y hacer lo que venimos haciendo los programadores toda la vida con un computador clásico. 

Nada más lejos de la realidad: me sorprendió e impactó que esto va de un nuevo paradigma de dispositivos y una forma totalmente diferente de resolver e implementar algoritmos.

Para mi sorpresa, la mitad de ese libro es de matemáticas, sí, has leído bien, en especial, álgebra lineal, números complejos y notación de Dirac, entre otras hierbas, y comprobé cómo todas esas asignaturas de matemáticas con las que tanto me machacaron en la universidad, habían pasado a otro plano en lo más profundo de mi mente (vaya, que apenas recordaba nada).

Por esa razón, actualmente estoy haciendo un máster universitario sobre esto, que dura aproximadamente un año, en la UNIR (Universidad Internacional de la Rioja), algo que estoy compatibilizando como puedo con mis responsabilidades laborales y familiares :-(, pero lo cierto es que me está gustando más de lo que yo pensaba. Una pequeña parte del contenido de algunas materias, ya las estudié en la universidad, hace más años de los que recuerdo, y el resto me está ayudando a profundizar en esta disciplina.

Existe un auténtico stack relacionado con la computación cuántica, tanto para su estudio como su aplicación, desde investigación básica hasta desarrollo de algoritmos, y un interés empresarial cada vez mayor; en algún sitio leí que el sector crece un 38% anualmente, mientras que IBM (que está apostando muchísimo por esto) anunció que antes de 2035 comenzará a comercializar ordenadores cuánticos, nada más y nada menos.

Poco a poco, fui introduciéndome más y más en el tema, hasta haciendo pequeños ejemplos simulados con Python con Quiskit y simuladores (una de las librerías más populares, de IBM), sin saber muy bien lo que hacía y sorprendiéndome al comprobar que esto no iba de programar ordenadores mucho más potentes que los actuales, en absoluto. Por cierto, gran parte de Quiskit está escrito en Rust: https://github.com/Qiskit/qiskit.

Para comprender bien de qué va la computación cuántica, hay que estudiar, y mucho, pero resumidamente, podemos decir que se trata de aprovechar ciertas cualidades cuánticas de los átomos para realizar cierto tipo de cálculos con una potencia hoy día inimaginable (de un orden exponencial) y muy superior en comparación con los ordenadores más potentes actuales como "El Capitan", ubicado en el Lawrence Livermore National Laboratory. Con la computación cuántica, se pueden afrontar problemas que hoy día son inabordables con las capacidades de la computación clásica, como la simulación de moléculas, factorización de números grandes (algo esencial en criptografía), optimización combinatoria de rutas logísticas y un larguísimo etcétera.

Ahora mismo mi interés en esto es prioridad número uno, y además encaja muy bien con mi experiencia en arquitecturas de sistemas muy escalables y de HPC (high performance computing). Existe lo que se denomina quantum-hybrid environment, en donde se combina la computación clásica, para la preparación de datos, por ejemplo, con la ejecución de ciertas rutinas en ordenadores cuánticos.

Pienso que estamos ante una enorme oportunidad profesional, y diría que hasta empresarial (existen de momento verdaderamente pocas compañías o startups que se dediquen a esto), para quienes estén muy bien posicionados en este sector ya no solo ahora mismo sino en los próximos años, y me llama la atención que aparentemente casi todo el mundo esté enfocado en la IA, acaparando titulares cada día, mientras que la computación cuántica tendrá capacidad de impactar en nuestra economía y sociedad todavía más.

Puesto que el sector está en crecimiento y hay poco talento formado, los salarios de entrada con increíblemente altos, como puedes ver en la imagen (extraída de https://www.quantumjobslist.com/):

Lo que comencé por simple curiosidad académica, ahora se está convirtiendo en una oportunidad que puede que moldee mi futuro profesional, quién sabe.

Eso sí, te advierto que esta disciplina es difícil, hay que dominar bien esas matemáticas que apuntaba antes y puesto que es un paradigma de programación totalmente diferente, cuesta trabajo comprender bien los conceptos y el tipo de problemas que realmente puede afrontar un ordenador cuántico. Existen algoritmos cuánticos bien definidos, como el de Shor, y hasta el más sencillo, cuesta comprender su funcionamiento.

La computación cuántica no existe para resolver más problemas, sino para resolver mejor aquellos problemas cuya estructura lo justifica.

No obstante, pienso que quienes en su día estudiamos Ingeniería Informática, estamos muy bien posicionados para evolucionar hacia este sector, por nuestra formación en física, matemáticas y teoría de la información que se estudia en la carrera, y evolucionar tu perfil como Software Quantum Engineer (suena hasta bien).

Sin ninguna duda, estamos en un punto histórico de divergencia tecnológica que pocas veces se ha dado en la historia, con la IA, blockchain, la robótica y por supuesto, la computación cuántica. Todavía somos incapaces ni siquiera de imaginar todo lo que se podrá crear con la combinación de todo ello, aunque el libro de Michio Kaku, de título "Supremacía cuántica", ya describe (o imagina) el mundo que viene.

¡Qué gran momento para estar vivo! y qué fortuna poder ver cómo evoluciona todo lo anterior y el impacto que tendrá en nuestro modo de vida.

Si quieres un punto por donde empezar o conocer de qué va la computación cuántica, te recomiendo sin duda el IBM Quantum Learning, y no te preocupes si después de un mes curioseando por aquí y por allá, aún no comprendas nada.

Con la computación cuántica va a pasar lo mismo (si es que no está pasando ya) como sectores como la IA y blockchain, cuya la eclosión exponencial actual es el resultado de los builders que trabajaron en silencio hace tan solo cinco o diez años.

Aprender un nuevo lenguaje de programación te va a costar más o menos dependiendo de la experiencia actual que tengas con otros. Algunos, se aprenden por acumulación, esto es, sumas sintaxis, sumas librerías, añades trucos, y practicando hasta la extenuación, claro está.

Y luego está Rust, que se aprende por sustitución. No porque sea caprichoso, sino porque te obliga a cambiar el modelo mental con el que llevas años resolviendo problemas, con algunos mecanismos del lenguaje que, reconozco, me han costado bastante digerir, hasta que en algún momento, algo te hace click y comprendes la razón de esos puntos que al principio parecen un tanto esotéricos, sobre todo si cometes el error de compararlos con otros lenguajes.

Si vienes de lenguajes interpretados y de muy alto nivel como Python o Javascript, Rust de va a sonar a chino, literalmente.

Si tu mundo es Java o C#, la curva de aprendizaje será, digamos, media.

Y por último, si conoces C++, tu aprendizaje de Rust será algo natural, aunque también te requerirá cierto esfuerzo.

Al inicio de mi carrera profesional (hace más años de lo que recuerdo), comencé programando en C++, de modo que cuando me acerqué a Rust hace unos años, de alguna manera pensé que me resultaría ameno y hasta atractivo, pero no fue así: comencé leyendo el libro clásico Programming Rust mas toda la documentación de la web del lenguaje (muy buena, por cierto), pero me quedé bloqueado en varias ocasiones, después de optar a un proyecto en WebAssembly con Rust (que al final no salió).

No obstante, siempre volvía a Rust y a su ecosistema, más que nada por curiosidad y por la escalabilidad en mis escarceos en infraestructuras HPC (high performance computing), en donde ahorrar hasta el último byte y ciclo de cpu son importantes.

Y de ahí este artículo, cuya intención es principalmente insistir en los conceptos que debes asumir y comprender muy bien desde el principio de Rust para no estrellarte, hasta que comienzas a ver el bosque completo.

Hoy día siento cierta fluidez con Rust, es más, diría que hasta entusiasmo. Rust no te pregunta “¿cómo quieres programar?”. Rust te pregunta “¿qué garantías estás dispuesto a declarar?”. Y en esta pregunta, que tiene cierto tono filosófico, está la razón por la que cuesta tanto al principio… y por la que, cuando por fin te iluminas, ya no miras igual ni el lenguaje ni el resto de su ecosistema.

Siempre he odiado las comparaciones infantiles entre lenguajes y entornos: cada uno tiene su sitio y su nicho, y nuestra habilidad es saber elegir qué entornos, tecnologías, etc. son las más adecuadas según cada proyecto (y su ciclo de vida futuro).

Este artículo, a modo de brújula, es una forma de nombrar lo que suele doler en Rust cuando vienes de otros lenguajes y que a mí me hubiese gustado encontrar al comienzo. 

En cierto modo, Rust no es una nueva sintaxis, sino una especie de nuevo pacto al programar, muy diferente de otros lenguajes aunque, obviamente, tenga sus connotaciones similares con C++.

1) Rust no es C++, ni Java, ni Python (aunque tenga ciertos parecidos a elementos concretos de todos ellos)

Es tentador clasificar Rust por proximidad o similitud a otros lenguajes:

• “Se parece a C++ porque compila y es rápido”.
• “Se parece a Java/C# porque tiene traits que recuerdan a interfaces”.
• “Se parece a Python en la ergonomía moderna y el tooling”.

Y sin embargo, si lo abordas desde esas comparaciones, Rust se te queda como una maqueta: se parece por fuera, pero por dentro no encaja.

En C++ el poder se negocia con convenciones, disciplina (no te olvides de los "delete") y una cultura de haz lo correcto, pero nada, salvo tu buen hacer, te obliga a hacer lo correcto. En Rust, como veremos, esto es diferent.

En Java/C# la memoria y la vida de los objetos se externaliza a un runtime y el poderoso recolector de memoria que tango te aligera programar y despreocuparte del ciclo de vida de variables y recursos. En Python, por su parte, el coste está en la ejecución, no en la compilación, te centras en lo funcional y el lenguaje mismo te da ciertas garantías, pero todo tiene un coste, claro.

Rust, en cambio, te da la primera en la frente al mover una parte importante de la complejidad de una aplicación al momento de compilarla. Sí, has leído bien: me costó mucho captar esta idea y su razón.

En otros lenguajes, muchos asuntos internos de una aplicación, de bajo nivel, te lo dan todo hecho, pero Rust es mucho más explícito, y esto duele al principio (y luego te enamoras precisamente de esta cualidad que abordas y fluye de forma natural y productiva).

2) El uso de la memoria no es un detalle interno: es una parte del diseño

La intención principal de Rust es evitar bugs antes de que aparezcan en ejecución (lagunas de memoria, data races, punteros tontos, accesos no permitidos, etc.), y para eso, para muchos tipos de errores, tienes que preocuparte explícitamente de cómo tu aplicación usa internamente la memoria. Pero tranquilo, que, en realidad, esto es más fácil de lo que suena.

En muchos lenguajes, la gestión de la memoria ni aparece por ningún lado: declaras una variable o instancias un objeto, lo usas, y luego te olvidas, y un recolector de basura o garbage collector (que ni te enteras de que existe), hace su trabajo. Pero para ganar esta fluidez a la hora de escribir código, hay que pagar un precio, bien en la forma de uso ineficiente de la memoria y falta de optimización o bien con la introducción de errores que darán en algún momento la cara.

En Rust, la memoria se vuelve parte de la arquitectura. Esto me costó mucho comprenderlo (después de estar muy viciado con C# y Javascript con Node).

En realidad, esto es una ventaja… si aceptas algo chocante al comienzo:

• No existe un recolector de basura que amortigüe el coste de decisiones vagas.
• La vida de los datos no es una consecuencia: es un contrato. Puff, otro concepto que digerir.

Esto es, explícitamente hay que indicar para qué vas a usar un variable o recurso, cómo y cuál va a ser su ciclo de vida en la aplicación.

Esta es la primera gran fricción: en Rust, el lenguaje te pregunta “¿quién es el dueño de esto?”, y lo hace porque quiere garantizar algo muy concreto: que su liberación sea segura, determinista y eficiente, y que se haga lo antes posible para liberar recursos. Esto se consigue directamente por la misma naturaleza del lenguaje.

Para ello, se introduce el concepto de propiedad (ownership), mover (move) y préstamo (borrow) de variables y recursos:

Ownership, en realidad, es un concepto muy simple, por el que (simplificando un poco):

• Cada valor tiene un único dueño.
• Cuando el dueño sale de scope (contexto), el valor se libera, y punto; esto es, los recursos que utiliza (memoria) es liberada inmediatamente.
• El valor puede cambiar de dueño (lo que se denomina "mover").
• Al prestar un valor, no se transfiere su propiedad.

Y ya está, ideas simples pero con un impacto poderoso.

En el siguiente snippet se puede ver todo lo anterior (y creéme, al principio es muy frustrante ver cómo para unas simples líneas de código, el compilador no para de protestar hasta que corrijes lo que está mal):

fn main() {

    let s = String::from("El Libro Negro del Programador"); // s es el dueño de esa cadena de texto

    let t = s; // move: ahora t es el dueño

    println!("{}", t);

    println!("{}", s); // error: s ya no tiene el valor, el compilador protesta

}

Pero lo importante es que ese error en el código, se detecta en compilación, no en ejecución, y esto tiene un impacto extraordinario en la seguridad y eficiencia de tu aplicación.

Cuando el compilador de Rust indica que está todo bien, te garantiza que formalmente, el código es correcto, al menos desde el punto de vista de data races, asignaciones erróneas de valores, y mil cosas más.

3) Mutabilidad y aliasing: cuando "&mut" es una promesa de exclusividad

Si vienes de lenguajes donde puedes tener múltiples referencias y mutar casi en cualquier sitio, Rust te parecerá extraño y hasta hostil. Pero la regla clave es elegante cuando la comprendes:

• Puedes tener muchas referencias inmutables ("&T") a un mismo valor.
• Solo puede existir una referencia mutable a un valor ("&mut T").

Para los que conocen C o C++, les sonará "&", pero en Rust no existe el concepto de "puntero" (pointer), es tan solo indicar una referencia a un valor y el derecho de leerlo o cambiarlo.

Esto parece un obstáculo hasta que lo miras como lo que realmente es: un principio de diseño para eliminar data races y estados intermedios ilegales que pueden provocar errores catastróficos al ejecutar la aplicación.

Lo improtante es que Rust te obliga a declarar cuándo algo puede cambiar, y la consecuencia natural de esto es que no solo se ayuda al compilador, sino también al lector del código a comprenderlo y, también, al diseño de la aplicación.

Llevaba preparando este artículo desde hace varios días, pero lo publico hoy dado que esta fecha (5 de diciembre de 2024), será recordada por muchos y apuesto a que señalará en el futuro como un gran hito.

¿Por qué razón? Porque hoy el valor de un bitcoin ha superado por primera vez la línea simbólica de los 100.000 dólares, nada más y nada menos.

Bitcoin es mucho más que su valor en monedas basura (dólares, euros, etc., aquellas cuya capacidad de almacenar riqueza se va deteriorando con el tiempo).

Al superar la barrera de los $100k, se abre un escenario nuevo, y, lógicamente no es por casualidad, hay muchas razones detrás para que alcance esta valoración: próximo gobierno de Trump pro-bitcoin, un interés creciente de grandes y no tan grandes empresas por mantener parte de su tesorería en bitcoins, un mayor conocimiento de qué es Bitcoin (diferenciándolo de lo crypto), inversores comprando los ETFs de los grandes fondos como si no hubiese un mañana, países legislando favorablemente para crear un ecosistema innovador alrededor y un larguísimo etcétera, mientras…, se reduce la oferta de bitcoins disponibles y cada vez hay más proyectos innovadores en el ecosistema.

Pero no quiero hablar aquí del momento actual, sino de lo que yo, como ingeniero informático desde hace más de veinticinco años, he aprendido estudiando esta tecnología, y que no es poca cosa, desde que comence a interesarme desde el 2019.

Al final, te propongo una lista de libros para que entiendas mejor de qué va todo esto y de cómo puede reformular el sistema financiero en el futuro, si es que no lo está haciendo ya.

Algunos hechos sobre Bitcoin a día de hoy:

• Superada la barrera simbólica y psicológica de los $100k.
• En apenas un año, ha llegado la inversión institucional, como los ETFs, aunque sobre esto hay muchas críticas y polémicas porque aleja a Bitcoin de su propósito fundamental.
• Propuestas por parte de gobiernos como el próximo de Trump de crear una “reserva estratégica”.
• Industria alrededor de Bitcoin en auge.
• Su comportamiento en valor y tendencia es similar al de anteriores ciclos post-halving, nada más y nada menos.

Estos son hechos recientes de este mismo año que cualquiera que haya seguido esta tecnología sabe o puede comprobar fácilmente.

Lo que quiero decir con lo anterior es que a estas alturas, no hay ninguna duda de que Bitcoin (la tecnología que lo implementa) ha venido para quedarse y no hay vuelta atrás.

Cuando comienzas a aprender sobre Bitcoin, la primera cuestión dogmática que te replanteas y cuestionas es ¿qué es el dinero en realidad?. Y a continuación, te das cuenta de lo poco que sabes sobre algo para lo que te levantas para ir a trabajar, que usas a diario, que te genera puede que grandes desvelos o alegrías, algo que además esperas almacenar de algún modo para el futuro, el futuro de tus niños, comprarte una casa, tu jubilación, quién sabe, esperando que eso que guardas, mantenga su valor.

El buen dinero (sound money), cumple estas tres reglas:

• Actúa como unidad de cuenta: es útil para valorar y comparar lo que adquieres o vendes, esto es, permite expresar su precio.
• Sirve para intercambiar productos y servicios, y es aceptado de forma generalizada.
• Actúa como reserva de valor: se espera que no pierda poder adquisitivo con el tiempo y puedas acumular en él tu riqueza (aquello por lo que has pasado tanto tiempo trabajando).

Si entrar en detalles, el dinero fiduciario (emitido por los bancos centrales y no respaldado por nada, como el euro y el dólar), cumple, qué duda cabe, con el primer y segundo punto (prácticamente por imposición legal).

Pero no el tercero y si no, prueba a ahorrar 100€ al mes y dentro de veinte años me cuentas lo que puedas comprar con ese dinero ahorrado y devaluado año tras año.

Una imagen vale más que mil palabras:

¿Y por qué ocurre esto? Muy simplificadamente y a riesgo de no ser preciso, porque los estados (sus gobiernos) tienen capacidad de endeudarse (pedirle dinero prestado impreso de la nada a los bancos centrales), para financiar sus políticas, gastando más de lo que ingresan, muchísimo más, de hecho. ¿Y qué pasa cuando se inunda el mercado de algo masivamente? Pues que pierde valor: inflación y aumento de impuestos para equilibrar el exceso de gasto.

Hay quien dice que a la revolución francesa le faltó algo esencial: separar al gobierno de la emisión monetaria.

Pues de todo esto va Bitcoin.

Todavía hoy, los que siguen criticando la tecnología Bitcoin, caen en el mismo error que aquellos que por los años noventa, opinaban que Internet no iría a ningún lado, que no servía para nada más allá del ámbito académico, que nadie tendría un ordenador en sus casas y una larga lista afirmaciones que nos parecen hoy día una barbaridad: la realidad es bien distinta, y como pasa con todo lo disruptivo, al principio, solo unos pocos lo entienden, y poco a poco, el fenómeno va creciendo hasta que termina en una auténtica bola de nieve e implantándose masivamente.

Pasó con la electricidad, el ferrocarril, la aviación, con Internet… y ahora con Bitcoin, con tan solo 16 años de vida.

Así es, Bitcoin (el proyecto software), tiene 16 años de vida desde que su creador (o creadores) bajo el pseudónimo de Satoshi Nakamoto, publicó el whitepaper indicando cómo se podría crear un dinero digital que resolviera el problema del doble gasto e inhackeable basado en pruebas de consenso, resolviendo los problemas que habían impedido hasta el momento implementar algo así.

En realidad se cree que Satoshi Nakamoto publicó el whitepaper después de implementar una primera versión del protocolo y comprobar que funcionaba.

Satoshi, que a día de hoy sigue en el anonimato, unió un conjunto de tecnologías que ya existían por entonces y que llevaban años de estudio y uso, algunas, como la criptografía, muy relacionada con círculos cyberpunks.

La genialidad consistió en unirlas para crear algo nuevo, algo extraordinariamente nuevo y disruptivo.

Tan nuevo y exitoso que aún hoy es inmensamente incomprendido por la mayoría de la humadidad: los cambios de paradigmas cuestan mucho trabajo de digerir.

Lee bien lo que voy viene a continuación (mejor, léelo varias veces):

Con Internet, se democratizó la transmisión de información, algo indudable hoy día, hasta el punto de transformar economías, modelos de negocio y hasta nuestras propias vidas cuando ya no solo tenemos un ordenador en casa, sino varios: varios portátiles, varios PCs y un smart phone del que no nos podemos despegar y que ya forma parte de nuestra piel.

Bitcoin es un cambio de paradigma radical: democratiza la transmisión de valor.

Bitcoin inventa algo nuevo e inexistente hasta ahora: la propiedad digital.

Pero una auténtica propiedad, que no depende de las garantías de un tercer (banco, estado, institución) y es inembargable (nadie te lo puede quitar salvo que te torturen para que desveles tus claves de acceso a tus direcciones).

Ha pasado ya un tiempo desde que no publico nada nuevo en mi web personal y profesional (que es ésta, claro, y que, por cierto, ahora mismo estoy modernizando en otra totalmente diferente), y es que en el último año y medio, he estado muy pero que muy ocupado. Tanto ha sido así, que apenas he tenido energía para trabajar en un nuevo libro ni para dedicarle algo de tiempo a mis proyectos personales (o side hustles).

Como Engineering Manager de una multinacional suiza con oficina en la ciudad donde vivo, he vuelto a acumular experiencias maravillosas, conocer gente inteligente y encantadora, incluso conocer una industria que desconocía totalmente (la del betting y el iGaming), entrar de nuevo en la dinámica estresante de lanzar un proyecto muy importante, gestionar situaciones difíciles en ocasiones, motivar cuando el ánimo caía en los equipos y la presión era asfixiante y también tratar de aportar mi granito de arena positivo en todo aquello.

Pero tuve que bajarme de ese proyecto, me temo.

Quizá es una cuestión de edad, de los años que vamos cumpliendo, pero llega un momento en que te planteas si lo que haces cada día está alineado con tu propósito, tu propósito vital, digo. Y esto es como con las parejas: si no te imaginas con tu pareja actual en unos años, entonces hay algo que falla y que no tienes valor de reconocer.

Ya sabemos que la vida (y la riqueza verdadera) tiene que ser un equilibrio: el te tus relaciones (tu pareja, familia, vida social, etc.), tu salud (ejercicio, comida sana), tu higiene mental (esa paz interior que en el fondo es lo que todos buscamos de un modo u otro) y, cómo no, la actividad profesional a la que te dedicas, con la que te ganas la vida, vaya.

Cuando ves que ésta última se aleja cada vez más de aquello que más te interesa, o cuando estás deseando que llegue el fin de semana para leer esto y aquello (en temas que no tienen nada que ver con los de la empresa para la que trabajas), o simplemente desconectar, comienza a crearse una distancia entre lo que haces y lo que quieres, y cuando esa distancia va aumentando, sientes una presión insoportable y tu motivación diaria se va diluyendo hasta desaparecer.

Cuando eso ocurre, puede que ya no tengas ni la motivación suficiente para desempeñar tu trabajo al 110% (que es lo mínimo que nos podemos exigir).

Como digo, puede que al cumplir más años y acumular ya unos treinta de experiencia profesional (y muchas experiencias vitales), ya no te conformas con un proyecto que no te apasiona, o que no es para ti, aunque se te retribuya de manera buena o excelente. Lo que quieres es dotar de sentido al proyecto para el que pasas más de 40 horas a la semana trabajando, sentirte útil y hasta imprescindible, y tener un impacto positivo en tu sector, en tu mercado, y por qué no, en el mundo. 

Al menos estas son las cuestiones que me planteo en los últimos años, de ahí que para mí sea tan satisfactorio ver cómo mis libros se venden cada día, porque entiendo que con ellos estoy ayudando a mejorar algún aspecto profesional (y personal) de la vida de quien los compra, nada más satisfactorio que esto. No hace mucho calculé (es difícil hacerlo, de modo que es solo una estimación), que desde que en el 2014 publiqué El Libro Negro del Programador, mi primer libro, se habrán vendido unas 40000 copias de todos los que he publicado (más las lecturas piratas, claro está).

Esto es, con ese trabajo difícil y arduo que es escribir, estructurar y publicar un libro, hay miles de personas que se han beneficiado.

Este último año y medio he vuelto a experimentar situaciones y dinámicas que he descrito hasta la saciedad en mis libros, buenas, normales y también tóxicas, sin haber tenido apenas capacidad para evitarlas. Pero, sobre todo, he vuelto a comprobar que por mucho trabajo de management que hagas, no se puede dejar de tener contacto con la base de nuestra profesión: programar y programar en proyectos personales, utilizar herramientas, conocer plataformas, diseñar arquitecturas, pulir procedimientos y flujos de trabajo, etc.

En mi opinión, hay que estar siempre afilando el hacha, algo que siempre he hecho como manager, team lead, jefe de proyecto o director de departamento (llámalo como quieras), con un doble esfuerzo por mi parte, y porque reconozco que amo mi profesión, que siento adicción cuando te sube la adrenalina cuando publicas un nuevo proyecto y porque programar es a nuestra profesión lo que hacer una salsa cualquiera para el mejor chef (se entiende la metáfora culinaria, ¿no? :-) ).

De lo contrario, echarás la vista atrás en un tiempo y verás cómo las habilidades que tenías hace años y que tanto esfuerzo te costó en adquirir, las has perdido, y quién sabe, lo mismo tienes que asumirlas de nuevo para un nuevo reto profesional.

Estos últimos meses (desde el momento en que escribo esto), además de descansar después de unos años con demasiados cambios (y hasta mudanzas :-) ), leyendo mucho, muchísimo, cuidándome más que nunca, terminando la certificación de Bitcoin Talents (programa en el que me admitieron a finales del año pasado, de la Frankfurt School Blockchain Center), retomando proyectos como Mantra, construyendo algunas aplicaciones, instalando nodos de Bitcoin y preparando mi próxima publicación y, sin prisas, buscando un proyecto nacional o internacional donde pueda tener esa sensación de aportación que es para mí la base de mi satisfacción profesional.

Leyendo la biografía de Amancio Ortega, me llamó la atención que varias veces en el libro se comentaba que pasaba la mayor parte del tiempo... en la fábrica, y no encerrado en el despacho de una torre de marfil, para mí todo un ejemplo de lo que quiero decir con este artículo.

Esto es para mí afilar el hacha.

Estos últimos meses he estado introduciendo muchas mejoras en el core de Mantra, plantenado el camino para que en los componentes de un proyecto se puedan introducir módulos en formato WebAssembly y programados en Rust, sin que el ciclo de vida del componente se haga más complejo; trabajo en este camino porque precisamente Mantra está planteado para implementar aplicaciones de alto rendimiento y escalables, por la propia naturaleza del framework y el paradigma de desarrollo que sigue.

Llevo profundizando en estas tecnologías desde que comenzó el año, y aunque a lo largo de mi carrera profesional he visto ya varias promesas que afirmaban que "lo cambiarían todo" (escondiendo, seguramente, algún propósito comercial, claro está), para desaparecer en el olvido años más tarde, no puedo decir lo mismo de WebAssembly en general y Rust como lenguaje en particular.

¿Por qué? Te lo explico a continuación.

En software ocurre exactamente lo mismo que en otras actividades: es cierto que en ocasiones, una moda pasajera impone que se usen tecnologías (o ciertas librerías o frameworks, que no siempre se distingue bien entre una cosa y la otra) que, en mi opinión, no deberían tener el puesto destacado que tienen, pero en otras, la enorme utilidad de algo hace que explote su uso, porque precisamente viene a llenar un vacío en la industria o a resolver un problema importante.

Eso es precisamente lo que pienso de WebAssembly y Rust que, al igual que el resto de tecnologías, ni resuelven todos los problemas ni son un cajón de sastre para hacer de todo, tienen su espacio y sus casos de uso.

Éstos se basan principalmente en aplicaciones (cada vez con mayor demanda y auge) que necesitan de un rendimiento mucho mayor (cercano al de las máquinas nativas donde se ejecutan) y que no se puede obtener por diversos motivos con otros entornos de programación, pero añadiendo también otras características que, sinceramente, cuando he ido profundizando en ellas me he quedado sorprendido: mayor seguridad por la propia naturaleza de Rust, no hay necesidad de que exista un recolector de memoria (sí, lee esto de nuevo) y, lo más importante, portabilidad a diferentes arquitecturas hardware y sistemas operativos, nada más y nada menos.

Mientras que WebAssembly es un lenguaje de bajo nivel similar al ensamblador (tranquilo, que no hace falta volver a programar en ensamblador), y que genera un formato binario portable y extraordinariamente compacto cuando se compila (generando archivos wasm), que puede ser ejecutado los navegadores de mayor use pero también en otros entornos, Rust es un lenguaje diseñado desde su base para generar código eficiente, con un uso de la memoria seguro y en contextos de threads también seguros, y que recuerda mucho a C  y C++ aunque no es de tan bajo nivel como éstos.

Rust no es un lenguaje escribir para cualquier tipo de aplicación, sino más bien y dada su naturaleza, para programar sistemas: drivers para dispositivos embebidos, sistemas operativos, procesamiento de imágenes y de video, internetworking, virtualización e incluso para programar otros lenguajes de mayor nivel. Otra definición para Rust: es un lenguaje para la programación concurrente sin la dificultad que implica esto en lenguajes como C o C++ y con el rendimiento de éstos.

Por decirlo de alguna manera, WebAssembly empaqueta en ese código binario portable y eficiente el resultado de aplicaciones escritas en Rust (pero también en C y C++).

WebAssembly está fuertemente apoyado por grandes de la industria, como Mozilla, y en mi opinión, aunque cuenta ya con unos años de desarrollo, su uso y aplicaciones se van a extender extraordinariamente en el futuro: tratamiento de imágenes y de video, aplicaciones en tiempo real que manejan grandes volúmenes de datos, aplicaciones embebidas para dispositivos IoT, FaaS (functions as a service), gaming (puesto que éstos son aplicaciones que también requieren de un mayor rendimiento), aplicaciones multiplataforma, etc.

Por otra parte, la curva de aprendizaje del tooling para WebAssembly así como de Rust, en mi opinión es baja, sobre todo si ya has tenido una experiencia previa con entornos basados en C o C++ y has programado mucho a bajo nivel. En una etapa laboral anterior, estuve 12 años programando en C++, de modo que veo en Rust muchas características similares que me llenan de cierta extraña nostalgia :-)

En software frecuentemente se lanzan tecnologías que terminan resultando efímeras (y que seguramente nos ha costado muchas horas aprender), pero WebAssembly y Rust han llegado para quedarse, tan solo hay que ver qué empresas lo usan y lo apoyan y están involucradas en su desarrollo.

O lees o escribes, o consumes o produces, o usas tecnología de otros o la creas. Ya sabes que lo más complicado está en lo segundo (escribir, producir y crear) y no comprendo por qué pasamos los desarrolladores de software más tiempo en lo primero que en esto último.

Es especialmente emocionante cuando sacas a la luz algo en lo que has estado trabajando muchísimo tiempo (años).

Me pasa con todos y cada uno de mis libros, cuando por fin ves el último trabajo en todas las tiendas de Amazon y el resto de plataformas (como esta pequeña aportación que he lanzado recientemente sobre Bitcoin), cuando publico un nuevo proyecto o cuando por fin paso a producción el realizado para algún cliente.

Desde hace unos meses, ya puedo decir que existe una release de Mantra suficientemente madura como para poder ser usada en proyectos en producción.

Para lo bueno y para lo malo, como desarrador profesional de software así como responsable de equipos y de proyectos desde hace más años de los que recuerdo, me ha tocado a menudo trabajar en proyectos más bien grandes y complejos y que, a lo largo de su ciclo de vida, han tenido que evolucionar mucho con bastante dificultad.

Del mismo modo, también me han contratado en ocasiones para evaluar la calidad de un proyecto software y recetar qué hay que mejorar para que la bola de barro (deuda técnica) no siga creciendo hasta hacer el proyecto inviable, inmanejable o inmantenible, cuando no se ha tenido que tirar todo a la basura y comenzar de nuevo, para espanto de los directivos y frustración de los desarrolladores. Esto no solo suele ocurrir por falta de profesionalidad en el código, también por déficits organizativos, entre otras cuestiones.

Te aseguro que detectar todo lo anterior no es ni fácil ni sencillo.

Esto es, conozco de primera mano por qué el software tiende a corromperse, cómo y por qué se acumula deuda técnica y cuáles son los malos hábitos de nosotros los desarrolladores que hace que un proyecto sea costoso de mantener, y también, tal y como digo, los malos hábitos organizativos que contribuyen a todo lo anterior.

Si has leído alguno de mis libros, sabrás ya que hablo de estos temas continuamente y en profundidad en ellos.

Y lo sé porque yo soy el primero que he cometido (y sufrido) todos los errores que se puedan cometer, pero siempre con el propósito de no comenter el mismo error más de una vez...

No en vano, uno de mis libros ("Legacy Code: Cómo modernizar en catorce pasos código heredado o proyectos software que han crecido demasiado rápido"), sugiere cómo mejorar en un conjunto de pasos la calidad de un proyecto software heredado y que hay que modernizar.

Mantra es un framework basado en Node.js que obliga a estructurar correctamente un proyecto, en base a una componetización radical y un desacoplamiento extremo entre ellos, permitiendo, a la vez, una alta testeabilidad y reusabilidad de todos y cada uno de los componentes que forman parte de un proyecto, entre muchas otras características.

Mantra no nace para competir con otros propuestas que existen desde hace mucho más tiempo (como Next.js, y que me encanta, por cierto), sino para dar respuesta a lo que yo considero que es una forma viable de enfocar el desarrollo de software para minimizar esa deuda técnica que tanto daño hace a la competivividad de las empresas, especialmente en proyectos de gran tamaño, que evolucionarán mucho, de alto rendimiento y escalables y que tienen que ser lo más competitivos posible.

Por decirlo de algún modo y sin que suene especialmente pretencioso: Mantra implementa un paradigma de desarrollo de software.

El desarrollo de un proyecto con Mantra sigue una serie de principios que he estructurado de la mejor manera posible en un whitepaper que puedes leer en inglés y en español.

Quizá, el whitepaper en el que se basa Mantra te sorprenda, porque, en realidad, más que identificar unos principios a seguir, se trata en verdad de un cambio de paradigma para enfocar el desarrollo de proyectos profesionales, grandes, evolucionables y escalables. 

Es mi pequeña contribución a la ingeniería del software aunque, créeme, muchos de esos principios son, sencillamente, buenas prácticas bien conocidas en nuestro sector pero que he agrupado en un conjunto coherente y que se implementa en Mantra para que los proyectos puedan crecer y evolucionar (con requisitos aún desconocidos) sin acumular deuda técnica.

Algunos de estos principios, incluyen:

• Componetización radical: un componente es la pieza fundamental de código de un proyecto y, por definición, es pequeño y reutilizable, apenas unos cientos de líneas de código.
• Un componente implementa una funcionalidad muy específica y la expone al resto del proyecto.
• Por definición, un componente está totalmente desacoplado de otro (las dependencias son blandas y no duras).
• La funcionalidad de alto nivel se implementa mediante orquestación de funcionalidad de bajo nivel.
• La persistencia de datos de un componente es transparente al mismo y no supone un vínculo fuerte.
• Un componente define modelos de datos minimalistas (apenas una, dos o tres entidades). Sí, leelo bien, nada de bases de datos grandes y acopladas, imposibles de mantener, migrar y evolucionar. Es más, Mantra permite aplicaciones multirepositorios (que usan varias fuentes de datos de forma transparente).
• Un proyecto está basado en un conjunto de aplicaciones que se comunican entre ellas.
• Las migraciones de un proyecto son frecuentes e incrementales.
• etc.

Las consecuencias prácticas de aplicar los principios anteriores son increíbles: proyectos evolucionables, sencillos y menos costosos de mantener, mayor reusabilidad, mejor testing y escalabilidad.

Con Mantra he construido ya varios proyectos para diversos clientes, incluidos Hub de Libros así como el mismo site del proyecto, claro está.

Y funciona: el esfuerzo para la evolución de cada proyecto (implementación de nuevos requisitos) es pequeño si se han seguido los conceptos anteriores, la mantenibilidad es extraordinaria y la satisfacción de desarrollador alta porque pasamos la mayor parte del tiempo... implementando funcionalidad o modificando la existente.

Aunque ya se puede usar libremente, Mantra es un proyecto más ambicioso en el que iremos publicando componentes descargables, seguros y probados, con funcionalidad habitual así como proyectos completos que puedan ser puntos de partida para proyectos finales específicos.

Sinceramente, estoy entusiasmado con Mantra, creo que es el proyecto más complejo que he realizado nunca y confío en poder dedicar gran parte de mi tiempo profesional a él.

¿Cómo aprender a realizar aplicaciones con Mantra?

La curva de aprendizaje es extraordinariamente corta.

Se ha hecho un gran esfuerzo en crear una documentación exhaustiva y clara (de momento solo en inglés), y, además, continuamente se están publicando proyectos de demostración mostrando cómo realizar tareas concretas, además de la constante publicación de how-tos indicando en breves artículos cómo hacer tareas concretas.

Mantra, como cualquier proyecto software, es un proyecto en evolución continua, en el que constantemente se están introduciendo mejoras de rendimiento y en la funcionalidad existente, pero con el compromiso de que el usuario y la empresa que usa Mantra, no tenga que pagar un coste por migraciones a las nuevas releases que vayamos lanzando, porque, insisto, uno de los objetivos que tiene Mantra es reducir el coste del desarrollo de aplicaciones profesionales para que sean más competitivas, y esto se consigue desde diversos ángulos.

Como framework, fue surgiendo poco a poco de forma natural al trabajar todos estos años atrás en proyectos basados en Node.js y sin convencerme del todo otros frameworks que ya existen, sencillamente por no poder implementar fácilmente y de forma natural los principios anteriores.

Como CTO de Mantra, confío en que esta aportación sea de una gran utilidad para nuestro sector, siempre en evolución y siempre con ese espíritu de kaizen de mejora continua.

Nada es más excitante cuando uno trabaja en algo durante mucho tiempo y por fin está listo para que salga a la luz.

Llevo varios años entusiasmado por todo lo relacionado con Bitcoin en particular y el mundo cripto en general, y lo que más me entusiasma de todo esto son las profundas implicaciones y el gran impacto que van a tener (tienen ya) en la sociedad y en nuestra relación con "el dinero", y así lo creo.

Para mí, estamos en un momento de cambio, aunque no se hable de ello continuamente, tan solo noticias a veces entusiastas y en otras ocasiones alarmantes, de un cambio tan profundo como fue la aparición al comienzo de Internet y su expansión exponencial años más tarde. Ahora toca algo igual o más importante: modernizar el dinero, ni más ni menos, porque Bitcoin es el "Internet del dinero".

Mi primer contacto con Bitcoin fue en el 2013, tal y como comento en la introducción de este nuevo libro, pero perdí el interés hasta años más tarde, en el 2018; a medida que leía y leía y profundizaba en Bitcoin y el mundo cripto, fui poco a poco comprendiendo las implicaciones y la importancia de todo esto.

Pensé entonces que llegaba tarde a la fiesta, para descubrir que, en realidad, aún estamos en una fase de adopción muy temprana.

Me he leído todo lo que ha caído en mis manos sobre Bitcoin y temas relacionados (libros que incluyo en la bibliografía) y raro es el día en que no lea un artículo o dedique un rato a este sector emergente. Es más, sigo en LinkedIn a numerosas empresas y profesionales que se dedican ya a esto.

También pienso que estamos ante una enorme oportunidad para los desarrolladores de software, con una demanda de profesionales que sepan de esto, solo hay que buscar las remuneraciones que se ofrecen.

Es más, comencé trabajando en un libro para enseñar a "programar servicios con Bitcoin", puesto que me he familiarizado con sus detalles técnicos y su uso, pero pronto me di cuenta de que incluso en nuestro sector, hay un gran vacío de su comprensión incluso rechazo (por falta de información, eso es lo que creo).

De modo que me propuse escribir un libro diferente de todo lo que había leía hasta entonces (demasiado académico o demasiado superificial o muy técnico), y que con él, cualquier persona sin conocimientos previos ni de Bitcoin ni siquiera con algún bagaje técnico, pudiese entender de qué va todo esto.

Esto es, este es mi primer libro para un público en general.

Tal y como digo en el libro, comprender Bitcoin requiere entender también el sistema económico actual, inflacionario por naturaleza y basado en deuda, a lo que dedico algunos capítulos. Me temo que muchos se llevarán grandes sorpresas al comprender mejor las trampas de nuestro sistema económico, con sus bondades pero también con sus defectos sistémicos.

Y es que Bitcoin nace como una alternativa a todo ello, de ahí el discurso ácido y agresivo de muchos agentes económicos, como bancos, instituciones de inversión, y hasta gobierno, etc. Claro, viene una tecnología que los deja obsoletos, inevitablemente y le quita al "poder" nada más y nada menos que la política monetaria.

Esto, ahora, puede parecer asombroso y hasta inquietante para algunos, para otros es una gran esperanza y oportunidad para la humanidad en general. No hay que irse muy lejos cuando eso del "libre intercambio de la información" que supone Internet, ponía nervioso a políticos allá por los 90 (algo que yo mismo presencié en aquella época).

Ya hay países que aceptan Bitcoin como "moneda legal", y su expansión tiene que ser inevitable. ¿Por qué? Porque sus atributos como moneda son muy superiores y no existe nada igual, del mismo modo el que correo electrónico dejó obsoleto el correo postal, por poner un ejemplo.

Jack Dorsey, el ex CEO y fundador de Twitter, dejó hace unos meses ese puesto para dedicarse totalmente a Block y fomentar Bitcoin y las finanzas descentralizadas, así que yo me pregunto que qué habrá visto como visionario en ese sector.

No sé si tienes ya una opinión sobre Bitcoin y la industria cripto que se está creando, pero te animo a leer este nuevo libro que acabo de lanzar con la ilusión de acercar esta nueva revolución a cualquiera que quiera aprender sobre ella y aprovechar todas las ventajas que tenemos ahora en esta etapa de adopción todavía temprana (aunque se estima que ya hay unos 140 millones de personas con cuentas de Bitcoin).

Buenas prácticas de diseño y de arquitectura, una buena política de testing y una metodología ágil, son necesarias pero, en ocasiones, no lo suficiente como para encontrar la mejor solución a una lógica de negocio particular, como veremos en este artículo.

Para bien o para mal, me ha tocado en los últimos años, abordar y dirigir proyectos en cierta medida complejos y escalables.

Reconozco que esta complejidad no radica exclusivamente en tener que resolver problemas ciertamente difíciles, con grandes volumenes de datos o sistemas que deben soportar grandes cargas de trabajo o usuarios, sino más bien en mantener una visión de diseño y de arquitectura suficientemente flexibles para que estas aplicaciones puedan ser mantenidas durante años, ya que, algunos de estos proyectos de los que hablo, consisten en sistemas que, por su naturaleza, una vez instalados para el cliente, se van a mantener activos durante muchísimo tiempo (incluso décadas, me atrevo a decir), debido al grado de integración y de dependencia de esos negocios con este tipo de productos.

Sin ir más lejos, uno de ellos es la Plataforma de Telegestión IRIS, que, a día de hoy, ya tiene unos ocho o nueve años de funcionamiento en diferentes instalaciones.

Como digo en ocasiones, una aplicación que va a evolucionar mucho y durar muchos años, tiene que ser construida de un modo diferente que los proyectos que se cotizan por horas, se entregan y no van a cambiar más. 

Cuando construyes aplicaciones así, te basas, lógicamente, en un conjunto de frameworks y librerías de muchos tipos (en el ejemplo que comenta, .NET, KendoUI, NInject y un larguísimo etcétera). Como cualquier otra aplicación, claro está.

No obstante, cuando implementas la funcionalidad específica del producto, en la forma de su lógica de negocio, solemos tender a implementarla ad-hoc, basada, claro está, en todos esos frameworks y librerías, como no puede ser de otra manera.

Tendemos a pensar que un framework en software consiste únicamente en eso: algo en lo que te basas para construir lo específico de un proyecto, y está bien y tiene que ser así, no hay duda de ello. Pero esa concepción de framework es demasiado limitada.

Todos los proyectos demasiado espaguetizados que he visto (e insufribles), tenían ese defecto: demasiado código explícito para resolver su lógica de negocio y ausencia absoluta de una mínima abstracción, esto es, la implementación de utilidades o reglas que permitan implementar esa lógica de negocio particular.

Programar, en cierto modo, consiste en aplicar un paradigma de trabajo que, finalmente, generará el código de una solución de una forma u otra. Por poner un ejemplo, no tiene nada que ver el diseño y la forma de resolver un problema usando orientación a objetos que si usas un lenguaje funcional. Según el lenguaje que uses, utilizarás unos artefactos u otros.

Pero no solo cambian las herramientas que usas (en la forma de sintaxis y utilidades), sino que, con ellas, tu mente aprende a abordar un problema de una forma u otra. Me explico.

Dadas unas herramientas concretas, la forma de implementar algo cambia, esto es, piensas en el modo de resolver el problema a partir de ellas. La limitación no se basa solo en lo que te ofrece un entorno de trabajo concreto (objetos, funciones, funciones lambda, ciertas APIs, etc.), sino en que adoptas un paradigma mental con el que encontrar la solución correcta.

De ahí que para mucha gente acostumbrada a usar lenguajes funcionales, cuando aprenden orientación a objetos, no usan correctamente este enfoque, porque siguen pensando desde la perspectiva de un lenguaje funcional (y suelen concebir las clases como simples cajas donde meter funciones relacionadas sin aprovechar todas las abstracciones y la riqueza de modelado que permite OOP).

Un artista que dispone de una paleta con muchos colores y varios tipos de pinceles, conseguirá plasmar en un lienzo una idea de cuadro con una técnica diferente que si tan solo tuviese a su disposición un bolígrafo bic y un folio A4 (es tan solo un ejemplo). El mismo pintor, claro está, pero la herramienta condiciona su forma de pensar para resolver el mismo cuadro de la forma más aproximada. Del mismo modo (y siguiendo con otro ejemplo algo peregrino), según la herramienta que tengas para clavar en una pared una puntilla, lo harás de un modo u otro: no es lo mismo hacerlo con un palo que con un martillo en condiciones, ¿no?, aunque, quizá, sería mucho mejor disponer de una pistola automática. 

En software, podemos pensar con la mentalidad de framework: cuando tienes que resolver una lógica de negocio ciertamente compleja, tendemos a implementarla directamente, en lugar de abordarla desde la mente y la perspectiva de un framework. Este modo de pensamiento y forma de abordar algunas soluciones software, se me ha revelado muy útil.

Por poner un ejemplo algo trivial e ilustrativo: supongamos que te piden implementar una aplicación para resolver la operación "2 + 5", y vas y programas el cálculo directo de esa operación. Después, a la aplicación hay que añadirle otra operación diferente, como por ejemplo "4*3 - 12", y vuelves a programar ad-hoc (explícitamente) el cálculo de esta expresión, y así, continuamente.

¿No es mejor implementar una librería a modo de calculadora genérica para resolver ese tipo de expresiones? Parece obvio, pero es así, con esas expresiones demasiado explícitas, como se suele implementar la funcionalidad de alto nivel de la mayoría de aplicaciones, cuando, en realidad, en muchos escenarios (y no digo en todos), hay una solución mejor.

Siguiendo con el ejemplo: dominio a resolver: operaciones matemáticas simples. Abstracción a implementar: calculadora (éste es tu framework para resolver tu lógica de negocio).

¿Qué será más inteligente y productivo? ¿Implementar el cálculo directo para cada tipo de operación o construir una sola vez la librería calculadora y utilizarla cada vez que haya que calcular una nueva expresión? Entiéndase el ejemplo.

Me temo que se suele implementar la lógica de negocio (esa funcionalidad que es exclusiva del dominio concreto de una aplicación) del modo anterior: escribiendo directamente el código para hacerla funcionar sin abstraer absolutamente nada, de modo que la evolución de esa aplicación consiste en escribir explícitamente cualquier nueva lógica de negocio que venga, aunque esté relacionada con la anterior.

De ahí, quizá, esos fragmentos de código con ficheros de cientos de líneas (o miles, sí, los he visto) con if, if, if, if... etc.

La abstracción consiste en darse cuenta de que dentro de la lógica de negocio de un dominio concreto, siempre se pueden encontrar patrones, logicas similares, reglas parecidas o funcionalidad sospechosamente parecida a otra.

En eso consiste la mentalidad de framework: tu trabajo ya no consiste en implementar directamente esa lógica de negocio o funcionalidad de alto nivel con código explícito ad-hoc (las expresiones matemáticas del ejemplo), sino en crear un framework que facilite implementar más fácilmente todas esas lógicas de negocio relacionadas (siguiendo con el ejemplo, crear la calculadora).

No siempre es posible aplicar esta forma de abordar el software, pero si se piensa de este modo, me atrevo a decir que las soluciones serán más robustas, más flexibles al cambio y permitirán una velocidad mayor de desarrollo.

Sin entrar en demasiado detalle, en la Plataforma de Telegestión IRIS que comentaba anteriormente, hay que gestionar muchos mensajes de diferente tipo pero similares provenientes de ciertos dispositivos que mantienen una estructura más o menos homogénea: en lugar de gestionarlos explícitamente según cada tipo (son unos cuarenta, si no recuerdo mal), creé una especie de framework para gestionar lo común de cada uno de ellos de modo que cuando los dispositivos evolucionan e incorporan uno nuevo, su inclusión en el sistema resulta trivial.

Del mismo modo, otro proyecto en el que he participaco, Picly (un servidor de imágenes al vuelo), existe un mecanismo de plugins extensible para incorporar todas las transformaciones imaginables sobre imágenes (el framework en este caso consiste en la implementación de ese gestor de plugins).

Son tan solo dos ejemplos que se me vienen a la cabeza, que, si no se hubiesen enfocado de ese modo, el desarrollo de esos dos productos habría sido muchísimo más costoso y más difícil de evolucionar y mantener.

Piensa con esta mentalidad de framework cuando tengas que resolver lógica de negocio, tus soluciones serán más robustas, menos costosas, más evolucionables y profesionales. 

Una de las características que me gusta de Kindle (el libro electrónico de Amazon), es que puedes señalar en los libros párrafos o frases. Es algo que hago habitualmente, de modo que cuando no tengo demasiadas ganas de leer, me he creado la costumbre de revisar las notas o citas que yo mismo he señalado de libros que me han gustado mucho. Imagino que esta funcionalidad la tendrán también los eReaders de otros fabricantes.

Del mismo modo, cuando lees cualquier libro, Kindle te indica qué secciones han sido más subrayadas por otros lectores, lo que te ayuda quizá a detectar ideas importantes que les han llamado la atención.

Movido por la curiosidad, estos días he comprado uno de mis libros en formato electrónico, El Libro Negro del Programador, por ser el que lleva publicado más tiempo y el que más comentarios tiene en las distintas plataformas en las que se vende, precisamente para averiguar, por simple curiosidad, si tenía muchas o pocas notas, o saber aquellos párrafos que hayan podido llamar la atención a un número suficiente de lectores como para que aparezca en el Kindle con la etiqueta de "148 han subrayado", por poner un ejemplo, como la captura que se ve a continuación:

Estas son las notas más señaladas por los lectores, frases, en mi opinión, bastante inspiradoras...:

"La genialidad de un buen desarrollador de software está en saber encontrar soluciones sencillas por complicado que sea un problema a resolver."

"El desarrollo de software es una actividad altamente creativa; por tanto, necesita de un ambiente que fomente esta actividad, no que la destruya o asfixie."

"Avanzar en los desarrollos con pruebas de calidad lo debemos incorporar a nuestro ADN  de desarrolladores."

"Antes de dar algo por finalizado, como por ejemplo, una nueva clase o una funcionalidad, nos debemos preguntar si hay algo que podamos hacer para mejorarlo o simplificarlo."

"A la capacidad de aprender de los errores y reponerse del fracaso, se llama resiliencia, y dado que trabajamos en una disciplina en la que los mecanismos para cometer errores están tan a mano y son tan etéreos, un buen desarrollador de software debe tener esta capacidad sí o sí: aprendemos más de los errores que de los éxitos."

"El arte de programar requiere de un entorno altamente creativo, lúcido, tranquilo, optimista y positivo."

"No se puede crear nada, ni software, ni arte, ni siquiera plantar un huerto buscando la excelencia en un ambiente desmotivador y nada creativo."

"En software, bello y elegante significa fácil y barato de evolucionar y de mantener."

"Somos eficaces en la medida que reutilizamos y escribimos código reutilizable. Esta es una de mis frases-mantra que repito continuamente."

Difícil describir la gratificación que uno siente cuando compruebas que algunas de tus ideas han calado en otros con ánimo de mejorar en su profesión.

No es lo mismo programar que desarrollar una carrera profesional como programador.

Hoy es un día muy feliz para mí.

Ya está por fin disponible en Amazon un nuevo libro: "De qué hablo cuando hablo de programar: Cómo avanzar mejor y más rápido en tu carrera como desarrollador", porque escribir un proyecto software no es tan solo escribir líneas de código..., existen muchísimos más aspectos "alrededor" de esta actividad.

Se trata de una primera recopilación de los artículos de esta misma web, seleccionados entre los más visitados y enlazados, y que he revisado, corregido, mejorado y hasta algunos que he escrito de nuevo para incluirlos en este primer volumen, enriquecidos con mis experiencias de los últimos años (buenas y no tan buenas).

Solo leyendo el índice, pienso que ojalá me hubiesen hablado de todos esos temas cuando terminé mi etapa académica.

Os dejo aquí el capítulo de introducción.

Más información, en la propia sección del libro.