Tecnología, Internet y juegos
173 meneos
2889 clics
Alguien borró 11 líneas de código open source y rompió Internet. El caso dejó varias lecciones de las que nadie tomó nota

Alguien borró 11 líneas de código open source y rompió Internet. El caso dejó varias lecciones de las que nadie tomó nota

En marzo de 2016 ocurrió un suceso insólito que puso en evidencia la fragilidad de nuestra infraestructura digital: un sencillo y poco conocido paquete 'open source' compuesto de tan sólo 11 líneas en JavaScript, fue eliminado por su autor del repositorio NPM (una referencia para los programadores web de todo el mundo), y eso bastó para que buena parte del ecosistema de desarrollo web colapsara durante varias horas. ¿Cómo fue posible que algo tan pequeño tenga consecuencias tan enormes?

| etiquetas: left-pad , log4shell , consecuencias
81 92 2 K 390
81 92 2 K 390
La dependencia de grandes proyectos...

Salu3  media
#8 Añadele:  media
#10 y  media
#12 Fiar todo un proyecto a un paquete externo que no es tuyo y que se tiene que instalar por internet en tiempo de despliegue en vez de simplemente copiar esas diez líneas directamente en tu código y eliminar ese riesgo jamás está justificado. Jamás.
#18 Solo si quieres ver el mundo arder. Hay gente así en este mundo, por lo visto.
¿Dónde deberíamos poner la línea? No vamos a reinventar continuamente la rueda para cada proyecto. Pero instalar dependencias para solucionar cualquier problema como el caso que narra el artículo tampoco es plan. Entre dos casos extremos hay que poner el punto medio en algún sitio, y no es fácil.
#9 Hacer tu mismo una chorrada o como minimo tener el fuente no es "reinventar" nada
#14 desde luego, el del artículo es un caso extremo, pero entre este y el caso opuesto hay una difusa escala de grises donde elegir.
#9 solo poniendo caching proxies ya solucionas el problema inmediato (que es que tus sistemas de CI/CD no se paran). Para mi, reinventar la rueda es desarrollar desde cero todo cada vez... lo suyo es tener un toolkit en la empresa con todas esas funcionalidades, y tirar de ahí.
#9 pues dependerá de la funcionalidad.

Lo suyo es reutilizar código, pero es peor cuando llegas a un proyecto y se tiene casi un framework específico del lugar, que fuera de ahí no te sirve para nada, cuando vas a pasar allí a lo mucho unos años.

Lo preferible son soluciones globales y bien asentadas antes grandes desarrollos.
#9 ¿Por qué en el ámbito empresarial hay tanto terror a "reinventar la rueda"? Es que no es reinventar, es adaptar a tu proyecto, personalizar y sobre todo evitar errores o simplificar su reparación. Pero bueno, es siempre la misma discusión con los jefes. A ellos un comercial de tal frontend o librería les ha vendido la moto de que con su función get() se ahorran escribir un document.getElementById() y con eso su negocio va a ganar millones y podrán despedir a Paco y a Andrés, que…   » ver todo el comentario
#35 en mi experiencia estas elecciones no las hace el jefe, si no los propios desarrolladores. O por pereza, o por desconocimiento o lo que sea.
#44 Estaba justo empezando a leerla cuando he tenido que salir.
Seguro que muchos por aquí lo sufrimos P***s frontends!!! :-D
#1 La que lió ... Y la gente que descargaba a local y no actualizaba, con una sonrisa de oreja a oreja ... xD xD
#12 que va, no recuerdo exactamente la libreria, pero era una tonteria del tipo ordenar un array. La gente preferia usar la libreria a pensar por ellos mismos. Lo mismo esta pasando con la IA, vamos a generar un monton de catetos que no saben que es un algoritmio de ordenacion... en fin
#13 no vamos a generar nada.

Es culpa de la mentalidad empresarial, prefieren correr riesgos que desarrollar algo en "casa" adaptado a las necesidades. Claro, eso requiere talento y un buen sueldo. Pero los jefes quieren lamebotas que se parezcan a ellos y pagar con cacahuetes.

Recuerdo hace 12 años a un jefe de proyecto encriptando equipos con un sw gratuito descargado de internet por requerimiento del cliente.

Desde luego, poco nos ha pasado en it para las animaladas que se hacen.
#15 Esos riesgos son muy cortoplacistas "bueno, lo solucionamos ahora y luego ya veremos" Ese luego da mucho más trabajo que el que habría dado el resolverlo en el momento del desarrollo.
#4 Sí, pero hasta cualquier mierda tiene su complejidad. Empezó con 11 lineas obvias, pero acabó siendo una función con más sutilezas
github.com/left-pad/left-pad/blob/5b3826ec7aa4664dbc55a0a9ddc5d2e679d0

cc #12 #13 #15 #17 #23 #27 #29
#54 No sé qué sutilezas ves en la funcionalidad de ese código
#58 Es sutil por eso no la ves
#13 si no recuerdo mal era una función de padding. Aparece en las etiquetas del envío como left-pad.
#17 sí, algo así recuerdo yo también. Entonces empecé a mirar con recelo npm y las mil mierdas que metía para cosas absurdas. Es lo que tiene utilizar la mierda de javascript y encima tratar de atajar camino con librerías de este pelo.
#13 ¿no sería más bien que de una librería entera, la gente solo usa la funcionalidad chorra de ordenar un array?

Es que es muy común, que la gente desaproveche todas las funcionalidades por vagueza de aprender a usarla.

