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.

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!

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.

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…

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

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:

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).

El «TLDR»: como prácticamente cada cambio más o menos revolucionario que hemos tenido en las últimas décadas, la IA generativa ha venido, sobre todo, a amplificar problemas que ya existían (como mínimo en las tres décadas anteriores, que son las que he presenciado yo en vivo y en directo, y me atrevo a aventurar que unas cuantas más) y que el sistema hacía todo lo posible por ignorar. Hasta ahora hemos ido sobreviviendo, más o menos, a los palos anteriores, por algún extraño milagro (no es tan extraño, ni milagroso, pero permitidme el abuso de notación). Y con la IAg a los políticos y demás responsables del sistema se les va a llenar la boca de discurso vacuo, vamos a atacar con fuerza y gran dispendio de recursos toda una serie de síntomas y vamos a seguir ignorando muy fuerte los aspectos [que a mí me parece] que son la verdadera fuente de los males del sistema.

(Antes de seguir, para quienes queráis pasar más allá del TLDR, a pesar de mis advertencias, recomiendo encarecidamente la lectura de Instituciones no educadoras e IA y Universidad: el urgente cambio sistémico en la política de educación superior, de Ismael Peña, que es lo que ha disparado este texto (ya tenéis culpable, yo no quería, me han obligado 😬), y quizás un poco más, todavía, La inminente crisis de credibilidad de la universidad y Rediseñar la evaluación cuando el estudiante usa IA generativa, de Juan Freire. Lo mío son mis dos céntimos a partir de mi muy anecdótica experiencia personal, y lo suyo, sus dos euros. Tampoco son breves, pero sí muchísimo más claros.)

Arranco con un par de apuntes que, en la línea que apuntaba mi TLDR, tienen muy poco que ver con la IA.

«Pero si tú lo entiendes»

Esa es una frase que me dijeron en algún momento de la década de los noventa, y que se me quedó grabada a fuego. Servidor no era, reconozcámoslo, un buen estudiante para la carrera de matemáticas. Y no fueron pocas las revisiones de examen a las que fui. Y la frase me la dijo a mí un profe en una de ellas (de análisis complejo iba la cosa). La nota que me llevó a la revisión del examen me la había ganado yo por méritos propios. Pero la frase es una de las críticas más salvajes al sistema que haya oído yo nunca. Porque además del implícito obvio «y estás en la revisión del examen porque te ha ido como te ha ido, a pesar de entenderlo», había otro implícito más: «y hay gente que no ha venido a la revisión de examen porque no les ha hecho falta, aunque que no lo entienden (o al menos lo entienden menos que tú)».

Podría rescatar algunas anécdotas más que apuntan cómo, en una carrera de matemáticas, la reina del «pensar por encima de memorizar», ya por entonces, en la práctica, «memorizar sin entender una palabra» era un mecanismo perfectamente válido para superar exámenes (de hecho, las voy a esconder en un par de notas al pie, recomendadas solo para los muy adictos ¹,²).

Y esto, insisto, pasaba en los noventa. Mucho antes de Bolonia, que es el objetivo al que muchas veces se señala como culpable de los males actuales de la universidad (al menos en España). No seré yo quien defienda Bolonia. No sé si los males que ha acabado trayendo estaban ya en sus palabras, o si ha sido el sistema el que ha pervertido sus nobles intenciones, pero, en cualquier caso, los ha traído. Pero algunos de los males de los que se le acusa ya estaban ahí antes. Puedo dar fe de ello.

«Capacidad de resolución de problemas» vs «memorización»

Sigo con cosas que poco tienen que ver con la IA.

En este país (imagino que en muchos otros también) nos vendieron hace unos años (y nos siguen vendiendo) que había que conseguir que en la educación primaria y secundaria perdiese peso la memorización y lo ganase la capacidad de resolver problemas (resumiéndolo de manera extrema y burda, sí). Y con ese nobilísimo ejercicio hemos tenido reformas, reformitas y contrareformas. Pero.

