Quien dice Photoshop, dice Aperture, dice GIMP, dice PaintShop Pro o dice Pixelmator, que no sólo del software de Adobe vive el retocador fotográfico. Y es que sí, queridos amiguitos, antes de la era digital ya existía el retocado de imágenes por parte de los fotógrafos y de los expertos en la materia; podemos decir que la alteración de imágenes fotográficas es prácticamente tan antigua como la propia fotografía. Y si no se lo creen, pues pasen, pasen y vean.

El retoque fotográfico es una técnica que permite obtener una imagen modificada a partir de otra, ya sea para lograr una mejor calidad o más realismo, o para obtener una composición totalmente diferente que distorsione la realidad. Wikipedia dixit.

Casi cualquier tipo de manipulación que hoy asociamos con la fotografía digital también fue parte del repetorio predigital: suavizado de arrugas en ellos, adelgazamiento de cinturas en ellas, adición y sustracción de personas o elementos en una escena, mejoras de luz y contrastes, montajes artísticos y piruetas onírico-paranoicas con el único fin de asombrar, asustar, ocultar, impresionar o entretener.

Pero, evidentemente, antes los medios no eran los mismos que existen ahora. Hoy día, una fotografía tiene un ciclo digital completo, sin llegar en muchos casos a pasar por un soporte físico en papel. Nuestra cámara de fotos captura una instantánea que codifica automáticamente en formato binario. De ahí pasa a un equipo informático (por cable o por «el aire») donde es retocada, recortada y/o redimensionada para, al final, terminar en la mayoría de los casos en un soporte digital, casi siempre en algún recoveco de Internet. Sin embargo, antiguamente las fotos habían de ser reveladas, lo que implicaba obligatoriamente su transmisión a un formato físico. Ahí empezaba entonces el retoque.

Los métodos de retocado eran múltiples y variados, la mayoría muy imaginativos e ingeniosos. El de más baja tecnología, por así decirlo, podría haber sido el que consistía en recortar varias fotografías con una cuchilla, obteniendo diversos elementos de cada una de ellas, para luego colarlos todos juntos de tapada en una nueva composición a modo de collage realista. Con una iluminación adecuada, se saca una última fotografía al montaje, generando así el nuevo original.

Otras técnicas incluían múltiples exposiciones de un único negativo o generar una foto desde varios negativos superpuestos. Al final era cuestión de mezclar dos o más imágenes en una sola. También existía el retoque manual por medio de pincel, o aerógrafo, y tinta negra directamente sobre el negativo, recurriendo a la técnica del puntillismo, corrigiendo imperfecciones o haciendo desaparecer elementos existentes. La exposición, en el cuarto oscuro fotográfico, de ciertas partes de la fotografía a más o menos luz y la utilización de unos elementos químicos u otros por zonas, también generaban efectos interesantes, ocultando o recalcando sombras y zonas claras, mejorando la luminosidad o el brillo, oscureciendo, etcétera.

Así las cosas, lo que resulta evidente es que aquellos fotosoperos manuales eran auténticos artistas cuyos trabajos competirían muy de cerca con los montajes actuales digitalizados. Uno de los primeros experimentadores en estas lides de los que se tiene constancia fue el fotógrafo de origen sueco Oscar Rejlander, que vivió casi toda su vida en la Inglaterra victoriana. En la década de 1850, Rejlander aprendió la técnica conocida como colodión húmedo, un proceso fotográfico, a la sazón incipiente, que produce una imagen en negativo en un soporte transparente, normalmente un cristal. Mediante la combinación de docenas de estos negativos, el artista consiguió producir su montaje más famoso, el titulado ‘The two ways of life’ (‘Los dos caminos de la vida’) en 1857 (imagen siguiente). Es una alegoría muy victoriana que representa la divergencia de los caminos alternativos que supone una vida de pecado y una vida piadosa.

