How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript

 ( toMpEr | 2016. március 23., szerda - 18:53 )

How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript
http://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/?mt=1458733182820

Egy másik, csodás javascript jelenség:

└─┬ 
  ├─┬ 
  │ ├── 
  │ ├─┬ 
  │ │ └── 
  │ └── 
  ├─┬ 
  │ └─┬ 
  │   └── 
  └── 

(pozitív szám ellenőrzés 9 függőséggel)

Érdemes megfigyelni, hogy az "is-positive" csomag már a 3.1.0-nál jár :)

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

"Egy másik, csodás javascript jelenség:"

ODABASZ. Nemreg olvastam egy cikket, amelyben npm statisztikakkal bizonygattak, hogy a node vilag milyen ROHAMOSAN fejlodik... Agyfasz.

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

Ez nem JS jelenség, mindenhol előfordulhat ahol külső dependencyk vannak, és azok valami automatizált módszeren keresztül kerülnek be a projektbe. Ott a composer php-nál, ott a maven javánál, amit nem ismerek, de ha jól tudom azzal se küszöbölöd ki túlzottan, ha leszedik a repót amiből töltene. Pythonnál a pypi mennyivel jobb? Stb.

Ha már valami miatt szidjuk az npm-et, az az iszonyú hülye redundancia. Ha a program amit írsz dependel A-ra és B-re, de A is dependel B-re, akkor B kétszer lesz a projektedben, lehet nem is ugyanazzal a verzióval. Na ez hülyeség.

mavenben van local cache - de mondjuk egy Travis CI-n törne a build, jah, ha eltűnik a dependency.

> Ha a program amit írsz dependel A-ra és B-re, de A is dependel B-re, akkor B kétszer lesz a projektedben, lehet nem is ugyanazzal a verzióval.
Ez pedig a java világban is probléma.
--
blogom

"The cache’s purpose is to make installing language-specific dependencies easy and fast, so everything related to tools like Bundler, pip, Composer, npm, Gradle, Maven, is what should go into the cache."

https://docs.travis-ci.com/user/caching/

npm3-nál (Node 5+) már nem így van szerencsére, ott már van annyi esze, hogy ezt megoldja, vagy legalábbis megpróbálja az ismétléseket kiküszöbölni.

A java vilagban good practice-nek tartjak maven-hez egy sajat repot uzemeltetni, es a cegek, akiknek dolgoztam eddig, ezt meg is teszik, hogy ilyen meg veletlenul sem fordulhasson elo.

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

3.1.0-nál jár...

Na bumm, elsőre (meg másodjára) nem sikerült jól

A szabad szoftveres licenszek védenek az ilyenek ellen, nem? Ha én kiadok valamit GPL alatt, akkor nem vonhatom vissza, hogy bocsika mégsem akartam, igaz? Szóval ez az NPM rendszer gyengesége, hogy a visszavonás jogát megkapja az eredeti szerző.

Persze ha eleve nem lett volna jogom kiadni, akkor más a leányzó fekvése... Akkor tényleg vissza kell vonni.

Az is-positivie csomagban két dolog vicces: először is az, hogy ennek az eldöntése nem triviális JavaScriptben. Másodszor pedig az, hogy ilyen granularitással mennek a csomagok. Egy metódus egy csomag?

Ha elolvasod, nem a kod tartalmaval, hanem a nevevel volt baj. Ha az eredeti licencelonek nincs joga a nevhez, nem is tudja licencelni. Ebben az esetben viszont a KIK jogaszok kicsit tagan ertelmeztek a nevhasznalathoz valo jogukat, az NPM meg nem akarta vallalni a balhet es leszedte.

Ami kulon jo: az NPM egy amerikai ceg, tehat nem csak ezzel, hanem mindenfele idiota vedjegyekkel is remekul lehet szivatni.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Ezóta gondolkozom azon, hogy hová vezet ha egy ügyvédnek megtanítják a google (kereső) használatát:

http://www.digitalrev.com/article/gopro-doesn-t-like-their/ODUyNjU2ODc_A