En la práctica (aquí es donde me voy a mi extremadamente anecdótica experiencia), con lo que me encuentro yo en las clases que doy en «la uni de toda la vida», la de pizarra (proyector y powerpoint las más de las veces, sí) y fila tras fila de estudiantes, ese cambio de peso no es tal. Mis estudiantes (que se portan mejor de lo que se portaba mi grupo, en mi experiencia, y que asisten bastante a clase, debo decir), de primero de una carrera que tiene una nota de corte medianamente alta, y de los que voy a asumir que no son ni mucho más listos ni mucho más tontos que mi grupo, son, al salir de la formación secundaria, maquinitas de memorizar y ejecutar algoritmos a mano, mientras que pensar y resolver problemas les causa bastantes más… problemas, valga la redundancia. ¿Puede ser un sesgo de la muestra? Comienzan a ser años de experiencia, o sea que diría que no. ¿Podría ser que sea yo un cincuentón gruñón quejándose de la siguiente generación? Algo de eso tiene que haber, por fuerza. ¿Podría ser que no sea yo muy buen profe? Absolutamente. Pero os va a costar convencerme de que las reformas hayan hecho lo que decían pretender. Os va a costar mucho.

¿Cómo pretendíamos que aprendiesen los estudiantes hasta ahora?

Describo brevemente mi caso particular. Yo llevo unos añitos dando diez semanas al año de clases de teoría y prácticas de teoría de grafos de una asignatura dentro de un grado de ingeniería de datos, con chicos y chicas majérrimos³ en lo general, por cierto.

En la asignatura, el objetivo es que entiendan qué es un grafo, que con grafos se pueden modelar problemas reales sumamente interesantes (redes sociales, epidemiología, el algoritmo de enrutado de Google Maps, por mencionar solo tres), cómo funcionan algunos de los algoritmos básicos de grafos, que entiendan que si se puede resolver a mano, el problema no tiene ningún interés más que como ejercicio de clase, que programen alguno de esos algoritmos básicos, y que sepan que hay bibliotecas con prácticamente todos los algoritmos de la teoría de grafos, y que la verdadera gracia de todo está en aprender a modelizar el problema para resolverlo tirando de esas bibliotecas.

¿Cómo funcionamos? Dos horas de teoría a la semana, en las que uno intenta que no se aburran en exceso viendo todas estas cosas, una hora de problemas (que no doy yo) que es… una hora de problemas al uso, en la que se intenta animarles a que trabajen con antelación y que la clase sea un espacio de resolución de dudas, y una de prácticas, en la que se les plantean problemas a resolver programando (tanto en la hora de problemas como en la de prácticas se les divide en grupos para poder atenderles algo mejor) que resuelven a lo largo de múltiples semanas. No nos van a dar un premio a la innovación docente, pero sí hacemos el esfuerzo de plantear clases dinámicas, al menos un poco participativas (cada semestre a alguien se le ocurre el DFS, me alegra comunicar, por ejemplo), y en las que se resuelven problemas que están conectados con la vida real.

¿Qué esperamos con esto? Que con las explicaciones de teoría, los problemas que se resuelven en la pizarra y, sobre todo, el esfuerzo de intentar resolver los problemas que se les plantean y de pelearse con Python para atacar los retos algo más complejos a los que les enfrentamos, las telarañas que les ha acumulado el sistema educativo en el cerebro se desvanezcan al menos un poco, y adquieran los conocimientos y competencias (ahora les llamamos resultados de aprendizaje) de la asignatura, estén en condiciones de enfrentarse con las siguientes asignaturas del grado, se acerquen un poco a ser las ingenieras que vamos a necesitar en el futuro, y puedan acceder al mercado laboral en condiciones.

Si quitamos cuatro detalles⁴, básicamente lo que habríamos hecho cuando yo estaba en el otro lado del aula, si el profe era medianamente bueno y le echaba ganas, que por aquel entonces lo de hacer participar al estudiantado, y el aprendizaje activo y estas cosas, al fin y al cabo, ya se predicaban.

