ugrás a tartalomhoz

A Google Drive elemzése

Hidvégi Gábor · Már. 6. (K), 23.26
Nemrég felvetettem kérdéseket és problémákat a Google Drive működésével kapcsolatban, amikre szakmailag értékelhető válaszokat nem kaptam. Mivel ez az alkalmazás a kliensen fut, a kódját letöltés után elemeztem, mert érdekel, a felhasználói felület egyszerűségéhez képest miért ennyire lassú és erőforrásigényes a működése.

Adatok

A Google Drive egy teljes egészében a kliensen futó program, ami egy API-n keresztül kommunikál a Google szervereivel, ahol a feltöltött fájlokat tárolják. A minifikált forráskód mérete nem sokkal egy megabájt felett van, ami egy szépítés után 4,5 megabájtra hízik, természetesen a rövid változónevekkel, így az eredeti kód megjegyzések nélkül szerintem öt-tíz megabájt körül lehet.

A program két főmodulra épül, alul a Google API található, ez szépítve fél megabájt körül van, és alapfüggvényeket tartalmaz, amivel az API hívásokat el lehet végezni. E mellett található a Google általános rutinkönyvtára, ami egy gigantikus osztálygyűjtemény. A teljes programban összesen 25125-ször szerepel a function( karakterlánc, azaz nagyjából ennyi osztály- és metódusdeklarációval dolgoznak. Az osztályok számát ebből csak becsülni lehet, az xhr.03.js-ben (lásd alább) mindegyik egy try ... cache {} blokkban van (nem mindenhol így oldották meg), amiből így ott 4743 függvényre 239 jut, azaz egy osztálynak átlagosan nagyjából tizenkilenc metódusa van. Ez az egészre arányosítva nagyjából 1250 osztályt jelent.

A forráskódot feltöltöttem a tárhelyemre, a Google API-hoz tartozók neve értelemszerűen api-val kezdődik, az xhr-esek pedig futás közben töltődnek be, és egymásra épülő a tartalmuk. Érdekesség, hogy az adatok.json-ban (én neveztem el így) van az az adatstruktúra, ami leírja, az adott mappának mi a tartalma, valamint egyéb metaadatokat tartalmaz. Ennek a megjelenítéséhez kell a többmegabájtnyi kód.

Összetettség

Ki az, aki ezt a komplexitást képes átlátni? Több jel mutat arra, hogy ez a készítőknek sem megy, például az api.1.js és az api.4.js körülbelül 50-100 bájtban tér el (amik paraméterek, a kód megegyezik). Mivel a legtöbb metódus rövid, pár soros, nyilvánvaló, hogy az egész egy gigantikus (fordított) fastruktúrába van szervezve. Ez azt jelenti, hogy az alsó szinteken lévő osztályok/metódusok nagyon mélyen vannak, szerencsére a modern böngészők hibakeresőjében ezt vizuálisan is követhetjük:



Egy mappa megnyitásakor végeztem a mérést, a tartalmának adatai már a gépemen voltak, azaz közben nem volt hálózati forgalom. A képen megszámolható, hogy harminchét függvényhívás van egymás alatt (a tetején a két narancssárga csíkból az egyik az idősáv alatt van), és a jobb oldali görgetősáv mutatja arányaiban, hogy mennyi látszik a képernyőn. Némi számolás után kijön, hogy majdnem 140 (!) szinten egymásba ágyazott metódusláncolatot hív a program. Természetesen ez nem egyedi eset, a következő képernyőn is látszik, hogy hasonló mélységek vannak máshol is.

140.

Ezek után nem meglepő az a döntés, hogy mindent a kliensen valósítsanak meg, hisz a világ összes pénze sem lenne elég, ha a Google a saját szerverein szeretné ezt a kódot futtatni. Inkább arrogáns módon kiszervezik az egészet, azaz a felhasználóikkal fizettetik ki az infrastruktúra költségeit.

A kérdés az, hogy vajon valóban ekkora kódbázisra van szükség az adott funkciókhoz? A fenti képen látszik, hogy a mappaváltás 0,2 másodpercig tartott, ezt nagyjából lefelezhetjük, mert a teljesítménymérőnek ennyi a "többletköltsége". Ha minden információ a memóriában van, mi tart három kép megjelenítésén 0,1 másodpercig, azaz száz ezredmásodpercig? Miért van szükség ennyi függvényhívásra?

Egyéb furcsaságok

A Google Drive-ba való bejelentkezés után az egyes elemekre kattintva helyzetérzékeny menüt kapunk.



A képen láthatjuk, hogy a menü kirajzolása közben a program nyolc kérést küld el a szervernek, amiből az első öt és az utolsó három minden paraméterében megegyezik (külön-külön). Ez normális? Miért kell nyolc kérés, ha elvileg kettő elég? Miért kéne két kérés, ha eggyel is ki lehetne szolgálni, hisz sehol sincs kőbe vésve, hogy egy kérésben több válasz is érkezhet? Nem rabolok több képernyővel helyet, így a következőt csak linkelem, ami a menünyitás erőforrásfelhasználását mutatja. Egyrészt ezen is látszik, hogy több mint száz szinten vannak az osztályhívások egymásba ágyazva, másrészt van rajta a jobb oldalon egy másik zöld sáv, ami két másodperccel a menü megnyitása után fut le. A menü megnyitásakor az egyik menüpont szürke, letiltott, és két másodperc után válik kattinthatóvá – a menü minden megjelenítésekor! És ezért az egy menüpont-engedélyezéshez minden alkalommal harminc ezredmásodpercig dolgoztatja a processzort (nanoszekundumok helyett).

A kódba belenézve feltűnhet, hogy a HTML sablonok és a javascript nem különül el, így, ha bármelyik változik, az egész modult újra le kell tölteni. 2003 körül indult el az a trend, hogy válasszuk külön a működést a megjelenítéstől, akkor kezdtek el külön JS és CSS fájlokba dolgozni a fejlesztők. Most ismét keveredik a szezon a fazonnal – hova is fejlődtünk akkor az utóbbi tizenöt évben?

Emellett a nyelvi feliratok is a függvényekbe vannak helyettesítve, azok cseréjekor ugyancsak az egész modult újra kell generálni és újra le kell tölteni.

"Érdekesség", hogy az xhr.03.js-ben a következőt találjuk a 30628.sorban: "Ünnepelje a sokszínűséget és az LMBT-ket a Google-lal.". Nem igazán értem, hogy miért kell politikai üzeneteket beletenni a kódba, és ezek után kérdés, hogy hány ilyen van még benne, és minek terhelnek ezzel bárkit?

Pazarlás

A fenti számokat látva válik egyértelművé, miért tart annyi ideig a Google Drive betöltése a böngészőben: a több mint ezer osztályt és a nagyjából huszonnégyezer metódust először definiálni, majd pedig példányosítani kell a memóriában. A számítástechnikában minden egyes absztrakcióért sebességgel kell fizetni (az egyéb veszteségen felül).

Az én gépemen nyolc másodperc után használható az alkalmazás, de a múltkori mérés képernyőképén látszik, hogy tizenhat másodpercig dolgozik a négy mag. Ennek az oka valószínűleg a javascript szemétgyűjtős módszere, azaz egyrészt rengeteg objektum van a memóriában, másrészt ezek csak rövid ideig élnek, és rövid időn belül ki kell őket takarítani. A Windows feladatkezelője szerint egyébként a Google Drive körülbelül nyolcvan megabájt memóriát foglal a Chrome böngésző 63-as verziójában.

Az Androidos telefonomról letöltöttem a Google Drive alkalmazás apk fájlját, belekukkantottam, és átnéztem a tartalmát, de nem találtam nyomát annak, hogy a webes alkalmazás kódja lenne benne, hanem natív program van benne (ez persze látszik a felhasználói felületen is). Tehát a Google mérnökei számára nem volt elfogadható a webes kliens bizonyos szempontokból, így megírták még egyszer, valamint feltételezem, hogy iOS-re is külön fejlesztettek. Így három klienssel háromszoros fejlesztési és karbantartási költsége van az anyacégnek, relatíve többször annyi idő elkészíteni az egészet, ahelyett, hogy egyszer csinálták volna meg a webre jól, amit aztán mobilon webview-ban lehetne használni, és csak azt írnák meg natívan, amire valóban szükség van.

Már jóideje nem olvasok mobiltelefonteszteket, mert egyrészt nincs bennük semmi izgalmas, meg unalmas azt olvasni minden fórumban, hogy egy-két naponta tölteni kell őket, azaz az ember állandóan azon izgulhat, hogy mikor merül le, és akkor nem tudja használni az eszközt. És miért van ez? Mert olyan jellegű metodikával készülnek rájuk a szoftverek, mint a Google Drive.

Ítélet

Meg lehetett volna írni jobban? Nem kétséges. Ha egy tízelemű menü kirajzolása egy mai hardveren és modern böngészőben tizedmásodpercekben mérhető, akkor ott óriási problémák vannak. A Google mérnökei egészen biztosan dilettánsak, ha nem tudják ezt jobban megcsinálni. Az, hogy a Google Drive-nak legalább két kliensprogramja van, rengeteg plusz költséget okoznak a fejlesztői a cégnek. Ez az óriási osztálystruktúra egyrészt rengeteg memóriát igényel, nagyon kevesen látják át, és mivel egymásra épülnek a modulok, rendkívül lelassítja a fejlesztést, hogy ha egy helyen megváltoztatnak valamit, annak nagy hatása van az egészre. Továbbá, mivel a fő modulok nagyon nagyok, ha megváltoznak, a böngészőnek az egészet le kell tölteni, így valószínűleg nem túl sűrűn adnak ki hibajavításokat.

Egy mammutcégtől nem várhat az ember mást, mint egy nagy, merev szerkezetű programot, ezért ezen a területen nyugodtan lehet versenyezni velük, mert méretükből adódóan sosem fogják utólérni a konkurenciát, technológiában nem nehéz megverni őket.
 
1

Miért?

T.G · Már. 7. (Sze), 08.19
Mi értelme van ezeknek a cikkeknek? Én tényleg nem értem. Volna egy homályos üzenet, amit már évek óta át szeretnél adni. Valljuk be sikertelenül. Számtalanszor elhangzott, hogy a pozitív példa sokkal hatékonyabb lenne, de nem. Sikeres projektek lényegtelen részei szétfikázása nem fog eredményt hozni.

Ha valóban tudnál csinálni egy hatékony konkurenciát a Google Drive-nak, akkor szerintem nagyon hamar komoly támogatók állnának be mögéd. Csináld meg! Közben várhatóan olyan problémák is fel fognak merülni amelyre elsőre nem gondolnánk. Amitől az oldal lassabb lehet. Ám, ha még azután is hatékony marad a kód, akkor a projekt még sikeres lehet!

Engem nagyon meglepne, ha erre a cikkre kapnál „szakmailag értékelhető válaszokat”. Ahogy az előző is, a cikk maga nem képvisel szakmaiságot. Ehhez csak így lehet bekapcsolódni.

Amúgy legalább annyi poént megtehettél volna, hogy a http://www.hidvegi.net/gd/ oldalon elérhetővé tetted volna a szóban forgó fájlokat. Menj el marketinget tanulni! Vagy bármit, de próbálj meg hatékonyabban kommunikálni, mert ezzel csak az amúgy is komolytalan WL-t húzod tovább lefelé...
2

Sikeres projektek lényegtelen

Hidvégi Gábor · Már. 7. (Sze), 10.16
Sikeres projektek lényegtelen részei szétfikázása nem fog eredményt hozni.
Miért tartod lényegtelennek azt, hogy a sikeres Google Drive jóval erőforrásigényesebb, mint a feladathoz szükséges? Nekem miért sikerült 58 elemből megoldani, ami nekik több mint 900-ból sikerült? Ezzel hoztam pozitív példát, de mennyi az, ami elég lenne a meggyőzéshez? Elemeztem a kódot, belementem részletekbe, kérdéseket tettem fel, de eddig egy szakmailag értékelhető választ sem kaptam.

Te, Túri Gábor, mit tudsz felmutatni? Tudsz jobbat alkotni, mint a Google?

Csináld meg!
Már megcsináltam, idén fog kereskedelmi forgalomba kerülni. A betöltési idő nem nyolc másodperc, hanem 120ms.

Közben várhatóan olyan problémák is fel fognak merülni amelyre elsőre nem gondolnánk. Amitől az oldal lassabb lehet.
Szerinted egy programban lévő featúrák száma és a megjelenítés sebessége fordított arányosságban van?

Ahogy az előző is, a cikk maga nem képvisel szakmaiságot.
Miért nem? Ezt ott miért nem fejtetted ki?

elérhetővé tetted volna a szóban forgó fájlokat
Milyen fájlokat? Ott van a link az írásban. Ha el sem olvastad, akkor mi alapján mondasz véleményt, hogy mi szakmai és mi nem az?
5

működik?

Pepita · Már. 7. (Sze), 10.40
Nekem miért sikerült 58 elemből megoldani, ami nekik több mint 900-ból sikerült?
Működik? Lehet fájlokat fel- letölteni, szinkronizálni, másokkal megosztani, google sheet, google doc - csak hogy a legfontosabbakat kérdezzem.
Ezt eddig még nem láttuk.

mennyi az, ami elég lenne a meggyőzéshez?
Ami számunkra is közel azonos funkcionalitással bír és működik is, szerintem meggyőző lehetne.

Tudsz jobbat alkotni, mint a Google?
Komolyan azt gondolod, hogy csak az lehet valamirevaló fejlesztő, aki egymaga tud valami jobbat - többet, mint a gugli többezer mérnöke együttvéve?...

Már megcsináltam, idén fog kereskedelmi forgalomba kerülni.
Nagyszerű, szerintem többen is vagyunk, akik ingyen vállalnánk tesztelni a drive-odat. Elérhető valahol?

Bár most nem velem, de ismét személyeskedsz, ezzel nagyon rossz úton jársz Gábor.
8

»Nekem miért sikerült 58

Hidvégi Gábor · Már. 7. (Sze), 13.33
»Nekem miért sikerült 58 elemből megoldani, ami nekik több mint 900-ból sikerült?«
Működik? Lehet fájlokat fel- letölteni, szinkronizálni, másokkal megosztani, google sheet, google doc - csak hogy a legfontosabbakat kérdezzem.
Mintha egyáltalán nem értenéd, amit leírok. Annyit írtam, hogy ugyanazt a kinézetet én 58 HTML elemből oldottam meg, amit a Google több, mint 900-ból. Semmilyen funkcionalitásról nem volt itt szó. Ezt érted? Nem nagyon tudom, hogyan fogalmazzak, hogy átmenjen. Pusztán a HTML elemekről beszélek, amiknek az a feladata, hogy a képernyőn valamilyen grafikai elemeket jelenítsenek meg. Hogyan tudtam én huszadannyi elem segítségével megjeleníteni ugyanazt a grafikát?

Komolyan azt gondolod, hogy csak az lehet valamirevaló fejlesztő, aki egymaga tud valami jobbat - többet, mint a gugli többezer mérnöke együttvéve?
Szerinted ha többezer mérnök csinál valamit, akkor azt a problémát csak azzal a módszerrel lehet megoldani, amit ők kitaláltak? Az lesz az Egyetlen, Legjobb Út? Nincsenek alternatívák?
9

És Te érted?

Pepita · Már. 7. (Sze), 13.48
Semmilyen funkcionalitásról nem volt itt szó.
Ez a baj. Érted?
Pusztán a HTML elemekről beszélek, amiknek az a feladata, hogy a képernyőn valamilyen grafikai elemeket jelenítsenek meg.
Nem, mert közben fikázod a szerinted túl sok js / css -t is. És emellett a DOM elemek száma / struktúrája is összefügg a működéssel is. Érted?
Hogyan tudtam én huszadannyi elem segítségével megjeleníteni ugyanazt a grafikát?
Nagyon ügyes vagy, többen és többször is jeleztük már, csak sajnos nem érted, hogy a grafika egy dolog, működő szolgáltatással működő szolgáltatás tud csak versenyezni.
Szerinted ha többezer mérnök csinál valamit, akkor azt a problémát csak azzal a módszerrel lehet megoldani
Egyáltalán nem. De nem is hülyézem le őket rögtön, pláne nem próbálom meg egyedül pár nap alatt lepipálni a több éves fejlesztésüket, mert pusztán a ráfordított fejlesztési órákban sok nagyságrendnyi hátrányban vagyok. Érted?
Nincsenek alternatívák?
Biztosan vannak, de az is biztos, hogy Hidvégi Gábor egymaga nem alternatíva gugli méretű cégekkel szemben. :)
11

