DEV Community: Hugo Ruscitti

Esta página está diseñada para durar

Hugo Ruscitti — Sun, 29 Dec 2019 16:05:13 +0000

Traducción del artículo: This Page is Designed to Last
Autor Original: Jeff Huang
Traducción: Hugo Ruscitti

Para un profesor, el fin de año es una oportunidad para limpiar y reiniciar las cosas para el nuevo semestre. Me encontré limpiando mi lista de sitios favoritos - sí, la lista de sitios favoritos, esa querida característica de los navegadores que perdió la batalla frente a la barra de direcciones que ahora tiene autocompletado.

Aunque este acto nostálico de ordenar me llevó a la desesperación.

Cada uno de los sitios marcados como favoritos me llevó a links rotos, uno tras otro. Desaparecidas quedaron las piezas maravillosas de escritos en kuro5hin
sobre cultura tecnológica, y una colección de puzzles matemáticos con sus
discusiones asociadas de matemáticos que me presentó mi papá; se fueron los tutoriales de ingeniería inversa de Woodman que leía en mis años de escuela secundaria, donde conocí el sentimiento de dominación del software gracias a esos textos; incluso mis sitios marcados como favoritos más recientes, una serie de post en Google+ exponiendo los cargadores usb-c no compatibles
con la especificación. Todo desapareció.

Esto es mucho más que links que dejan de funcionar, es sobre la creciente
complejidad de mantener vivo el contenido independiente en la web, conduciendo todo hacia plataformas y formatos de publicación ordenadas cronológicamente (blogs, feeds, tweets).

Por supuesto, yo también contribuí al problema. Un paper que publiqué hace 7 años tenía una nota donde se incluía un link a una demo, que luego fue tomada como una pagina de spam por un servicio. Parte de ese lapso reconozco que tuve pereza de renovar y mantener funcionando la demo web año tras año.

He recomendado a mis alumnos poner sitios web en Heroku, y publicar sus
portfolios en Wix. Aunque todas las plataformas con contenido irreemplazable mueren algún día. Geocities, LiveJournal, what.cd, y recientemente Yahoo Groups. Un día, Medium, Twitter, e incluso sitios de alojamiento como GitHub Pages van a ser saqueados y luego descartados cuando ya no puedan crecer o no encuentren un modelo de negocios que les funcione.

El problema tiene muchas facetas. Primero, lleva esfuerzo mantener el contenido. El contenido puede necesitar actualizaciones para mantenerse relevante, y eventualmente va a tener que mudarse a otro sitio. Un montón de contenido, que solía ser la gran mayoría del contenido, fue generado por personas individuales. Pero las personas (¿tal vez vos?) pierden el interés, así que tal vez un día simplemente no quieren lidiar con la migración de un sitio web a otro proveedor de alojamiento web.

Segundo, la creciente cantidad de bibliotecas y frameworks están haciendo la web mucho más sofisticada pero al mismo tiempo más compleja. Primero jquery, luego boostrap, npm, angular, grunt, webpack y más. Si sos un desarrollador web que se mantiene actualizado con lo último, esto último no te va a parecer un problema.

Pero si no es así, tal vez seas un programador de sistemas embebidos o un
director de tecnología en una startup o un desarrollador de Java para empresas o un estudiante de doctorado en química. Por supuesto podrías encontrar la forma de poner en funcionamiento un servidor web y corregir problemas de actualización con las herramientas, ¿pero podrías mantener esa consistencia año tras año, década tras década?, Probablemente no. Y cuando el siguiente año te encuentras con un problema de dependencia en los paquetes o te encuentres con problemas para generar los archivos .html de tu sitio, tal vez te rindas y hagas un .zip con los archivos para verlo "después". Incluso los conjuntos de tecnologías más simples como los generadores de sitios estáticos (como Jekyll) requieren un conjunto de herramientas que dejarán de funcionar en cierto punto. Vas a caer en el infierno de las dependencias de npm, y olvidar el comando para empaquetarlo todo y hacer un lanzamiento. Y tener sitios con múltiples páginas es complejo; ¿cómo vas a saber a qué páginas hace referencia cada uno de los links?. ¿"index.html.old", "Copia de about.html", "index.html (1)", "nav.html"?

Y tercero, y esto ha sido ha sido mencionado por otros (e incluso refutado), la
desaparición de la web pública en favor de la web mobile o aplicaciones web, Walled Gardens (Facebook pages), carga a través de websockets y AMP reducen la proporción de la red a nivel global, que ahora se parece más a una red continental en lugar de una red "verdaderamente global".