(Quiero pensar que pertenezco a la categoría de «profe medianamente bueno que le echa ganas», pero mejor preguntar a mis estudiantes.)

¿Y la IAg?

¿Usan los estudiantes la IAg como yo no quiero que la usen, con el objetivo de aprobar sin estudiar? Sí, claro. Exactamente igual que la hubiesen / hubiésemos utilizado los estudiantes de mi generación si la hubiésemos tenido a mano.

¿Cómo no quiero que la usen? Los problemas y prácticas que les ponemos están pensados para que se puedan resolver con un cierto esfuerzo, y para que en el proceso de intentarlo adquieran la práctica y las estrategias de resolución de problemas que, primero, les llevarán a aprobar la asignatura y, segundo y mucho más importante, les convertirán, poco a poco, en profesionales comme il faut.

En la práctica, los enunciados de esos problemas y prácticas, pensados para las estudiantes de primer año, son lo suficientemente fáciles como para que los resuelva cualquier bot de IA medianamente competente. Si caen en la tentación de encargarle el trabajo al chatbot, lo de adquirir estrategias, competencias y demás, se va directo al garete. Y si los estudiantes que caen en la tentación son lo suficientemente buenos haciéndome/se trampas, es bastante probable que aprueben la asignatura. Lo de aprender, ya si eso, otro día⁵.

¿Puedo yo plantearles problemas que no resuelvan los chatbots? Claro que sí. ¿Haciendo que esos problemas sigan siendo del nivel competencial de mis estudiantes? ¿Sin que necesiten mucho más acompañamiento del que les doy ahora mismo, que es el que me pagan? Podría ser, pero prometo que llevo una buena temporada dándole vueltas al tema, y no se me ha ocurrido el cómo. Las respuestas que he visto hasta ahora a ese reto pasan por estudiantes que te llegan con las capacidades que espera (pero en absoluto garantiza) el sistema, y por muchas más horas de atención del profesorado que las que paga el sistema.

(¿Hay usos buenos de los chatbots? Desde luego. «Explícame este algoritmo de otra forma», «plantea y da los pasos para resolver diez ejercicios de este tema o de este otro», «ponme problemas que se puedan resolver usando estos algoritmos». Cosas que, naturalmente, me pueden pedir a mí (y les atenderé encantado, claro), pero el chatbot lo hace al segundo y, en la práctica, para mi asignatura, lo hace estupendamente.)

¿Y cómo atiendo / evalúo yo?

Volviendo al problema inicial. De hecho, la solución la tengo. O creo tenerla, vaya. Lástima que sea una vaca esférica, ahora mismo.

El examen que estoy proponiendo yo ahora mismo para evaluar, que es el factor de mayor peso en la evaluación (aunque suma menos del 50% del total), consiste en dos horas en que los estudiantes trabajan duramente, y yo después dedico cinco o diez minutillos a evaluar cada examen. Cada estudiante le dedica dos horas a ser evaluado, y yo me paso esas dos primeras horas vigilando y resolviendo (elaborar el enunciado tiene su trabajo también, pero no entraremos en eso ahora) y luego, para unos 50 estudiantes, por ejemplo, unas seis horas corrigiendo y poniendo notas. Ocho horas, más o menos.

¿Qué creo que debería pasar ahora? Que los estudiantes deberían ver el enunciado (otro enunciado, algo diferente), disponer de una horita para trabajarlo y, después pasarse… ¿veinte, treinta, cuarenta? minutos hablando conmigo sobre ese trabajo que han hecho. Pongamos que veinticinco minutos por estudiante. Me queda una hora vigilando… y, redondeando, veinte horas más. Y claro, mis estudiantes no pueden encontrarse por primera vez con la experiencia traumática de tener que explicarme sus razonamientos y defender sus argumentos el día del examen. O sea que habría que hacer algún simulacro antes. O dos. Cuarenta horas más⁶.