Ez a baj. Érted?Nem, nem

Hidvégi Gábor · Már. 7. (Sze), 14.31
Ez a baj. Érted?
Nem, nem értem. Én azt kritizáltam, hogy túl sok elemet használnak. Mivel tudod alátámasztani, hogy tévedtem?

És emellett a DOM elemek száma / struktúrája is összefügg a működéssel is. Érted?
Mivel függ össze? Milyen működéssel? Tudnál példát mondani?

a grafika egy dolog, működő szolgáltatással működő szolgáltatás tud csak versenyezni.
De én a grafikát kritizáltam. Te szalmabábként behoztad a funkcionalitást. De én a grafikáról beszéltem. Ha meg tudod indokolni a google-féle több mint 900-as elemszámot, akkor utána továbbmegyünk a funkcionalitásra. De addig kénytelen vagyok azt hinni, hogy nem érvelni jöttél ide, hanem kötözködni.

De nem is hülyézem le őket rögtön
Konkrétan hol hülyéztem le őket?

az is biztos, hogy Hidvégi Gábor egymaga nem alternatíva gugli méretű cégekkel szemben
Biztos?
16

Én azt kritizáltam, hogy túl sok elemet használnak.

Pepita · Már. 7. (Sze), 15.53
Én azt kritizáltam, hogy túl sok elemet használnak.
Akkor a többit csak én olvastam félre:
Ki az, aki ezt a komplexitást képes átlátni? Több jel mutat arra, hogy ez a készítőknek sem megy, például az api.1.js és az api.4.js körülbelül 50-100 bájtban tér el
Bárhogy próbálom html elemekre érteni, nem megy.
Némi számolás után kijön, hogy majdnem 140 (!) szinten egymásba ágyazott metódusláncolatot hív a program.
Melyik html - metódust?
Ezek után nem meglepő az a döntés, hogy mindent a kliensen valósítsanak meg, hisz a világ összes pénze sem lenne elég, ha a Google a saját szerverein szeretné ezt a kódot futtatni. Inkább arrogáns módon kiszervezik az egészet, azaz a felhasználóikkal fizettetik ki az infrastruktúra költségeit.
Nyilván itt is a html kódra gondolsz "futtatás" címszóval.
Ez normális? Miért kell nyolc kérés, ha elvileg kettő elég?
Biztos, hogy itt sem a http kérések számát tartod abnormálisnak.
Tehát a Google mérnökei számára nem volt elfogadható a webes kliens bizonyos szempontokból, így megírták még egyszer
Máskor meg az a problémád, ha ugyanazt a kódot akarják futtatni a sokkal gyengébb telón.. Ez is tisztán html element kérdés.
nem tudja használni az eszközt. És miért van ez? Mert olyan jellegű metodikával készülnek rájuk a szoftverek, mint a Google Drive.

Meg lehetett volna írni jobban? Nem kétséges.
Itt is csak és kizárólag html-t kritizálsz, én értettem félre, bocsi.
A Google mérnökei egészen biztosan dilettánsak, ha nem tudják ezt jobban megcsinálni.

Egy mammutcégtől nem várhat az ember mást, mint egy nagy, merev szerkezetű programot
Itt is természetesen html programról van szó.

---
Nos, számomra most is úgy látszik, hogy bizony keményen fikáztad az egészet.

De én a grafikát kritizáltam. Te szalmabábként behoztad a funkcionalitást.
Lécci most olvasd végig mégegyszer, amiket fentebb idéztem.

Ha meg tudod indokolni a google-féle több mint 900-as elemszámot
Nem nekem kell indokolnom, hogy miért igen, hanem neked, hogy miért nem. Te állítottad, hogy rossz.
addig kénytelen vagyok azt hinni, hogy nem érvelni jöttél ide, hanem kötözködni.
Eddig 2/2 hozzászóló gondolta úgy, hogy Te nézed túl negatívan a világot. Ha ennyi marad az össz érdeklődők száma, akkor az nem azt jelenti, hogy én kötözködöm veled, hanem azt, hogy az 50%-a vagyok a bármilyen közönségednek...

Konkrétan hol hülyéztem le őket?
Pl itt:
A Google mérnökei egészen biztosan dilettánsak

És most kérlek ne menjünk abba bele, hogy ebben a mondatban nem szerepel a "hülye" szó...
12

ismét személyeskedsz, ezzel

Hidvégi Gábor · Már. 7. (Sze), 14.50
ismét személyeskedsz, ezzel nagyon rossz úton jársz Gábor


Személyeskedés: "Egy álláspont vagy egy állítás helyességét a kijelentő személye, vélt vagy valós személyiségjegyei vagy feltételezett érdekei alapján próbáltad meg kétségbe vonni."

Ez alapján pontosan hol személyeskedek, tudnál idézni? Jó lenne, ha ezt tisztáznánk, mert különben kénytelen vagyok azt hinni, hogy te pedig lejáratni próbálsz engem.
18

