devLecturas (IV)

Me ha interesado bastante este artículo sobre una «craft crisis» en el mundo del diseño, pero no por el mundo del diseño. Ni el inicio del artículo: personalmente, saltaría directamente hasta How we got here. El artículo va de cómo, desde el mundo del diseño, si bien no hace falta saber escribir código, perder el contacto íntimo con la parte técnica representa un problema, y sí es necesario tener una «alfabetización estratégica» (y ojo, que el artículo deja el listón de esa alfabetización considerablemente alto)… A media lectura me ha parecido que, de hecho, no hablaba del diseño (o al menos no estrictamente de las personas que etiquetamos como diseñadores, gráficos / de interacción / …), sino de cualquier campo que dependa de otro para implementar lo que sea: si delegas absolutamente el conocimiento, flaco favor el que te haces, y traspasas buena parte del poder a diseño / desarrollo / el departamento que sea que hay entre tú y el producto / servicio a entregar.

Por lo que respecta a novedades-ya-no-tan-novedosas de CSS, llego a 12 CSS features you can use today with no build step (es de septiembre :-S), entre las cuales el anidado en CSS sin pre ni postprocesadores, :has(), subgrid, espacios de color OKLCH (todas baseline widely available desde hace más de un año), container queries (aún más viejas: baseline widely available desde hace dos), cascade layers (tres años ya) o :is() y :where() (cuatro). No quiero mirar cuánto no se usan, porque me deprimo (aunque igual el «mal de muchos» me consolaría un poco).

Por su parte, la consultoría de accesibilidad Tetralogical publica su Accessible components library, con su documentación y, sobre todo, los requisitos de accesibilidad, los escenarios de prueba y los tests automatizados. Incluyen acordeón, migas de pan («breadcrumbs«), cuadro de diálogo, «disclosure«, paginación, pestañas y entrada de texto, documentando los correspondientes criterios de éxito de las WCAG 2.2.

Otro de accesibilidad. Me entero por este hilo (de hace como un mes) de Bluesky de Eric Bailey de la última edición (la undécima, parece ser) de la «survey» sobre el uso de lectores de pantalla de WebAIM. Documento de interés muy alto, y no dejéis de leer tampoco el hilo de Bluesky, que la interpretación de Bailey es de lectura casi obligatoria para los que (como yo) no sabemos tanto como querríamos.

Y cerramos con accesibilidad… e IA. En mayo (sí, estas entradas deberían llamarse «devLecturas a punto de caducar)) en el blog de GitHub publicaban una historia sobre el desarrollo de un agente (de IA) de accesibilidad de propósito general. Con la precaución necesaria al leer una historia sobre agentes IA de una compañía que quiere vender agentes IA, resulta interesante. El objetivo era que el robot fuera capaz de (i) responder a las preguntas de los desarrolladores, y (ii) detectar y corregir problemas de accesibilidad simples y objetivos (los adjetivos son importantes). Para mayo, el agente había revisado tres mil quinientas pull requests y resuelto (según las métricas de GitHub, claro) un 68% de problemas. El texto enlaza a una evaluación de la accesibilidad de lo que producen los modelos grandes de lenguaje que, para sorpresa de nadie, no es para tirar cohetes (o sí, dependiendo de hacia dónde se apunten dichos cohetes, claro), fruto de este proyecto (que parece que lleva unos meses sin tocarse). A pesar de ser GitHub, el autor, Eric Bailey (le acabáis de «ver» en el párrafo anterior), tiene un recorrido importante en esto de la accesibilidad, y el planteamiento y conclusiones hacen que valga la pena leer sobre los aspectos que se pueden automatizar en cuestiones de accesibilidad.

Spam or not

Captura de pantalla de la pantalla de moderación de comentarios de WordPress comienza con los metadatos, que se han ocultado después, Buena lista, sobre todo en el apartado de reproductores de vídeo. Para la tele echo en falta una opción ligera: un reproductor que reproduce la lista propia del usuario, organizada por categorías, y que funciona bien en Android TV, TV Box y Fire TV. Ese tipo de reproductor sencillo, sin complicaciones, es ideal para ver contenido en pantalla grande. en respuesta a la entrada ¿Qué software gastas? (Android edition, v4)

