Hace 7 años | Por ezain123 a haneycodes.net
Publicado hace 7 años por ezain123 a haneycodes.net

Desarrolladores, es hora de tener una conversación seria. Como probablemente ya sabes, esta semana React, Babel, y un montón de otros paquetes de alto perfil en NPM se rompieron. La razón fue bastante asombrosa. Un simple paquete de NPM llamado left-pad de once líneas fue despublicado del repositorio. [...] Lo que me interesa aquí es que tantos paquetes adquirieran una dependencia de una simple función de relleno cadena izquierda, en lugar de tomar 2 minutos para escribir una función tan básica por sí mismos.

Comentarios

sorrillo

#8 Pero lo que yo añado es que no necesariamente ese paquete está testeado y validado

¿18 millones de descargas al mes y dices que no necesariamente ha sido testeado y validado?



y si lo está no por ello seguirá siendo así en el futuro

Si en el futuro produce errores se fija la dependencia en la última versión donde no los producía y listo.

g

#9 Una cosa es una función y otra es un paquete (que yo lo entiendo como un conjunto de funciones; quizá me equivoco). Sería mejor crear un paquete con todas las funciones tipo (es solo un ejemplo): leftpad, rightpad, leftzero, rightzero, etc.. y no un paquete para cada una de esas funciones.

Por ejemplo en go, https://golang.org/pkg/net/url/#pkg-examples hay un paquete con varias funciones que es para "parsear" una uri. O en perl http://search.cpan.org/~ether/URI-1.71/lib/URI.pm

Si cada función para hacer parse fuera un paquete, sería un lío difícil de mantener. Que es lo que ha pasado en NPM con el leftpad

D

#2 A mi me parece que en este meneo hay una queja un tanto legítima, utilizar dependencias innecesariamente, y otra un tanto absurda que es utilizar código existente. A lo mejor muchas de esas funciones estarían mejor en un paquete que incluya funcionalidades similares en vez de paquetes-función.

Por cierto, lo que dices en #8 me recuerda de una forma a un problema genérico en internet, y es que la información útil está muy diluida entre mucha mierda.

Hace algún tiempo alguien me pasó una noticia sobre un artísta español que trabajaba con piedras (en general de gran tamaño) al buscar información sobre él encontre un montón de copias en distintos blogs diciendo básicamente lo mismo que la noticia original, que era casi nada. lol

D

#20 #16 #57 Muy de acuerdo, es la fiebre de las dependencias en JavaScript. Hace poco vi en Twitter un chiste que viene PERFECTO para esta noticia, y resume la chorrada de tirar de dependencias para todo, sobre todo para aquellas cosas que realmente no necesitas:

subzeta

Test unitarios + inversión de dependencias. Si la interfaz cumple con tu modelo de dominio da igual qué dependencias tengas importadas mientras los tests sigan pasando.