Y claro, esto aplica también a los ejercicios evaluables que les ponemos y a la evaluación de las prácticas que realizan.

¿Tres, cuatro, cinco, ocho veces más trabajo?

¿Se merecen mis estudiantes que dedique yo ese tiempo a evaluar su aprendizaje? La respuesta es que, [insert expletive here], sí. Y más. Se lo merecían antes de la IA. Me lo merecía yo en los noventa. ¿Me salen a mí los números con lo que me pagan? Ni en broma. ¿Le saldrían las cuentas al sistema, con el dinero que puede / está dispuesto a invertir? Ni en broma.

Pero es que el problema principal no es ese

(Se debe haber escrito mucho sobre el tema, pero fuera de lo que leo yo habitualmente. Se agradecerán todo tipo de ayudas en ese sentido.)

El problema es qué enseño, cuáles son los conocimientos, las habilidades y competencias que deben adquirir mis estudiantes, tanto para ser profesionales válidas para el mercado laboral como para poder contribuir a la investigación, desde la universidad o desde las (pocas) empresas que saben que la investigación es esencial. Y yo no tengo ni idea. Y cada vez que escucho a alguien que dice, con mucho aplomo, tener la solución, me da la risa-por-no-llorar. Y ahora mismo lo urgente (el tema de las trampas) está ocupando todo el espacio, sin dejar ni un resquicio para lo importante.

¿Es este problema nuevo? Noparanada. La universidad siempre ha ido por detrás (y en ocasiones, además, esto no solo no es malo, sino que puede ser bueno y todo). Pero si en 2016 (y en 2006, y en 1996, y seguramente mucho antes) esto ya era un problema grave, ahora lo es muchísimo más. Y urgente, también. Pero no os preocupéis, que lo que decía al principio, que vamos a dedicar muchos recursos a tratar los síntomas y a ignorar la enfermedad, ya está pasando y va a seguir haciéndolo. Eterna gloria al sistema.

Y lo descansado que me he quedado yo con mis tropecientas palabras para describir el problema y solo apuntar una solución impracticable, oiga.

¹ La primera anécdota es un conjuro mágico: «El conjunto es medible porque es una unión numerable de conjuntos de medida cero, que son a su vez medibles, y toda unión numerable de conjuntos medibles es medible». Esas palabras mágicas fueron, durante años (con un poco de relleno, pero no mucho, lo aseguro), los dos puntos y medio que sacábamos todos en el examen de Análisis II. Las entendieses o no. ↫

² La segunda fórmula mágica, «DE, DIP, DEFEÚ«, esta vez con un relleno de unas cuantas densísimas páginas a memorizar, representaba dos puntos y medio del examen de Álgebra III. Las entendieses o no. (Que todo dominio euclidiano es de ideales principales, y que todo DIP es un dominio de factorización única, por cierto, es una cosa maravillosa. Excepto si te fallan los fundamentos y te van a examinar de Álgebra III. En ese caso son unas cuantas páginas de embrujos a memorizar y poco más.) ↫

³ Off topic salvaje. ¿Que por qué defiendo yo tanto LanguageTool? Me acaba de no subrayar en rojo majérrimo. Yo ya no sé qué hacer para convenceros. ↫

⁴ Los detalles: la existencia de bibliotecas de funciones (como NetworkX en el caso de Python), por un lado, y, por el otro, unos pocos miles de veces más potencia de los ordenadores que usan en las prácticas (esto es, resolver en segundos lo que antes costaba horas, que no es poca cosa). ↫

⁵ Que esto no es nuevo, ¿eh? La combinación de Google y Stack Overflow ya contenía todas las respuestas. Y siempre se ha podido copiar de un amigo. Solo ha cambiado que ahora es mucho más fácil, y más cuando cada vez, y por múltiples y muy razonables motivos, usamos la evaluación continua, con trabajos que los estudiantes hacen en su casa. ↫

