Entradas de octubre de 2013

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.