Un saludo.

A mayor altura, más especialización

Conceptualmente, cuanto más cerca de la raíz se encuentre una pieza, más cerca se encontrará de la abstracción inicial, y la manera de enfocar su cometido será también más abstracta. Para ello se apoyará  en las piezas que ofrecen sus ramas, las cuales estarán diseñadas para resolver problemas más concretos. Podríamos decir que las piezas de una misma rama pertenecen al mismo dominio del problema. Una rama puede necesitar de otras ramas más especializadas en las que apoyarse, y estas a su vez necesitar de otras ramas. A medida que nos desplacemos por ellas nos encontraremos con piezas más simples cuyo propósito será resolver problemas más concretos. Cuando una pieza es capaz de resolver su cometido por sí misma, se convertirá en una hoja.

La verdad es que no se me ocurre un término mejor para definir  cómo funciona una aplicación diseñada bajo el paradigma de la orientación a objetos. Si nos fijamos en la cadena de montaje de una fábrica de coches veremos cómo cada sección de la misma se dedica exclusivamente a una tarea específica. Cada una de las secciones trabaja sobre el resultado producido por la sección anterior, el cual es procesado de nuevo y puesto a disposición de la siguiente sección. Todas estas piezas forman un sistema que resuelve el objeto de fabricar un coche. Si alguna de las secciones deja de funcionar o se para, el sistema entero se detiene.

Un sistema software funciona de forma parecida. Aunque las piezas  no se desgastan por el uso sufren de otro tipo  de  debilidades. Como no queremos que ninguna de nuestras piezas se pare o deje de funcionar, debemos ser exigentes con ellas. Para empezar, no queremos que sepan qué hacen ni cómo funcionan las demás. No queremos que sean inteligentes y las obligaremos a dedicarse a una única cosa, que es resolver eficientemente el problema para el que han sido diseñadas. Queremos que además sean asociales por naturaleza, que no puedan relacionarse libremente con su alrededor, y que cuando lo hagan que sea a través del mínimo número de interlocutores, y siempre que resulte imprescindible para garantizar su corrección. Sobre todo, exigiremos que sean discretas y muy claras en sus intenciones, pues no queremos atraer las miradas de otras piezas que quizás podrían malinterpretar su funcionamiento y utilizarlas para fines inadecuados, pervirtiendo así el sistema.

Si tuviéramos que diseñar una versión software de la cadena de montaje, cada eslabón sólo debería conocer a qué otro eslabón se tiene que dirigir para pedirle la materia prima con la que trabajar. De la misma forma, éstos tendrían que ofrecer un mecanismo para acceder a su producto finalizado. Nada más y nada menos. Un eslabón no  sabe qué es una fábrica de coches, ni que forma parte de una  cadena de montaje, ni siquiera tendría conciencia de sí mismo, porque esa información es irrelevante para el propósito de su existencia.

Diseñar nuestras piezas de la cadena con estas premisas nos da una serie de ventajas:

1. Si se estropea una pieza, sólo tenemos que desconectarla de las otras dos a los que está conectada y enganchar en su lugar una que funcione.

2. Si queremos modificar el funcionamiento de una pieza el cambio afectará única y exclusivamente a esa pieza.

3. Si queremos extender la cadena con una nueva característica, sólo tenemos que insertar una nueva pieza en el lugar adecuado.

En ninguno de estos tres casos se verían afectadas las otras piezas del sistema, y esto lo conseguimos aplicando uno de los principios fundamentales del diseño orientado a objetos:  Ocultación de la Información.

Una pequeña fisura en una pieza puede arruinar todo el sistema

Una de las tareas más complicadas para un programador es la del diseño de las piezas del puzzle de la aplicación. Sólo hay una pieza posible para cada posición del tablero, además ha de encajar perfectamente con las piezas de su alrededor y no puede faltar ninguna pero tampoco sobrar. Más complicado aún es descubrir qué piezas son las que tenemos que diseñar. Para identificar estas piezas es esencial conocer y entender todos los parámetros del problema que intentamos solucionar. Debido a que generalmente toda aplicación parte de una idea más o menos abstracta además tendremos que echar mano de mucho lápiz y papel, y raudales de imaginación.