Y estoy de acuerdo con todos los que ya han comentado (#2, #10) que paquetes de una sola línea son perversiones del propio concepto de paquete. Para eso están los helpers, lo que viene siendo un utilities.js en JavaScript y un helper.php plano en PHP.

Cidwel

como dice #2 creo que no es cuestion de escribir o no el código de tu programa. Simplemente es la perversión del sistema de paquetes. NPM deberá gestionar esta clase de paquetes tan básicos de otra forma. Suponiendo que son paquetes libres, deberían migrarse a un paquete mayor mantenido por la comunidad y no solo por un desarrollador.

c

#2 #1 El problema de fondo es que se está intentando usar un lenguaje con un API muy reducida y esto pervierte el nivel de paquetización.
Debería de hacer un JS y un Extended JS con todo este tipo de funciones para arrays, strings y demás objetos que en otros lenguajes son parte de la base y en JS no existen.

s

#40 Es que además ya existe! Lodash o underscore tienen esas dos funciones...
De hecho, creo que lodash lo puedes configurar con las funciones que necesites.

Es absurdo que exista un módulo de leftpad... Me extraña que React no use una librería de esas que sí son muy útiles... Seria doblemente grave porque incluirían el módulo sin necesitarlo.

D

#84 Los de React simplemente se colaron. Lo típico, te va bien y lo dejas en el package.json sin darle más vueltas.

Como bien dices, underscore o lodash es a lo primero que tienes que acudir siempre antes de complicarte la vida por tu cuenta o depender de una basura de 11 líneas.

oricha_1

#2 claro que si, ¿que es mas rapido? pip install PaqueteCualquiera que ademas esta testado o ponerte a picar tu propia funcion quickSort() ??

D

#47 No compares un módulo completo en Python con cientos de módulos, funciones y varias clases, con una función que cualquier programador hasta de los lerdos como yo realiza en 5 minutos.

D

#52 Y que no tendríamos ni idea si está bien o mal, ese programador es humano, y a veces es muy fácil comerse los casos límite, o no pensar en casos excepcionalmente extraños.

Al final un buen profesional del tipo que sea, tiene que tomar decisiones considerando que pierde y que gana en cada caso, no hay soluciones ideales. A lo mejor no son 5 minutos, son 30, pero te conviene más, o no, depende de lo que necesites.

p

#95 Totalmente de acuerdo.

A veces necesitas personalizar las cosas, a veces necesitas hacer las cosas lo más rápido posible, a veces necesitas saber con exactitud total lo que se está haciendo por debajo. No siempre coger dependencias es el camino a seguir, aunque suela serlo.

Yo tengo mi propia colección de "utils" que salen muy frecuentemente en cualquier programa recopiladas desde hace años (por ejemplo en web es extremadamente común necesitar temas de formateo específico de fechas, conversiones de caracteres para archivos unicode dañados, formateo de números, etc.). Unas hechas por mí y otras encontradas por la red.

Lo que siempre será un error es dar una respuesta "mantra" que valga para todo sin tener en cuenta nada más.

D

#47 "o ponerte a picar tu propia funcion quickSort() ?? "

Esas funciones están en paquetes de Python dedicados a ellos junto con miles de implementaciones y funciones, no en una librería con solo UNA función.

Menudo chiste.

Y si eres ingeniero y no reutilizas TU propia función quicksort creada en cinco minutos para futuros desarrollos y dependes de internet para la mayoría de tu código, pues olvídate.

p

#21 Se nota quien tiene experiencia y quien no, porque los que no la tienen repiten mantras como autómatas y no entienden que hay que tener flexibilidad (porque nunca se vieron en situaciones reales con restricciones de requisitos, tiempo, etc.) y saber elegir lo que más conviene en función de cada problema.

D

#1 Tienes muchísima razón, como decía mi primer jefe "si has conseguido escribirlo sin errores ya no lo vuelvas a escribir".

Ahora que, en mi opinión, una cosa es reusar código probado y otra descargarlo de un sitio remoto cada vez que lo vayas a necesitar, siempre puedes tener una o varias librería locales con las funciones que más uses y no depender de nadie o de que un iluminado le meta un día una "mejora" y mande tu aplicación ATPC.

Sofrito

#1 pero no lo llames desde el gestor de paquetes. Inclúyelo en tu proyecto y menciona la fuente. Es absurdo incluir un paquete que solo contiene unas pocas líneas.

De hecho, Github tiene una sección especial para compartir ese tipo de códigos:
https://gist.github.com

D

#51 "De todo lo que hay en Github, NPM, PyPI, Gem y similares sobra por lo menos el 60%. "

Diras NPM. En PyPi hay mucho proyecto útil.

p

#66 A mí es algo que me flipa. Cada vez que voy a meter una nueva dependencia importante en un proyecto investigo durante un tiempo considerable (si es suficientemente importante a veces me tomo una semana), viendo qué opciones hay para lo que quiero hacer y qué me lo resuelve mejor (incluyendo la facilidad de instalación y uso), más que nada porque es muy valioso no trabajar en balde y darte cuenta demasiado tarde que estás utilizando una librería de mierda que además no se entiende bien y no tiene documentación útil.
Alguna vez tuve yo mismo que corregir bugs que directamente hacían que la librería no funcionase en lo más básico, o tener que reimplementar cosas parcialmente porque lo que hacían no era ni útil ni práctico. Desde entonces miro con lupa.

Sin embargo hay gente que tira de buscador y mete la primera mierda que encuentra en los primeros cinco minutos sin pensárselo demasiado. En esto incluyo la inmensa cantidad de frameworks completamente innecesarios para cosas sin sentido (ya me los he encontrado incluso para css, cosa que sinceramente no entiendo en qué ayuda excepto que seas inepto en el tema).

Meneacer

#1 No sé nada de Javascript, pero después de leer un par de artículos me ha quedado bastante claro. Esto no es un tema de reutilización, que siempre es deseable, aunque no a cualquier precio. El problema es de gestión de dependencias a módulos externos y de definición de esos módulos.

Aquí veo tres "culpables":
1) Los diseñadores del lenguaje, por no incluir una librería estándar de manejo de strings o de arrays. Que sí, que la implementación es muy sencilla, pero precisamente por eso y porque no queremos que todos los proyectos se reinventen la rueda.