Igen

Pepita · Már. 7. (Sze), 16.17
Te, Túri Gábor, mit tudsz felmutatni? Tudsz jobbat alkotni, mint a Google?


SZERK.:
különben kénytelen vagyok azt hinni, hogy te pedig lejáratni próbálsz engem
Én nem politizálok, vagy nem itt. :)
Vicc nélkül: személyesen veled semmi problémám nincs, a nézőpontod, érvek nélküli érvelésed helytelen.
Ahogy TG is jelezte: pozitív példákkal és hozzáállással sokkal többre mennél.
Emellett ha felvetődik valakinek valamilyen konkrét szakmai problémája, abban készséggel segítesz, ez tök jó, ezt a fajta fikázós - lenézős dolgot kéne valahogy egészen másképp, vagy nem- csinálni.
7

Én kérek elnézést!

T.G · Már. 7. (Sze), 13.27
Én kérek elnézést! Tényleg sikerült bebizonyítanod, hogy remek sitebuilder vagy… csak… mintha nem erről szólna a cikked, hanem a teljes projekted fikázod. Poénból menj el egy befektetőhöz és mutasd meg neki! Azt fogja mondani, hogy nagyon jó, meg hogy ügyes vagy. De ez így édeskevés. Ez senkit semmiről nem győzhet meg. Legfeljebb sitebuilder álláshoz referencia, bár szerintem oda is kevés. Ha látjuk, hogy működés közben is minden oké, akkor mondhatjuk rá, hogy minden oké.

Nem értem, hogy a mit tettem én le az asztalra hogy jön ide? Biztatlak, hogy valamit tegyél te az asztalra, de ezt csak akkor tehetem, ha már valamit én is letettem?
Én nem fikáztam annyit, szerintem ennyivel előrébb vagyok! :)
Anno írtam cikkeket, amelyeknél pont az volt a lényeg, hogy megnéztem eszközöket, majd amelyek tetszettek, azokról írtam egy ajánlást. Pozitív üzenetek! Tényleg ajánlom neked is! Az én világmegváltási igényemnek ennyi pont megfelelt. Igaz nekem annyival könnyebb, hogy én nem érzem azt a frusztrációt, hogy mindenki szembe megy velem az autópályán…

Amúgy tényleg hihetetlen destruktív tudsz lenni, miközben pont ezt kifogásolod. Elolvastam a cikket, emiatt tudom, hogy vannak fájlok, ám ha már egy mappa megjelenítő mintaoldalt csinálsz, akkor szerintem ötletes lenne összekötni a kettőt. De persze mit pofázok én bele…
10

Biztatlak, hogy valamit

Hidvégi Gábor · Már. 7. (Sze), 14.19
Biztatlak, hogy valamit tegyél te az asztalra, de ezt csak akkor tehetem, ha már valamit én is letettem?
Számonkérted tőlem a szakmaiságot, én pedig kíváncsi vagyok rá, hogy te mi alapján szeretnél engem elbírálni.

Pozitív üzenetek! Tényleg ajánlom neked is!
Köszönöm, bár, ha elolvastad ezt az írást, teljesen pozitív a végkicsengése. Egyébként miért hagytad abba?

Igaz nekem annyival könnyebb, hogy én nem érzem azt a frusztrációt, hogy mindenki szembe megy velem az autópályán…
Úgy is fogalmazhattál volna, hogy "én nem érzem azt a frusztrációt, mert együtt megyek a nyájjal" : )

Képzeld el, hol tartana a világ, ha nem lett volna majom, aki ne unta volna meg a banánt. Inkább azt gondolta volna, hogy "inkább megeszem ezt a banánt, így nem érzem azt a frusztrációt, hogy mindenki szembe megy velem az autópályán".

Vagy mondjuk a középkorban Kolumbusz azt mondja, hogy "inkább hiszem azt, hogy a Föld lapos, így nem érzem azt a frusztrációt, hogy mindenki szembe megy velem az autópályán".

És nem lesz a legtöbb másképp gondolkodóból Kolumbusz, sokan leesnek a világ széléről. De ha senki sem indul el Nyugat felé, mert az autópályák kelet fele visznek, akkor sosem fedezzük fel az Új Világot.

---

És még mindig érdekel, hogy mi és hol nem szakmai szerinted abban, amit leírtam.
13

Szakmaiatlanság

T.G · Már. 7. (Sze), 14.52
Ha valamit fikázol, miközben látszódik, hogy a problémakör felületét is csak éppen hogy megkapirgáltad, akkor az szakmaiatlanság. Hozhatok példákat, de attól még nem tudom jobban megfogalmazni, hogy amit bemutattál az semmit sem bizonyít. És mivel ebből olyan messzemenő következtetéseket levonsz, hogy „az irány egyértelműen rossz”, arra tényleg csak azt lehet mondani, hogy mindez nélkülözi a szakmaiságot.

Viszont itt érzek egy zsákutcát, számomra az előbbiek evidensnek tűnnek. Ezzel szemben viszont te úgy látod, hogy megfogalmaztad a lényeget és minden más csak mellébeszélés. Itt most nem látom a kompromisszumos köztes verziót.

Szerintem ez olyan, mintha azt néznénk, hogy a roller vagy a repülőgép a jobb? A rollerrel sokkal gyorsabban át tudok menni a szomszédhoz. Ráadásul még olcsóbb is. Így hát mindenki hülye, aki bármire is használná a repülőgépet. Főleg a Google, mert őket trendi szidni. Ne hidd azt, hogy a Google szidásával nem tartozol semmilyen nyájhoz. És, ha már választani lehet, akkor szívesebben tartozok a technikai újdonságok iránt fogékonyak csoportjához, mint az utáljuk együtt az XY-ékat csoporthoz. Ám visszatérve a példádhoz, egy statikus html oldalt hasonlítasz össze egy olyan oldallal, ahol közel valós időben változik a tartalom. Nulla jelentősége van, hogy hány div-ből épült fel, nem ezen múlik a sebesség. Szerintem a felhasználói élmény javításához nem a div-ek számát kell csökkenteni.

Különben olyan érzésem van, mint amikor egyesek politikáról vitatkoznak. Mindenki hisz a saját igazában, mondja a saját hülyeségét, majd nem érti, hogy a másik miért nem érti és elmondja ismét ugyanazt. Kicsit más köntösbe, de lényegében semmi újat nem hozzáadva. Szerintem ezek a beszélgetések sem tudnak kilépni ebből a hibából...
14

Szakmaiság

Hidvégi Gábor · Már. 7. (Sze), 15.04
Pedig nagyon örülnék a példáknak, mert azzal alá is tudnád támasztani az állításaidat. Lehet, hogy igazad van, de ezt anélkül, hogy a te álláspontodat ismernénk, nem lehet megállapítani.

Ezzel szemben viszont te úgy látod, hogy megfogalmaztad a lényeget és minden más csak mellébeszélés.
Ezt mi alapján állítod? Tudnál idézni?

Ám visszatérve a példádhoz, egy statikus html oldalt hasonlítasz össze egy olyan oldallal, ahol közel valós időben változik a tartalom. Nulla jelentősége van, hogy hány div-ből épült fel, nem ezen múlik a sebesség.
Nem, én azt hasonlítottam össze, hogy ugyanazt a grafikát én hány elemből készítettem el, és ezt vetettem össze a Google-éval, akiknek ugyanehhez hússzor annyi kellett. A funkcionalitás ezt nem támasztotta alá (ha egyszer kattintasz az elemre, nem történik semmi, ha kétszer, akkor pedig új tartalmat jelenít meg a program), ráadásul, ha az ember megnézi a kódot, bizonyos elemek kétszer vannak benne, például a mappák ikonját tartó div.

És igenis számít, hogy hány elemből áll egy blokk, mert ha valamihez hússzor annyit használnak fel, amennyi kell, ahhoz a szükséges többszörösét kell dolgozni.

És ha a szükségesnél több elemet használnak fel, akkor mi garantálja, hogy más munkafázisoknál sem bánnak pazarlóan?

Ebben az elemzésemben pedig rámutatok, hogy nem egyedi eset, hogy valamit többször csinálnak meg feleslegesen, például ugyanazt a javascript kódot többször töltik be, ugyanazt a kérést elindítják nyolcszor stb.

Ezek mind egy mintázatot mutatnak, amiből lehet következtetéseket levonni.
15

Álláspont

T.G · Már. 7. (Sze), 15.48
Az én álláspontom egyszerű. Semmi értelme indokolatlanul fikázni sikeres projekteket. És hiba a lényegtelen részeket kiemelni és azokat fikázni. Kb. ezzel kezdtem.
Ám nekem elfogytak az érveim. Én azt mondom, hogy elsősorban nem a divek számával kell spórolni, te azt, hogy igen. Közben látunk egy sikeres példát, ahol nem a html méretén spóroltak és látunk egy mintaoldalt, ahol a működés nem lett elkészítve. Szerintem ez összehasonlíthatatlan. Ez ebben a formában már hitvita, mindenki azt lát bele, amit szeretne. Én speciel azt, hogy nem működik a mintaoldal. Nincs mit elemezni ezen.
19

Igen, ezzel kezdted, de nem

Hidvégi Gábor · Már. 7. (Sze), 17.16
Igen, ezzel kezdted, de nem támasztottad alá semmivel, hogy miért lényegtelen például a sebesség vagy az, hogy mekkora a letöltött kódméret.

Én ezzel szemben leírtam, hogy miért fontos vele foglalkozni: mert mobilon egyrészt korlátozott az akkumulátorok kapacitása, másrészt korlátozott lehet a mobilnet.

Az, hogy a Google Drive pénzügyi szempontból sikeres, technológiai szempontból teljesen irreleváns. A weblabor egy szakmai portál, és nem is értem, hogy miért ne lehetne szakmailag kritizálni őket? Ez hülye érv.

Ám nekem elfogytak az érveim.
Még egy szakmai érvet sem láttam tőled.

Én azt mondom, hogy elsősorban nem a divek számával kell spórolni, te azt, hogy igen.
Én ilyet sehol sem állítottam.
21

magadnak mondasz ellen,

Pepita · Már. 7. (Sze), 18.40
ezért tűnik inkább politikai megmozdulásnak.

mert mobilon egyrészt korlátozott az akkumulátorok kapacitása, másrészt korlátozott lehet a mobilnet.
Másik hozzászólásodban meg azt kritizálod, hogy miért írnak mobilra natív appot a (asztali) böngészős cucc helyett.

Most akkor az sem jó, ha mobilra van arra optimalizált megoldás és az sem, ha ugyanaz fut mobilon is?

Az, hogy a Google Drive pénzügyi szempontból sikeres, technológiai szempontból teljesen irreleváns.
Technológia (szakmai) szempontok közé számold bele légyszi azt is, hogy sokan használják és meg vannak vele elégedve. Ez a mi szakmánkban rendkívül fontos.
24