Más o menos por la misma época (1858), otro fotógrafo inglés, Henry Peach Robinson, utilizaba la técnica de impresión combinada para crear su obra ‘Fading Away’ (‘Debilitarse’). Este procedimiento consiste en el uso de dos o varios negativos fotográficos en conjunción con otro de fondo para generar una sola imagen en positivo. Algo similar a la técnica de doble negativo para fotografiar paisajes, pero más complicado y trabajoso. ‘Fading Away’ (a continuación) representa una macabra escena victoriana de un lecho de muerte. Robinson tuvo que dejar de hacer fotografías y cerrar su estudio cuando contaba sólo con 34 años; la exposición prolongada a productos químicos fotográficos muy tóxicos había arruinado su salud.

Entre 1885 y 1915, el movimiento fotográfico conocido como Pictorialismo capturaba la imaginación del público. Los pictorialistas creían que la única buena fotografía era aquella que había sido manipulada, propugnando así sus pretensiones altamente artísticas. En aquella época se alteró y se retocó cada foto mediante la reducción o eliminación de enfoque nítido, la impresión en colores distintos al blanco y negro, o la adición de elementos extraños a las imágenes, como pinceladas. La fotografía de George Seeley, ‘The black bowl’ (‘El llanto negro’), de 1907, es un buen ejemplo de una imagen manipulada pictorialista. Asimismo, por su lado, la obra titulada ‘Artículos eléctricos para el hogar’ (1949), primer fotomontaje, onírico y surrealista, de la serie ‘Sueños’ de Grete Stern, diseñadora y fotógrafa alemana radicada en Argentina, se enclava ya en el movimiento modernista, que no comulgaba con las tesis de los pictorialistas, pero no por ello obviaba las manipulaciones más evidentes. (Fotos siguientes, las comentadas).

En la década de los años treinta, otro fotógrafo modernista, el famoso artista estadounidense conocido como Man Ray, estaba viviendo en una buhardilla, que era a la vez su estudio, en París. Era el fotógrafo y el artista arquetípico de la época, siempre deambulando por ahí con los escritores de la Generación Perdida como Ernest Hemingway, con artistas surrealistas como Salvador Dalí y con periodistas fotográficos como Robert Capa. Las mujeres era uno de sus temas favoritos, y, tal vez por eso, su fotografía más famosa y más copiada es ‘Le violon d ‘Ingres’ (‘El violín de Ingres’), que se puede contemplar a la derecha. Este montaje es una parodia de los retratos de damas que hacía el pintor Jean-Auguste Ingres. En él aparece el torso desnudo de la cantante de cabaré Kiki de Montparnasse, presentada como un instrumento musical, con los agujeros de sonido de violín en forma de efe minúscula en su espalda.

Hoy día, fotógrafos como Jerry Uelsmann se han convertido en la imagen analógica de los antiguos retoques en la actualidad. Uelsmann sigue siendo un trabajador de cuarto oscuro con increíbles habilidades, conocido sobre todo por sus montajes en blanco y negro, asombrosamente realistas para las antiguas técnicas que utiliza, y de carácter profundamente imaginativo y onírico.

Entre octubre de 2012 y enero de 2013, el The Metropolitan Museum of Art de Nueva York acogía una grandiosa exposición de fotografías, que fueron retocadas entre 1840 y 1990; una exposición que se dio en llamar ‘Faking It: Manipulated Photography Before Photoshop’ (algo así como ‘Falsifícalo: Fotografía manipulada antes de Photoshop’). Más de doscientas imágenes en las que las técnicas manuales reemplazaron a los ordenadores, y que todavía se pueden visualizar desde la web correspondiente, con comentarios aclaratorios en cada una de ellas.

Para finalizar, comentar un par de cosillas muy interesantes. Primero, un libro de 1946 titulado ‘Short cuts to photo retouching’ (‘Atajos para el retoque fotográfico’). Un manual, friki a más no poder, en el que vienen trucos, detalles y ejemplos para la edición fotográfica de la época. Se puede ver una reseña del libro en el blog CreativePro. Imprescindible no perdérselo.

Y segundo, y ya termino, proponer la visualización del vídeo siguiente. Un pequeño documental ruso de 1987 en el que se muestra cómo se retocaban las fotos por esa época. Atención especial al escáner de pedales, el ordenata de pedales, el monitor de pedales y el software de pedales. Más pedales que una bicicleta, vaya.