2) El que decidió publicar una función de once líneas en un sistema de gestión de paquetes, como un paquete individual y sin más código. Mejor habría sido que él o mejor un equipo de personas se hubieran planteado qué funciones básicas de manejo de strings faltan en Javascript y hubiera publicado un paquete con todas esas funciones. Depender de ese hipotético paquete tendría más sentido que de miles de paquetes cada uno con una única función.

3) Los usuarios del paquete, que inconscientes del precio que se paga al depender de un módulo externo buscaron uno para hacer un left-pad, encontraron esta birria en forma de paquete y lo incluyeron como dependencia en su código y como tenemos una herramienta maravillosa como NPM que nos descarga las dependencias nos creemos que ya está todo resuelto. La demostración de que es un error es lo que les ha pasado. Mejor les habría ido haciendo su propia librería de este código tonto, que quizá algún día podría evolucionar a un módulo externo, si como parece, existe ese hueco en Javascript.

pawer13

#1 si la reutilización conlleva añadir 50 dependencias y 1000 líneas de código en lugar de una línea de código yo me lo pensaría

D

#1 En un lado tenemos: str = leftpad (str, 10, " ")
...que llama a un bonito while empeñado en copiar la cadena una y otra vez como un imbécil

En el otro lado: str = " ".repeat(10 - str.length) + str
...sin dependencias, perfectamente optimizado

La creación de funciones, en un paquete, añadidas como dependencia, solo para sustituir media línea de código... no solo es criticable, sino que debería ser penada con latigazos.

xiobit

#17 Y en binario, nada de mariconadas de ensamblador.

D

#163 Mira que chico es el mundo hombre de 20 años de proyectos y no se que pollas , mentiroso .........


#29 #25 Pregunta: ¿cómo haces para sacar (tantos) puntos?
Lo digo porque llevo usando StackExchange desde hace más de 5 años, principalmente para buscar respuestas y de vez en cuando preguntar o responder algo, y en total apenas llego a unos 30 puntos. ¿Buscas preguntas a propósito para responderlas, o algo así?



Esta bien no me muestres tu GitHub, con eso que lei me basto .... y opinando sobre NPM ......

D

#19 Con pulsadores eso de tener una terminal es de maricones. lol

D

#17 ...y sabían sumar y restar, y usar las funciones que les daba el lenguaje.

D

#15 El problema no son tanto las librerías mínimamente serias, sino las que, como en este caso, no aportan nada que no se pueda solucionar de forma trivial en el lenguaje.

Si necesitas una librería porque no sabes que puedes usar .repeat en cualquier cadena, que las cadenas tienen un atributo .length, y que puedes sumar y restar... ¿entonces qué coño es lo que sabes?

D

El que utiliza dependencias tan alegremente es que no los está utilizando en ningún proyecto mediano ni a medio/largo plazo.

O eso, o como bien apunta #23 , que todavía les falta mucha experiencia.

Elsasu

No reutilizar es querer reinventar la rueda. Mientras que se está aprendiendo si veo sentido obligar al alumno no utilizar código de otros. Una vez se sabe hay que reutilizar todo lo posible.

Ventajas:

1. Menos código que picar.
2. Mayor estabilidad. Si la librería es conocida habrá miles de proyectos que la utilicen a diario.
3. La librería mejorará con el tiempo, ganando aún más estabilidad y rendimiento.

Elsasu

#57 Lo que si que no comprendo es tu analogía. Ahí sí, si que me pierdo.

Es cuestionable la existencia de una librería de una única función. El hecho de que la gente utilice una función de una libreria, por muy simple que sea dicha función, no es cuestionable. Es recomendable.

Por poca complejidad que tenga una función testearla ya es un dolor en el ano.

m

#80, #57 y la noticia te indica que incluso algo tan probado, perfeccionado y versátil como una rueda, no hace falta utilizarla en absolutamente todos los escenarios ya que puede ser absurdo y contraproducente.
La rueda es la mejor opción para desplazarse en la mayoría de los escenarios, pero para desplazarse del sofá al baño, te desplazas a pata.

Zade

#80 Lo mejor es cuando la rueda se pincha y el que la ha hecho, en lugar de arreglarla se larga con ella dejándote tirado a mitad de camino.

A ver, es muuuyyy simple:

- El código que necesitas se escribe en 5 minutos? Hazlo tu y mételo en una librería propia tuya bajo tu total control para poder reutilizarlo en el futuro.