a sracnak "szerencseje" volt, hogy kitort a balhe, miutan eltorte a fel nodejs alapu internetet. kulonben ebbol is csak egy sima sikertortenet lenne a kik jogaszok naplojaban... :(

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Nem tudok JavaScriptül, és ezen nem is szeretnék változtatni. De.

Idézet a leftpad() cikkben közölt forrásából:

  while (++i < len) {
    str = ch + str;
  }

Ez hányszor másolja str tartalmát? Ugye rosszul gondolom, hogy...?!

Szerinted miért van az, hogy bármi komolyabb mai weboldaltól felizzik a cpu és üvölteni kezd a laptopventi? A "while (1);" ciklusmagra építkező programozók közöttünk vannak!

(off: C-ben így szokták a lelkes fiatal kollégák:

for (i=0; i<strlen(s); ++i)
    dosomething(s[i]);

)

Erre való a code review. Az értelmesebbje megérti és megjegyzi, ha egyszer elmagyarázod neki.

Ez nekem is feltűnt, de meg se mertem kérdezni hogy miért nem substring-gel csinál padding anyagot :D
Ilyen pici feladatnál alighanem mérési hibán belül lenne a különbség (gondolom én), úgyhogy leginkább a szemlélet zavar.

Bár pythonnál láttam, hogy sokszor az ránézésre lassabb megoldás a gyorsabb (persze az meg lehet implementációs nyomor is :D).

Régebben olvasgattam a string konkatenálásról JS alatt. Ugye a string specifikáció szerint nem módosítható objektum. Az álmoskönyv szerint a betűnkénti konkatenálás négyzetes algoritmus lesz (1etemen egyik gyakorlaton pont ez volt egy meglepő optimalizálós példa C# alatt). Felmerül a kérdés, hogy akkor hogy kell hatékonyan stringeket konkatenálni JS alatt. Kerestem StringBuilder-szerű objektumot, és meglepetésemre: nincs. Ellenben a böngészők optimalizálják a string konkatenálást valamilyen trükkös módon. Sajnos erről nem találtam leírást, hogy ez hogy működik, de valójában nem másolgatja a stringeket úgy, mint mondjuk a Java tenné. Itt van leírás a témáról: http://www.sitepoint.com/javascript-fast-string-concatenation/

Felmerül azonban a kérdés, hogy ha balról konkatenálgatunk, mint ahogy a leftpad teszi, akkor is működik-e a böngészők optimalizálása? Esetleg az egyiké működik, a másik meg belaggol? Mondjuk ezt gondolom ilyen 10-es nagyságrendű számokkal hívogatják az emberek, szóval csak kb 10-szer fog lassabban futni, mint muszáj lenne, az meg semmi. Akkor derülne ki a turpisság, ha valaki profilert venne a kezébe, de ettől szerintem a JS huszárok esetén nem kell félni. Optimalizálni nem fogják, hanem vesznek új gépet, mert a modern programok alá jár. LOL

https://jsperf.com/leftpad/8 alapján nálam (chrome) ez a gyönyörűség a nyertes (kb 2x gyorsabb, mint a csomagban szereplő while loopos megoldás):

    function leftpad4(str, len, ch) {
        if (!ch && ch !== 0) ch = ' ';
        var cnt = len - str.length;
        var pad = '';
        while (1) {
          if (cnt & 1) pad += ch;
          cnt >>= 1
          if (cnt) ch += ch;
          else break;
        }
        return pad + str;
      }

Ez is megközelíti, de a repeat támogatottsága eléggé szegényes, így nem javallott:

    function leftpad2(str, len, ch) {
      if (!ch && ch !== 0) ch = ' ';
      return ('' + ch).repeat(Math.max(0, len - str.length)) + str
    }

Valami ilyesmit képzeltem el mint a .repeat, de most hogy megnéztem hogy mi támogatja... egyre inkább megértem azokat a fejlesztőket aki a hello word-hoz is letöltik a frameworköket :(

Más kérdés hogy nem hiszem hogy ettől az jó :D

Jól értem, hogy a ciklus valahogy "duplázgatva" hozza létre a pad stringet, és ezáltal nyer egy csomó teljesítményt? Zseniális - és ezt komolyan mondom.

Totál vicces ez amúgy, mert ha belegondolunk valójában egy tömb létrehozásáról és feltöltéséről van szó. A triviális művelet nem áll rendelkezése, ezért mindenféle trükkökkel próbálkozik mindenki :-).

LOL, mekkora kókányolás.

Régóta ismert probléma, hogy ha rohadt sok külső dependencyd van, akkor elég nagy rizikót vállalsz. Éppen ezért érdemes egy mirrort üzemeltetni ezekre, ahol cacheled az eredeti forrást. Hiszen GitHubról is bármikor letörölheti valaki a repót.

Az más kérdés, hogy a JavaScript nyelv nagyon kevés eszközt ad a kezedbe, ezért rendeteg apró libre szükséged van még a legalapvetőbb dolgok megoldásához is.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

-1

Sajnos a mirror nem oldja meg ezt a problémát.

Belső projektben igen, továbbra is tudod buildelni. Viszont ha van egy nyílt projekted (lásd node.js, babel), és kihúzzák a dependencyt, akkor ennyi, más nem tudja buildelni.

Reszben igaz, de sztem egy openszosz projektnel sem baj, ha van backupod a libekrol, hogy adott esetben at tudj allni a sajat masolatodra ha kell.

En szemely szerint nem szeretem a hatalmas dependencia-erdot, csomo problemat okoz, ha a maintainer egy idiota es ossze-vissza commitol/tagel. Helyette inkabb keves, jol kivalasztott dependencia. Ilyen csipetnyi kodokat meg behuzni a sajat forrasba, es tesztet irni ra.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

JS ecosystem....van még mit tanulni.

A sok mikrolib meg csak arra való, hogy a nyelv gyengeségeit (mint például itt azt, hogy nincs egész adattípus, csak IEEE 754 duplapontosságú lebegőpontos) workaroundolja.
Poor JS.

És erre a törékeny, folyamatosan változó platformra építenek manapság egyre több mindent, nem gondolva bele abba, hogy mennyire törékeny alapokon áll az egész: a böngészők, a "szabványok" is hetente változnak, nemhogy a libek.

Amikor kompatibilitási táblázatokat kell nézegetni meg polyfilleket használni ahhoz, hogy működni tudjon az alkalmazás, az már régen rossz.

+1

+1

Az a jó, hogy az ilyen technológiákra építő cégek jó része úgyis bebukik, a maradék meg elég tőkeerős lesz kifizetni a csillagászati consulting díjakat. Vagyis nem kell félni, hogy nem lesz munkánk. /s

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

+1

Minden komolyabb rendszer összeépítésénél könnyen bele tudsz futni a dependency hell-be, ha csak nem egy platform egy szállító szisztéma és/vagy "konzervatív" szemléletű fejlesztés van. :)

Na, magyarán meg is mondtad, hogy mivel lehet elkerülni a dependency hellt. :)