Ártatlanság vélelme

T.G · Már. 7. (Sze), 19.11
Bocsánat, az ártatlanság vélelme megilleti a Drive-ot is. Szerintem az egy kifejezetten jól működő alkalmazás, amire te olyan súlyos vádakat hoztál fel, ami szerintem szakmaiatlan. Tehát elsősorban az indoklás onnan hiányzik, hogy miért gondolnánk azt, hogy „A Google mérnökei egészen biztosan dilettánsak”, és miért mondanánk rá, hogy „az irány egyértelműen rossz”. Attól mert hosszan írtál még nem jelenti azt, hogy alá is támasztottál bármit. Erre hoztam én fel, hogy lényegtelen részek kiemelésével szeretnéd igazolni az állításodat. Mivel szerintem ezek az összehasonlítások nem a lényegről szólnak, így nem is tudnak igazolni semmit sem. Erre most mit vársz, milyen szakmai érvet hozzak fel? Szakmai érvem: az egész elemzésből hiányzik az az alap, amit érdemes lenne összehasonlítani!

Én azt mondom, hogy a html mérete nem lehet elsődleges. Nem azon kell spórolni. Amit te úgy kódoltál le magadnak, hogy szerintem a sebesség nem lényeges. Ugye abban egyetértünk, hogy ez a következtetés igencsak téves? Jóhiszeműen csak egyszerűn tévesnek nevezem, de talán szándékos csúsztatásnak is nevezhetnénk?
De, akkor mégegyszer. A teljes projektben a sebesség nagyon sok szempont alapján alakul. Ebből a nagyon sok szempontból a html mérete egy elenyésző egység. Legtöbb esetben egy SPA optimalizálás nem a html méreténél kezdődik. Ebben egyetértünk, vagy ezzel sem?

Viszont te mást nem hasonlítottál össze. Csak a html méretét. Amikor arról írsz, hogy az eredeti 900 elem helyett 58-ból sikerült megalkotnod ugyanazt, akkor nem azért írtad ezt, mert szerinted ez egy követendő hozzáállás? Nem azért írtad, hogy jó az, ha az elemek számát minimalizáljuk? Más szavakkal, hogy a divek számával spórolni kellene? Nem igazán értem, hogy miért kérdezel vissza, hogy hol állítottál ilyet? Nem erről szól a minta oldalad? Az általad készített összehasonlítás nem erről szól, hogy ha meg lehet csinálni kevesebb html elemből, akkor szerinted azt kevesebb elemből kell megcsinálni? Vagy valamit akkor nagyon félreértettem. :)
29

Félreérted

Hidvégi Gábor · Már. 7. (Sze), 21.02
Vagy valamit akkor nagyon félreértettem. :)
Hát persze.

Súlyos vádakat hoztam fel, és ezt meg is indokoltam, ha olvastad az írást, akkor találkoztál is vele. De szívesen megismétlem a kedvedért: a fő ellenérvem az, hogy a Google Drive-nak legalább két kliensprogramja van, egy webes és egy Androidos, és a kettő nem ugyanazt a kódbázist használja.

Ez azt jelenti, hogy a webre leprogramozott kliens nem alkalmas mobilon való használatra, pedig ma már minden technológia adott ahhoz, hogy böngésző alapú, offline is működő mobilos alkalmazásokat készítsünk.

Én azt mondom, hogy a html mérete nem lehet elsődleges.
Látom, ezt nagyon nem tudod megérteni. A HTML mérete önmagában indifferens.

Ha a képernyőn ugyanazt a kinézetet huszadannyi HTML elemből is meg lehet valósítani, akkor az azt jelenti, hogy húszból tizenkilenc elem nem látszik. Akkor jön a kérdés, hogy ha egy elem nem látszik, akkor miért kerül legenerálásra? Hússzor annyi elem legenerálása hússzor annyi munkát ad a processzornak, de miért is jó ez, ha ennek csak az egyhuszada látszik? Ráadásul az egésznek a sablonját is jóval több munka létrehozni.

A teljes projektben a sebesség nagyon sok szempont alapján alakul. Ebből a nagyon sok szempontból a html mérete egy elenyésző egység.
Ezt kifejthetnéd, mert nem világos számomra, miért gondolod így! Kíváncsi vagyok a szempontokra, és arra is, hogy te hogy látod, mik sebesség szempontjából a fő egységek.

Legtöbb esetben egy SPA optimalizálás nem a html méreténél kezdődik. Ebben egyetértünk, vagy ezzel sem?
Ebben is érdekelnének a tapasztalataid, és utána tudom megmondani, hogy mivel értek egyet és mivel nem.

Nem azért írtad, hogy jó az, ha az elemek számát minimalizáljuk? Más szavakkal, hogy a divek számával spórolni kellene?
Spórolni? Nem értem ezt a szót ebben a kontextusban. Ha valamit meg lehet oldani egy elemmel, akkor miért használna bárki is kettőt?

Az általad készített összehasonlítás nem erről szól, hogy ha meg lehet csinálni kevesebb html elemből, akkor szerinted azt kevesebb elemből kell megcsinálni?
Nem, nem kell úgy csinálni semmit, ahogy én elképzelem. Mindenki úgy dolgozik, ahogy neki jól esik, mert mindenkinek szabad akarata van. De ha például a szükségesnél hússzor több elemmel valósít meg egy megoldást, akkor azt kritizálni fogom. Hússzor több elem hússzor több erőforrást igényel, és ezt pazarlásnak tartom.

Lehet, hogy az én kódomon is lehet javítani. Ha így van, akkor megteszem.
31

Az én verzióm

T.G · Már. 7. (Sze), 21.42
Oké, akkor amit én helyesnek tartok: mivel egy SPA alkalmazást hosszabb ideig használnak, így a hangsúlyt nem az első 2-3 másodpercre tesszük, hanem a későbbi működésre. Innentől kezdve teljesen indifferens, hogy 200k-s vagy 1M-s JavaScript indul el. Ha 10 percet töltesz el az oldalon, akkor az első 2-3 másodpercet észre sem veszed. Az összbenyomást nem ez fogja meghatározni.

Több helyen kimutatták már, de ajánlom, hogy akkor vizsgáld meg ezt is: Sokkal gyorsabb egy dom-ben lévő elemet megjeleníti, majd eltüntetni, mint a dom-ba betenni, majd kivenni egy elemet. Elején bekerül, további 1 másodperc az elején, majd a következő 10 percben minden gyorsabb lesz.

És valójában a megás js fájl betöltése sem 2 másodperc, 900 html elem felépítése nem fogja meg a procit, az ügyfél észre sem veszi, hogy a kezdőképhez képest mik történtek a háttérben. Én nem ismerem a Drive felépítést, nem tudom, hogy miért kell az ikonnak két div, ahogy írtad. De, hogy ebből lekövetkeztetni, hogy biztos dilletáns a készítő azt erős túlzásnak érzem.

A működés sebessége nem függ a html dom méretétől. A beszúrás és törlés költségesebb, mint a nem megjelenítés. Ám itt sem egyértelmű a kép, irreálisan hosszú html nem jó. Ez is igaz. Persze. De nem 900 elemnél kezdődnek el a gondok!

Optimalizáláskor például megnézhetjük az Ajax hívások gyakoriságának szükségességét. Cachelhetünk-e bármit is? Igen, még több infó a memóriába. Össze lehet-e vonni Ajax hívásokat, vagy adott esetben ketté lehet-e szedni, ha az úgy jobb? Az eseménykezelésen hihetetlen sokat lehet agyalni. A konténer elem kapja el a kattintást és utána vizsgáljuk, hogy mely elemre kattintottak, vagy minden elem kapjon önálló kattintás eseményt? Nagy elemszámnál ez sokat tud segíteni. Adott esetben a kód egyszerűsítéséhez is vezethet, ami egyéb okból lehet hasznos. Én minden egyes képet összenyomok, amennyire csak lehet. Túl magas labda, de nem bírom nem lecsapni. A minta oldalon ez kimaradt, például az ikon_listanezet.gif esetén a 1318 bájt helyett elegendő lenne 93 bájt. Úristen, vajon a honlap további része is ennyire pazarló??? 14-szeres a különbség!!! Igen, pontosan tudom, hogy sikerült kiemelnem egy totál lényegtelen részt, de szeretném a hasonlóságot hangsúlyozni!
41

Gyorsaság

Hidvégi Gábor · Már. 8. (Cs), 11.01
Sokkal gyorsabb egy dom-ben lévő elemet megjeleníti, majd eltüntetni, mint a dom-ba betenni, majd kivenni egy elemet.
Ez így van, aláírom.

De mi van akkor, ha az illető nem fog az elemmel interakcióba lépni? Például nem kattint rá, mert nem érdekli a tartalma. Akkor miért generálnék le előre bármit is?

Erre annál nagyobb az esély, minél több elem van az oldalon. Ugyanis két eset lehetséges: vagy csak bizonyos logikai elemekkel fog dolgozni (a Drive-ra levetítve: mappákkal, fájlokkal), vagy minddel. Ez utóbbi esetben tudunk csoportműveleteket létrehozni, például az összes fájl letöltése egyben. Tehát az esetek többségében nem fog semmit sem csinálni az elemek egy részével.

Végeztem egy mérést, egy saját oldalamon egy negyven elemből álló dialógusablak legenerálása alkalmazáslogikával, sablonozással együtt 10ms az Atomos gépemen. Úgy gondolom, hogy ez jó viszonyítási szám.

Megnéztem, a Google Drive-on a mappa ikonjához 30 elemet használtak fel (nekem 3-ból sikerült ugyanaz). Tegyük fel, hogy tényleg mind a harmincra szükség van; mennyiből tartott volna nekik is három elemet legenerálni az elején, és a harmincat akkor, ha valaki interakcióba lép vele?

Az átlagember reakcióideje egytized másodpercnél kezdődik, ami 100 ms. Gyakorlatilag senki sem venné észre, ha a három elemből álló elemet lecserélnénk a harmincasra.

Ez is egy járható út. Így az eredeti 14x30=420 helyett 14x3=42 elem elkészítése is elég lett volna. Sok kicsi sokra megy.

Hány helyen lehetett volna még hasonlóan spórolni?

Ugyancsak emberi tényező, hogy nem vagyunk gépek, azaz nem folyamatosan gépelünk, kattintgatunk, hanem közben gondolkodunk, megiszunk egy kávét, azaz rengeteg a holtidő.

Ha már nagyon előre be akarunk tölteni mindent a memóriába (aminek én személy szerint nem látom sok értelmét, de a vita kedvéért tegyük fel, hogy így jó), miért nem lehet például ezekben a holtidőkben ezt a betöltötetést elvégezni?