Comenzamos hoy y aquí esta nueva categoría de bichos electroinformáticos viejunos, arcaicos y anticuados, cacharros de hace mil años que contemplaban muy pocas prestaciones para lo que hoy conocemos en el mundo de la computación binaria (casi cuántica), pero que supusieron un avance muy importante en su época y, además, sentaron, establecieron y afianzaron los basamentos sobre los que se sustenta la informática actual. Por empezar con uno cualquiera, le va a tocar el placer de una inauguración por todo lo alto al flamante Mark-8. Por friki, por artesanal, por original, extravagante y excepcional.

La mítica revista estadounidense Radio-Electronics fue una publicación muy geek del siglo pasado que se mantuvo en los quioscos, bajo distintos nombres, desde el año 1929 hasta el reciente 2003. En ella se sucedieron multitud de artículos impresionantes sobre audio, vídeo, radio, televisión y, en general, sobre electrónica de la época, incluyendo en su momento, como no, joyas incunables de la incipiente tecnología informática de esa circunstancia temporal.

En lo que al mundo computacional se refiere, el magacín marcó dos hitos históricos: uno de ellos en septiembre de 1973, cuando publicó los esquemas de construcción de lo que dieron en llamar el TV Typewriter, y otro en julio de 1974, momento en el que apareció entre sus páginas el diseño de un microcomputador muy curioso conocido como Mark-8.

Con el titular en cubierta «BUILD THE MARK-8. Your Personal Minicomputer.» (en la imagen que sigue se puede ver aquella portada), Radio-Electronics presentaba el diseño de un microordenador de 8 bits, basado en la CPU 8008 de Intel, diseñado por un estudiante licenciado en el Virginia Tech de Blacksburg (Virginia), llamado Jonathan Titus, como parte de su doctorado. Con 256 bytes de RAM y sin ROM, el Mark-8 debía ser programado cada vez que se encendía el sistema mediante un procedimiento de interruptores tipo switch y atendiendo a las lucecitas rojas de un panel, ya que carecía de teclado y de monitor, así como de otro tipo de periférico más amigable. (Tampoco tenía caja, ni fuente de alimentación, ni sistema de guardado en disco o cinta).

En su pantalla LED incluía 4 filas de 8 diodos cada una. Las dos filas superiores mostraban el bus de direcciones (14 leds) y el estado del ciclo del procesador (2 leds). La tercera fila definía un conjunto de datos de memoria de 8 bits, y la cuarta el valor de 8 bits disponibles desde el puerto 0 (cero) de salida (siguiente imagen).

Y es que el Mark-8 fue concebido como un proyecto do-it-yourself, o «hágalo usted mismo», para Radio-Electronics. La revista ofrecía un pequeño manual de instrucciones de 48 páginas por 5,50 dólares americanos de la época, escrito por el propio Titus, que contenía todos los diagramas de las diversas tarjetas de circuitos integrados del aparato y las descripciones del proyecto de construcción o montaje. Por 47,50 $ adicionales, y si no querías buscarte la vida por ahí y volverte loco, se podía pedir a la revista la placa base, que fabricaba una empresa con sede en Englewood (Nueva Jersey) y con la que se llegó a un acuerdo de suministro. También, y por 250 $ más, se podía adquirir todo el conjunto de componentes restantes, microprocesador y otras placas incluidos. Con todo en casa, sólo había que ponerse a montar.

Alrededor de 7.500 electrofrikis fanáticos pidieron el folleto de montaje, y cerca de 400 de ellos el kit completo de piezas o la placa principal. Sin embargo, muy pocos aficionados tuvieron éxito con el montaje. Lo que parecía un «móntalo fácil en tu casita» resultó ser un proyecto largo y bastante complejo, lleno de enredos electrónicos, dificultades, obstáculos e impedimentos sólo franqueables por profesionales. Como proyecto era muy bonito, pero materializarlo fue todo un fiasco.