Así que en base a estos problemas, ¿qué podemos hacer al respecto?. Este no es un problema simple que se puede resolver en este artículo. El proyecto The Wayback Machine y archive.org ayuda a mantener cierto contenido por más tiempo. Y a veces alguna personas reubican el contenido en otros lugares.

Pero la solución necesita tener muchas facetas también. ¿Cómo hacemos contenido para que pueda durar y ser mantenido por al menos 10 años?. Como alguien que estudia la interacción entre humanos y máquinas, naturalmente creo que las partes interesadas no somos secundarias. Actualmente, poner contenido en la web está optimizada tanto para los desarrolladores profesionales (que usan los últimos frameworks y herramientas) como para los usuarios no expertos en tecnología
(que usan una plataforma).

Pero creo que tenemos que también considerar 1) a los mantenedores
de contenido web de forma casual, aquellos que no están constantemente
manteniéndose actualizados con las tecnologías web más recientes, lo que significa que los sitios web tienen que tener pocas necesitas de mantenimiento; 2) los rastreadores que preservan el contenido, lo que significa que el sitio debería ser simple de guardar e interpretar.

Así que mi propuesta es una serie de siete sugerencias poco convencionales sobre cómo gestionar sitios web diseñados para ser informáticos, fáciles de mantener y preservar. La intención principal es que el mantenedor intente mantener el sitio web por la menos 10 años, tal vez incluso 20 o 30 años.
Estas no son observaciones necesariamente controversiales, pero sí son
algo no convencionales a modo de manifiesto para sitios web que duren
más tiempo.

1 - Volver a HTML y CSS tradicional. Creo que alcanzamos un punto en donde html y css es mas poderoso y agradable de utilizar que nunca. En lugar de empezar con una plantilla gigante inyectada con varios archivos .js, está bien solo escribir HTML plano y desde cero otra vez. Características de CSS como Flexbox y Grid, canvas, selectores, box-shadow, el tag Video, filter etc. elimina un montón de necesidad de bibliotecas javascript. Podemos evitar jquery y bootstrap, que de todas maneras se están volviendo menos relevantes.
Podemos omitir los polyfills y prefijos de CSS, y quedarnos con atributos
CSS que funcionan en todos los navegadores. Y validar con frecuencia nuestro HTML; ya que puede ahorrarnos varios dolores de cabeza en el futuro cuando encontremos un bug.

2 - No minimizar ese HTML - Minimizar o comprimir tu HTML y todos los archivos CSS y Javascript asociados parece que ahorra mucho ancho de banda preciado por todas las grandes compañías que lo hacen. ¿Por qué no?, Bueno, no vas a ganar mucho porque tus páginas web deben estar siendo 'gzippeadas' por el webserver antes de ser enviadas por la red, así que achicar tu contenido preventivamente probablemente no contribuya a reducir el ancho de banda en absoluto. Pero incluso si eso ahorra unos pocos bytes (que es texto después de todo), vas a necesitar tener un proceso de compilación y agregarlo a tus herramientas, así que actualizar el sitio web se vuelve más complejo. Y es poco amistoso con tus usuarios también, muchas personas dieron sus primeros pasos con HTML pulsando la opción "Ver código fuente", y minimizar tu HTML prohibe completamente esta idea apasionante de ver algo cool y aprenderlo mirando cómo se hizo. Minimizar HTML no preserva su calidad educacional, y lo que se archiva es solo el resultado de código basura.

3 - Preferir una página en lugar de muchas - Muchas páginas es más difícil de mantener. Podes perder el control de qué página apunta a cual, y también conduce a algún sistema de plantillas para reducir la repetición. ¿Cuantas páginas realmente puede mantener una sola persona? Teniendo un solo archivo, probablemente "index.html", es más simple e imposible de olvidar. Has uso
de ese scroll que no se termina. No vas a tener que escarbar entre los
archivos para ver dónde está el contenido. ¿Y cómo debería
poner en un control de versiones ese archivo?, ¿debería usar git?, ¿Meterlo en una carpeta "old/"?. A mí me gusta un enfoque simple que consiste en nombrar a los archivos con la fecha en la que fueron retirados, como index.20191213.html.
Usando el formato de fechas ISO los archivos se pueden ordenar fácilmente de forma cronológica, y no hay confusión entre sistemas de formatos de datos Americanos o Europeos. Si tienes múltiples versiones de un archivo en un día, podrías usar un estilo similar al que se utiliza frecuentemente en los archivos de log, como index.20191212.1.html. Un lindo efecto colateral es que vas a poder acceder las versiones anteriores de un archivo si recuedas la fecha, sin siquiera ingresar en el host a ver el listado de archivos.