⁶ No vamos a hablar de que evaluar a los estudiantes «en serie» supone problemas y que habría que hacerlo «en paralelo», pero eso lo podríamos llegar a solucionar repartiendo trabajo. ↫

Me encuentro en la newsletter de Frontend Focus con este generador de CSS crítico: lo apuntas hacia una URL, le especificas un tamaño de pantalla objetivo y te analiza el CSS para extraer el que es crítico para renderizar el «above the fold», que puedes incrustar en el HTML para minimizar el tiempo que tarda el navegador en mostrarte el contenido.

De la misma newsletter, pero de una edición posterior, sale esta técnica para sidenotes solo con CSS que este fan de las notas al pie y familia debería explorar con cariño. También esta de anotaciones.

Siguiendo con CSS, me encuentro con CSS Bed, un agregador de temas «classless» (esto es, no definen su CSS para determinadas clases, si no directamente para los elementos HTML).

Por no hablar solo de CSS… el 29 de septiembre se anunció la 1.0 de emDash, un CMS nuevo, construido sobre Astro, con el soporte (para bien o para mal, a gusto del consumidor) que parte de la pregunta (dicen ellos mismos) «¿cómo sería WordPress si se crease hoy?». Con la que está cayendo en Automattic, estudiar si es una alternativa real a WordPress, o puede serlo en el futuro, comienza a ser una necesidad…

Y cerramos con un poco de accesibilidad, de la mano de This hue shall pass, un verificador de la accesibilidad de paletas de color que, como factor diferencial, no solo te dice si la paleta es o no accesible, sino que te da herramientas para intentar mejorar su accesibilidad (idealmente, hasta pasar los criterios AAA, claro :-)).

(Espero que otras administraciones públicas lo hagan mejor y que esto solo sea de interés en el área de Cataluña. Aunque no me jugaría dinero.)

La historia: veo algún titular sobre precipitaciones intensas mañana y que la Generalitat ha publicado alguna alerta, o sea que me voy a mi recurso sobre el tema: beteve.cat/temps-barcelona (barceloneses y allegados, esta es vuestra página del tiempo, creedme), y allí me encuentro un titular que me lleva a una noticia…

betevé ha decidido incrustar el tuit de @meteocat. Como podéis ver (como no podéis ver, de hecho, al menos si tenéis mi vista y no hacéis zoom), el texto de las imágenes incrustadas en el tuit es demasiado pequeño como para leerse en el incrustado, o sea que… clic, y

Algo hemos ganado, que ya podemos leer (aguzando la vista) los textos de las imágenes, pero casi mejor hacer clic en ellas para leer con comodidad, convendréis. Y entonces…

Que si quieres arroz, Catalina, y que si quieres ver las imágenes a la resolución original, que te des de alta en un servicio privado con ánimo de lucro. El servicio podría ser propiedad de mi mejor amigo y no me parecería de ley. El servicio pertenece a Elon Musk.

(Esto no lo he comprobado porque no me da la gana hacer log in en Twitter, pero me parece que las imágenes incrustadas por la cuenta de Twitter no tienen texto alternativo y, por tanto, no son accesibles para una persona con discapacidad visual. Espero de todo corazón equivocarme y que el Meteocat no se esté saltando la ley.)

Pero claro, César, no me seas bruto: no te están obligando a hacer log in en el servicio de Meloncete, seguro que el Meteocat publica su información de servicio público en su web meteo.cat, que para eso está. Y es así, PERO.

¿Veis el gráfico (bastante currado, debe decirse) que había en Twitter? ¿Veis el texto destacado hablando de una situación meteorológica de peligro en las próximas horas? No, eso es para quienes tengan una cuenta de Twitter. (En la captura os he hecho ya clic en mañana en el mapa de avisos, porque si no, el naranja de media Cataluña mañana no se vería.)

Pero no me seas tonto, y haz clic en el mapa, que nos lleva a meteo.cat/prediccio/general:

La página contiene la información, sí, y hay unos triangulitos naranja para que veamos que hay avisos. Y si hacéis clic en los triangulitos naranja, llegaréis a la página con la previsión de mañana, y allí podréis hacer clic en el aviso, y llegar, finalmente, a

Las imágenes de resumen publicadas en Twitter, eso sí, no las he sabido encontrar :-S.

Por aquello de ir cerrando:

1. A mí me parece bien razonable que el meteocat tenga cuenta en Twitter (y en Facebook y en Instagram). Hay muchísima gente en esas plataformas, y acudir a la gente es lo que creo que deberían hacer los servicios públicos. Aunque quizás estaría bien que hubiese un mastodon.gencat.cat y que tuviésemos un canal de microblogging para cada servicio de la Generalitat, comenzando por @meteocat (y lo mismo aplica a todas las administraciones públicas de un cierto tamaño). Pero lo que no puede ser es que el esfuerzo que se dedica a comunicar en esas plataformas privadas no se lleve a todos los lugares posibles. Especialmente si Twitter no me permite acceder cómodamente a la información sin registrame ni hacer log in.
2. La página de meteo.cat contiene muchísima información muy útil, pero igual estaría bien darle un lavado de cara y aprovechar para reservar un lugar destacado en portada para los avisos de situaciones meteorológicas potencialmente peligrosas. Digo yo.

En fin, disculpen el rant de señor mayor 🙏.

Ya habíamos hablado brevemente de educación en línea en 1986 en el último post dedicado a las Computer Chronicles, de este mismo mes, pero es maravilloso leer cómo, desde la revista, se animaba a las universidades al mundo del online, hablando de ruralidad, formación continua y lifelong learning, entre otros aspectos :-)

Comenzamos con los dos primeros episodios de septiembre de 1986, que se centran en el uso de la informática en educación. Arrancamos en un cole (curiosamente, de Cupertino) al que Apple había dotado de unos cuantos Apple II para que cada estudiante tuviese uno (sin entrar en muchos detalles), para luego tener una demo del estado del arte de la época del software educativo de la época. Curioso que ya por entonces, cuando el periodista pregunta si se ha hecho algún tipo de diseño experimental para medir la efectividad del uso de la informática en las escuelas, no hay mucha respuesta, precisamente… Afortunadamente, en la siguiente entrevista hay algo más de reflexión antes del uso ciego de la tecnología. Como solemos decir por aquí, hace cuarenta años estábamos mucho más cerca de cómo estamos hoy de lo que creemos… (En los breves del final del programa, y en esa misma línea, Apple estaba intentando detectar por dónde se les filtraban los nuevos desarrollos a la prensa 😬.)

En el segundo episodio temático, nos pasamos del uso educativo del ordenador en las escuelas a su uso en casa, entre otras cosas para matricularse en educación universitaria en línea 🙀, o el uso de un Amiga (claro) para consultar recursos multimedia almacenados en LaserDisc. Y en los breves del final, noticias sobre interfaces cerebro-ordenador (sí, hace cuarenta años), y el uso de la red francesa de Minitel para usos ilícitos no anticipados, entre otras…

Y en el tercer y último episodio del mes nos encontramos con el que tiene que ser el estándar más longevo de la informática: MIDI, que básicamente sigue siendo el mismo hoy que ya era en 1986 (y una de las pocas cosas en las que el Atari ST era superior al Amiga). Y de regalo podréis ver cómo eran las DAWs de la época, para el ST, el Amiga… e incluso el Apple IIGS¹, y unas cuantas más de las aplicaciones musicales de la época. En los breves, el primer piloto para hacer la declaración de la renta digitalmente en los Estados Unidos.

Y eso es todo por septiembre. Amenazamos con volver el mes que viene. 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.

1. Hace un par de meses nos quejábamos por aquí de lo perdida que iba Commodore cuando lanzó su 128 en vez de dedicar todos sus recursos al Amiga. El IIGS sería el equivalente de Apple… pero no tuvo los mismos efectos devastadores en Cupertino. ↩︎