Én rendkívül kicsi esélyét látom annak, hogy valaki egyszerre szeretne térképet nézni, közben excel táblát és word dokumentumot tervezni. Ezt egyébként nagyon jól lehet mérni. Szóval érdemes-e mindent előre betölteni és inicializálni, ha nincs rá valós szükséglet?
47

Következik-e ebből bármi?

T.G · Már. 8. (Cs), 13.29
Következik-e ebből bármi? Meglehet írni másként. Hurrá. De miért gondoljuk, hogy az jobb lenne? Gyorsabb? Vagy akár lassabb? Van megfelelő összehasonlításunk? Sajnos nincs, így nem tudhatjuk. Ennél többet nem lehet erről az elemzésről elmondani.
50

Nem értem

Hidvégi Gábor · Már. 8. (Cs), 14.12
Nem igazán értem az érvelésed. Ha valamit tizedannyi munkával el lehet végezni és tizedannyi lesz a kimenete, arról nem tudod megállapítani egyértelműen, hogy gyorsabb lesz vagy lassabb?

Írtál lentebb egy példát. Ha abban a quantity értékét 100-ról 10-re csökkentem, akkor gyorsabb vagy lassabb lesz a futás? Nem tudod?
52

Persze, hogy nem.

T.G · Már. 8. (Cs), 14.21
Ha a feladat első 1 százalékát tized annyi idő alatt elvégezted, akkor abból miért következne, hogy a maradék 99 is gyorsabban végzed el? Az egész eszmefuttatásom erről szól, hogy amit te mintaként bemutattál az nagyon kevés. Ennyi adatból nem szabad messzemenő következtetést levonni.
54

Kérdés

Hidvégi Gábor · Már. 8. (Cs), 14.27
Ha valaki egy feladat egy százalékát tízszer-hússzor annyi munkával oldja meg, mint amennyi szükséges, akkor abból miért következne, hogy a maradék 99-et becsületesen – eskü! –, a szükséges minimális munkával végezte el?
56

Talán mert például előre gondolkodnak?

T.G · Már. 8. (Cs), 14.39
Szerinted a cache jó dolog? Ha csak egyszer hívjuk meg az adott részt, akkor a cache hátrány, ha sokszor, akkor előny.
57

Konkrétumok

Hidvégi Gábor · Már. 8. (Cs), 15.21
Ez a cache-dolog valami konkrétum vagy megérzés? Én konkrét kérdéseket tettem fel, tudnál-e válaszolni azokra? Mint egy kígyó kisiklasz minden konkrét válaszadás alól, így nehéz veled vitatkozni bármiről is.

Ha nem tudsz választ adni, akkor inkább ne írj semmit.

---

Ezt az előre gondolkodást nem értem, és erre kérdeztem rá a 41-es hozzászólásban: honnét tudod, hogy azt a bizonyos dolgot fogják-e használni? Miért kell előre legenerálni, miért nem lehet akkor, amikor szükség van rá? Miért és mi alapján végeznek el előre munkát?

De a vita kedvéért tegyük fel, hogy igazad van, és a gyorstárazás miatt generálnak le előre bizonyos html kódrészleteket. Hol van a határ? Mi az, amit előre le kell generálni, és mi az, amit nem? Ha pl. egy excel tábla van a könyvtárban, akkor az ahhoz szükséges szerkesztőfelületet miért nem generálják le? Mert én erre nem találtam nyomot a html kódban. Hisz sokkal gyorsabban meg lehetne így nyitni ezt a fájlt. Ha egy word doksi is van a könyvtárban, annak a szerkesztőfelületét miért nem generálják le előre?
59

Szerepcsere?

T.G · Már. 8. (Cs), 16.04
Tele van az egész beszélgetés érvelési hibákkal, maga a témafelvetés is egy hatalmas érvelési hiba. Egy lényegtelen rész hibájából következtetsz arra, hogy az egész hibás. Vagyis hogy pontosan idézek, szerinted az következik ebből, hogy „az irány egyértelműen rossz”.

Én azt állítom, hogy az "elemzésed" kevés ahhoz, hogy ilyen szintű vádakat megfogalmazzál. Ebben a felállásban nem nekem kellene bizonyítanom, hogy a Google Drive kódja jól van megírva, hanem neked kellene, hogy rosszul.

Nem megyek bele abba a hibába, hogy megvédjem a Drive kódját, amikor azt én nem ismerem. Én csupán a te irományodat látom, és abból azt szűrőm le, hogy a megfogalmazott vádaskodásaidnak nincsen alapja.
60

Lényegtelen

Hidvégi Gábor · Már. 8. (Cs), 16.15
Ha szerinted lényegtelen, akkor igazából nem értem, hogy miért túráztatod itt magad. Ha úgy gondolod, hogy csak egy részt kritizáltam, akkor feltételezem, hogy nem olvastad az irományt, így pedig nehéz bármiről is vitatkozni veled (az általam feltett kérdésekre várt konkrét válaszok hiányán kívül).

Én úgy gondolom, hogy lényeges, amiket felhoztam.

Örülök, hogy erre jártál, és várom a pozitív kicsengésű írásaidat!
61

Ez tényleg félreértés.

T.G · Már. 8. (Cs), 17.05
Ez tényleg félreértés. Én sosem írta azt, hogy én megvizsgáltam a Drive kódját. Így a konkrét kérdéseket azzal kapcsolatba hiába teszed fel. Nem tudom, hogy mikor, mit optimalizáltak? Azt sem, hogy mit szerettek volna. A leírtak alapján az az érzésem, hogy te sem nézted át alaposan, de ezt persze nem tudhatom...

Én azt állítom, hogy fikázod az egészet, de csak egy kis részét tudtad megvizsgálni. De ezt nem szabad érdemként feltüntetned! :-) Az összehasonlítás, amire hivatkozol az a teljes Drive funkcionalitásának egy elenyésző része. Egy lényegtelen hányada. Az becsülendő, hogy szerinted lényeges rész, de nem az.
32

Költséghatékonyság?

T.G · Már. 7. (Sze), 21.48
Illetve, ami még kimaradt. A Google egy gazdaságilag sikeres cég, így megengedheti magának, hogy egy-egy alkalmazást a különböző platformokra önállóan elkészítsenek, ha az úgy hatékony. Én használtam Android-on WebView-t, elégedett is voltam vele. De elfogadom azt az álláspontot, hogy a natív verzió szebb, jobb, gyorsabb. Pontosan miért is dilletáns az, ha valaki megteheti, hogy több munkával a jobb verziót csinálja? Ha egyedül dolgozol, akkor használj WebView, ha viszont sok programozód van, akkor használd azt a verziót, ami az adott esetben jobb. Nem dilletanizmus az, ha valaki az egyiket vagy a másikat használja. Ebből bármilyen következtetést levonni szerintem butaság.
44

Alternatíva

Hidvégi Gábor · Már. 8. (Cs), 12.44
És abból, hogy a Google legalább két kliensprogramot írt a Drive-hoz, következik-e az, hogy a webes klienst – más módon, persze – nem lehet megírni ugyanolyan gyorsra és kényelmesre, mint a natívat?
48

Semmi nem következik ebből...

T.G · Már. 8. (Cs), 13.29
Mivel semmi infónk semmiről, így elmondható, hogy semmi nem következik semmiből. És ez igaz a teljes cikkre is, illetve annak a végére is. Ezt hangsúlyozom egy ideje, hogy alaptalan az ítéleted.
53

Információ

Hidvégi Gábor · Már. 8. (Cs), 14.22
Mármint milyen információra lenne szükséged ahhoz, hogy a fenti egyszerű kérdésre válaszolj?
55

Miért mit tudunk? :)

T.G · Már. 8. (Cs), 14.32
Még azt sem tudjuk, hogy mi a program specifikációja. Nem tudjuk, hogy pontosan miket csinál a program. Mennyire összetett az a rész, amely nem a felületre vonatkozik? Merthogy az Android verzió is ugyanúgy figyeli a megadott mappát. Miért gondoljuk, hogy ugyanúgy http kérésekkel kéri le a tartalmat, miközben ott van kéznél egy mappa, amely tartalmazza a szinkronizált fájlokat. Nem tudjuk, hogy mik voltak az elvárások. Van egyáltalán bármi amit tudunk? Azon túl, hogy neked nem tetszik? És azt, hogy nekem pedig igen? Szerintem egyáltalán nincsen.
58

Miért gondoljuk, hogy

Hidvégi Gábor · Már. 8. (Cs), 15.26
Miért gondoljuk, hogy ugyanúgy http kérésekkel kéri le a tartalmat, miközben ott van kéznél egy mappa, amely tartalmazza a szinkronizált fájlokat.
Honnan tudod, hogy ez a mappa valóban szinkronizálva van-e, és nincs azóta újabb verzió a szerveren? Miért érdemes két protokollt elkészíteni, egyet a webes, egyet pedig az androidos kliensnek, ha meg lehet ezt oldani eggyel is? Érdemes-e egy protokoll miatt egy mobilos klienst kifejleszteni?
3

90%-ban egyetértek

Pepita · Már. 7. (Sze), 10.30
Annyi különbséggel, hogy szerintem többször is kapott „szakmailag értékelhető válaszokat”, csak sajnos nem tudta értékelni.
Konkrétan a drive-al kapcsolatban is, többször elhangzott az is, amit javasolsz ("Csináld meg!"), de ami nem az elképzeléseit támasztja alá, abba vagy bele köt, ahol tud, vagy egyszerűen figyelmen kívül hagyja..
Szerintem a legnagyobb probléma a nézőpont / hozzáállás.

"Tegyük fel, hogy jó ez az irány, de hogyan lehet még optimalizálni?"
vs
"Ez így biztos, hogy szar és én egyedül is százszor jobbat csinálok."

Azt gondolom, az első lényegesen egészségesebb és azon az úton jóval több "szakmailag értékelhető" választ lehet kapni.
4

Nem érted

Hidvégi Gábor · Már. 7. (Sze), 10.34
Akkor nem ment át az üzenet. Ezzel az elemzéssel arra mutattam rá, hogy az irány egyértelműen rossz.
6

De, értem

Pepita · Már. 7. (Sze), 10.43
Évek óta ugyanez az üzenet, csak a "kiválasztott" szolgáltatók mások. Ahogy TG is írta: menj nyugodtan a másik irányba, mutasd meg. Ha valóban neked van igazad, és mindenki más hülye hozzá, akkor valószínűleg meggazdagszol. :)
17

Hogyan tovább?

Endyl · Már. 7. (Sze), 15.59
Sajnálatos, hogy az írás végén csak egy ítélet van, nem pedig megválaszolható kérdések, cselekvési útmutatások.