En el siguiente post hablaré de las piezas principales del Hey Deejay! sobre las que se sostiene el resto de la aplicación. No debería tardar demasiado puesto que está prácticamente acabado.

Sin embargo, es fácil caer en el defecto contrario: preocuparse de la gestión de memoria cuando no nos corresponde. Un ejemplo que lo ilustra se da cuando durante la llamada a una función necesitamos usar algún otro objeto de forma temporal para producir el resultado. Uno puede llegar a pensar: “si cada vez que llamo a este método creo una nueva instancia de un objeto, ¿por qué no tener una única instancia de éste último ya creada y reusarla cuando sea necesario?” Pues esto es una mala idea en la mayoría de los casos.

Por un lado, es bastante probable que tengamos que modificar o extender el interfaz de la clase para añadirle la característica de reusable. Querríamos como mínimo tener una función Reset(), o quizás un par de funciones Initialize(…) / Deinitialize(), pero esto tiene implicaciones más profundas de lo que a simple vista parece. No se trata sólo de añadir una o dos funciones nuevas, estamos hablando de añadir estado a una clase, y con ello todo lo necesario para garantizar que el uso de dicho objeto será coherente con el estado actual en que se encuentre. En nuestro sencillo ejemplo, convertir un objeto en reusable afectará al resto de su API, ya que al menos se habrá de comprobar en cada llamada que el estado actual es inicializado, y lanzar una excepción en caso contrario. Visto con un poco más de perspectiva, en realidad lo que haremos será modificar profunda e innecesariamente una pequeña clase para adecuarla a un caso de uso muy concreto, el cual además, como veremos a continuación, está basado en una suposición errónea.

Resulta que el GC de Java y .NET son generacionales, es decir, clasifican los objetos según su tiempo de vida. Un objeto recién creado pasa a formar parte de la primera generación o generación 0, mientras que objetos que al cabo de cierto tiempo siguen estando referenciados en alguna parte del código son ascendidos a una generación superior. El porqué de clasificarlos de esta manera está basado en en el comportamiento de la mayoría de las aplicaciones. Se ha observado que la gran mayoría de los objetos que se crean en un momento dado tienden a tener un tiempo de vida muy corto, y que cuanto más viejo es un objeto, más probable es que se haga más viejo aún. Sin entrar mucho en detalles (hay mucho escrito sobre este tema), diré que esta manera de trabajar del GC le permite despachar los objetos que mueren jóvenes de una manera ultrarrápida y eficiente.

En conclusión, no merece la pena en absoluto cachear instancias de pequeños objetos cuyo tiempo de vida va a ser efímero. Ya lo hace el GC y probablemte más rápido y mejor. La única excepción, cuando el sentido común lo aconseje,  no querremos hacer constantemente news de algo que tarde mucho en construirse o se apropie de 1Gb de memoria.

Un par de años más tarde tuve la oportunidad de trabajar con C# en un proyecto. Inicialmente sólo éramos dos programadores que sumábamos más de 25 años de experiencia en C++ y cero en C#. Aunque a mí no me apetecía cambiar, el tipo de proyecto, su corto tiempo de desarrollo y los pocos recursos disponibles aconsejaban su uso. En dos meses debíamos tener listo un prototipo.

Al principio lo hacíamos todo en C++ disfrazado de C# (no sabíamos hacer otra cosa al fin y al cabo), pero poco a poco nos fuimos enganchando y entendiendo el verdadero potencial de la herramienta. Era un lenguaje formal, elegante, muy estricto en cuanto a las formas, de modo que era prácticamente imposible retorcerlo para usarlo de una manera digamos creativa. Un lenguaje diseñado, entre otras cosas, para cubrir las necesidades reales de un programador y hacerle la vida más sencilla.