Lo de siempre, coger un ferrari para ir a buscar el pan.
#13 Estoy parcialmente de acuerdo contigo. Creo que deben existir librerías para todo aquello que se hace miles de veces por que no es la misma dedicación y empeño que le pones a esas 10 líneas de código para resolver algo que no si es una librería y hay literalmente gente dedicando su esfuerzo a mejorar ese punto y hacerlo más rápido y eficiente
Desconozco si esa librería es más amplia o son sólo esas 11 líneas de código, que menuda chorrada, eso lo implemente directamente en mi código, no necesito una librería externa para ello, ¿qué se puede mejorar ahí?.

Otra cosa es que sea algo más complejo, yo no se cómo se le ocurre a la peña trabajar con algo sobre lo que no tienes control, si necesito librerías externas, me las copio a un repositorio interno, si hay cambios en el externo veo si son lo suficientemente importantes para incorporarlos, los paso a un entorno de pruebas y una vez verificado que funciona bien lo paso a producción, así me ahorro quebraderos de cabeza.
#32 Me gusta cómo piensas. Además menuda chorrada de librería, hay que ser un vago redomado para no programarla tú mismo.
"El paquete left-pad tenía una función muy simple: agregar caracteres a la izquierda de una cadena de texto para que alcanzara una longitud específica" :palm:

Luego en el mundo real con las consultoras, los plazos de entrega irreales, la falta de testing, legacy codes y miles de juniors programando como pollos sin cabeza supervisados por un pobre senior deprimido por el burnout, el síndrome del impostor y la falta de ayuda... pues ya se entiende mejor todo esto.
#36 Supongo que será porque empecé a programar en Basic, donde te tenías que currar todo, al menos en mi caso, la única "librería" que compramos en la empresa fueron las FABS-Plus para trabajar con ficheros indexados, creo que la única rutina que encontré por alguna BBS o FidoNet era para imprimir códigos de barras EAN-13 en impresoras matriciales.
#36 dios, tu segundo párrafo es tan descriptivo de la realidad.....
#36 como he dicho arriba, el problema vino porque esa librería era dependencia de otras más gordas y claro, adiós todo.
#32 el problema no era la librería en sí, era que esa librería era dependencia de librerías más gordas y claro, todo a tomar por culo se fue.
Que nadie tomo nota? Si npm lo primero que hizo fue cambiar su politica de borrados.
#2 Va bastante más allá de lo que hiciera o dejase de hacer NPM y si lees el artículo verás a qué se refiere.

Cosas todas ellas que cualquier persona con un mínimo sentido común ya era capaz de ver unos cinco-ocho años antes de que todo eso pasara, que fue más o menos cuando el webdebbeloopment se volvió completamente loco y empezó la juerga de librerías y paquetes instalables en tiempo de despliegue escritos por fulanos para resolver cualquier mierda que no supondría más de diez líneas en el…   » ver todo el comentario
#4 "no supondría más de diez líneas"
En el caso del artículo eran 11 líneas y, quizás, si estuviese justificado su uso.
#12 no, era simplemente rellenar una cadena con caracteres por la izquierda, probablemente para alinear números y cosas así.
"123“ --> " 123"
"1" --> " 1“
#4 Es que por entonces, la parte front era algo simplón y dependía todo del backend para la lógica.
#4

¿No pasó hace no mucho algo parecido con el log4java?

p.s. viene en el texto como segunda cagada del mismo tipo.
#45 esa es a la que creía que se refería, sin leer la noticia.
#52

Era la que me sonaba a mí ... pero lo del leftpad es de traca.
Como en el apagon electrico pero seguro que aqui descubrieron el problema exacto mas rapido.
Es posible porque mucha gente no sabe hacer la O con un canuto
Estoy con el que borró left-pad. Que se jodan. Ojalá kik las hubiera pasado canutas.
#6 el puto amo. También te digo que hacer una librería así, subirla y tener que "mantenerla" pues no sé, pero mucho ego tienes que tener, porque esa librería era lo más simple del mundo.
Al final son dos principios contrapuestos.
No reinventar la rueda.
Depender lo mínimo del exterior.
Que esto lo diga Genbeta, que vive básicamente de coger contenidos de aquí y allá en lugar de generar sus propios contenidos, no deja de tener su ironía. :troll:
Pues es un artículo interesante, para entender un poco que en estos tiempos, casi todo es un castillo de infinitos naipes, veanse esos ejemplos y el reciente apagón.
#31 Fuá y lo bien que estábamos cuando solo había hidrógeno en el universo? Pocos problemas teníamos!
#33 "Todo esto antes era hidrógeno"
Odio npm y necesitar dependencias hasta para poner una cadena en mayúsculas.
#21 text-transform: uppercase :troll:

Supongo que era una exageración. Yo también odio npm y la ingente cantidad de dependencias de cualquier aplicación web. Una vez oí (como chiste) que más de la mitad del tráfico de internet es por los npm install, el resto es porno xD
#30 Veo que lo han marcado como obsoleto, pero me sonaba de hace años ver cosas de este estilo

www.npmjs.com/package/upper-case

muy bueno lo del trafico, me lo creo! jajaja
#30 El porno está en segundo lugar.
El primero lo ocupan las fotos y vídeos de gatetes,
Es una pena que no se quedara roto. Ojalá volviéramos, tecnológicamente hablando, a la era pre-internet.
#19 y de la electricidad qué me dices? Lo bien que vivíamos antes, sin calambrazos ni robos de cobre !
#20 en la era pre-internet ya había electricidad. Te lo aclaro por si no entendiste mi comentario.
#20 ¿Y los gametos qué? Con lo bien que estábamos siendo organismos unicelulares. :troll:

menéame