El 21 de julio de 1967 Douglas Engelbart solicitaba una patente bajo el nombre X-Y position indicator for a display system, patente que le fue concedida el 17 de enero de 1970:
Un control para indicar la posición X-Y para ser movido por la mano sobre cualquier superficie para mover un cursor en la imagen mostrada en un tubo de rayos catódicos, con el controlador generando señales que indican su posición que causan que el cursor sea mostrado en el tubo en la posición correspondiente. El mecanismo de control del indicador contiene ruedas de posición X e Y montadas perpendicularmente una a la otra, que rotan de acuerdo con los movimientos X e Y del mecanismo, y que operan reostatos que envían señales a través de un cable a un ordenador que controla lo que se muestra en el TRC.
Ese X-Y position indicator for a display system no es ni más ni menos que lo que hoy conocemos como ratón (de ordenador), un periférico sin el que muchos no seríamos capaces ya de manejar un ordenador.
Prototipo de ratón construido por Bill English según los esquemas de Douglas Engelbart
Engelbart y su equipo del Augmentation Research Center del Instituto de Investigaciones de Stanford protagonizaron lo que hoy se conoce como la madre de todas las demos el 9 de diciembre de 1968, asombrando a propios y extraños con lo que se podía hacer con el oNLine System o NLS. El NLS utilizaba un ratón, texto interactivo, videoconferencia, correo electrónico e hipertexto, sembrando sin duda muchas ideas que influirían poderosamente en el desarrollo de la industria informatica.
Pero estas ideas tardarían tiempo en dar su fruto. Así que para cuando quedó claro que el camino para la inmensa mayoría de los usuarios eran los interfaces con ventanas, iconos, ratón y puntero, básicamente con el Macintosh de Apple y con Microsoft Windows la patente de Engelbart ya había caducado. Y además se habían desarrollado nuevos mecanismos de funcionamiento para estos dispositivos que no infringían la patente de Engelbart, con lo que nunca vio un duro por su invento.
Se puede descargar la patente, que tiene el número US 3.541.541, en formato PDF [3 MB].
(Vía Andreu Veà).
Relacionado,
Utilizando lo que vendrían a ser palos y piedras digitales en este vídeo de Udemy (una sitio tipo «academia por Internet, con vídeos») Christian nos enseña cómo escribir todo el código de un juego tipo Serpiente (Snake) en tiempo récord. Y le bastan 270 segundos.
Las herramientas son el editor de textos básico (Sublime Text, pero vale cualquiera, vamos), JavaScript y un navegador web moderno. El trabajo se hace a machete, sin librerías de ayuda, motores gráficos ni Flash ni nada de eso. Como en los viejos tiempos del medievo de la programación.
Se ve perfectamente además cómo no está «copiando» sino escribiendo un poco sobre la marcha, dado que va comentando, editando y corrigiendo errores (el editor valida las erratas más típicas). Probablemente habría practicado antes para no dejarse nada importante, pero se lo damos por válido porque como demo de programación rápida es genial.
Esta conclusión no científica y más anecdótica que otra cosa podría poner fin el eterno debate entre si se deben indentar (sangrar) los bloques de código en programación usando espacios (¡y cuántos!) o usando tabuladores: los programadores que usan espacios para indentar no sólo son mejores, también ganan más,
Stack Overflow encuestó a casi 26.000 programadores. El 40,7 por ciento de los encuestado indentaba el código usando tabuladores, mientras que el 41,8 por ciento dijo usar espacios. Aquellos que usan espacios ganar de promedio 59.140 dólares al año, mientras que quienes usan tabuladores ganan 43.750 dólares al año. Según Stack Overflow es un dato concluyente y no está claro el porqué, pero no parece tener relación con el país de origen.
Dado que no se encuentra la relación entre usar espacios y ganar más dinero (¿mejores programadores?) el dato se queda en la mera curiosidad. Pero por si acaso y visto lo visto parece mejor usar espacios.
En Quartz, Computer printers have been quietly embedding tracking codes in documents for decades,
En 2004, cuando las impresoras láser color todavía eran una novedad, la revista PCWorld publicó un artículo titulado Government Uses Color Laser Printer Technology to Track Documents. Aquella fue una de las primeras referencias a una práctica silenciosa que se ha mantenido durante 20 años. Reveló que las impresoras en color imprimían en los documentos una codificación que contenía el número de serie de la impresora y la fecha y hora en la que se había impreso el documento. Los códigos estaban formados por puntos de menos de un milímetro de diámetro y en tono amarillo que, al imprimirse sobre papel blanco, no resultaban visibles a simple vista.
La esteganografía de impresora empezó a utilizarse como medida de seguridad ante la preocupación que esa tecnología causó entonces en los gobiernos habida cuenta de las posibilidades que ofrecía la impresión láser en color, por ejemplo, para imprimir papel moneda o reproducir documentos oficiales.
Tanto fue así que algunos gobiernos —según el artículo de Qartz que recoge el testimonio de Peter Crean, ex directivo de Xerox— incluso rechazaron la posibilidad de importar esas impresora si no incorporaban algún tipo de medida que les permitiese en un momento dado averiguar quién había impreso el qué y cuándo.
El asunto no es nuevo y tras el artículo de PCWorld la EFF descodificó esos códigos en 2005, como ya recogimos en Microsiervos en su día. Desde entonces la EFF ofrece un programa online que interpreta los códigos detectados en documentos y devuelve su significado (básicamente, número de serie y fecha y hora de la impresión) y un listado (actualizado a 2015) de impresoras láser color para informar de qué fabricantes usan o usaban entonces el código de puntos amarillos y cuáles no.
El tema resurge ahora a raíz de los puntos amarillos detectados en un informe de la NSA (National Security Agency) filtrado recientemente al medio The Intercept.