A tartalomban elszórt kérdések inkább költőinek tűnnek, semmint olyannak, amire korrekt választ lehet adni (nekem például nincs időm/kedvem deobfuszkálni a drive kódját, a forrás hiányában viszont csak elméleteket gyárthatok, hogy miért X függvényhívás és Y mélységű osztályhierarchia van Z elem megjelenítéséhez).

Lehetne jobban csinálni, mint a Google? Van rá esély, és ezt szerintem senki nem vonja kétségbe. De mit kezdjünk ezzel a tudással/feltételezéssel? Fejlesszünk egy alternatívát? Írjunk egy cikksorozatot, ami bemutatja a "Better Than Google" metodológiát?

Mi a cél az ítélkezésen túl?
20

Gondolatébresztő

Hidvégi Gábor · Már. 7. (Sze), 17.45
Például el lehet gondolkodni azon, hogy T.G szerint egy sikeres projektet nincs értelme kritizálni, vagy Pepita szerint a Google többezer mérnöke csak jót alkothat.

El lehet gondolkodni azon, hogy a Google vagy a Facebook technológiáját (Angular, React) használja egyre több fejlesztő. Ez a két rendszer hasonló elvekkel készült, mint a Google Drive.

El lehet gondolkodni azon, hogy az itt hozzászólókat nem zavarja a több másodperces betöltés és a több tizedmásodperces válaszidők, de korábban már sokszor volt vita a kliens- és/vagy szerveroldali ellenőrzésről, ahol a kliensoldali mellett az volt az érv, hogy gyorsabb. Most tehát akkor számít-e a sebesség vagy sem?

El lehet gondolkodni azon, hogy ha bonyolult egy rendszer, mint például a Google Drive, az mennyire befolyásolja a fejlesztési időt, mennyire befolyásolja a hibák számát.

El lehet gondolkodni azon, hogy ha a Google-nél ekkora bakikat követnek el, akkor az olvasó miért ne tudna náluk jobb szoftvert írni?
22

Ejnye ejnye képviselőjelölt Úr!

Pepita · Már. 7. (Sze), 18.50
Azt értem én, hogy nagyon fontos neked az álláspontod, de nyomatékosan megkérlek rá, hogy soha ne próbálj olyat a számba adni, amit nem mondtam és nem írtam!

Tudsz jobbat alkotni, mint a Google?
---
Komolyan azt gondolod, hogy csak az lehet valamirevaló fejlesztő, aki egymaga tud valami jobbat - többet, mint a gugli többezer mérnöke együttvéve?...
---
Már megcsináltam, idén fog kereskedelmi forgalomba kerülni.


Mutasd már meg idézettel légyszi, hogy hol is állítottam olyat a linkelt hozzászólásban, hogy
a Google többezer mérnöke csak jót alkothat.


De marha gyorsan ám, mert már elérted azt a szintet, amivel szemben komolyabban lépjek fel.
23

Ezen kívül

Pepita · Már. 7. (Sze), 18.59
többször jeleztem már neked, hogy nincs tökéletes szoftver, de segghülye fejlesztői csapat sem.
Nyilván a drive-on is van mit / lehet mit optimalizálni, nyilván teszik is ezt nap mint nap (legfeljebb nem verik nagy dobra), nyilván akadhat benne olyan rész / részlet is, ahol ha ismernék a te javítási ötletedet, akkor jóvá is hagynák.

Ez viszont nem jelenti azt, hogy az egész hóbelefranc úgy szar ahogy van.
És ha valaki (akár én, akár más) azt meri neked mondani, hogy "azért az csak nem annyira kuka, ha egyszer sikeres", azzal az illető nem azt mondta neked, hogy "nincs annál jobb".

Figyelj má' csávó, a Pepita én vagyok, de úgy látszik neked valami vagy csak fehér, vagy csak fekete lehet, de az nagyon. :)
Találj középutat, ezt kívánom, a stílusodon meg nagyon nagyot javíts, mielőtt komolyabb baj lenne belőle.
25

Hát gondolkodj el

Pepita · Már. 7. (Sze), 19.21
Próbálok segíteni egy kicsit a miértekkel, a magam nevében, de lehet, hogy másokét is eltatlálom.
az itt hozzászólókat nem zavarja a több másodperces betöltés és a több tizedmásodperces válaszidők
mert felhasználóként sem zavar, és feltételezem, hogy a többi felhasználót sem zavarja, valamint nem látok rá esélyt, hogy akár fejlesztői- akár pénzügyi erőforrásban tudnék versenyezni az üzemeltetővel, ennél fogva engem nem motivál a "csinálok jobbat".
de korábban már sokszor volt vita a kliens- és/vagy szerveroldali ellenőrzésről, ahol a kliensoldali mellett az volt az érv, hogy gyorsabb
A második linken lévő kommentet figyelmesen elolvasva láthatod, hogy megint szélsőségesen általánosítasz. Kiemelem az általad figyelmen kívül hagyott részt:
(vitatkozhatsz vele, de a kliens oldali ellenőrzés akkor is gyorsabb egy regex esetén)

Számít a sebesség, senki nem mondta, hogy nem. Nyugodt lehetsz, a drive fejlesztőinek is számít. De például funkcionalitáson nem fognak csökkenteni azért, hogy kicsit gyorsabb legyen, mert azáltal usereket vesztenének.
Fontos a sebesség, de kérdezz körbe légyszíves a tágabb ismeretségi körödben, hogy hányan vannak azok, akik korábban használtak google drive-ot, de sebbesség-problémák miatt már nem használják, esetleg mást használnak helyette.
Itt a wl-en úgy tűnik, te vagy az egyetlen, aki elégedetlen vele.

A bonyolult rendszerekre összetettebb a munkafolyamat is, ahogyan fejlesztik, ez módszertan függő, nem feltétlenül növeli jelentősen a fejlesztési időt, viszont tisztább kódot eredményez, ami lefelé befolyásolja a hibák számát is. A hibák ellen pedig ott van még a rengeteg féle automatizált teszt, code review "hegyek", UAT, manuális teszt és még sorolhatnám.

El lehet gondolkodni azon, hogy ha a Google-nél ekkora bakikat követnek el
El kellene gondolkodni azon, hogy amiket te akkora halálos hibáknak látsz / élsz meg, azok valójában mekkorák, érdemes-e az eddig ráfordított időnknek akár csak töredékét áldozni rá.
(Nem.)
26

Ezek továbbra sem olyan

Endyl · Már. 7. (Sze), 19.36
Ezek továbbra sem olyan dolgok, amikre reagálni lehet akár szóban, vagy tettben.

Szép dolog, hogy ki-ki elgondolkodik azon, ami lejön neki ezekből az írásokból (bár az ábra azt mutatja, hogy a többségnek nem az jön le, amit szeretnél), de azzal mivel leszünk előrébb? A neten továbbra is csak a "Google és társai" módszerről fog részletes leírást találni az egyszeri fejlesztő, a "Hidvégi módszer"-ről meg csak végeláthatatlan litániákban utalásokat arra, hogy túl sok a html elem/http kérés/stb., elgondolkodik rajta, majd megvonja a vállát és bevág az 5 statikus oldal alá egy éppen sokat látott módszert, és kész.

A techgigászok mutatják, hogy hogyan kell majmolni őket, te pedig a wl egy csendes sarkában ítélkezel. Ők haladnak (hogy milyen irányba, az lényegtelen, de haladnak), te pedig ugyanazokat vádakat írod le évek óta ilyen-olyan köntösben. E mellé nem lehet beállni, hogy "na, mostantól én is így csinálom", mert arra nem ad senki fizetést, ha "tudod", hogy a drive túl lassú, és kevesebb kóddal kellene megoldani.

Mutass irányt hasznos funkciókat megvalósító példákkal (nem minimalista design mockupokkal), és talán lesz, aki majd utánad akarja csinálni.

Szóval ha a célod a webes ökoszisztéma felrázása/javítása, akkor nagyon rosszul csinálod, mert a jelek szerint az olvasók többségéből csak ellenszenvet váltanak ki az írásaid és ha el is gondolkodnak rajta, olyan környezetben teszik, hogy "valaki megint ledilettánsozta a google fejlesztőket", miközben megosztja egy kirándulás fotóit a drive-on.
27

Félreérted

Hidvégi Gábor · Már. 7. (Sze), 20.31
A gondolkodásra serkentés a célom, az egyéni felismerések. Sehol sem állítom, hogy ahogyan én csinálom, az az egyetlen jó megoldás. Sőt, lehetnek jobbak, ebben biztos vagyok.

Pont az a fontos, hogy a majmolás helyett más is nézze meg, mi az, ami történik, ő azt hogyan valósítaná meg, és akkor rájön, hogy a nagy techcégek alapjában véve nagyon vacak kódot generálnak, amit nem nehéz felülmúlni.

Sokszor hangsúlyoztam már, hogy a Google egy példa, nem egy főbűnös. Mint írtam, a facebook bizonyos funkcióit megvalósítottam, például a végtelen görgetést, és ott is pont ugyanez a pazarlás megy például a felhasznált HTML elemek számában, mint a Google-nél, ugyanígy rengeteg JS kódot kell letölteni, és úgy általában, rendkívül lassú és erőforrásigényes - minden különösebb ok nélkül.

Tehát még egyszer: nem kívánok kész megoldást adni, mert akkor azt fogják másolni. Aki csak másolásra képes, az szolgának jó, de vitapartnernek nem igazán.

Mindenki jobban jár, ha gondolkodó emberekkel vagyunk körülvéve. Tehát

kezdjetek el gondolkodni!

33

Ezért nem éred el a célod,

Endyl · Már. 7. (Sze), 21.52
Ezért nem éred el a célod, mert az emberek nagy része marhára nem akar gondolkodni. Ezért használják a kész megoldásokat. Ha nincs egy egyszerű "Hogyan készítsünk blogot 10 perc alatt" leírás egy módszerről, akkor a lusta többség azt fogja használni, amiről van. Mert azt tizedannyi idő előállítani, így tízszer annyit tud eladni (az más kérdés, hogy utána lelép, és más lapátolja utána a végterméket; ez őt már nem érdekli, csak az, hogy "termel"). Aki magától is gondolkodik, annak meg feleslegesek az ilyen írások. És lehet, hogy neki is csak arra van ideje, hogy a tizedannyi idő alatt elkészülő megoldást használja, mert úgy tud versenyképes maradni.

Szép dolog a gondolkodás, csak azért kevesen hajlandóak fizetni.
34

Ez kezd egy kicsit erős lenni...

BlaZe · Már. 7. (Sze), 21.54
Ez kezd egy kicsit erős lenni... A mások hülyének nézését, szakma(i) lehúzását nem kéne itt tovább erőltetni. Észre kéne venned lassan, hogy erre nem vevő itt senki.
36

Minősítés