google-val keresve van "left-pad" és "leftpad" csomag is. Mindkettő megszűnt? Tényleg kétszer kell megvalósítani? Vicc...

https://github.com/tmcw/leftpad

Mondjuk kiváncsacsi volnék, egy ilyen leftpad mit csinálna azzal, hogy leftpad(-21, 5, '0'). Egy kőbaltás FORTRAN vagy C azt mondaná, hogy "-0021", de hát azokat már rég meghaladtuk.

Feltételezésem szerint ezt:
00-21

Tekintve azt, hogy ez a leftpad egy stringgel dolgozik, a C-s implementáció ugye így nézne ki: printf("%05s", -21); Értelemszerűen ez nem lesz jó:
warning: format ‘%s’ expects argument of type ‘char *’, but argument 2 has type ‘int’

Akarommondani, miért várnád el, hogy felismerje azt, hogy egy számot adtál át, és azt másképp kezelje, ha a printf-től se várható el? :)

A Python közösség gyorsan reagált a kínálkozó lehetőségre (hátha át tud pár js fejlesztőt csábítani): megjelent a left-pad 0.0.3-as verziója PyPi-n. https://pypi.python.org/pypi/left-pad/ :D

(A "mezőszélesség" az valami mezőgazdasági dolog, gondolták, semmi értelme ebben az esetben, legyen a 'len' inkább a töltőkarakterek száma. Köszönjük, Emese.)

left-pad microservice: http://left-pad.io/ :)

:-)

:D

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Azóta már 'hek' a korábbi 'kik'
https://github.com/hek/hek

Na, ezért kellett a derék török kollégát b____tatni: https://www.npmjs.com/package/kik