4 - Elimina todas las formas de hotlinking - esta palabra parece haber desaparecido del vocabulario de Internet, pero es una de las razones por las que he visto sitios perfectamente buenos desmoronarse sin ninguna razón aparente. Deja de incluir imágenes desde otros sitios web, deja de "tomar prestadas" las hojas de estilo solamente poniendo un link a ellas, y especialmente deja de poner links a archivos JavaScript externos, incluso aquellos que son alojados por los mismos desarrolladores originales. Hotlinking generalmente se considera algo rudo ya que tus visitantes
usarán el ancho de banda de alguien más, hace la experiencia del usuario más lenta, estarás dejando que el otro sitio web rastree a tus visitantes, y lo peor de todo: si la locación del archivo que estás solicitado cambia de ubicación o simplemente pasa a estar offline, entonces la cascada de errores llegará a tu sitio web también. Google Analitics es innecesario; almacena tus propios logs y configura GoAccess o léelos como quieras. No les regales tus registros de logs a Google.

5 - Quédate con las 13 fuentes seguras +2 - Ponemos el foco en el contenido primero, así que tipografías inusuales o decorativas son completamente innecesarias. Quédate con una paleta pequeña y las 13 fuentes estándar de los navegadores. Ok, tal vez realmente necesites una tipografía neo-grotesque que no es Arial ni Helvetica, o necesitas una tipografía geométrica. En ese caso, ve por las mínimamente necesarias, como Roboto y Open Sans; estas son las dos tipografías más populares en Google Fonts así que lo más problable es que estén almacenadas en el cache de la computadora de tus usuarios. Además de esas dos fuentes extra, tu foco debería estar
en entregar el contenido al usuario de manera efectiva y hacer que la decisión de la fuente sea invisible en lugar de acariciar tu ego de diseño. Incluso si usas Google Fonts, no necesitas que estén vinculadas mediante hotlinking. Descargá el conjunto de fuentes que necesitas y utilízalas localmente desde tus propios directorios.

6 - Comprimí tus imágenes agresivamente - es más rápido para tus usuarios, ocupará menos espacio a la hora de archivar y más fácil de mantener cuando no tengas que hacer una copia de seguridad de una carpeta enorme. Tus imágenes pueden tener la misma calidad, pero ser más pequeñas. Minificar tus archivos SVG, comprimir tus archivos PNGs sin pérdida de calidad, y generar archivos .JPG que coincidan exactamente con el tamaño en que se muestran en el html. Vale la pena pasar tiempo buscando la manera óptima de comprimir y reducir el tamaño de tus imágenes sin perder calidad. Y una vez que WebP gane soporte en Safari, cambia a ese formato. Reduce despiadadamente el tamaño total de tu sitio web y mantenlo lo más pequeño posible. Cada MB puede costar algo de dinero real, y de hecho, mi operador de telefonía móvil cobra centavos por cada MB, así que un sitio web de 25MB que es bastante común hoy en día cuesta casi como un periódico cuando era niño.

7 - Elimina el riesgo de una URL caída - Hay servicios de monitoreo que te avisarán cuando tu URL se caiga, evitando que te des cuenta un día que tu sitio web estuvo caído un mes y los buscadores te han quitado de sus resultados de búsqueda a causa de esa caída. Porque 10 años es mucho más tiempo del que los discos duros y sistemas operativos están diseñados para durar. Pero para eliminar por completo el riesgo de una URL rota, configura un segundo servicio de monitoreo. Ya que si el primero deja de funcionar por alguna razón (si se mueven a un modelo de pago, se apagan u olvidaste renovar algo, etc) aún recibirás una notificación cuando tu URL se caiga, y así te darás cuenta que el segundo servicio de monitoreo se cayó porque no recibiste la segunda notificación. Recuerda: estamos intentando mantener algo por más de 10 años (idealmente mucho más, incluso 30 años), así que un montón de servicios van a darse de baja durante ese periodo; entonces, dos servicios de monitorización es la forma más segura.