El Mark-8, pues, representó todo un fracaso de construcción, pero a los editores de Radio-Electronics les gustó tanto la experiencia que maduraron la idea de volverla a repetir más adelante con un nuevo equipo informático más fácil de ensamblar y más rentable económicamente. Sólo seis meses después presentaron el Altair 8800, un microordenador de MITS basado en la CPU Intel 8080. Los diseñadores terminaron vendiendo diez veces más kits de montaje de lo que esperaban. Pero eso ya es otra historia.

NOTA: Todas las especificaciones y componentes del Mark-8 en The Vintage Computer.

Decía, hace ya un lustro, Craig Mundie, Jefe de Desarrollo y Director de Estrategia de Microsoft, que la industria informática está de nuevo ante una encrucijada. La concurrencia de hardware, entendida como la implantación de nuevos procesadores de varios núcleos, junto con software de creciente complejidad, requerirá que la industria tecnológica (fundamentalmente) reconsidere tanto la arquitectura de los ordenadores modernos como el software resultante de los diversos paradigmas de desarrollo.

Durante las últimas décadas, los equipos informáticos han progresado cómodamente debido al crecimiento exponencial de la capacidad sin merma significante en el modelo de cálculo subyacente. El hardware siguió durante años la Ley de Moore, las velocidades de reloj se incrementaron, y el software se escribía para explotar este crecimiento incesante en el rendimiento, a menudo por delante de la curva de los equipos físicos. Esa relación simbiótica entre hardware y software continuó sin cesar hasta hace muy poco. La Ley de Moore sigue vigente, pero se ha obviado la ley no escrita que dice que las velocidades de reloj seguirán aumentando proporcionalmente… ¡siempre!

Las razones de este cambio de dirección de hardware se pueden resumir en una sencilla ecuación formulada por David Patterson, profesor de Ciencias de la Computación en la Universidad de California, en Berkeley:

Pared de energía + Pared de memoria + Pared ILP = Una pared de ladrillos para el rendimiento en serie

La disipación de calor y energía en la CPU aumenta proporcionalmente a la frecuencia de ciclos de reloj, imponiéndose un límite práctico en las velocidades de reloj. Además, hoy en día, la capacidad de disipar el calor ha alcanzado ya un límite físico. Como resultado de ello, un significativo aumento en la velocidad de reloj sin una refrigeración exagerada, y muy cara, o sin nuevos materiales y avances tecnológicos, es simplemente imposible. Esto se refiere a la parte de «Pared de energía» (Power Wall) en la ecuación

Por otro lado, las mejoras en el rendimiento de la memoria se quedan cada vez más por detrás de la productividad del procesador, haciendo que el número de ciclos necesario de la CPU para acceder a la memoria principal no pare de crecer continuamente. Esto es lo que se conoce como «Pared de memoria» (Memory Wall).

Por último, los ingenieros de hardware han mejorado el rendimiento del software secuencial haciendo que las instrucciones se ejecuten antes de que se conozcan los resultados de las instrucciones anteriores, una técnica conocida como Paralelismo a nivel de instrucción (ILP son sus siglas en inglés). Las novedades en ILP son difíciles de predecir, y su complejidad aumenta el consumo de energía. Como resultado de ello, las mejoras en ILP también se han estancado, lo que resulta en la llamada «Pared ILP» (Wall ILP).

Conclusión de la ecuación: todo esto es como dar contra un muro. Hemos llegado, pues, a un punto de inflexión. El ecosistema de software debe evolucionar para apoyar mejor y adaptarse correctamente a los sistemas de varios núcleos, y esta evolución llevará tiempo. Para beneficiarse de la rápida mejora en el rendimiento de los equipos y para mantener el paradigma de «una vez escrito, deberá ejecutarse cada vez más rápido en cada nuevo hardware» (write once, run faster on new hardware), la comunidad de desarrolladores debemos aprender a construir aplicaciones simultáneas multihilo. Una mayor y más amplia adopción de la concurrencia también habilitará al binomio Software + Servicios para modelos asíncronos y sistemas de acoplamiento flexible (loose coupling), para desarrollo en paralelo del lado del cliente y, también, para computación en la nube, o cloud computing, del lado del servidor.

