A lo largo de la semana son muchas las páginas, lugares, rincones y, en general, vertederos de toda índole, que visito. No en vano, y dado que tengo una existencia más bien solitaria en mi apartado rincón de Parla —el ermitaño, o mejor el anacoreta, del sur de Madrid acabarán llamándome—, paso mucho tiempo delante de una pantalla retroiluminada como mejor compañía (portátil/ordenador de trabajo, iPhone, iPad…). Estoy conectado veinticuatro horas al día, siete días a la semana, trescientos sesenta y cinco días al año. Éste trescientos sesenta y seis.
Al tajo, sin perder dedos en el camino. Sirva todo este esfuerzo como recordatorio y como muestra de por dónde tuercen mis desviaciones. ¿Alcanzaré aún nivel mayor de cutrez existencial?
Esta semana, con la cuarta parte del horario de verano consumido, lo han protagonizado, principalmente, el Sudoku y frameworks de Inyección de Dependencias para .NET. Entre cabezada va, cabezada viene, en el tren retomo la búsqueda de una métrica para calcular la dificultad de un Sudoku, tropezando con un PDF que tiene buena pinta y de título Sudoku: Bagging a Dificulty Metric & Building Up Puzzles. Lo apunto para leerlo durante el fin de semana, Batman mediante [2]. Hace meses hice un programa para resolver sudokus usando una mezcla entre Exact Cover (¿cobertura exacta?) y Backtracking. No obstante me quedé con las ganas de hacer un generador y calcular empíricamente una medida de dificultad. Al parecer es harto jodido, ya que se basa en heurísticas y no existe una medida solvente de lo que se busca. Al menos que yo sepa. Desistí. Retomando el tema acabé en el PDF mencionado. En la búsqueda también tropecé con otro PDF que apunto para lectura más tardía: A Pencil-and-Paper Algorithm for Solving Sudoku Puzzles. Lo mejor (o lo peor, según se mire) fue que, rebotando aquí y allá, guiado por mi TDA, llegué a Notices of the American Mathematical Society y pude descargarme el último ejemplar de forma íntegra en PDF. ¡Que me da un jamacuco! ¡ARGHHHH! ¿A qué tanto chute matemático? Pues porque con el horario de verano —¡tardes libres!— retomé la idea de programar un juego para smartphones y se me ocurrió, antes de seguir con Profanation versión deluxe-chachi-guay-new-age meterme con algo más sencillo para familiarizarme con Frameworks y chuminadas varias, que desde el año pasado han cambiado algo [3]. Para ser «sencillo» aún queda bastante curro, pero esta es la pinta que va presentando (de momento desarrollo con Visual Studio y XNA).
Tiene mérito insistir tanto con XNA cuando la propia Microsoft parece no apostar por él para el desarrollo de juegos para la interfaz nativa Metro de su próximo Winwows Phone 8. Básicamente proponen dos alternativas: C++ con DirectX y HTML5 con JavaScript. La tercera, Silverlight, ni mencionarla. Todo, y todos, apunta, apuntan a, que la quinta será la última versión. Y mira que la gente de MonoGame está haciendo un trabajo estupendo para propagar el framework XNA a diferentes plataformas. ¡Si hasta Sony ha elegido una variante de MonoDevelop para su entorno de desarrollo de juegos para la PSP Vita (A look around the PlayStation Mobile tools and SDK)! Sea como fuere, en breve desempolvaré [4] los libros de C++ que tengo.
Esta semana toca rehacer el código de un servicio que alguien malparió hace una década. Casi. De mediados del año 2003 está fechado ese proyecto. Malparió el código —y la arquitectura relacionada—, porque el servicio tiene su sentido de ser. Incluso la solución planteada, de forma global, no es mala, pero es que hay cada aberración pestilente en cómo está implementada que tira para atrás. Hablo de un servicio Windows, de esos de los de antes. El programador original, protegido por el anonimato que dan años de olvido —y de rotación de personal— dejó algunas joyas y una década de datos defectuosos. Aunque con incidencia y repercusión tan diminuta que apenas ha merecido atención hasta ahora. Lo curioso es que es un servicio de importancia vital para la plataforma en la que se engendró, pero como únicamente afecta en unos marcos espaciotemporales tan bien definidos, no se ha querido tocar hasta la fecha. Por aquello del «peor el remedio que la enfermedad», supongo. Obstinado como estoy en inculcar ideas tales como Integración Continua, estoy por reprogramarlo. Cada vez que me pongo con una cosa como esta acabo implementando mi propia versión de la Inyección de Dependencias en su forma manual [5]. Pero ya va siendo hora de dejar las cosas a los expertos de verdad, así que me puse a buscar Frameworks para la inyección de dependencias o Dependency Inyection Containers, como los vienen llamando, esos mismos expertos, para .NET. ¡La polla! ¡Hay un montón! Finalmente hice poda y me quedé con cuatro candidatos: Castle Windsor, Spring.NET, Unity y StructureMap. No porque el resto sean peores. Simplemente porque no tengo tiempo de evaluarlos uno a uno y tenía que decantarme por alguno en poco tiempo. Inicialmente quería elegir Sprint.NET porque también estoy metido en un proyecto Java y era una forma natural de enganchar, pero andar con archivos XML de configuración y sus namespaces y sus estructuras particulares poco documentadas, es algo que me supera y quería hacerlo directamente desde código. Al menos para ponerlo rápidamente en marcha. Por lo poco que pude ver, StructureMap parece el mejor para eso, definir en código, sin perder de vista la futurible configuración externa en XML. Seguro que me equivoco, pero la decisión ya está tomada. Los cambios tengo que hacerlos en tiempo récord, suponiendo siempre que no desista en rehacerlo y opte por parchear hasta que lo retome el siguiente programador, y aún tengo que pensar en cómo voy a solucionar algunos problemas para incorporar test unitarios (¿por qué la gente programa las cosas de forma tan acoplada?). Siempre habrá tiempo de cambiar/mejorar dentro de otra década. Para entonces supongo que la programación funcional será lo más y alguien vendrá, dirá que lo que yo hice apesta, y que hay que hacerlo todo con funciones y en «petabito», el nuevo lenguaje de moda masmejó para eso y todo lo que necesites.
Por último, y sinceramente sin venir a cuento por nada en particular, recordé haber visto hacía tiempo una especie de nube de palabras. En particular fue tras el debate que mantuvieron los dos candidatos a las últimas elecciones. Creo que fue El País —o cualquiera de tirada gratuita que pasa por mis manos casi cualquier día— donde aparecieron sendas nubes con los términos más destacables de las propuestas de cada uno de los dos
Hay que pulir un poco, pero el servicio tiene muchas opciones para la presentación. Algún día haré la nube para todo lo publicado hasta la fecha. Algún día.
[1] Que decepción más grande me he llevado al descubrir que la Academia de la Lengua acogía la palabra bárbara blog como parte de nuestro patrimonio lingüístico. Si es que todo se acaba pegando. Lo malo, claro.
[2] Me va a resultar muy complicado no ir al estreno de la tercera y última película de Nolan sobre tan oscuro personaje.
[3] ¿Pero es que no recuerdan aquel magnífico Recocido de Profanation sobre cama afrutada de XNA y con relleno de MonoGame (o XNATouch) y ese espectacular recopilatorio que supuso El blues de los momentos perdidos?
[4] Quien dice «desempolvar» podría decir también «descargar». Hasta que desaparezca completamente, todavía quedan sitios como wowebook.com donde los más viles y rastreros pueden hacerse con libros técnicos sin pagar. De todas formas yo siempre pago. Al menos por los que merecen la pena. Es una absurda cuestión de principios. Pero antes de saber si merece la pena, no está de más echarle una lectura rápida obteniéndolo de forma poco digna.
[5] Algún día me gustaría continuar el artículo Diseño reincidente (I) - IntroMix 2010, filosofía zen, las articulaciones y el bambú. En esencia de lo que iba era de contar cómo empecé a usar esas técnicas (parecidas al menos) en 2002 de forma intuitiva (mi descubrimiento de IoC/DI es bastante reciente) y cómo, desde entonces, siempre acabo haciendo las cosas muy parecidas. Está claro que si funciona, ¿por qué cambiarlo? Y a mí me funciona.