Si hay algo que multiplica por 100 el valor de cualquier lenguaje .NET es el Framework Class Library (FCL), una vastísima colección de clases destinada a ser la base sobre la que construir componentes, servicios, aplicaciones y en definitiva cualquier solución software. Se acabó el tener que recurrir a la búsqueda de librerías de terceros, a veces caras, difíciles de mantener, de dudosa calidad, indocumentadas o en el peor de los casos incompatibles entre sí. Con la librería de clases tenemos prácticamente todo lo que nos podamos imaginar a la distancia de unos pocos clicks, con el añadido de disponer de un API consistente tanto en funcionalidad como en estilo (el 90% de las veces).

Otra de las cosas que se hace notar es que es un lenguaje vivo en constante evolución. En cada nueva release podemos encontrar características de lo más variadas que lo van situando poco a poco en la categoría de lenguaje ‘todoterreno’. La única pega, por el momento, es que está confinado a la plataforma Windows, aunque paralelamente se está desarrollando Mono, un proyecto Open Source impulsado por Novell con Miguel de Icaza a la cabeza, con el objetivo de hacer posible el desarrollo de aplicaciones .NET en Linux, BSD, UNIX, Mac OS X, Solaris y el mismo Windows.

En definitiva, cada día que pasaba descubríamos un par de cosas nuevas que nos dejaban asombrados. Reconozco que de cuando en cuando nuestro pasado nos cegaba: “¡Maldita sea, se les ha olvidado meter ‘x’ en C#!”. No, no se les había olvidado, simplemente se hacía de otra manera, más elegante, mejor. Una cosa importante que hay que tener en cuenta para evitar frustraciones futuras es que C# no es una forma de C++, ni siquiera es una evolución del mismo. Son dos lenguajes diferentes de la misma familia que comparten una sintaxis muy parecida. Por parecerse a algo se parece a Java, lenguaje del cual ha heredado las cosas buenas y desechado las malas.

Después de un par de meses trabajando en C# tomé la decisión de reescribir el HD con esta nueva y perfecta herramienta. Tenía un montón de código pero se limitaba a un framework sobre el que basar el core de la aplicación. Para mi sorpresa, el FCL tenía todo lo que durante meses había estado escribiendo: listas enlazadas, pilas, diccionarios, gestión de memoria, gestión de ficheros etc, y solo me llevó una semana tener el nuevo motor funcionando. Básicamente más que reescribir código fue tirar el antiguo y reemplazarlo con algo que ya estaba hecho y probado, con mucha pena en el alma eso sí.

El único apartado en el que tenía dudas era en la parte de DSP. Se me ocurrió escribirlo primero en C# para tener algo funcional que después podría pasar a C ó C++ . La primera implementación era terriblemente lenta, pero entonces descubrí el modo unsafe, dentro del cual es posible escribir código libre de comprobaciones extras por parte del compilador, haciéndolo muy eficiente y peligroso a la vez. Básicamente tienes acceso directo a la memoria a través de punteros estilo C/C++, por lo que si no se manejan con cuidado pueden causar los mismos estropicios de antaño, como sobrescribir variables, provocar desbordamientos de pila, pisar zonas de memoria etc. Si esto ocurre y tienes mucha suerte tu desliz provocará un crash inmediato, en caso contrario prepárate para un dolor de cabeza seguro.

Por el momento no he tenido la necesidad de escribir nada en C++. Haciendo un poco de profiling  en un ordenador de gama media he llegado a mezclar simultáneamente cerca de 150 pistas de audio 16 bits estéreo a 44.100 hz,  todas con envolventes de pitch y volumen, lo cual es mucho más de lo necesario en cualquier aplicación práctica.

En definitiva, y hasta que no se me demuestre lo contrario, he desterrado el C++ de mis herramientas del trabajo, algo que a algunos les puede parecer un sacrilegio. Quizás algún día necesite hacer alguna rutina que precise de millones de cálculos y deba ser llamada millones de veces por segundo. Bueno, pues ese día usaré C ó C++, al igual que antaño se usaba el ensamblador para estos casos.