Las plataformas del tipo Windows o .NET Framework, por ejemplo, ofrecen compatibilidad total para concurrencia. Este apoyo ha sido desarrollado desde hace ya más de una década, desde la introducción del soporte multiprocesador en Windows NT. Posteriormente, se han sucedido mejoras en el rendimiento de la programación de subprocesos, sincronización de las API y jerarquía de la memoria. Ello ha hecho de los sistemas Windows (y de otros entornos también) unas herramientas perfectas para la maximización de la simultaneidad.

Por lo tanto, debemos aprender cuándo utilizar estructuras de desarrollo multihilo en nuestras aplicaciones y que la importancia de la arquitectura y el diseño limpio es fundamental para la reducción de la complejidad del software, y mejora la capacidad y facilidad de mantenerlo. Hay que poner énfasis en la comprensión, no sólo de las capacidades de la plataforma, sino también de las mejores prácticas emergentes.

La gente se asusta sobremanera cuando escucha hablar de aplicaciones para Facebook, pues parece algo muy complicado de llevar a cabo, con un montón de requisitos, pegas y escollos por todos los lados. Y, la verdad, es que resulta la más auténtica insulsez del universo, siempre, claro está, que no tengamos grandes exigencias y que lo que vayamos a desarrollar sea algo más o menos sencillo. Vamos a desentrañar a continuación las bases del desarrollo para Facebook, algo muy sencillo y muy fácil de explicar. Aquel que así lo desee, podrá adentrarse más profundamente en el asunto; misión que, por cierto, no es tampoco harto complicada para un programador mínimamente experimentado.

Cuando «alojamos» una aplicación en Facebook, realmente no la estamos alojando allí, sino que estamos utilizando Facebook como un proxy entre nuestra aplicación y los usuarios de la red social. Una aplicación típica basada en Facebook funciona de la siguiente manera:

1. Los usuarios acceden a http://apps.facebook.com/nombre_de_nuestra_aplicacion.
2. Facebook hace una llamada a nuestros servidores, esto es, donde tenemos alojada la aplicación, a través de una etiqueta iFrame de HTML.
3. Los servidores reciben la llamada y formatean los datos que van a enviar acorde a la petición. Durante este tiempo, estos servidores donde alojamos la aplicación pueden devolver llamadas al API de Facebook para solicitar información adicional (amigos, información del perfil, etcétera) antes de mandar los datos al usuario.
4. Entonces, nuestras máquinas devuelven a Facebook los datos formateados a través de un iFrame, a modo de marco dentro de la red social
5. Facebook parsea (lee y comprueba) esos datos y los formatea más a fondo, añadiendo su encabezado, columna lateral y demás.
6. Por fin, Facebook envía la página completa al usuario.

Es un proceso sencillo y lógico, como se puede comprobar. Elegir un lenguaje de programación y un entorno de desarrollo va en función de nuestras pretensiones, gustos o limitaciones. Al final es desarrollo web puro y duro, sin más. Existe un Facebook Javascript SDK que es, sin lugar a dudas, la librería de código abierto (open source) más fácil de utilizar. Hay también un Facebook PHP SDK, un Facebook Python SDK y hasta kits de desarrollo oficiales para iOS y Android. También existen entornos no oficiales en Ruby, Perl, Java e, incluso, en .Net. Por supuesto, también se puede utilizar programación web a pelo en HTML, JavaScript, Java, PHP, ASP o lo que sea. Al fin y al cabo, el resultado ha de ser una web embebida.

Por lo tanto, desarrollar una aplicación para Facebook se podría resumir en cuatro simples pasos: el primero es elegir un editor para escribir el código; el segundo, decidirse por un hosting o alojamiento web que sirva nuestras páginas; tercero, un lenguaje de programación y, si lo prefieres, un entorno de desarrollo; y, el cuarto y último, instalar la aplicación de extensiones de desarrollador, lo que llaman Facebook Developer Application (algo que se hace en dos clics desde la web de Facebook).