- Lo que necesitas hacer te va a llevar muchísimo tiempo / es demasiado complejo para que seas capaz de hacerlo? Búscate una librería y créate esa dependencia con ella. Eso si, las librerías y todas las mierdas externas, siempre detrás de un wrapper o fachada para eliminar depender de ella en muchos puntos distintos de tu código, así como poder mockear fácilmente esa dependencia en tus test, etc...

PD: Aún así, tener siempre en cuenta la filosofía YAGNI (you aren't gonna need it), esto es, no te crees una librería genérica propia compleja que mantener para cada gilipollez que hagas. Por otro lado, esa librería super probada por millones de desarrolladores, es una bomba de relojería, si solo necesitas un caso en concreto, debes saber que las librerías no están hechas específicamente para tu caso, intentará ser lo más genérica posible, llevandote contigo un montón de mierda de código que no necesitas junto con todos sus puñeteros bugs. Por muchos usuarios que la usen y muy "crack" que sea el desarrollador, a menos que tu seas un paquetón de la hostia, lo más probable es que tu código específico para tu caso sea mucho más estable y óptimo que toda la puta librería genérica sobre la que no tienes ningún control.


ea lol

enrii.bc

#57 vaya troleada

D

#16 Si la librería es una función de un línea...

Vamos a ver, desarrolladores de JS: dejadlo.

Eso no es un gestor de paquetes, es un chiste.

D

#16 Que obsesión con lo de no reinventar la rueda. Si eso se lo aplicasen los que hacen ruedas, seguirían siendo de madera.

barni

#65 los que hacen ruedas se especializan en hacer ruedas. Los que hacen librerías se especializan en hacer librerías.

El "no reinventar la rueda" no se refiere a no volver a revisar un concepto, sino a no rehacer lo que ya está hecho (y, más importante, probado) por otro.

D

#75 Un buen coder debería tener completo conocimiento acerca de las librerías necesarias para desempeñar su trabajo diario.

Lo que diferencia a un buen coder de uno malo es la capacidad para ver si es buena o mala idea utilizar algo o reemplazarlo con otra cosa. El mal coder siempre pondrá de excusa para usar una mala librería, que es mejor eso, que el reinventar la rueda. Menos mal que hay buenos coders que no se conformarán con esa excusa de vagos e intentarán hacer una rueda mejor.

Elsasu

#65 'Reinventar la rueda', es una expresión. No hay que tomarlo literalmente.

Y créeme, hay funciones, por ejemplo funciones de ordenado o de filtrado, o en general por ejemplo toda la stl de c++, que poco margen (por no decir ninguno) de mejora tiene.

Te lo aseguro, hay funciones que antes mejoras la 'formula de la rueda' que encontrar un algoritmo que resuelva determinados problemas mejor de lo que ya hay.

Una cosa es querer hacerlo todo desde 0 porque a ti te divierta hacerla.
Otra cosa es querer ir al mundo real tm y querer hacer así las cosas. Para cuando la otra empresa ha terminado tu estás todavía testeando tus funciones primitivas.

D

#83 Yo no se si será mejorable la stl de c++ o no, pero estoy seguro que sus mantenedores no caerían en eso de "no hay que reinventar la rueda" a la hora de hacer mejores versiones si algo es mejorable.

Lo de "no reinventar la rueda" al final está teniendo unos incentivos perversos que se están viendo muy claramente en nodejs. Que cada cual haga lo que quiera, ya está bien eso de reprimir al personal para que no sea creativo y así de paso, no aprenda nada.

Elsasu

#86 Precisamente no tener a miles y miles de personas, haciendo las mismas funciones una y otra, y otra vez. Es lo que propicia la creatividad

D

#87 ¿Que creatividad?, ¿la de hacer la misma web guarra una y otra vez?.

Penetrator

#86 Reinventar la rueda porque sí es una muy mala idea. Yo estuve en un proyecto en el que se nos prohibió explícitamente usar ningún tipo de librería. Sólo podíamos usar C++ a pelo, ni siquiera la STL. ¿El resultado? Tras meses de proyecto no teníamos absolutamente nada para enseñar, pues no habíamos avanzado. Casi todo el tiempo lo habíamos invertido en crear nuestras propias clases de strings, sockets, mutex, ficheros... Y había bugs a puntapala, lo cual dificultó y ralentizó sobremanera el desarrollo posterior del propio programa. El proyecto estuvo a punto de cancelarse varias veces. Años después, los costes de mantenimiento se han disparado, pues hay bastante rotación y cada vez que entra alguien nuevo tarda semanas en poder picar código, porque antes tiene que aprenderse como funciona nuestra librería y no es intuitiva en absoluto.

Conclusión: no reinventes la rueda a no ser que sea estrictamente necesario.

barni

#16 te olvidas de un aspecto fundamental, que es el de aprovechar los recursos (tiempo, developers, dinero) para trabajar en lo que hace único un desarrollo.

Si estoy haciendo un sistema de gestión hospitalaria, el mejor uso de mi tiempo y el de mis desarrolladores no estará en escribir un left padding o un parser de csv, sinó en funcionalidades que son propias de un sistema hospitalario.

D

#16 Próximamente:

function add(a,b)

¡A reutilizar se ha dicho!
Y cuando la librería mejore... mmm... ¡la de estabilidad y rendimiento que podremos ganar! roll

M

No he comprendido nada del articulo.

Sera porque me gano la vida programando en C/C++

Y claro la std ya me viene de serie

ezain123
Wayfarer

#5 El artículo de Quartz lo explica bastante mejor; incluye todo el fondo de la discusión por la propiedad del nombre 'kik', los emails de la empresa Kik, etc.
http://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/

D

#4 hipsters programadores de node.js, volviendo a demostrar sin querer, lo mierda que es Javascript.

Libertual

#7 Es un lenguaje que mucha gente utiliza pero que pocos saben utilizar. Es un creador de inútiles que al final se acaban cambiando a otro lenguaje. Solo los ninjas sobreviven.

vickop

#13 Bueno, eso es como justificar el uso de ensamblador para hacer aplicaciones de alto nivel porque solo los ninjas tienen capacidad de estructurar su código para que al final sea mantenible.

Sé que corren ríos de bits acerca de esto y seré duramente criticado, pero me mantengo firme en que un buen lenguaje es aquel que restringe en la medida de lo posible que el programador la cague. Cosas como el tipado dinámico son aberraciones que no deberían permitir los lenguajes de programación salvo para cosas muy explícitas. Todo aquello que se pueda detectar en tiempo de compilación (aunque en determinado lenguaje no haya una compilación como tal) ahorrará problemas en la ejecución.

j

#53 No se trata de usar ensamblador para hacer aplicaciones de alto nivel.
Se trata de entender que están haciendo al escribir su código.

No creo que el problema sea javascript, creo que el problema es que muchas personas escriben código por "ensayo y error" sin entender que narices estan haciendo. Ese es el problema detrás de este artículo y desde luego estoy totalmente de acuerdo con lo que dice.

Importar módulos de una linea por no conocer como se comporta un array o como comprobar si una variable es null... es completamente estupido y reduce al absurdo todo el ecosistema.

p

#53 Aquí programador con años de experiencia y que ha rodado en C++, Java, Python, Lisp, JS, PHP, Ada, AS3 y unos cuantos más.

Los que dicen que el tipado dinámico es un problemón, no tienen experiencia en ello. Punto.

Si un programador con experiencia tiene problemas con los tipos (da igual qué lenguaje sea) o para darse cuenta de cuando metió la pata con los tipos (cosa que se ve al depurar de todas formas), lo siento mucho pero es un inútil.

Anda que no habrá problemas reales a la hora de programar que no te va a coger ningún compilador.

Ovlak

#7 por desgracia una mierda necesaria...

x

#7 Pero defienden a muerte usar librerias de otro y "snipets" fusilados de Stackoverflow...

ccguy

#4 Anda, que será en C/C++ no hay problemas con librerías
std te viene de serie pero boost no.

D

#12
std te viene de serie pero boost no.
Pero cada vez hay más funcionalidad de Boost metida en la STD. E incluso las implementaciones también.

Ovlak

#14 a lo largo de los años boost cada vez parece más un escaparate de lo que puede incluir std en la siguiente versión.

D

#12 Ya están pensando en meterla en la siguiente versión.

D

#12 Pero una buena parte boost aparece como c++14-17 .

Y por defecto C++ permite hacer mucho más que JS.

x

#26 C++ y una lavadora... Todo permite hacer mas que JS

D

#26 Un pequeño cincel te permite tanto moldear delicadas estatuillas como, si tienes mucha paciencia, cortar un árbol.

No le digas a un leñador que tu cincel puede hacer mucho más que su motosierra. Se reirá de ti y con razón.

avalancha971

#12 Jeder, he pensado lo mismo, con C/C++ a la mínima tienes que meter boost.

D

#42 boost es c++. Para C te toca espabilar.

A no ser que seas uno de esos programadores de windows que confunden C con C++... mejor no pensarlo.

avalancha971

#44 Cierto, en C glib no da para mucho

ur_quan_master

#12 Boost! esa monumental obra a mayor gloria del la complejidad absurda del diseño. Llamarla experimental es ser cariñoso con ella. ¡Vaya desproposito!

Cada vez que limpio de Boost y me cargo una docena de templates, me ahorro tiempo de compilación, tiempo de mantenimiento, tamaño del compilado y va más rápido.

D

#78 "tamaño del compilado y va más rápido. "

https://ccache.samba.org/

ur_quan_master

#82 va más rápido en runtime, pero gracias por la sugerencia

D

#94 Con ccache te ahorras tiempos de compilación.

En Linux es poner /usr/lib/ccache" en $PATH antes de la ruta normal.
en .bashrc tal que así:

export PATH=/usr/lib/ccache:$PATH

D

Programadores de Javascript enfrascados en sus tareas:

D

Reutilizar código depende de por dónde me dé y el estado de mi ego. Un estado superpuesto como en física cuántica. El mero hecho de observarlo cambia el resultado lol

r

"There’s a package called isArray that has 880,000 downloads a day, and 18 million downloads in February of 2016. It has 72 dependent NPM packages. Here’s its entire 1 line of code:

return toString.call(arr) == '[object Array]';
"

Por lo que entiendo (yo de programación muy muy poco...) el paquete "isArray" es UNA línea de código y tiene 72 dependencias? y sólo hace lo de ésa línea??? de dar True o False si es Array???? de verdad????

bewog

#41 es al revés, 72 paquetes dependen de el.

ezain123

#50 y paquetes que dependen de esos 72 ya ni te cuento.

LeDYoM

Es javascript. Aún no han aprendido

D

El problema es que cualquier mongui con un cursillo de Node en coursera se hace llamar programador (o coder, que queda más 3.0) y se popularizan engendros como todo lo relacionado con Javascript y sus malas prácticas.

D

Mi opinión es que en proyectos a corto / medio plazo es un acierto por el potencial ahorro en tiempo de desarrollo y testeo. Ideal para cárnicas y consultoras.

Ahora bien usar librerías y paquetes de terceros también requiere de cierto tiempo de aprendizaje y adquisición de hábitos para utilizarlas conforme ideó su creador.

Para proyectos internos y a largo plazo desaconsejo totalmente depender tanto de terceros. Recomiendo añadir al repositorio las dependencias, no usar módulos para cosas concretas y puntuales, preferir invertir dos días en desarrollar a dos horas para buscar e investigar... cosas de sentido común.

anxosan

Simplemente por diversión (y ver quien programa algo) yo borraría el jquery de la faz de la tierra. Se usa para todo y sobra en más de la mitad de las veces.

D

Aquí, la cantidad de módulos de los que depende jquery que cuentan con un script .
http://dustycloud.org/blog/javascript-packaging-dystopia/
#63

prejudice

#63 Yo desde que uso angular no he vuelto a necesitar de jquery. Pero llevas razón hay gente que importa la bestia de jquery para usarlo solo una vez para un carrusel o cualquier tontería

anxosan

#85 Precisamente yo me hice un carrusel para mi página y había un montón de ejemplos de gente que usaba el dichoso jquery, me pareció incomprensible.
(Yo, por no meter javascript, que no era necesario, al final lo hice solo en CSS y quedó bastante resultón y bastante ligero)

prejudice

#89 subelo a github

anxosan

#91 No lo tengo comentado y además seguro que he hecho alguna chapuza indigna; de todos modos, si quieres eres libre (tu o cualquiera) de mirarlo, adaptarlo, comentarlo y subirlo.

p

#89 jquery muchas veces no se usa por capricho, sino porque elimina diferencias entre navegadores e incorpora utilidades que ahorran mucho tiempo, además de incorporar eventos como "ready" que son básicamente imprescindibles para un comportamiento consistente.

Hoy día es menos acuciante, pero hace no muchos años era obligatorio ya que los eventos entre navegadores no eran consistentes y si no querías tener que hacer una versión específica para explorer era el camino más sencillo.

Por poder se puede hacer a pelo, pero hay una buena razón para que se utilice. Más de uno conozco que no hizo otra cosa que echar pestes durante años de jquery, hasta que lo entendió, y calló como un muerto.

También es cierto que hoy día con CSS3 se pueden hacer muchas virguerías. Yo me curré una galería de fotos 3D que queda que te cagas.

devil-bao

Si, nos hemos olvidado. En coding horror lo explican muy bien: http://blog.codinghorror.com/why-cant-programmers-program/

D

#43 Os. Os. A los que programen en C, Python, y demás, no les pasan esas cosas ni locos.

" The majority of comp sci graduates can't. I've also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution."

Wut, si esa la he hecho con Scheme

devil-bao

#46 No es algo exclusivo del mundo javascript & web, yo lo he visto con conceptos muy básicos de la informática.

D

#43 Más que "olvidado", creo que es gente que nunca ha sabido, pero que el sistema educativo no hace nada por filtrar y les deja pasar igual.

D

#71 Según lo que veo con NPM el cachondeo es tan que hay funciones para lo más básico. Y encima mal implementadas, en vez de realizar una librería con ello.

Lo que veo con JS solo lo ví en perl... con CPAN con los módulos creados para autoparodiarse con ACME:: con longitudes ridículas y funciones chorras y cortas, pero al ser clasificados automáticamente "de coña", se permiten ciertas licencias (y encima con ello aprendes a usar y empaquetar módulas para CPAN )

Por ejemplo en el módulo ACME::Eyedrops tienes estas locuras:
http://search.cpan.org/~asavige/Acme-EyeDrops-1.62/lib/Acme/EyeDrops.pm

Lo de NPM con JS es que es demencial.

D

#74 Y encima mal implementadas, en vez de realizar una librería con ello.

Lodash. Ese problema en JS está superado desde hace mucho tiempo ya. Otra cosa es que la gente ponga una dependencia de mierda que le funcionó en su día y se olvide.

Es de sentido común que un "módulo" de 11 líneas no tiene ni pies ni cabeza.

w

A mi lo que me parece curioso es esa facilidad para utilizar librerías externas de un repositorio. Es útil porque se supone que el propietario la mantiene y actualiza y "tu", te despreocupas.
Pero, sin ser programador, yo tiraría por descargar las librerías a un repositorio local (controlado) e ir actualizandolas con las, una vez probadas, oficiales.
Asi, supongo, que es bastante mas complicado que estas cosas pasen o que un cambio te reviente tu aplicacion.

Saludos

prejudice

#38 lo normal es indicar en las dependencias de tu proyecto no solo los paquetes si no la versión exacta que usa de cada paquete y testeas tu proyecto solo con esa versión. Así te despreocupas de los problemas que puedan haber en versiones futuras de tus dependencias.
Luego (una vez al año por ejemplo) puedes ver si hay actualizaciones de tus dependencias, intentar actualizar, y ver si todo va bien (tu proyecto sigue pasando los tests unitarios)

D

Aqui esta lleno de 'premio nobel' , me gustaria ver sus GitHub's ....

D

#100 Porque todo el que llama mierda a la mierda, es un "premio nobel" engreído, ¿verdad?
Supongo que tú la llamas "postre" y te la comes.

alexwing

Un día de geniales ideas del desarrollador de la librería que usas y esa función que tanto te ayudaba pasa a ser Deprecated.

Nova6K0

Es sencillo si optimizas el tiempo de desarrollo, el coste del producto (aplicación, juego,...) es mucho menor, o eso sería lo normal, porque hay cada precio que... el caso es que si todo se tuviese que hacer, sin poder usar librerías, reutilizar código, etc. Los costes se dispararían una barbaridad.

Salu2

D

Mierda, otra vez que llego tarde a la comparación de pollas

m

Creo que aquí el problema viene por como funciona NPM.

En otros casos para utilizar una librería te la descargas y la incluyes en el proyecto (un jar por ejemplo). En estos casos aunque desparezca la librería del repositorio tu proyecto sigue funcionando.

Sin embargo por lo que he entendido (no conozco NPM ni programo en javascript) el problema es que no te la bajas, la usas desde el repositorio donde está colgada (puede que la cachee, pero supongo que de vez en cuando refrescará la caché).
En este caso si desaparece del repositorio, o desaparece por completo el repositorio, entonces es cuando falla todo.

D

#31 Exacto, si "despublican" el paquete, se jodió.

cream

#31 #106 Sí se descargan

proclamo

#31 Funciona igual que maven o apt o composer o pip, etc.

C

Lo que no entiendo es que siempre actualice las librerías a la ultima versión. No se vosotros, pero yo si tengo dependencias, mis dependencias están en una versión concreta, y si esas librerías se actualizan soy yo quien testea primero y decide después si se incluyen o no.

D

#61 En npm puedes definir por cada dependencia de tu proyecto si quieres una versión fija, sólo actualizaciones de patch, de minor, de major o directamente lo último de lo último. Es responsabilidad de cada uno controlar las dependencias de su proyecto.

D

#61 En este caso lo que ha pasado es que el desarrollador directamente ha des-publicado todas las versiones.

a

Lo que desde luego no tiene ningún sentido es reescribir algo que ya esta escrito. Si el problema es que el gestor de paquetes no da las garantías necesarias (básicamente garantizar la accesibilidad y la inmutabilidad de versiones publicadas) la solución no puede pasar por reescribir o hacer copy&paste del código. Hoy copio esta función, mañana aquella otra, pasado otra más y al final termino con una montaña de código a mantener en mi proyecto por que no quiero añadir dependencias, gran idea si señor.

No vendría mal de paso entender porque en la comunidad js existe la tendencia a hacer librerías pequeñas, cuando incluyes una dependencia en js el código de esa librería lo tienes que distribuir junto con tu aplicación, esto en una app cliente js implica que el tamaño de tu aplicación aumenta, así que si hacemos una librería gigantesca con montones de funciones y luego la incluimos solo para usar un par de cosas nos llevamos la librería entera y aumentamos considerablemente el peso de nuestra aplicación. Por eso es tan habitual ver esas micro-librerías en js que pueden resultar chocantes para gente que venga de otros entornos donde realmente añadir un poco más de peso a la aplicación no es tan relevante (sobre todo el entornos servidor).

Vamos, que antes de decir que le problema es que la gente no sabe programar y yo si que soy muy listo, como hace el autor del blog, no vendría mal entender un poco mejor las motivaciones que tuvieron otros programadores para hacer las cosas así.

Profesor

#0 "Lo que me interesa aquí es que tantos paquetes adquirieran una dependencia de una simple función de relleno cadena izquierda, en lugar de tomar 2 minutos para escribir una función tan básica por sí mismos."

Precisamente se adquiere dependencia de una simple función de relleno cadena izquierda, en lugar de PERDER 2 minutos reescribiendo una función tan básica que ya han escrito miles de personas antes que tú.

D

#67

Así me gusta, que se aprenda.

Luego ya de paso importamos el módulo de la aplicación, le cambiamos un poco los iconos, instanciamos una nueva clase y a lanzarla.

Sin NPM y StackOverflow muchos estarían en el paro.

Profesor

#69 Oh, claro, todo buen programador que se precie debería diseñar su propio compilador en ensamblador, incluso su propio interprete de lenguaje si me lo permitís. Porque comprender la orientación a objetos, la instanciación, ahorrar tiempos, ser más eficiente y rentable... ¡bah, eso no tiene nada que ver con la programación!

p

#71 Entre la parida número 1 que escribiste en #67 y el extremo contrario (parida número 2 en #71) hay diferentes grados.

Los que tienen cabeza la utilizan para pensar en vez de repetir como loros lo que creen que dicen los "pros". Defender esto para un módulo de 1 línea es absurdo.

De hecho, ya puestos, hagamos un programa de millones de líneas y que cada línea sea una dependencia. Total, como ya la escribieron otros antes, así somos millones de veces más eficientes. ¿A que sí?

D

#71 " incluso su propio interprete de lenguaje si me lo permitís. "

Sí. Debería.

Al menos un intérprete de LISP.

ur_quan_master

Usando la librería adecuada te aseguras de tener la posibilidad de mejoras funcionales y de rendimiento. Más aún en lenguajes de script donde alguien puede decidir programarla en un lenguaje de verdad y llamarla mediante una interfaz.
En cuanto a la pregunta de la noticia mi opinión es que muchos scripters nunca aprendieron.

D

#3 Propongo una nueva función:

function add(a, b)

...para asegurarnos de tener la posibilidad de mejoras funcionales y de rendimiento

Rubalomen

Yo no, nunca he tenido ni jodida idea, así que...

j

Como casi siempre en informática no creo que haya una respuesta Última y Verdadera. Lo que tienes que saber es qué estás haciendo.

Una función propia sólo sabes que funciona en los casos que tú pruebes. Y nadie la va a tocar que no seas tú (o tu equipo). Una función de un paquete sabes que funciona en muchos más casos de los que tú pruebas, pero la puede tocar gente que ni conoces (y por tanto esta gente está alterando tu aplicación, sin saber nada de ella ni sus objetivos).

Ya sabiendo esto, pues que cada cual elija qué "subcontrata" y qué hace él mismo. Si tengo el código de una característica no crítica, importaré paquetes. Si tengo un código donde el rendimiento es crítico, no importaré paquetes aunque funcionen si no sé que su objetivo es ser lo más rápido posibles, por si en el futuro cambian la implementación a algo más robusto pero mucho más lento. Si no sólo el rendimiento es crítico, sino que ese es mi factor diferenciador, no me la jugaré y directamente lo haré yo sin llamar a ningún paquete, porque ahí necesito todo el control. Etc.

1 2