A mundér becsülete
Pár nappal ezelőtt egy másik témában kezdtem a szálat, de úgy gondolom, ez többet érdemel, ezért kihoztam ide, hátha közösen sikerül találni a felmerülő kérdésekre választ.
A probléma alapvetően a modern fejlesztési elvekkel van, amit a Google Drive példáján illusztrálok. Ezen a linken található egy tárhely hét mappával és hét fájllal, erről a biztonság kedvéért készítettem képernyőképet is:
Mint látható, a kezelőfelület végtelenül egyszerű, viszont a betöltése a négymagos Atom processzoros gépemen nagyjából nyolc másodpercnek érződik. Ez az idő frissítés után sem csökken, sőt, készítettem egy képernyőképet a processzorhasználatról:
A kicsinyítés miatt egy függőleges csík lemaradt, de ez az eredményt nem befolyásolja. Az ábrán egy percnyi processzorterheltséget láthatunk, egy oszlop, ami 10 másodpercet jelez, 38 pixel széles, és kiszámolható, hogy a "hegy" lábánál nagyjából 62 pixel széles idősávban történt a Google Drive betöltése a böngészőben. Ez 62/38*10 = 16,31 másodpercet jelent, ennyit dolgozik a processzor az oldal betöltésekor.
Jó kerekítéssel mind a négy mag 50%-os terheltségen ment, ami megegyezik azzal, mintha két mag 100%-on dolgozott volna ennyi ideig, vagy egy mag 32,63 másodpercig. Ez 1,3 Gigahertz-cel számolva 42,42 GHz teljesítményt jelent.
Viszont lejön összesen 1,3 megabájtnyi "minifikált" javascript, ami szerintem rengeteg. Miért szükséges ennyi script ilyen kevés elem megjelenítéséhez? Miért szükséges bármilyen javascriptre egy ilyen egyszerű oldal megjelenítéséhez?
Az eredmény, miután a konzolban lekértem a
Miért?
Miért kell a Google-nek majdnem hússzor annyi elem ugyanannak a tartalomnak a megjelenítéséhez? Igaz, kihagytam pár placeholdert, valamint néhány grafikánál nem SVG-t, hanem képet használtam, de ezeket betéve a saját eredményem nem módosult volna érdemben.
A hálózati forgalmat elemezve kiszűrhető, hogy a lényegi tartalom, ami egy JSON objektum, 1750 bájtos. Ebből a Google Drive a fejlesztői eszközök szerint összesen 227 kilobájtnyi HTML-t gyártott (Fejlesztői eszközök, HTML fül, jobb gomb a
Ez a 14 ikonra levetítve 16 kilobájtnyi kódot jelent egyesével. Miért?
Nagyon kíváncsi vagyok a tisztelt kollegák véleményére, magyarázatára, mert minél többet gondolkodom a dolgon, annál kevésbé értem.
■ A probléma alapvetően a modern fejlesztési elvekkel van, amit a Google Drive példáján illusztrálok. Ezen a linken található egy tárhely hét mappával és hét fájllal, erről a biztonság kedvéért készítettem képernyőképet is:
Mint látható, a kezelőfelület végtelenül egyszerű, viszont a betöltése a négymagos Atom processzoros gépemen nagyjából nyolc másodpercnek érződik. Ez az idő frissítés után sem csökken, sőt, készítettem egy képernyőképet a processzorhasználatról:
A kicsinyítés miatt egy függőleges csík lemaradt, de ez az eredményt nem befolyásolja. Az ábrán egy percnyi processzorterheltséget láthatunk, egy oszlop, ami 10 másodpercet jelez, 38 pixel széles, és kiszámolható, hogy a "hegy" lábánál nagyjából 62 pixel széles idősávban történt a Google Drive betöltése a böngészőben. Ez 62/38*10 = 16,31 másodpercet jelent, ennyit dolgozik a processzor az oldal betöltésekor.
Jó kerekítéssel mind a négy mag 50%-os terheltségen ment, ami megegyezik azzal, mintha két mag 100%-on dolgozott volna ennyi ideig, vagy egy mag 32,63 másodpercig. Ez 1,3 Gigahertz-cel számolva 42,42 GHz teljesítményt jelent.
Mi tart ezen ennyit?
Mint láthatjuk, az oldal végtelenül primitív, alig van rajta pár elem; a css nagyjából 100 kilobájt, azt kissé sokallom, de ráfogom, hogy rendben van; a képek mérete nagyjából 11 kilobájt a fejlesztői eszközök szerint.Viszont lejön összesen 1,3 megabájtnyi "minifikált" javascript, ami szerintem rengeteg. Miért szükséges ennyi script ilyen kevés elem megjelenítéséhez? Miért szükséges bármilyen javascriptre egy ilyen egyszerű oldal megjelenítéséhez?
Doppelgänger
Elkészítettem az oldal mását demonstrációs célból. Nem volt célom a pixelpontosság, nem volt célom a funkciók lemásolása, csak arra voltam kíváncsi, hány elemből lehet elkészíteni azt, amit a Google Drive megnyitásakor látok.Az eredmény, miután a konzolban lekértem a
document.body.getElementsByTagName('*').length értékét: 58 elem. Ehhez képest a Google Drive-on ugyanezt lefuttatva 938-at kapok.Miért?
Miért kell a Google-nek majdnem hússzor annyi elem ugyanannak a tartalomnak a megjelenítéséhez? Igaz, kihagytam pár placeholdert, valamint néhány grafikánál nem SVG-t, hanem képet használtam, de ezeket betéve a saját eredményem nem módosult volna érdemben.
A hálózati forgalmat elemezve kiszűrhető, hogy a lényegi tartalom, ami egy JSON objektum, 1750 bájtos. Ebből a Google Drive a fejlesztői eszközök szerint összesen 227 kilobájtnyi HTML-t gyártott (Fejlesztői eszközök, HTML fül, jobb gomb a
<html> elemen, Copy OuterHTML), míg az enyém 3.Ez a 14 ikonra levetítve 16 kilobájtnyi kódot jelent egyesével. Miért?
Mérés
Találtam egy bő 600 kilobájtos JS fájlt a gépemen, ennek a feldolgozása (betöltés gyorsítótárból, parse-olás stb.) ugyanebben a böngészőben 480ms. Tehát a Google Drive esetében az 1,3 megabájt JS kódnál egy nagyjából 1 másodpercet tesz ki. Mi történik a többi 15-ben?Nagyon kíváncsi vagyok a tisztelt kollegák véleményére, magyarázatára, mert minél többet gondolkodom a dolgon, annál kevésbé értem.
Szerintem túlságosan
A rengeteg JS lehet, hogy felesleges, csak a google dolgozói lusták voltak rongyosra optimalizálni a keretrendszerüket, így egyben lerántja az egészet.
De van egy olyanom, hogy jó részére valóban szükség van a teljes funkcionalitás eléréséhez.
Csillog-villog, mellette még egy komplett fájlkezelőt is ad a böngészőn belül úgy, hogy lehetőleg egyformán lásd böngészőből, android kliensből stb.
Egyforma
Lusták :)
Szia Gábor! Ismerős a
Ismerős a jelenség és szerintem is a hóhér által említett ok áll a háttérben. A jómunkásemberek kivárják, amíg megjelenik az oldal, addig legfeljebb nézik a körbe forgó hullahopp karikát, a JS kódot minden egyes szolgáltatásra ráfaragni meg sok fejlesztői munka lenne. Egyre erősebbek az eszközök, nincs nagy motiváció a fejlesztési időigényes optimalizálásra.
Arról nem is beszélve, hogy biztosan valami saját keretrendszerrel dolgoznak, ami minden problémára ad varázsmegoldást, ennek az ára viszont a feleslegesen nagy JS, az elburjánzó DOM és az erőforrás pazarló algoritmusok.
Üdv:
Dávid
Újrahasznosítás
Az ok az volt, hogy sok weboldalnál elkezdett "túl sokat fogyasztani" a böngésző, vagyis hamarabb megette a vasat (CPU és / vagy RAM), mint kellett volna.
Érdekes módon a frissítés után az összes Google szolgáltatás zavartalanul működött tovább, így én azt gondolom, hogy nincs baj náluk a motivációval és a ráfordított fejlesztési idővel sem, optimalizálnak amit kell és jól. (Amelyik oldal megfeküdt a stack - csökkentés miatt, azok nagy része jQuery each - nél durrant -> érdemes párszor meggondolni az ilyesfajta "varázsfüggvények" használatát..)
Rossz mérések
windows task manager kép:
- Ugye nem állítod azt, hogy az egyetlen futó folyamat a böngésző volt? :) Mert innentől a processzor - teljesítményt így mérni kb butaság. Process list-en másodpercenként kiírja az előző sec átlagát %-ban, ez az adott szál teljesítménye, a képen pedig az összes szerepel, kb 30 ... 60 szálé.
- Az első képen mintha Chrome böngésző lenne, ez egyetlen html oldalhoz is 2 szálon fut, amiből csak az egyik "matekol" az adott oldal DOM-jával, js-el, stb. Ezt az egy szálat kéne mérned.
- Nagy valószínűséggel az általad kifogásolt kódot / működést egyetlen szálon, egyetlen mag intézi, emiatt kissé pontatlan mind a négy magot számolni.
Ez a fajta szorzás - osztás a pixelekkel szintén nem egy valid teljesítménymérés, egyébként a chrome-nak van erre saját eszköze, most nem jut eszembe a neve.
Remélem nem bánod, hogy "minifikált", szerintem sokkal jobb, mint kiscsillió darabból (http requestek száma) 10 MB..
Nézd meg pl mi történik, amikor gmail-en levélhez csatolsz x fájlt a drive-ról. És ez még egy nagyon egyszerű példa a felhasználói aktivitások közül.
A lényeg az, hogy nagyon sokféle szolgáltatás van, amik mára elég jól össze vannak kötve. Ennek viszont ára is van.
Ekkora szolgáltatás-rendszert nem fogsz tudni egyesével külön-külön fejleszteni, illetve sokkal nagyobb lesz az összméret (és teljesítményigény).
Ha viszont azt állítod, hogy egy js kódnak a "feldolgozási ideje" pusztán a méretétől függ és egyenes arányban van vele - hát akkor nagyot tévedtem a tudásoddal kapcsolatban.
Komolyan: esetleg megpróbálhatnál bekerülni a fejlesztőik közé, biztosan sokat tanulnál tőlük, és nem utolsó sorban a legtöbb itt feltett kérdésedre is választ kaphatnál.
Szerintem leginkább azért nem érted, mert kizárólagosan nagyon pici részegységeket vagy csak hajlandó mikroszkóp alá tenni, így eleve figyelmen kívül hagysz egy rakat függőséget.
És itt még nem is érintettük az üzleti érdekeit, a felhasználók elemzését, ami pedig saccra a felét jelenti a cuccnak. ;)
(Viszont a múltkori xy bank témánál ilyen fel sem merült, ezért itt se érzem fontosnak.)
Nekem kiürített cache-el,
- Nagy valószínűséggel az általad kifogásolt kódot / működést egyetlen szálon, egyetlen mag intézi, emiatt kissé pontatlan mind a négy magot számolni.
Nézd meg pl mi történik, amikor gmail-en levélhez csatolsz x fájlt a drive-ról.
Ennek a műveletnek az elvégzéséhez a Google Drive-on 8 másodpercig kellett várnom. Elkészítettem egy tesztoldalt, amin ugyanez (nálam) 26ms, és a fájlokra kattintva letölti őket a böngészőm.
Semmi mást nem teszteltem, csak ezt az egyszerű letöltő funkciót. Hogy a Google milyen más funkciókat tesz még bele, az engem nem érdekel.
Az érdekel viszont, hogy mi történik abban a 15 másodpercben, amit nem a JS betöltésével és feldolgozásával tölt a böngésző.
Ne már :)
Akár tetszik neked, akár nem. Ne használd egyik szolgáltatásukat sem, ha nem akarod.
Ha sikerül, akkor kérlek add meg a csatornát, hogy hogyan kaptál választ, mert néha sokkal fontosabb dolgokban nekem is lenne rá szükségem. :)
Mondtam: akkor csináld meg. Nem egy anonym "drive-ot", hanem legalább a felét, amit nyújtanak. Akkor van értelme "mérni" valamit.
Remélem így már tisztult kicsit a kép, ha nem, akkor én sajnálattal el fogom engedni a témát.
Minimum
Ez a baj, hogy a "tesztoldalad" gyakorlatilag semennyit nem valósít meg a vizsgált funkcionalitásból (a kapcsolt szolgáltatásokon kívül sem).
Absztrakció
Készítettem egy példaoldalt, amin van hét mappa és hét fájl ikonja.
Most próbáld meg elképzelni, hogy a mappákra kattintva egy nagyon hasonló oldal jön be, csak azon mások az ikonok. Az pontosan ugyanilyen gyorsan jelenne meg.
Tehát a lényegen nem változtat, hogy egy vagy száz példaoldalt készítek.
Sikerült?
Ez nagyon analóg azzal, amikor azt írtam, hogy a Google Drive összesen 16 másodpercig dolgoztatja a processzort. Azt is leírtam, hogy az én gépemen nagyjából nyolc másodperc után használható, de ettől függetlenül a Chrome tizenhat másodpercig dolgoztatja a négy processzort.
Ez érthető?
Engem az érdekel - és még nem kaptam rá magyarázatot -, hogy mi történik ez alatt a tizenhat másodperc alatt. Igen, nyolc másodperc alatt használható a Drive, de tizenhatig megy a négy mag.
Ezt te is kipróbálhatod, csak az i7-esen arányosan kisebb számok jönnek ki.
Nekem nem i7-esem van, hanem egy Atom, ezért nagyobbak a számok. Azzal nem tudok mit kezdeni, hogy neked i7-esed van, mert az nem egy átlagos hardver, a legtöbb felhasználónak ennél lassabb van. A mobiltelefonok többsége az Atomos gépemmel nagyjából megegyező sebességű. Ma már az internetet jelentős mértékben mobilról böngészik, ezt ezért tartom fontosnak.
Most mit érzel, miközben ezeket olvasod? Én pontosan ugyanezt éltem át a te soraid abszolválásakor.
---
Ugyanilyen absztrakciós készség szükséges ahhoz, amit a processzorteljesítménynél írtam.
Abból indultam ki, hogy a csatolt képen látszik, a Google Drive betöltésekor négy mag dolgozik tizenhat másodpercig, mindegyik átlagosan 50% teljesítményen. Ha arányosítani szeretnénk, ez, ugye, jó kerekítéssel megfelel annak, mintha két mag ugyanennyi ideig 100%-on dolgozna, vagy egy magra levetítve harminckét másodpercnyi munkának. Mivel a processzor 1,33 Gigahertzes, ezt egy gigahertzre számolva nagyjából azt jelenti, mintha egy egy gigahertzes processzor 42 másodpercig dolgozna száz százalékon, vagy arányosan egy 42 gigahertzes gép egy másodpercig.
Erre írtam, hogy 42 gigahertznyi teljesítmény. Tisztában vagyok, hogy ez egy pongyola megfogalmazás, de aki el tud vonatkoztatni (absztrakció) ettől a pontatlanságtól, az megérti a mondanivalót.
Természetesen bele lehet kötni a mértékegységbe, csak kérdés, hogy van-e értelme, és a "nagy" probléma szempontjából mi a jelentősége.
Absztrakció?
Nos, a képzelőerőmmel szerintem nincs semmi gond, de mérnökemberként a szakmámban tényeket és mérési eredményeket szeretek összehasonlítani, nem képzeletbeli dolgokat.
Nos, a teszt kedvéért módosítottam jócskán PC-ről a drive-omon, majd hatalmas teljesítményű telefonomon is megnyitottam, épp 3G-s mobilnetről. Kevesebb, mint 5s volt, minden funkcionalitással együtt.
Azt javaslom, hogy mint a PC-t használók többsége, Te is asztali / laptop géphez illő, 10 évesnél fiatalabb procit használj, mert bármilyen szoftvert / webappot nem úgy kell "telefonra tesztelni", hogy azzal hasonlóan kis teljesítményű asztali PC-vel próbálgatod, egész más oprendszeren, stb.
Ha linkelnél hasonló adatlapot az Atomodról, mint én az i7-ről, akkor könnyebb lenne összehasonlítani.
Processzor "teljesítménynél" vegyük inkább alapnak az órajelciklust, mert ebből kiindulva szinte bármelyik processzora +/- 10% eltéréssel ki lehet számolni a tényleges futásidőt másodpercben, amennyiben ismert az órajel(GHz) és a magok száma.
Ott van azért az a 10%, mert kívülről nem tudjuk, hogy hány szálon mehet egyszerre a cucc, de egész jó viszonyszámot ki lehet hozni pl Atom és i7 között.
Másik lehetőségként továbbra is erősen javaslom a Chrome saját task manager-ét. A kedvedért rákerestem, és nincs is szükség semmilyen plugin-re vagy extension-re, csak nyomd meg a SHIFT + ESC billentyűket. :)
Ezután nyisd meg új lapon a drive-ot, és látni fogod az adott lap konkrét "fogyasztását" real time. Itt is %-ban látható a processzor kihasználtsága, de ellentétben a windowsos task managerrel, adott böngészőlap erőforrásigényét látod.
Ha esetleg egy nagy képkockaszámú videót is csinálsz a tesztről, akkor vissza tudod nézni egész pontosan, hogy a kattintástól kezdve mikor mennyi erőforrásigény van.
Plusz lehetőség még (akár egyidőben) a böngésző (development tools) network fülén megnézni, hogy mi mennyi idő alatt töltődött be, ha szerencséd van, DOMContentLoaded időt is láthatsz (bár a drive sok XHR kérést küld periodikusan, így a DOM idő nem biztos, hogy valid.)
A nagy probléma szempontjából annyi a jelentősége a "kötözködésemnek", hogy próbáltalak kicsit pontosabb és ferdítésektől mentes mérés irányába terelni, sajnálattal látom, hogy ez számodra kötözködés... Természetesen bárki képes "pongyolán fogalmazva" a valóságtól nagyon eltérő adatokat produkálni, én feltételeztem, hogy nem ez volt a célod, ezért jeleztem, hogy hol van benne olyan buktató, ami túl nagy tévedésekhez vezet. Ilyen "mérésre" alapozni olyan súlyos ítéleteket, amiket tettél - hát nem túl korrekt szakmailag.
De elnézést kérek, nem kötözködöm többet. :/
Érdekes
Azt sem gondoltam volna soha, hogyha egy szoftver funkcionalitásának az 1%-át implementálom, akkor meg tudom oldani 1%-nyi forráskóddal/fogyasztással/stb.
Az "én ezeket nem használom, miért van benne" mentalitásra: ha bemész mondjuk egy tetszőleges boltba/bevásárlóközpontba/hipermarketbe, ott sem minden a te kényelmedet szolgálja, hanem mondjuk más vásárlókét, a partnerekét, a tulajdonosokét, stb; ezeknek a fenntartása mégis bele van kalkulálva az ott megvásárolható termékek árába.
Szóval legközelebb ha mész egy ilyen helyre vásárolni, légy szíves követelj x% kedvezményt, mert te nem használod az alkalmazotti mosdót/étkezőt, feleannyi világítással is rendesen látnál, nincs szükséged légkondira (mert jól bírod a meleget), nincs szükséged fűtésre (mert van rajtad kabát), nem használod az ingyenes parkolót (mert tömegközlekedsz), stb.
Ha tényleg csak fájlokat akarsz megosztani, akkor miért nem üzemeltetsz/bérelsz egy ftp-szervert, és akkor meg van oldva a problémád; csak azért fizetnél, amit használsz.
Ugyanakkor nyilván meg lehetne oldani ezt máshogy is, de a Google számára úgy látszik az x megabájtos js fájlok kiküldése és a különböző szolgáltatásaik összekötése megéri. Legalábbis te szoktál azzal példálózni, hogy mit szólna a megrendelő, ha szándékosan x%-os többletkiadást vagy bevételkiesést okozna valaki; gondolom ekkora mennyiségű kód a Google felhasználószámánál nem kis forgalmat generál, amin elég sokat lehetne spórolni, ha ennek a nagy része csak passzióból lenne benne az oldalban, mert simán ki lehetne dobni és a fenntartására sem kellene erőforrást fordítani; szóval talán mégsem csak a móka kedvéért van ott az a kód? Főleg egy olyan cégnél, ahol állítólag észreveszik a párszáz ezredmásodperces plusz betöltési idő miatti felhasználócsökkenést?
Én például egy 15-20 ezer
Miért, mit teszel még bele,
Ezzel arra céloztam, hogy hiába vered a melledd, hogy mennyivel kevesebb kóddal megvalósítod a google drive-ot, mert nem azt tetted, hanem csak annak egy töredékét (triviális letöltés funkció), így nyilván meg tudod oldani töredék mennyiségű kóddal.
Ahogy Pepita is mondta, majd akkor szólj, ha a drive minden funkcióját (nem csak azt, amit éppen használsz, vagy kedved van hozzá) megvalósítottad. Majd akkor méregethetjük, kinek nagyobb a kilobájtja.
Úgy látom itt is szivároghatnak az absztrakciók.
De mint ahogy többen már írták neked, némi absztrakció szükséges a Google szolgáltatásainak megértéséhez.
Hadd ne linkeljem az egszerű hibakeresés cikkedben a JS debuggeres részt :) Ha ennél praktikusabb választ vársz, akkor interjúvolj meg egy drive fejlesztőt.
A leginkább az a bosszantó ezekben a témákban, hogy látszólag értelmes, jó szakember létedre, kontextustól függetlenül kiragadsz "problémákat", és csúsztatásokkal teletűzdelve bemutatsz valamit, ami alapján dobálod a sarat másokra, nem figyelve a probléma egészére (lásd: "miért van ez a sok minden a driveban, én csak fájlt akarok letölteni": mert a drive nem csak fájlletöltésről szól, kész). (Bár az tény, hogy most legalább az ostobázás elmaradt :) )
Nyilván azt sem mondom, hogy a Google minden (vagy akár bármelyik) szolgáltatása a mérnöki tervezés és munka csúcsa, amitől jobbat nem lehet alkotni (amikor először kipróbáltam a Chrome-ot, a gmail-től, youtube-tól rendszeresen összeomlott :) ). Ott is nyilván ugyanolyan emberek dolgoznak, akik ugyanúgy hibáznak is. Viszont mind a lehurrogás, mind pedig a "majmoljuk a Google-t/nagyokat" trend szempontjából érdemes szem előtt tartani, hogy ekkora cégeknél már az infrastruktúrájuk mérete miatt is könnyen lehet, hogy más prioritásokkal állnak hozzá akár egy egyszerű letöltéshez is. Nem mondom, hogy ez a hozzáállás a jó, vagy a legjobb, vagy hogy bármilyen (kisebb) cég számára követendő, de valamennyire érthető (elvégre még nem ment csődbe a Google, tehát nekik megérheti így csinálni).
Ezzel arra céloztam, hogy
Ahogy Pepita is mondta, majd akkor szólj, ha a drive minden funkcióját (nem csak azt, amit éppen használsz, vagy kedved van hozzá) megvalósítottad. Majd akkor méregethetjük, kinek nagyobb a kilobájtja.
Hadd ne linkeljem az egszerű hibakeresés cikkedben a JS debuggeres részt :) Ha ennél praktikusabb választ vársz, akkor interjúvolj meg egy drive fejlesztőt.
---
Elfelejtettél válaszolni a következő kérdésemre: Szoftver esetében kötelező a nem használt funkciókat betölteni a memóriába?
Fogalmam sincs, hogy milyen
Ugyanakkor nem zavar, mert még sohasem okozott problémát, mert egyrészt ritkán használom a drive-ot, másrészt amikor meg igen, akkor sem éreztem kifejezetten lassúnak.
Világos
Gondolom, számodra ezek alapján nem egyértelmű, hogy adatokat csak úgy lehet-e gyűjteni felhasználókról, hogy az ember letölti mellé a fél világot. Mondjuk az tény, hogy így is megoldható.
Igazából arra nincs ötletem,
Mi a célja ezeknek a szálaknak? (a sárdobáláson kívül)
Egyébként honnan tudnánk annál többet mondani, mint amilyen adatokhoz te is hozzáférsz a különböző fejlesztői eszközök segítségével?
Itt nem értem, hogy hogyan jutottál erre a következtetésre, vagy hogy egyáltalán mit akarsz ezzel mondani/kérdezni.
Sárdobálás
Vettem a fáradságot, és újraolvastam mindent, amit ezen az oldalon írtam, javaslom neked is!
A kijelentő mondataimban megosztottam az általam mért adatokat. Semmit és senkit nem minősítettem, nem vontam le következtetéseket. A kijelentő mondatok után kérdéseket tettem fel.
Úgyhogy megkérlek, tisztázd, hol van itt a sárdobálás, mert szerintem minden alap nélkül járatsz most le engem.
A többi kérdésedre a választ akkor kapod meg, ha ezt megtetted.
A sárdobálás előtti kérdésben
Elnézést, ha úgy jött volna le, de nem célom a lejáratásod (írtam is, hogy én igazából jó szakembernek tartalak az itteni írásaid alapján; sokmindenben egyet is értek veled, de a hozzáállásod sok esetben számomra érthetetlen, mivel a konstruktív aspektusa nem jön át a dolgoknak).
Szóval, ahogy te nem érted a Google-t, én úgy nem értem, hogy miért ölsz ekkora energiát ezeknek a témáknak a feszegetésébe, amikor a konkluzió jobbára csak annyi, hogy valamit valaki nem a legszerencsésebben oldott meg (amennyire külső szemlélőként ezt meg lehet ítélni), te viszont töredék mennyiségű kóddal/komplexitással/buggal/stb. meg tudnád oldani ugyanazt.
Energia
Lassan tizenkettedik éve, hogy egy integrált vállalatirányítási rendszert fejlesztünk, amit jelenleg pár cég használ, és ha minden jól megy, ősszel lépünk piacra vele. Ebben lehet számlázni, raktárkészletet kezelni, kapcsolatot tartani, hozzá lehet férni a levelezéshez, lehet fájlokat fel- és letölteni, ezeket és az egyéb dokumentumokat egymáshoz csatolni, nyomtatni, kimutatásokat készíteni, az adatokat exportálni különböző formátumokban, végtelen scroll stb.
Ha jól belegondolunk, ez elég jól lefedi a Google Drive - Gmail szolgáltatásokat.
Csatolom a legbonyolultabb űrlapunk képét, amin többek között a számlákat lehet kezelni. Igen, csúnya, de mentségünkre legyen mondva, hogy csak két hete csatlakozott hozzánk olyan ember, akivel a kinézetet és a használhatóságát meg tudjuk csiszolni.
Mint látható, némileg több látható elem van rajta, mint a Google Drive-én, bár a DOM-ban ez kevesebb, egészen pontosan 800. Ennek a lerenderelése az adatok betöltése után 530ms körül van, és ebben minden benne van (a fenti Atom processzoros PC-n). Ha mellé teszem, hogy a kliensprogramunk 59 (ötvenkilenc) kilobájt, akkor az már kezdi az "ezt úgysem hiszem" szintet megütni.
Az ember nem lehet mindig tökéletesen elégedett, ezért már dolgozom a következő verzióján. Most mértem le, ugyanennek az űrlapnak a renderelése 123ms.
Ez most egy belső fejlesztés, de neked szívesen megmutatom, még a forráskódot is, mert te rendes ember vagy.
Mi a célom a felhozott témákkal?
Az egyik az, hogy kibillentsem a kollegákat a megszokott keréknyomból. Ez a korábbi két írásomban talán kicsit túl jól sikerült, a kognitív disszonancia elég erős lehetett. Talán emiatt is lett ez az írásom jóval visszafogottabb.
A másik cél, és ezért teszek fel kérdéseket, hogy gondolkodásra késztessem a társaságot. Bár már leírtam az évek során minden tudásom, de úgy hiszem, hogy akkor tud fejlődni az ember, ha saját maga elkezd utánajárni, átgondolni, kipróbálni, azaz tapasztalatot szerezni.
Nekem is!
Hatalmas különbség van a Ti és a Google rendszerei között: a Ti célközönségetek egy eléggé szűk üzleti kör, míg Google kb mindenkire céloz, a legszegényebb (de internetet használó) egyéntől a legnagyobb cégekig. Ennél fogva a nyújtott szolgáltatások is rendkívül különböznek.
Ettől függetlenül szívesen tanulnék a Ti példáitokon is, abban biztos vagyok, hogy elég rendhagyó.
Nem feltétlenül tűnik
Megtisztelő a bizalom, de hacsak nem ragaszkodsz hozzá, nem szívesen ütöm az orrom más üzleti titkába :) Valamikor azt írtad, egyszer majd publikálsz dolgokat a módszeredről, szerintem ráérek megvárni azt.
Ezekrő a témákról valahogy mindig ez jut eszembe (az lényegtelen, hogy ki melyik szerepben van éppen, általában oda-vissza változik): You're not going to believe what I'm about to tell you
13-ra:
vs
Gábor, itt Endyl szájába próbáltál már adni olyan véleményt, ami ellenkezik az övével.
Ez ne fair, viszont azt mutatja (számomra), hogy nem megérteni szeretnéd a dolgot, nem tanulni belőle, hanem egyszerűen csak ellenkezni. Ráadásul olyan dolgokban, amikre mi is csak tippelgetünk, mert egyikünk sem drive- vagy gugli fejlesztő.
Azt hiszem nekem ezen a ponton ment el a kedvem ettől a témától. :(
Szerintem a titok nyitja,