Una vez que tengamos acceso a las herramientas de desarrollo de Facebook, es necesario contar con cierta información básica acerca de la aplicación que se va a desarrollar. Como mínimo, debemos saber cómo llamar a su instancia y dónde alojarla. De esta manera, Facebook puede ofrecer a los usuarios la dirección correcta cuando quieran visitar nuestra aplicación. A su vez, Facebook nos aportará información que se puede utilizar para construir la aplicación, como por ejemplo el ID de la aplicación y, en función del tipo, una clave secreta de su API.

Para todo ello necesitamos dirigirnos a http://www.facebook.com/developers y hacer login con nuestros datos de la red social. Si nos lo pregunta, deberemos hacer clic en el botón Permitir, para que Facebook acceda a la información de nuestra cuenta. Y ya está, ahora ya tenemos asociada la aplicación de desarrolladores a nuestra cuenta en Facebook. El siguiente paso es crear nuestra aplicación, y lo vamos a hacer en sólo cinco minutos. Sí, sí; sólo cinco minutos.

Minuto 1. Configurar la aplicación. En la web del desarrollador hacemos clic en App y luego en Crear una nueva aplicación. Escribimos el nombre de la aplicación (le llamamos teknoPrueba), el espacio de nombres (el nombre de nuestra aplicación para la URL en Facebook; que no debe existir ya, por cierto; le ponemos teknoprueba) y seleccionamos categoría y subcategoría. Escribimos el captcha y listo. En la opciones bajo el epígrafe App on Facebook escribimos la URL real del alojamiento de la aplicación, por ejemplo https://www.teknoplof.com/teknoAPP/ (importante la barra inclinada del final). Guardamos los cambios.

Minuto 2 a minuto 4. Programar la aplicación. Dos minutos son más que suficientes para generar un HTML sencillito. Pensemos que, como ya hemos aclarado, una aplicación de Facebook no es más que una web que se muestra encima de la de Facebook a través de un marco del tipo iFrame. Podemos generar una web sencillita y, también, podemos complicarnos la vida de la manera más perversamente intrincada (mostrar nombre y foto de perfil del usuario que entra, actualizar su muro, guardar datos asociados y un largo etcétera). Para aprender sobre todo ello tenemos la posibilidad de recurrir a los documentos en línea para desarrolladores, desde donde podremos obtener información muy valiosa sobre las distintas API de Facebook, los plugin, los SDK y demás.

Minuto 5. Ver y comprobar la aplicación. En nuestro ejemplo accederíamos a http://apps.facebook.com/teknoprueba y, si todo va bien, podremos ver la web diseñada totalmente embebida en Facebook.

Ya está, ya hemos creado nuestra primera aplicación para Facebook. ¿Fácil, verdad? Pues a practicar se ha dicho.

Es para ponerse a reír y no parar, oiga usted. Estoy terminando de ver la tercera temporada de ‘El barco‘, una serie que empezó muy bien y que, desde el segundo capítulo de la primera temporada, comenzó a caer en picado hasta el fondo más fondo de las profundidades abisales. El caso es que me incordia empezar a ver una serie y luego no terminarla, por muy mala que sea, que no es el caso. ‘El barco’ tiene capítulos muy entretenidos y otros muy de folletín melodramático; a veces divierte, pero, desde luego, no es la gran serie televisiva española de nuestro siglo.

Desde el punto de vista técnico y tecnológico, la serie cojea más que una mesa de Ikea. Ya comentamos en su momento lo cutre y salchichero de sus efectos digitales en 3D, algo que, si bien ha mejorado un poquito con el tiempo, todavía no alcanza la calidad visual de otras producciones con el mismo nivel de presupuesto. Pero ahora he descubierto otra joya, un dechado de perfección técnica informática al más puro estilo peliculón vespertino tragicomédico y soporífero de Antena 3. Algo que, quizás quisieron hacer pasar desapercibido o, quizás, quisieron incluir a guisa de huevo de pascua para que los frikis gafotas lo encontráramos. Esto último lo dudo bastante.