Para los que no hayáis visto nunca WordPress por dentro, la captura corresponde a un comentario que ha dejado alguien en el blog y que está pendiente de moderación. Como podéis imaginar, a la izquierda de la captura hay un enlace a un reproductor de vídeo para Android.

¿Marcar como spam o aprobar? Para opinar, usad los comentarios 😇 (que ya veré si marco como spam 😬).

¡Gracias!

Computer Chronicles, octubre del 86

Seguimos repasando la historia de la informática, recuperando los episodios de hace cuarenta años de las Computer Chronicles de Stewart Cheifet.

Abrimos el mes de octubre del 86 presentando nada más y nada menos que la arquitectura RISC, la arquitectura que no se comió ni a Intel ni a Motorola en la época… pero que es la más popular hoy (siendo en la que se basan las CPUs de los móviles (y los Macs desde el M1, y algunos, aunque pocos, PCs)). De los breves, me quedo con Lotus presentando HAL, un asistente con inteligencia artificial para ayudar con el uso de su hoja de cálculo, la hegemónica 1-2-3.

En el segundo programa nos presentan el concepto de las utilidades, esas pequeñas aplicaciones que nos salvan la vida de vez en cuando con cosas que, por algún extraño motivo, no resuelve el sistema operativo (como, en los tiempos de los discos duros convencionales, los optimizadores de disco, o sobre MS-DOS, tener dos programas ejecutándose simultáneamente), y nos presentan a gente como Vernon Buerg (fallecido en 2010, por lo que veo), creador de utilidades que distribuía como shareware. Curiosa la discusión (allá por el minuto 22 del vídeo) sobre que en 1986 estábamos en la época de la informática equivalente a la era de los automóviles en la que un conductor tenía que tener bastantes habilidades mecánicas, y por lo tanto el usuario de un ordenador tenía que ser capaz de resolver múltiples problemas. Igual resulta que la automoción avanzó más rápido que la informática, porque, cuarenta años más tarde…

El tercer programa, sobre el mercado de segunda mano en informática, debió ser muy interesante en su momento, pero cuarenta años más tarde, no lo es tanto…

Y el cuarto y último programa era la primera parte de un programa doble dedicado al maravilloso (y novísimo) mundo del desktop publishing, centrándose en el mundo Mac, con una demostración del uso de Pagemaker (había salido al mercado en 1985, que es cuando compenzó a usarse realmente el término desktop publishing, y fue adquirido por Adobe en 1994, que anunció que dejaría de darle soporte en 2004) para gestionar las publicaciones propias de una gran corporación, y hablar del diseño de tipografías con Fontographer (cuya última versión salió hace algo más de diez años, pero todavía se puede comprar). También podréis ver una descomunal (de verdad, en 1986) pantalla de 17″ con una resolución de 640×864 (formato apaisado, sí) que hacía mucho más viable el desktop publishing que los exiguos 512×342 del Mac.

En las noticias breves, además, se anunciaba el lanzamiento de Lotus Manuscript, un potentísimo (de nuevo, para la época) procesador de textos (con soporte para fórmulas matemáticas y todo), del que podéis encontrar más información en la Byte de noviembre de aquel año… y la celebración de los cuarenta años del ENIAC (sin mencionar a sus programadorAs, que seguían en el olvido).

El mes que viene, más. Como de costumbre, si queréis avanzaros con los deberes, podéis acudir tanto a la lista de episodios de la Wikipedia como a la playlist a la que pertenecen los vídeos de YouTube que tenéis aquí arriba.

El multifactor autobús de internet es 1:n. Y n no es pequeño

Dice la wikipedia en español que el «factor autobús» es

un término usado en proyectos de desarrollo de software, que alude a una gran cantidad de información vital de un proyecto de software limitada solamente a uno o unos pocos desarrolladores, impidiendo la continuación del proyecto en el hipotético caso de que estos desarrolladores clave sean atropellados por un autobús.

Vamos, que tu factor autobús es uno si basta con que un autobús atropelle a la persona correcta para que tu proyecto se venga abajo, dos si hace falta que atropelle a las dos personas correctas, etc.

(Mucho más «maravilloso» me parece el factor bus inverso: ¿a cuánta gente tiene que atropellar el autobús de marras para que el proyecto funcione?)