Hidvégi Gábor · Már. 8. (Cs), 09.19
Nos, hadd idézzek egy másik hozzászólást:
Ezért nem éred el a célod, mert az emberek nagy része marhára nem akar gondolkodni. Ezért használják a kész megoldásokat. Ha nincs egy egyszerű "Hogyan készítsünk blogot 10 perc alatt" leírás egy módszerről, akkor a lusta többség azt fogja használni, amiről van.
Tehát Endyl szerint az emberek nagy része nem akar gondolkodni és lusta. Akkor most hogy is van ez az egész?

Aki nem akar gondolkodni, azt mennyire lehet szakmailag elismerni? Mi garantálja, hogy a Google-nál gondolkodó emberek dolgoznak?
38

Hülyének nézés

Hidvégi Gábor · Már. 8. (Cs), 09.34
Én a Google-n kívül nem minősítettem senkit. A hozzászólásomban, amire válaszoltál, pont azt írtam le, hogy a Google Drive forráskódjának elemzésével megadom mindenkinek a lehetőséget, hogy elgondolkodjon azon, ő hogyan dolgozik (ha ezt eddig nem tette volna meg), és eldönthesse, hogy ez neki jó-e vagy sem.

Szóval az állításoddal ellentétben nem hülyének nézem az olvasókat, hanem önálló, felnőtt embereknek, akiknek megvan a szabadsága az általam megosztott információk alapján, hogy döntést hozzanak a sorsukról, ha azokat relevánsnak találják.
39

Aki nem akar gondolkodni, azt

BlaZe · Már. 8. (Cs), 10.29
Aki nem akar gondolkodni, azt mennyire lehet szakmailag elismerni? Mi garantálja, hogy a Google-nál gondolkodó emberek dolgoznak?
A Google mérnökei alighanem kicsit több dolgot gondoltak át, miközben a kódot írták, mint te ebben a hozzászólásban. Ha tudni szeretnéd hogy szűrik a jelölteket, menj el egy interjúra. Nekem volt kollégám náluk több interjú körön is, nem agyhalottakat vesznek fel oda...

Nagybetűkkel kiírni, hogy gondolkodjatok emberek eléggé kimeríti a minősítés és hülyének nézés fogalmát. A komolyabb projecteken általában egyáltalán nincs, vagy nagyon limitált időd van arra, hogy olyan problémákkal foglalkozz, amikre van off-the-shelf megoldás. Amire esetleg jut időd az az, hogy kiválaszd az elérhető kész megoldások közül a szempontrendszered szerint legmegfelelőbbet. És ennek a szempontrendszernek az egyik legfontosabb pontja általában pont az, hogy sokan használják, mert az garantálja, hogy megfelelő támogatást és hibafelderítést kap a termék. SOHA nem láttam még olyat, ahol ez nem szerepelt nagyon komoly súllyal a szempontok között. Sok egyéb szempont szerint persze. Te pont ezt kérdőjelezed meg ezekben a cikkekben, és ezért támadod be az egész fejlesztői szakmát.

Ha úgy gondolod, hogy ezek a termékek rosszak, akkor állj elő a saját gyorsabb-hatékonyabb-tesztelhetőbb stb megoldásoddal, reklámozd azt a saját blogodon, hogy az miért jobb. Ha tényleg jobb, akkor sokan be fognak állni mögé és foglalkozhatsz azzal, amit láthatóan szeretnél csinálni, nő a szakmai respected és emellé kereshetsz vele még egy kamion pénzt is. Ennek amit itt csinálsz semmi értelme nincsen, és nem mondasz vele semmit senkinek, csak a saját szakmai ázsiódat ásod alá.
45

Jobb

Hidvégi Gábor · Már. 8. (Cs), 13.01
Múltkor betettem az általunk fejlesztett rendszer képét, ott leírtam a részleteket, ezekből csak a lényegi részeket ismételném meg:

Az a legbonyolultabb űrlapunk, 800 elemből áll, a renderelése 500ms körül van, ennek a nagy része beviteli mező, aminek a létrehozása kétszer annyi, mint egy szimpla div-é.

Ehhez a kliensprogramunk 59 kilobájt. És mi is tudunk többek között fájlokat, mappákat menedzselni.

A komolyabb projecteken általában egyáltalán nincs, vagy nagyon limitált időd van arra, hogy olyan problémákkal foglalkozz, amikre van off-the-shelf megoldás.
Namost, mondd meg nekem, kérlek, hogy mennyi idő elkészíteni egy 59k-s programot? Ehhez szükség van "többezer Google mérnök"-re, akik biztosan nem agyhalottak?

Tehát vannak-e más utak, amikkel szoftvert lehet fejleszteni? Tilos-e kritizálni mások munkáját?

Az, hogy ide írok néha valamit, jelenti-e azt, hogy csak az én fantáziám szüleménye, vagy pedig meglévő tapasztalatok alapján próbálok rámutatni az alternatívákra?

Származhat-e bárkinek hátránya abból, ha kiderülne véletlenül, hogy van igazság azokban, amit állítok?
49

Látom nem akarod megérteni,

BlaZe · Már. 8. (Cs), 13.33
Látom nem akarod megérteni, amit írtak már neked olyan sokan, meg most én is. Senkit nem érdekel, hogy 59kb, vagy 500kb, mert vannak sokkal fontosabb szempontok. Pl a tesztelés, karbantartás, támogatás stb költsége, ami a többszöröse az implementációs költségeknek, és ráadásul az sokkal nehezebben tervezhető is.

Én itt ebből kiszállok, semmi nyeresége nincs ennek a témának, teljesen ignorálsz szakmai alapvetéseket. Csak annyit tegyél meg kérlek, hogy ne az itteni fórumtársak és a szakma ostobázásával, lenézésével hangoskodva próbáld meg ráterelni a figyelmet a gondolataidra.
51

Kérdések

Hidvégi Gábor · Már. 8. (Cs), 14.20
50 vagy 500 kilobájtos program tesztelése/karbantartása/támogatása az olcsóbb?

Hogyan változnak ezek a költségek, ha harmadik féltől származó, off-the-shelf szoftvert használ az ember? Ugyanis bejön az időfaktor, azaz egy külső függősége lesz, és a hibajavításokra így esetleg kiszámíthatatlan ideig kell várakozni?

A Google Drive egyébként teljesen saját fejlesztése a cégnek, azaz nem külső könyvtárakat használtak hozzá. Volt-e így választási lehetősége a készítőknek, hogy milyen úton induljanak el?
62

Azt azért érdemes tudnod,

BlaZe · Már. 10. (Szo), 00.16
Azt azért érdemes tudnod, hogy a nagyobb cégeknél általában vannak különböző, belső technológiákat szállító csapatok. Kb mint egy belső cég, akinek ügyfelei a konkrét terméket fejlesztő csapatok. Ez alighanem a Googlenél is így van, és minden valószínűség szerint az általad drive kódnak titulált kód nagy része egy több project között megosztott platform. Vagy inkább több.

A többi meg már párszor ki lett tárgyalva...
28

Indokolatlan...

T.G · Már. 7. (Sze), 20.46
Egy másik hozzászólásban már kiemeltem egy csúsztatást, de ez is kiváló példa.
Én írtam: "Semmi értelme indokolatlanul fikázni sikeres projekteket."
Te írtad: "T.G szerint egy sikeres projektet nincs értelme kritizálni"
És nem csak az indokolatlan szó hiányzik. Ezek a bejegyzések nem kritikák, ezek értelmetlen fikázások. Messze nem ugyanaz a kettő.
30

Nincs jelentősége

Hidvégi Gábor · Már. 7. (Sze), 21.06
Az, hogy számodra mi indokolt és mi indokolatlan, nem feltétlenül egyezik meg azzal, hogy számomra mi indokolt és mi indokolatlan.

Én alátámasztottam az érvelésem, ha az számodra nem elfogadható indok, az a te problémád, és nem az enyém.

Valóban azt írtad, hogy "indokolatlanul", ez kimaradt az Endylnek szánt mondatomból, de a kontextusban nincs jelentősége a fentiek miatt.
35

Elemzés, kritika, fikázás?

T.G · Már. 8. (Cs), 06.49
Egy dolgot emelnék még ki. A cikk címe az, hogy A Google Drive elemzése. Szerintem a Google Drive-ban hihetetlen nagy know-how van. Azt gondoljuk végig, hogy mennyi minden kell ahhoz, hogy te bemásolsz a számítógép egyik mappájába egy fájlt, majd én ezt a változást néhány másodperccel később láthatom a böngészőmbe? Sosem hallottam még itt biztonsági problémáról. Sebesség probléma sincsen, valóban néhány másodperc és automatikusan megjelenik a fájl ikonja.

A cikk címe az, hogy A Google Drive elemzése. És egy árva szó nincs erről. Pedig ezért szeretjük a Drive-t, emiatt használjuk, ez benne a jó, ez benne az érték. Az elemzésnek csúfult írásban egy teljesen lényegtelen részlet lett kiemelve. Mégpedig, hogy az alkalmazás indulásakor mi történik. De valójában még ez sem, mert nem lett ez kielemezve. Nem értetted meg, hogy mi miért történik. Ám ami még rosszabb, hogy meg sem próbáltad megérteni! Majd végül levontad a következtetést, hogy mivel nem értetted, akkor biztosan rossz az egész.

Ez nem elemzés, de még kritikának sem kritika. Ez tényleg nem több mint indokolatlan fikázás. Ami szerintem nagyon, de nagyon káros!
37

Gondoljuk végig

Hidvégi Gábor · Már. 8. (Cs), 09.26
Oké, nézzük csak, tegyük fel, hogy van egy mobiltelefonom és egy PC-m. A mobiltelefonról feltöltöm a fájlt a webes szolgáltatásba, a PC-n futó program vagy alkalmazás pedig egy bizonyos időnként lefutó ajax kérés vagy állandó adatkapcsolat segítségével pingeli a szervert, hogy van-e változás. Ha van, akkor frissíti a nézetet.

Egyébként a Google Drive pont így működik, ha megnézed a hálózati forgalmat.

Ha ez számodra "hihetetlen nagy know-how", akkor nem tudom, hogy van-e miről vitáznunk.

Említed még a biztonságot: a kliens visszafejthető, könnyebben, mint egy natív program, tehát itt semmi olyasmit nem tudnak csinálni, aminek ne lehetne utánajárni. A szerveroldali biztonság pedig a klienstől teljesen független.
40

Próbáld egyben