En el capítulo 9 de la tercera temporada (lo que vienen a llamar los geeks el 3x09), Gamboa, el malo malísimo de la película, encierra al curilla Palomares en la sala de máquinas y hace saltar la alarma de incendios. Esto provoca que se ponga en funcionamiento un sistema antiincendios del buque escuela que extrae el oxígeno del compartimento y libera CO₂ a través de una tubería, con el fin de sofocar las llamas por ahogamiento. El problema es que el personaje de Andrés Palomares se encuentra allí sin poder salir y a punto de perder la vida asfixiado.

Desde el puente de mando, el capitán, el primer oficial y la doctora Julia contemplan desalentados cómo van subiendo los niveles de dióxido de carbono hasta puntos muy peligrosos para el muchacho, mientras hablan con él por walkie-talkie. El protocolo contra incendios ha activado una aplicación informática en el ordenador del puesto del capitán, una preciosa pantalla de Windows (imagen siguiente), con su barra de herramientas y sus botoncitos de Nuevo, Guardar, Buscar, Ayuda, Rehacer y Deshacer (entre otros), tan imprescindibles en este tipo de software de seguridad. Además, la pantalla está dividida en varias áreas, tituladas como Status, Items, LogBoot, Process y Avanced, cada una con sus alarmas, sus controles, sus configuraciones etcétera.

Si nos centramos en las dos áreas verticales de la izquierda (LogBoot y Process) podemos observar que, lo que sea que esté haciendo toda la parafernalia antiincendios produce un listado continuo de códigos en ambos cuadros, a modo de depuración, compilación o ejecución de órdenes supercomplejas, supercomplicadas, superemocionantes de la muerte, comandos megaprofesionales no comprensibles por los seres humanos llanos y sólo alcanzables al entendimiento de los profesionales de la informática especializada en la seguridad integral de los navíos modernos más avanzados. Pues no, oiga, es código HTML muy rápido para que no se distinga en tiempo de visualización normal del capítulo. ¡Y qué código HTML! (Véase foto subsiguiente y ábranse bien los ojos).

El HTML (con su javascript, su CSS y demás) no es otro que el código interno de la web del motor de búsqueda de Google España; efectivamente, el HTML de www.google.es (en aquel momento, claro). En determinado instante del visionado, hay una oportunidad en la que se aprecia bien (en modo pausa) la pantalla del equipo y, durante cuatro o cinco fotogramas, se pueden distinguir perfectamente las etiquetas, los valores, los parámetros y hasta textos reconocibles mundialmente como el «Voy a tener suerte» del botón de la página del buscador. Increíble, pero cierto. (Imagen a continuación).

En otro punto del código aparece la palabra Origami entre etiquetas <title> de título, algo que me desconcertó hasta que recordé que la gran G homenajeó con uno de sus doodle a Akira Yoshizawa, el maestro japonés que elevó el origami a la categoría de arte. Este doodle apareció allá por marzo de 2012, y el capítulo nueve de la temporada tres de ‘El barco’ se grabaría más o menos por esas fechas; porque esta tercera de las temporadas se estrenó en octubre del mismo año 2012. (Imagen siguiente).

Estamos muy acostumbrados a ver aberraciones informáticas y tecnológicas en series y largometrajes; desde direcciones IP que no existen, sistemas operativos que hacen milagros en muchos colorines, correos electrónicos que se abren con alucinantes animaciones e interfaces gráficas imposibles que aumentan mil millones de veces la resolución de una fotografía hecha desde un satélite. Por supuesto, los chicos de ‘El barco’ no nos podían fallar en este asunto y debían meter su propia gamba técnica haciéndonos creer que aquello es más que sofisticado.

Pocos ejemplos hay en el mundo del celuloide del tipo ‘Matrix Reloaded’ y su exploit SSHv1 CRC32, con un manejo de la escena impecable. Es una pena, pero es así. Seguiremos asistiendo a despropósitos informáticos mientras los responsables no se preocupen un poquito de documentarse en condiciones.

Para terminar lo haremos con el vídeo de la escena completa, que comienza, más o menos, en el minuto 16:20.