Me viene a la cabeza el «conceto», irremediablemente, al leer The people holding up the internet (lectura casi obligatoria), que documenta casos como el de Paul Eggert, profesor de UCLA y mantenedor del archivo de zonas horarias que usa… básicamente toda la tecnología digital del mundo para determinar qué zona horaria aplica en cada lugar del mundo. Eggert, además, ha hecho 218 de los 251 cambios hechos al archivo en los doce meses anteriores a la publicación del artículo. 251 cambios en un año, sí. Si te bajas de un avión en Winnipeg dentro de un mes, tu reloj solo se pondrá en hora correctamente gracias a un cambio hecho a ese archivo en los últimos meses.

No parece el problema más grave del mundo, ¿no? Pero la pieza también habla de Lasse Collin, que mantenía xz, una utilidad de compresión presente en muchísimos servidores de internet y en el iPhone (dice la pieza, no lo he comprobado), que explicaba hace unos años que era un hobby suyo por el que no ingresaba nada… y que estaba teniendo problemas de salud mental que le dificultaban el «hobby»-llámale-trabajo-llámale-mejor». Al cabo de poco se ofreció un alma inocente a echar una mano… que resultó no ser tan inocente y acabamos con un considerable agujero de seguridad (ya parcheado) en una cantidad más que notable de servidores de los que alimentan internet. También habla de sudo, ese comando sin apenas importancia para la seguridad… Y de…

Vamos, que existen múltiples personas que hacen que el factor autobús de internet (y buena parte de nuestras vidas depende de internet, no lo olvidemos) sea muy, muy pequeño.

El multifactor autobús

Y esto me lleva a mí a sacarme de la manga el concepto de «multifactor autobús» (obvio para todos los que hayáis llegado hasta aquí): si tienes factor autobús n, pero hay m n-uplas a las que se les puede aplicar la definición, entonces tienes multifactor autobús n:m. Si n es pequeño, tienes un problema. Y ese problema crece ¿linealmente? ¿exponencialmente? ¿¡factorialmente!? (yo voto que factorialmente) a medida que crece m.

(Seguro que alguien ha documentado antes y mejor el concepto, sí.)

Y lo peliagudo de la cosa (uno de los aspectos peliagudos de la cosa, de hecho) es que nuestras infraestructuras digitales, lamentablemente, además de tener una n muy, muy pequeña, tienen una m muy, pero que muy grande. Y no estamos haciendo lo que deberíamos para resolver el problema (con nobles y notables excepciones, como la de sovereign.tech, agencia alemana de soberanía tecnológica).

PS Que sí, que lo del «multifactor autobús» me ha hecho gracia, pero todo esto es solo una excusa para incrustar aquí una de las mejores (en mi inmodesta opinión) tiras de xkcd…

…y la versión que le hice yo hace cerca de un año…

a variation on the popular all modern digital infrastructure meme. a big stack of pieces is very unstably balanced on top of four small pieces. everything would fall down if just one of the pieces is moved even a tiny bit. the pieces are labelled "cloudflare", "Amazon us-east-2", "some Azure zone or another", and "and open source project you hadn't even heard about". a text to the side says "with apologies to Randall Munroe and countless other people"

(que, efectivamente, no es más que una más entre un millón de variaciones, pero es la mía 😬).

#breBytes Amiga, la «review»

Antes de entrar en materia, quiero destacar que la portada de la Byte de octubre del 86 se la dedicaban al Apple II GS, el ordenador que demostraba que Apple tampoco lo tenía muy claro con el Mac, por aquel entonces, y que no se atrevía a matar del todo la gallina de los huevos de oro que había sido hasta entonces el Apple II, y hacía como Commodore con el 128, intentando alargar la vida de su línea 8 bits con un 16 bits compatible (después de otro intento con el malogrado Apple III). Afortunadamente para Apple, tenían más recursos y capacidad de ejecución y no les pasó como a Commodore…

Anyway. Volviendo a lo nuestro… la velocidad del periodismo tecnológico, para bien y para mal, era muy diferente hace cuarenta años: el Amiga había sido portada… en agosto ¡del año anterior! (Y, como podéis ver siguiendo la etiqueta Byte del blog, había ido apareciendo número sí, número también, desde entonces.) En este mismo número, incluso, había un artículo sobre el sonido del Amiga. Pero es ahora cuando lo revisan a fondo:

The Commodore Amiga by Tom Thompson The strong point of this well-designed machine is spectacular graphics The Amiga from Commodore International is a business machine, a graphics workstation, a multitasking system, and a home computer. A bold statement, but the Amiga has a unique hardware design that gives it sufficient power, especially when combined with some pricey peripherals and improved software, to meet most of these expectations. Hardware The basic Amiga comes with 2 56K bytes of RAM, and you can upgrade to 512K bytes easily with a 256K-byte RAM expansion cartridge that plugs into a slot behind a front panel. A built-in 3 1/2 inch double-sided disk drive holds 880K bytes, and the machine has a connector for an external drive. The Amiga can support three additional drives— either double-sided 3 '/2-inch or double-sided 5 1/4-inch. The system has programmable serial and parallel ports. Two RCA jacks provide stereo audio output. The two joystick ports can be used to connect a two button optomechanical mouse. The Amiga provides analog and digital RGB output for color monitors and a composite video output that can input directly into a VCR or color monitor. The Amiga also has an RF modulator port for TV outputs, but you need an external RF adapter unit for this type of use. On the right side of the machine, a panel covers the expansion bus interface, a card edge into which you can attach additional memory or special peripherals. An important feature of the hardware is that you can synchronize the display to an external television signal, allowing the possibility of receiving, viewing, and processing VCR or video camera input. The Amiga uses a Motorola 68000 microprocessor chip running at 7.16 megahertz. Three custom chips handle the bulk of the display control, sound generation, and DMA (direct memory access) data transfers (see "The Amiga's Custom Graphics Chips" by Phillip Robinson, November 1985 BYTE). You can manipulate eight reusable sprites on two playfields with priority control and collision detection. Area-fill and bit-plane copying are also supported, and four programmable audio channels are available. For additional information on the Amiga's hardware, see "The Amiga Personal Computer" by Gregg Williams, Ion Edwards, and Phillip Robinson, August 1985 BYTE. I was disappointed to find out that the Amiga doesn't have a battery-operated clock. Such clock circuits are not difficult to build, and with 880K bytes of data per floppy disk drive, a time stamp on a file is a requirement. The clock should be standard, but you can buy peripherals that contain a clock. Display The Amiga display has two resolutions. Low resolution is 320 pixels per line and 200 lines per screen, with a choice of 32 colors from a palette of 4096. High resolution is 640 pixels per line for 200 lines, displaying 16 colors out of 4096. An interlace mode allows you to double the vertical resolution: 320 pixels for 400 lines in low resolution and 640 pixels for 400 lines in high resolution. A special mode called hold and modify (HAM) allows you to use six bit planes in a controlled manner to display the entire 4096 colors simultaneously. This last mode is perhaps the most spectacular: Digitized pictures utilizing HAM have a televisionlike quality to them due to the range and subtle shading of the colors displayed (see photo 1). The Amiga can present text in a variety of sizes, colors, fonts, and styles. You can also present text in 60 or 80 characters per line. The system ROMs contain two default system fonts; other fonts are stored as .font...

Leer la revista te recuerda, primero, la cantidad de cosas que había que explicar en 1986 al lector incluso de nivel medio alto («You can move, resize, open, and close windows using the mouse. You use the left mouse button for operating on a window or its contents and the right mouse button to activate and make selections on the pulldown menus. It takes a little practice, but it is easy to get used to«), después, que para 1986 el sistema operativo del Amiga aún andaba en versiones tempranas y que le quedaban bastantes aspectos por limar y, finalmente, que por aquella época los ordenadores te los programabas tanto o más que usabas programas ajenos (y, por lo tanto, la disponibilidad de compiladores e intérpretes era algo de lo que hablar con un cierto detalle).

Y no os digo nada de lo que opina el crítico del «bicho»… porque apenas dice nada, y es más interesante repasar las opiniones sobre todo positivas sobre el potencial de la máquina y universalmente negativas sobre la gestión de Commodore que han ido apareciendo por aquí en los últimos meses.

El mes que viene, más (o no).