Empezar algo desde cero puede ser desconcertante. A menudo la idea que tienes en la cabeza es amorfa e incompleta y es posible que ni siquiera seas consciente de ello. No sabes cómo ni por dónde empezar y ahora te has creado una nueva necesidad que tu cerebro percibe como un problema que tiene que resolver, y tienes muchas tentaciones de ponerte a escribir código cuanto antes para estar más cerca de la solución y poder aliviar esa incómoda carga. No se podría empezar de una manera peor.

La primera herramienta que uno debe instalar es el lápiz y papel. Baja a la tienda y compra lápices, bolígrafos y papel, mucho papel. Es preferible usar blocks en lugar de hojas sueltas o acabarás perdiendo alguna. Si eres de esa clase de programador que expresa ideas y conceptos con cajitas y otras formas geométricas, es muy recomendable usar papel cuadriculado. No se trata de escribir un documento formal sino de de dejar constancia de todo lo que pasa por la cabeza. Garabatos, dibujos, lluvias de flechas, cualquier cosa que ayude a separar el barro del oro. Pierde todo el tiempo que sea necesario en esta tarea. Be un carpintero my friend.

1. Un día te viene a la cabeza lo que te crees que es una idea buenísima que va a revolucionar el mercado. Pasas días o semanas entusiasmado dándole vueltas. Piensas también en los países a los que vas a viajar y en la vida de lujos que te espera debido a tu éxito.

2. Te pones a ello. Para reafirmarte en tu decisión haces tonterías para autoengañarte, como instalar una versión mejor del Visual Studio (tu súper idea se merece algo mejor), instalar otras herramientas de developer que sabes que nunca vas a usar (pero son profesionales), reformatear el disco duro (para que todo vaya más fino), reinstalar una versión superior del SO, o incluso comprarte otro ordenador (el que tienes es demasiado pequeño para la magnitud de lo que quieres hacer).

3. Este es el punto clave, a partir de aquí sólo puede pasar una cosa buena y muchas malas:

-  Se te ocurre otra idea muchísimo más buenísima que la anterior, abandonas tu mediocre idea actual y te encuentras de nuevo en el paso 1.

-  Te agobias tanto que decides procrastinar un poco (ya si eso el lunes…). Varios meses más tarde no recuerdas nada de esto y vuelves al paso 1 con una nueva idea, tan feliz.

- Lo que quieres hacer existe hace años, va por la versión 7.1 y hace cosas que a ti nunca se te hubieran ocurrido.

- Al cabo de un tiempo te das cuenta de que tu idea en realidad apesta y te preguntas si deberías dedicarte a otra cosa.

En mi caso, la causa número uno de abandono ha sido el aburrimiento. Aburrimiento por no haber sido capaz de llevar a la pequeña pantalla mis brillantes ideas en una cantidad de tiempo razonable y no haber sabido utilizar las herramientas precisas en el momento adecuado.

Aquella tarde me propuse en serio hacer algo, una vez más, y mientras escuchaba el Max Mix 3 se me ocurrió la idea. ¿Por qué no hacer un editor de audio especializado en este estilo de discos? En lugar del típico editor multipistas genérico capaz de hacer millones de cosas… ¿por qué no hacer uno especializado en la creación de mixes, remixes, megamixes y cualquier otro tipo de montaje musical? Siendo un friki de esta manera de marear la música lo peor que me podría pasar es que me divirtiera haciéndolo.

Pensaba que no iba a ser tarea fácil ya que mis conocimientos sobre audio y DSP no eran precisamente brillantes (y siguen sin serlo realmente), aunque pronto me di cuenta de que este aspecto no iba a representar ni un 10% del total. El verdadero reto era diseñar un motor de audio lo suficientemente potente como para producir resultados de calidad profesional y lo suficientemente flexible como para permitir la inclusión de nuevas features con el mínimo esfuerzo. Aún quedan cosas importantes por definir pero las contaré más adelante cuando diseccione la arquitectura de la aplicación.

Ya han pasado tres años desde ese día y hasta la fecha no he pensado ni un solo momento en abandonar, y estoy tan sorprendido de no haberlo hecho aún que he empezado este blog con la intención de hablar de vez en cuando de mi pequeño.