Después de hacer estas cosas, pon un poco de texto en el pie de página: "Esta página fue diseñada para durar", con un link a esta página explicando qué significa. Estas palabras prometen que el mantenedor hace su mejor esfuerzo para seguir las ideas en este manifiesto.

Y antes de que objetes, esto obviamente no es para aplicaciones web. Si estás haciendo una aplicación, hace tu web o aplicación mobile siguiendo el flujo de trabajo que necesites. Ni siquiera conozco alguna aplicación web que se mantenga funcionando de forma similar por más de 10 años (excepto el tutor de python de Philip Guo, a través de su estratégia minimalista para mantenerla así que esta guía no intenta abarcar aplicaciones. Tampoco es para sitios web mantenidos por una organización como Wikipedia o Twitter. Cada uno con sus cosas, y el salario de un equipo de IT es probablemente suficiente para
mantener algo vivo por un buen tiempo.

De hecho, tampoco es tan importante que sigas estrictamente estas 7 "reglas",
ya que son más una provocación que reglas estrictas.

Pero digamos que alguna pequeña parte de la web comienza a diseñar sitios web para hacer durar el contenido que se quiere preservar por más tiempo. ¿Qué pasará entonces?, bueno, las personas puede preferir hacer links a esos sitios ya que se han comprometido a seguir trabajando en el futuro. Las personas podrían volverse más conscientes en hacer sus páginas más permanentes. Y tanto los usuarios como los archivadores salvarán ancho de banda cuando visiten
y almacenen esas páginas.

Los efectos son a largo plazo, pero los logros son incrementales y pueden
ser implementados por dueños de sitios webs sin ser dependientes de nadie más o esperar por un efecto en red. Puedes hacer esto por ahora por tu sitio web, y eso en sí mismo es un resultado positivo. Como usar una bolsa de compras reciclada en lugar de tomar una de plástico, es una pequeña acción individual.

Este artículo está destinado a provocar y sugerir una acción individual, no propone una solución completa a la decadencia de la web. Es un paso simple y pequeño para un sistema socio-tecnológico complejo. Me encantaría que esto sucediera. Tengo la intención de mantener esta página por al menos 10 años.

Gracias a mis estudiantes de doctorado Shaun Wallace, Nediyana Daskalova,
Talie Massachi, Alexandra Papoutsaki, a mis colegas James Tompkin, Stephen Bach, mi asistente de curso Kathleen Chai y mi asistente de investigación Yusuf Karim por los comentarios sobre los borradores anteriores.

Mira los comentarios de este artículo en
Hacker News y
reddit /r/programming

Esta página está diseñada para durar.

Sobre ser un mantenedor de Software Libre

Hugo Ruscitti — Thu, 26 Sep 2019 21:44:11 +0000

Traducción del artículo: On Being a Free Software Maintainer
Autor Original: Georges Stavracas
Traducción: Hugo Ruscitti

Es el año 2013. Estoy aprendiendo sobre un proyecto nuevo llamado
"GNOME Calendar". Interesante...

Me gustan los calendarios.

Mi niño interior dice: "¡Genial!, voy a seguir este proyecto". Los
cambios más recientes y novedosos estaban siendo realizados en el branch
ui-rework. Todos los días, aparecían algunos commits nuevos. Hacía pull,
compilaba y probaba las mejoras. Excepto por día: no había commits nuevos.
Tampoco había commits al siguiente día, ni a la semana, ni al mes, ni al
año. Estaba desilucionado. No quería que el proyecto muriera.

Como mencioné antes: Me gustan los calendarios.

Mi niño interior nuevamente dijo: "No, esto no va a suceder". Así que
cloné el repositorio, compilé, reparé bugs u envié los arreglos. El
interés del mantenedor en el proyecto se renovó. Conseguimos un ícono
nuevo, las cosas se empezaban a poner estables. Creamos un canal de
IRC nuevo (!) y lanzamos la primer versión pública de GNOME Calendar.

Pasó un año más, es el año 2015. Después de contribuir por más de
un año, Erick me nombró el nuevo mantenedor ¹ de GNOME Calendar.
Una mezcla de emociones positivas fluyeron: satisfacción por el
logro; entusiasmo por lograr la posibilidad de llevar mis ideas
al futuro de la aplicación; miedo, por el peso de la responsabilidad.

Pero diablos, ahora soy un mantenedor de software libre.

Eso fue hace 4 años. El tiempo pasó, ocurrieron cosas, se construyó
experiencia. Y la experiencia difiere de lo que originalmente esperaba.

Ser un mantenedor de software libre te pone en un sitio algo raro. Cosas
buenas vienen de ahí, cosas malas, pero también terribles y extrañas.

Naturalmente, hay una sensación de logro muy fuerte en vos cuando
logras, bueno, conseguir el liderazgo de mantenimiento en un proyecto.
Usualmente, conseguir ese logro requiere un número muy grande de
interacciones durante un periodo de tiempo muy prologando. Significa
que son alguien en quien se confía, significa que das seguridad y que
tenes las habilidades técnicas que se necesitan para hacerlo bien.

Usualmente también significa lograr vínculos más fuertes con
la comunidad. Conocer personas excelentes, que saben un montón u están
dispuestos a compartir, aconsejar y ayudar. Hay un enorme valor
humano en poder estar rodeado de personas así.

Y para aquellos que disfrutamos programar, ¡mucho mejor!. También
puede interesarte planificar entregas, codificar y hacer
revisiones de código. Vas a encontrar problemas, buscar soluciones,
pensar y diseñar tu código. Hay una multitud de problemas para resolver
en este lugar y vas a tener la chance de resolverlos independientemente
vos mismo.

Y las personas, eventualmente van a enviarte un email de
agradecimiento, o te van a invitar un café. De una forma u otra,
las personas van a encontrar la forma de llegar a vos.

Las personas realmente van a encontrar la forma de llegar a vos.

Ahora bien, el software que mantienes a veces falla. Esos fallos
podrían hacer que se pierdan los datos de alguien más. A veces alguien
puede generar una condición única dentro de tu código que vos nunca
atendiste. Esas personas se pueden enojar, poner tristes, y frustrarse ².

Y entonces, esas personas van a encontrar la forma de llegar a vos.

Van a reclamarte que repares tu software, van a gritarte. A veces,
pueden cruzar la linea, e incluso van a insultarte. "¿Cómo no vas a
(usar tu tiempo libre para) arreglar este bug ultra importante que
me está afectando a mí?" o "¡Esta es una característica super básica!
¿Cómo no está implementada aún (por vos en tu tiempo libre)?!!" o
incluso "Me hiciste cambiar al Software Y, y ahora vas a necesitar
ganarme como usuario de nuevo para que vuelva".

Estas frases van a ser realidades con las que vas a tener que lidiar.

Podrías tener emociones muy particulares acerca de tu código. Tal
vez te sientas avergonzado por cosas que hiciste y haces en el
código. Después de todo, tu código tiene bugs, hay un montón de issues
pendientes de resolución en tu bug tracker y las personas se están
quejando sin parar. (Oh, y naturalmente, va a haber alguien intentando
poner su mejor esfuerzo en hacértelo notar.)

En algún punto, vas a mirar la lista completa de issues en tu
bug tracker y sentir una desesperación sutil cuando te des cuenta
que nunca vas a ser capaz de resolver todos los bugs.

Si estás dispuesto a revisar y aprobar las contribuciones de otras
personas, hay una alta probabilidad de que encuentres desafíos
disfrazados de contribuidores. Y tu revisión de código será como
una batalla intelectual entre el bien y el mal. Vas a necesitar
explicar y clarificar una y otra vez, lidiar con lógica circular
y con casi cualquier herramienta que las personas usen para ganar
batallas en lugar de mejorar su código. Eso, es increíblemente
tedioso.

Seguramente van a decirte que necesitas crear una piel más gruesa.
Que ignores eso, que lo dejes ir, pensar de forma positiva y no
prestar atención a toda la mierda que te tiran y por qué sos
tan negativo siendo un mantenedor.

Puede que ya no sientas la alegría de trabajar en lo que trabajas. Tal
vez tengas que cambiar a otra cosas. Puede que no lo hagas por el
sentido de responsabilidad que tienes con tu código, tu comunidad
y las personas que usan tu software.

Desafortunadamente, ser un mantenedor de software libre puede tener
un costo muy alto para tu salud emocional y psicológica.

Hace cuatro años, ciertamente no lo sabía.

1 - Y por "mantenedor" me refiero a ser el mantenedor de código
principal, no el mantenedor del paquete.

2 - Y con razón, nadie quiere perder sus cosas o romper su flujo de trabajo.