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 http://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.

Esta mañana ha ocurrido una cosa muy curiosa grave entre los medios de comunicación digitales no especializados; que es lo que tiene Internet, que todo se sabe al momento y luego resulta muy difícil desdecirse. Resulta que leo, vía ALT1040, que Google ha decidido, de manera unilateral y sin previo aviso, eliminar los términos BitTorrent y uTorrent de los filtros antipiratería que contienen sus autocompletados y sus resultados de búsqueda. Esto es, y repito, ELIMINAR dichos términos de SUS FILTROS ANTIPIRATERÍA, o sea, dejar de considerarlos como algo susceptible de ser considerado una violación de los términos del copyright.

Como decían en este blog, hace tiempo, «la batalla de los defensores del copyright contra la llamada (o mal llamada, en muchos casos) piratería llevó a los principales responsables de los motores de búsqueda más importantes de la web a filtrar, parcialmente, algunos resultados de búsquedas relacionados a los entes malvados y demoníacos, como los catalogan asociaciones como la MPAA (Asociación Cinematográfica de Estados Unidos) […]. Por supuesto, términos como BitTorrent, uTorrent, Rapidshare y Megaupload, fueron las principales víctimas de los filtros».

ALT1040 basaba su entrada en otra anterior de TorrentFreak (en inglés), a la cual citaba como fuente. El caso es que me llama poderosamente la atención ver la primicia llegar al agregador de noticias Menéame (era cuestión de minutos), enlazando a un periódico valenciano en línea. Y digo que me llama la atención porque la crónica contaba la noticia totalmente al revés (imagen siguiente). Venía a decir que Google pasaba «a retirar los términos BitTorrent y uTorrent de sus servicios de autocompletado y Google Instant […]. Estos términos han pasado a formar parte de la lista de términos relacionados con la piratería, aunque en un principio la compañía del buscador no los consideró como tal».

¿Mande? ¿Qué demonios estaba ocurriendo aquí? Yo no entendía nada. Retorno a ALT1040 y a TorrentFreak y vuelto a leer la reseña por segunda, tercera, cuarta y quinta vez; por si las moscas, no vaya a ser que tenga yo el día retorcido y no me entere de las evidencias más allá del arco de mis narices. Pues nada, oiga, lo mismo que antes. Me quedo frío.

Empiezo a investigar y compruebo, con estupor, asombro y desconcierto, que la mayor parte (por no decir todos) de los medios digitales españoles están dando la noticia (los que la dan) totalmente tergiversada y deformada; totalmente al revés, vaya. El ABC, El País, La Nueva España, El Imparcial y el anterior diario Levante, entre otros muchos. Esto me lleva a pensar que el borregueo mediocre que caracteriza a la prensa española ha vuelto a surgir de su letargo una vez más.

Tiro de la manta con intención de llegar a la fuente principal, que sospecho sea una agencia de noticias, y termino en Europa Press, donde ofrecen la noticia igual de mal y cuyo texto tiene un extraño tufillo que me recuerda a los ya leídos anteriormente en los medios. Pero lo más gracioso deprimente del asunto es que desde Europa Press se cita como fuente ¡el mismo post de FusionFreak que se cita en ALT1040! Impresionante.

¿Puede ser una cuestión de falta de cultura tecnológica o es que simplemente en Europa Press no saben inglés? Tanto un asunto como el otro me parecen igual de graves, así que elijan ustedes mismos.

NOTA: Europa Press ha cambiado ya su noticia, de ahí que me apresurara yo a realizar capturas de pantalla en el momento exacto (que me lo veía venir). Los demás medios aún no han reculado. Una retirada a tiempo no siempre es una victoria, pero salva un poquillo la honra.