Pepita · Már. 8. (Cs), 10.51
Egyetlen egyszer - ha már "elemezni" szeretnél - próbáld meg egészében is (át)látni az alkalmazást.
Ezen kívül tök jó lenne, ha azt próbálnád érteni, amit mondanak neked, nem azt, amit bele tudsz magyarázni.
"hihetetlen nagy know-how" - ezt nem egy 10 soros js függvényre értette TG, hanem a teljes szolgáltatásra.
Folyamatosan kiragadsz egy-egy apró részletet, amibe éppen bele tudsz kötni, de nem vagy hajlandó látni a fa mögötti erdőt.
Ahhoz, hogy az "igazadat" erősítsd, nem riadsz vissza a csúsztatott "idézetektől" sem - milyen érdekes, hogy ahol nem szó szerint idézel mást, ott többnyire van is rá jelzés, hogy "én nem ezt mondtam"...
Közben még magadnak is ellent mondasz (az is rossz, hogy natív app van és az is, ha mobilon ugyanaz, mint asztali böngészőben).

Ezért nem találsz partnerre ebben és a hasonló fikázásaidban.

Sokkal értékesebb lenne, ha olyan példákat mutatnál, amit legalább a kezdők hasznosítani tudnak, például a végtelen görgetés is érdekes lehet.
Ha ezt jól csinálod, akkor nem másolgatni fogják, hanem tanulni belőle.

Ha viszont picit belenézegetsz egy elég nagyra nőtt szolgáltatás kódjába, nem érted meg, hogy mi miért van, de lefikázod, majd pedig a többiektől várod el, hogy túrják szét nálad sokkal jobban azért, hogy elmagyarázzák neked, amiket nem értettél, különben "neked van igazad" - nos ezzel csak magadat tudod lejáratni.
Mondhatod nekem / rám, hogy én járatlak le, de attól még nem lesz igazad, hogy hangosan kiabálsz, én nem ostobáztalak / hülyéztelek le...

Próbáld megkeresni a pár évvel ezelőtti segítőkész és szerény Hidvégi Gábort, szerintem sokkal hasznosabb lenne a társadalom számára és neked is.
42

Próbáld megvalósítani!

T.G · Már. 8. (Cs), 11.38
Pepita megelőzőt, így most csak ismételni tudom őt, hogy igen, próbáld megvalósítani! Majd észreveszed, hogy itt nagyon sok mindent kell még optimalizálni. A felületes vizsgálat során talált feleslegesnek ítélt div-ek kiszedésén kívül még nagyon sok mindent kell itt optimalizálni.

Vannak olyan helyzetek, amikor felmerül, hogy vagy feleslegesen bekerül egy konténer div, vagy a forráskód csúnyább lesz. Mivel a divek számának nincs súlya, így véleményem szerint, és ebben sokan hasonlóan vélekednek, a helyes választás a szép forráskód.

Ám amíg csak egy statikus html oldalt készítesz, addig ezek a problémák fel sem merülnek. A cikkeid alapján az látszódik, hogy egyszerűen te még nem tartasz ott, hogy a valódi problémákat meglásd! Emiatt mindenféle álprobléma ellen küzdesz. Amikor meg valaki felveti, hogy nem a lényeggel foglalkozol, akkor nem érted, hogy miért. A cikkeid színvonala nem éri el azt a szintet, hogy valóban a Drive működését elemezze. Ami nem is lenne baj, ha nem vonnál le olyan következtetéseket, hogy teljesen rossz az irány, amit ők megvalósítottak.

Tényleg, próbáld megépíteni, majd amikor a 2 másodperces Ajax hívások nem hozzák ugyanazt az eredményt, akkor keres más alternatívákat. Long polling ajax hívást például.

És majd a sokadik probléma megoldása után megtapasztalhatod, hogy tényleg volt ott tudás.

Vagy persze akár küzdhetsz a szélmalmokkal is tovább, nekem végül is mindegy! :-)
43

Mivel a divek számának nincs

Hidvégi Gábor · Már. 8. (Cs), 12.41
Mivel a divek számának nincs súlya
Ezt alá tudnád esetleg számokkal is támasztani? Lehet, hogy igazad van, de amíg ezt nem teszed meg, addig kénytelen vagyok azt hinni, hogy ez egy megérzés. Megérzésekre pedig nem sokat adok szakmai témákban.

Tényleg, próbáld megépíteni, majd amikor a 2 másodperces Ajax hívások nem hozzák ugyanazt az eredményt, akkor keres más alternatívákat
Nem igazán értem, hogy itt mire próbálsz célozni a két másodperces ajax hívásokkal. Ezért írtam alternatívának az állandó kapcsolatot, ami lehet long polling vagy websockets. Mi ezzel a probléma?
46

Számok

T.G · Már. 8. (Cs), 13.21
Érzékelhetetlen a különbség:

var quantity = 100;
var depth = 30;
var html = '';
for (var i = 0; i < depth; ++i) {
    html = '<div>' + html + '</div>';
}
console.time('t');
for (var i = 1; i < quantity; ++i) {
    $('body').append(html);
}
console.timeEnd('t');
Ha bárhol a kódban egy darab Ajax hívást meg tudsz spórolni, akkor már előrébb vagy.

Persze, hogy meg lehet oldani. Látjuk, hogy a Google Drive-nak is sikerült. Ha probléma van, akkor az csupán annyi, hogy jelenleg nem rendelkezünk olyan összehasonlítással, mely segítségével a kód milyenségéről bármit is lehetne mondani.
63

Hibás mérés

Hidvégi Gábor · Már. 11. (V), 17.48
A példakódod önmagában nem sokat ér, ráadásul hibás a metrikád, hadd mutassam be, hogy miért:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<head>
  <meta http-equiv="content-type" content="text/html; charset=utf-8">
<style type="text/css">
/*div {
  width: 100px;
  height: 15px;
  background: red;
}*/
</style>
</head>
<body>
<input type="button" id="gomb" value="gomb" />
<div id="tarto"></div>
<script>
var tarto = document.getElementById('tarto'), ido;
function gomb_klikk() {
  tarto.innerHTML = '';
  var quantity = 100;
  var depth = 30;
  var html = '';
  ido = new Date();
  for (var i = 0; i < depth; ++i) {
    html = '<div>' + html + '</div>';
  }
  for (var i = 1; i < quantity; ++i) {
    tarto.innerHTML += html;
  }
  document.title = new Date() - ido;
  //setTimeout(function() {document.title = new Date() - ido;}, 1);
}
document.getElementById('gomb').onclick = gomb_klikk;
</script>
</body>
A gomb_klikk utolsó parancsa most egy document.title metódushívás, kattints párszor a gombra, és nézd meg, mekkora számok jönnek ki a címsorban, nálam Chrome 64-ben átlagosan 1390ms körüli értékek.

Aztán kommentezd ezt a sort, és vedd ki a kommentezést a setTimeout elől, és utána nézd meg az eredményt: nagyobb lesz. Miért? Mert a függvényen belül csak a DOM fát módosítod, de a böngésző még elvégez a függvény befejezése után egy műveletet, amit nem mérsz, a kirajzolást.

Ez nálam átlag 1515ms-re módosítja a fenti számot. Ez ráadásul függ attól, hogy az elemeknek milyen stílusa van, azaz, ha a <style> elemben kiveszed a kommentezést, még nagyobb lesz az érték, nálam 1600ms körüli.

Lemértem, a mi rendszerünkben a ~ 800 elemes űrlapon az elemek fájának összeállítása és DOM-ba szúrása 140ms körül van, de a teljes rajzolási ciklus (setTimeout-tal) már 500 körül. Azaz ennyit számít, hogy nem szimpla <div>-eket teszünk a képernyőre, hanem stílusozott elemeket.

És hogy lehet az, hogy a 800 elemet 140ms legenerálni, míg a fenti példában a 2300-at a tízszerese? Azért, mert az utóbbiban egymásba vannak ágyazva, azaz az elemek egymáshoz viszonyított pozíciója is számít a számukon kívül.

Ezért érdemes az elemek számával spórolni.
64

Szerintem megint szellemekkel küzdesz.

T.G · Már. 12. (H), 01.00
Most ebből mi következik? Érdemes spórolni a divek számával? Mennyit is takarítunk meg? Az nem derült ki. A 60 div és a 900 div generálása továbbra is hibahatáron belül mozog. Attól, hogy felszorozzuk a számokat 1.2-vel semmi nem változik, a hibahatár is nő, így a különbség nem mérhető továbbra sem. Ha már egy frappáns összehasonlítást szeretnél, akkor ne az én kódom ellen küzdjél. Szerintem tök felesleges. A cikked egy parányival is közelebb került a valósághoz? Ugyanmár. Ehelyett készíthetnél egy másik statikus fájlt, pont ugyanazzal a html-lel, amit a Drive használ. Se Ajax hívás, se dinamikus felépítés, se semmi. Ugyanúgy, ahogy a te kódodban is. Majd megnéznénk, hogy a 60 környéki és a 900 környéki html elem mekkora különbséget mutat időben. Ha ott ki tudnál valóban érzékelhető különbséget mutatni, akkor máris volna miről beszélni. A hangsúly mindenképpen az érzékelhetőn van!
65

Következmények

Hidvégi Gábor · Már. 12. (H), 12.03
Ezekből következik a jó hír, hogy mindkettőnknek még van hova fejlődnie, azaz esélyünk van arra, hogy a végén mindketten jobb emberek legyünk!

Nyilván a stílusomon még elég sokat kell csiszolni (vagy baltával faragni), bár ez a tényen nem változtat, hogy alapvetően igazam van.

Számodra tanulság lehet, hogy teljesítménymérésben még nem vagy tökéletes. Továbbá a koncepcionális hibák kiszúrásában is érdemes elmélyülnöd, én ma reggel jöttem rá, hogy a kódomban egy elég nagy baki van:
for (var i = 1; i < quantity; ++i) {
  tarto.innerHTML += html;
}
Ez messze szuboptimális, sőt, nagyon rossz, mert az innerHTML egy speciális attribútum, és amikor a fenti módon adunk hozzá új karakterláncot, mindig újraértelmezi az egészet.

Ezért ha lecseréljük a következőre:
var str = '';
for (var i = 0; i < quantity; ++i) {
  str += html;
}
tarto.innerHTML = str;
akkor 1380ms-ről 25-re csökken a függvény végrehajtási ideje, de ha a végén a setTimeout-tal mérünk, akkor 225 lesz, azaz 200ms a kirajzolás.

Miért tartom fontosnak az elemek számát? Mint korábban írtam, önmagában ez az adat nem hordoz információt, de ha annak fényében nézzük, hogy[list]
  • a kirajzolás sebessége sok egyéb mástól függ, amire rámutattam,
  • a kliens undefined, azaz nem tudod, hogy milyen hardveren/operációs rendszeren/böngészőn fog futni a kód,
  • [*]nincs okunk feltételezni, hogy ha az egyik helyen pazarlóan bántak az erőforrásokkal, akkor máshol optimális lesz, és erre is hoztam példát, az írásomban mellékelt grafikonokon látszik, hogy több, mint száz mélységig egymásba ágyazott függvényhívásláncolatok vannak az egész programban.