Hirdetés

2024. március 29., péntek

Gyorskeresés

Hozzászólások

(#1) gabor.79


gabor.79
aktív tag

Szegénynek elég megkeseredett arca van ilyen fiatalon.

A weboldalak túlnyomó része azért lassú, mert a készítője egyszerűen dilettáns: fogalma sincs, hogyan működnek a böngészők, nem ismeri a CSS-t és a javascriptet, önálló munkavégzésre képtelen, ezért csak keretrendszerekkel dolgozik, saját kódot nem tud írni, copy-paste huszár. Nekem ez a szakmám lassan húsz éve, pontosan látom, mi megy webfejlesztés néven.

Hogyan próbálják ezt megoldani a problémát a HTTP 2 fejlesztői? Ész hiányában erővel: a keretrendszerek miatt kimegy ezer JS és CSS fájl, hát küldjük őket egyszerre. Csak arról felejtkeznek el, hogy a szoftver olyan, mint a gáz, mindik kitölti a rendelkezésére álló helyet, azaz ebben az esetben a kedves fejlesztők gondoskodni fognak arról, hogy a HTTP 2-t is megtelítik, például még nagyobb keretrendszerekkel.

Ez nagyon analóg arra, hogy az okostelefonok tulajdonosai panaszkodnak készülékeikre, hogy azok gyorsan lemerülnek. Nosza, tegyünk beléjük nagyobb akkumulátorokat. Ezt észlelik a fejlesztők, beletömnek még plusz pár featúrát az operációs rendszerbe vagy a szoftverbe, és megint csak egy-két napig bírják a vasak.

Szerintem jobb út, ha a tisztelt programozók megtanulnák a szakmájukat. A jó megoldásokat pedig mindig erőforráshiányos helyzetben lehet hozni, bőségben nem.

Tapasztalataim szerint a legtöbb weboldalt/webes szolgáltatást meg lehet úgy csinálni, hogy az eredetinél öt-tízszer gyorsabb, a kódja pedig fele, harmada. Csak ehhez elképzelhető, hogy energiát kell fektetni a tanulásba előtte.

(#2) Dezsike válasza gabor.79 (#1) üzenetére


Dezsike
tag

Egyetértek. Én is fejlesztő vagyok, épp egy web alapú szoftvert fejlesztünk egy kisebb méretű rendszerre (max 5 kliens párhuzamosan). Az oldal egyetlen (szerveroldalon generált) HTML és egy nagy CSS (itt esetleg lehetne fragmentálni, mert nem minden modul használ ki mindent, de nem vagyok benne biztos, hogy bármit is nyernénk vele). Szándékosan nem húztunk bele semmilyen keretrendszert, így van, hogy a kód nagyon ronda egy-két helyen, de működik és hasít. Az oldal betöltése a teszt szerveren (ami egy átlag "netezős" gép volt 6 éve) max 100 ms. Egy ismerősöm hobbi weboldala is hasonló értékeket produkál, ráadásul a neten keresztül, nem belső hálón. Ellenben más fejlesztők oldalai, még ha nem is túl bonyolultak, másodpercek alatt nyílnak meg. Az okát sejtem, a HTTP 2 nem fog segíteni rajta.

(#3) gyurkikrisz válasza gabor.79 (#1) üzenetére


gyurkikrisz
őstag

Mi baj van a keretrendszerekkel? Vagy muszáj minden project alkalmával feltalálni a kereket?

A tuning a kisfiúk alap órajele. | i5 6500

(#4) zolij válasza gyurkikrisz (#3) üzenetére


zolij
tag

"bezzeg a mi időnkben" :)

(#5) dragon1993 válasza gabor.79 (#1) üzenetére


dragon1993
őstag

LoL

A keretrendszer azért van, hogy ne kelljen már mindent 100x megírni. Legtöbbször a nem használunk keretrendszert azt jelenti, hogy sajátot csináltunk és nincs hozzá dokumentáció az új kollégát lehet betanítani.

A weblap betöltésénél a legtöbb időt nem az oldal generálása hanem a css jsek képek betöltése viszi el, ilyenkor jobb ha egy fájlba összerakjuk a sok css/js fájlt és a képeket optimalizáljuk.

A HTTP2-nek a push funkción kívül nem sok köze van a fejlesztőkhöz, az üzemeltetési feladat.

Nézted mostanában a Laravel doksit, az ott lévő dolgokat mennyiért csinálnád meg?

(#6) xTc


xTc
aktív tag

Én is ott voltam ezen az előadáson, messze az egyik legjobb volt szerintem szakmailag.

(#7) Drizzt válasza xTc (#6) üzenetére


Drizzt
nagyúr

Én a Crafton voltam, de ezen az előadáson éppen nem. De semmi gond, mert már fenn van a konferencia weboldalának Ustream csatornáján. Nekem amúgy ez tetszett a legjobban.

I am having fun staying poor.

(#8) Feruendios válasza dragon1993 (#5) üzenetére


Feruendios
aktív tag

Osztom, nincs ma hatékony Webfejlesztés Frameworkok nélkül.

Sajnos mar nincs magyar billentyuzetem :(

(#9) gabor.79 válasza dragon1993 (#5) üzenetére


gabor.79
aktív tag

Ha nincs keretrendszer, akkor te mindent százszor megírsz? Saját kódot te nem szoktál dokumentálni?

"A weblap betöltésénél a legtöbb időt nem az oldal generálása hanem a css jsek képek betöltése viszi el, ilyenkor jobb ha egy fájlba összerakjuk a sok css/js fájlt és a képeket optimalizáljuk."

Tényleg? Akkor ezt a HTTP2 készítőinek magyarázd el, mert van benne egy funkció, ami pont ezt valósítja meg. De ha ennyire egyszerű és triviális lenne a dolog, mint ahogy írod, akkor miért tették bele?

"Nézted mostanában a Laravel doksit, az ott lévő dolgokat mennyiért csinálnád meg?"

Néztem - pontosan melyik funkcióira gondolsz?

Egyébként nem tudom, miért kevered ide a Laravelt, a gyors oldalbetöltés - a tartalomgeneráláson felül - frontend probléma. Én a mostanában népszerű Angular, React és társaikra gondoltam, amikor megírtam a fentieket, de a csökkenő népszerűségű jQueryvel is nagy és lassú oldalakat készítettek a kollegák, köszönhetően az ezer pluginnek.

Kiváló példa a problémára az Elittárs nevű társkereső. Az átlag oldalbetöltése négy és hat másodperc, ebből a http forgalom öt egész kilobájt egy profil oldalnál, a többi képek, ezek össz betöltési ideje pártized másodperc, a többi az oldal renderelése, amit kliensoldalon végeznek, hisz Angularban valósították meg.

Hasonló a Facebook, ami a saját fejlesztésű React-et használja, bárhova kattintasz, több másodperces renderelési idők vannak, az adatforgalom itt is minimális - és mit látsz cserében? Egy poszt pár logikai elemből áll (szerző, dátum, publikusság, szöveg, kép, érzelmek, hozzászólások), de érdemes megnézni a HTML kódját, több tízszer annyi HTML elemből áll össze, mint amennyi szükséges lenne, és ez részben a hozzá nem értésük, részben a keretrendszer működése miatt van így. És utána csodálkoznak, hogy lassú.

(#10) Egon válasza dragon1993 (#5) üzenetére


Egon
nagyúr

Na ja.
Tegyük hozzá azt is, hogy biztonsági szempontból pont a saját gányolásokban szokott a legtöbb lyuk lenni (ez nem (csak) az én véleményem: ismert hazai, sérülékenységvizsgálattal foglalkozó cég szakemberei mondták).

"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)

(#11) gabor.79 válasza Egon (#10) üzenetére


gabor.79
aktív tag

Biztos? Szerinted a nézeted osztják a prohardver lapcsalád (meg index, origo stb.) fejlesztői is? Te a sajátjaidat gányolod? Mert akkor tényleg jobb egy keretrendszer.

[ Szerkesztve ]

(#12) dragon1993 válasza gabor.79 (#9) üzenetére


dragon1993
őstag

Tényleg? Akkor ezt a HTTP2 készítőinek magyarázd el, mert van benne egy funkció, ami pont ezt valósítja meg. De ha ennyire egyszerű és triviális lenne a dolog, mint ahogy írod, akkor miért tették bele?

Tapasztalataim szerint HTTP2 estén is lassabb 500db fájlt kiszolgálni, mint 1db-t.
Melyik funkcióra gondolsz a HTTP2 estén a push-ra a multiplexelésre vagy mire, mert így elég nehéz vitatkozni, hogy van benne egy funkció

Néztem - pontosan melyik funkcióira gondolsz?
Egyébként nem tudom, miért kevered ide a Laravelt, a gyors oldalbetöltés - a tartalomgeneráláson felül - frontend probléma. Én a mostanában népszerű Angular, React és társaikra gondoltam, amikor megírtam a fentieket, de a csökkenő népszerűségű jQueryvel is nagy és lassú oldalakat készítettek a kollegák, köszönhetően az ezer pluginnek

Ha így leszűkítve kéred, mely funkciók érdekelnek akkor Queues, Collections és az Eloquent érdekelne első körben.
Őszintén megmondom, hogy frondend frameworkkel nem dolgoztam még, de lassan ezt is igyekszem pótolni.
A jQuerynél meg nem kell eszetlenül használni 1000 plugin-t a hello world-nél.

[ Szerkesztve ]

(#13) gabor.79 válasza dragon1993 (#12) üzenetére


gabor.79
aktív tag

"Melyik funkcióra gondolsz a HTTP2 estén a push-ra a multiplexelésre"

Természetesen a multiplexelésre gondoltam, a push teljesen más.

"Ha így leszűkítve kéred, mely funkciók érdekelnek akkor Queues, Collections és az Eloquent érdekelne első körben."

Queues: mi is használunk ilyet, 11 kilobájt a bruttó kód.

Collections: idézet a dokumentációból: "The Illuminate\Support\Collection class provides a fluent, convenient wrapper for working with arrays of data."

Mi tömböket a PHP beépített tömbkezelő függvényeivel manipulálunk.

Eloquent: az ORM-ek rendkívül erőforrászabálóak, soha eszembe nem jutna ilyet használni.

"A jQuerynél meg nem kell eszetlenül használni 1000 plugin-t a hello world-nél."

Mindenki annyi plugint használ, amennyi szükséges.

(#14) Egon válasza gabor.79 (#11) üzenetére


Egon
nagyúr

LOL.

Biztos?
Nem. Semmi sem biztos, max. valószínű.

Szerinted a nézeted osztják a prohardver lapcsalád (meg index, origo stb.) fejlesztői is?
Nem igazán értem, hogy jön ez ide, másrészt nem hat meg, hogy konkrétan az említett fejlesztők mit gondolnak. Egyébként is, tapasztalatom szerint a fejlesztők pont azok, akik leginkább tesznek a biztonságra. Ha működik a program, akkor minden oké, kb. ez az általános felfogás (persze tisztelet a kivételnek, és akinek nem inge...).

Te a sajátjaidat gányolod?
Nem vagyok fejlesztő. IT biztonsággal foglalkozom.

Nem tehetek róla, hogy a pici szívedre vetted az általános (megalapozott) megállapításokat. Még egyszer: akinek nem inge...

"Bonyolult kérdésre egyszerű választ keresni helyénvaló, de ritkán célravezető megoldás" (Wayne Chapman)

(#15) gabor.79 válasza Egon (#14) üzenetére


gabor.79
aktív tag

Úgy jönnek ide a felsoroltak, hogy van jópár weboldal, amelyik saját fejlesztés, nem keretrendszerre épül, és működik (és biztonságos, amennyire biztonságos).

Keretrendszerre épülő weboldalt is lehet gányolni, meg saját fejlesztés is lehet atombiztos.

"Egyébként is, tapasztalatom szerint a fejlesztők pont azok, akik leginkább tesznek a biztonságra. Ha működik a program, akkor minden oké, kb. ez az általános felfogás"

Ez pedig pont azt támasztja alá, amit az első hozzászólásban írtam a fejlesztőkről.

---

Az IT biztonságon belül mivel foglalkozol?

(#16) Kurt Hectic válasza gabor.79 (#1) üzenetére


Kurt Hectic
tag

"ezért csak keretrendszerekkel dolgozik"

Nem ezért dolgozunk keretrendszerekkel, hanem az újrafelhasználhatóság, a kompatibilitás és az egyszerűsítés végett.

"Hogyan próbálják ezt megoldani a problémát a HTTP 2 fejlesztői?"

Sehogy, nem erről szól a HTTP2, ill. ez csak a sokadik priorítás.

Dezsike

"Az oldal egyetlen HTML és egy nagy CSS"

Merthogy a sebesség jellemzően nem a nagy fájlok miatt veszik el, hanem a TTFB (Time To First Byte), azaz a várakozás a kapcsolat felépítésére, és a fejlécadatokra. Épp ezért van az, hogy egy nagy HTML+CSS+JS fájl jóval kevesebb idő alatt töltődik le, mint több különálló HTML, CSS, JS fájl.

dragon1993

"A weblap betöltésénél a legtöbb időt nem az oldal generálása hanem a css jsek képek betöltése viszi el,"

A képek igen, de a CSS és JS fájlok rendszerint nem a méretük miatt lassítják a betöltődést, hanem a kapcsolatfelvétel idővonzata miatt.

"ilyenkor jobb ha egy fájlba összerakjuk a sok css/js fájlt és a képeket optimalizáljuk."

Igaz, de ez is a fentebb említett kapcsolatfelvételi idő, ill. a TTFB miatt van.

(#17) gabor.79 válasza Kurt Hectic (#16) üzenetére


gabor.79
aktív tag

"Nem ezért dolgozunk keretrendszerekkel, hanem az újrafelhasználhatóság, a kompatibilitás és az egyszerűsítés végett."

Keretrendszer nélkül nem tudsz újrafelhasználható, kompatibilis és egyszerűbb kódot írni?

(#18) dragon1993 válasza Kurt Hectic (#16) üzenetére


dragon1993
őstag

Én is a TTFB-re gondoltam csak nem fejtettem ki.

(#19) TomMusic válasza gabor.79 (#1) üzenetére


TomMusic
őstag

Abszolút egyetértek!
Bár én inkább HW oldalról tudom megközelíteni a témát, de talán pont ezért alakul ki árnyaltabb kép. Fáj a szívem, mikor látom, milyen HW-t nyomnak az okostelefonokba, és "mire képesek". Gyötrelem! Ami a weben zajlik, az meg már súrolja a felháborítás szó fogalmát. Egy hello world weblap is már csilliónyi felesleges hülyeséggel terheli a klienst. És hiába mondod nekik, hogy ez így nem oké. Erre az a válasz hogy: dehát a multiplatform, meg van sávszélesség, meg különben is, ő jobban tudja. De talán nem is a fejlesztőkkel van a baj, hanem a rendszerrel. Ugyanis a fejlesztők abból tudnak dolgozni, ami van.

Állítólag az egyetemen töltött évek a legszebbek. Ezért a képzési időt próbálom a lehető leghosszabbra nyújtani.

(#20) hcl válasza gabor.79 (#1) üzenetére


hcl
félisten
LOGOUT blog (1)

Programozás fronton is ugyanez zajlik sok éve. Csodálkozunk, hogy a hardveren futó OS-en futó frameworkon futó interpretált script lassú, és így is erőmű kell hozzá. Csak azért, hogy a gagyi alkalmazást gyorsabban ki lehessen adni, ne kelljen kicsit több idő a fejlesztésre.

@TomMusic : De az erősebb hardver általában azért kell, hogy az azon futó virtuális gépen futó alkalmazás ne legyen tetű... :D
Meg hogy az ezer plusz folyamat, aminek a fele felesleges, is kapjon CPU időt.

[ Szerkesztve ]

Mutogatni való hater díszpinty

(#21) TomMusic válasza hcl (#20) üzenetére


TomMusic
őstag

Így van, és ez itt a probléma kéremszépen!

Állítólag az egyetemen töltött évek a legszebbek. Ezért a képzési időt próbálom a lehető leghosszabbra nyújtani.

(#22) dragon1993 válasza hcl (#20) üzenetére


dragon1993
őstag

Megírom neked assembly-ben a is a céges alkalmazást csak a webhez képest akkora szorzót kapsz az árra ami ide nem fér ki.

(#23) hcl válasza dragon1993 (#22) üzenetére


hcl
félisten
LOGOUT blog (1)

A hozzáállást mondtam. Sajnos amióta "van" teljesítmény, azóta pazaroljuk is.
Nem feltétlen kell assemblyre gondolni, de amikor meglátom, hogy egy MS Lync telepítő 1 giga, akkor röhögök. Érted, nem az a baj, hogy vannak új feature-k, és gyors fejlesztést lehetővé tevő környezetek, hanem hogy manapság már hírből sincs optimalizáció a legtöbb helyen.

Volt egy szép cég ahol egy adatbázishoz fejlesztettek többféle klienst. .net és webes kliens is volt.
Változatos géppark volt a gyártósorokon, de főleg roncsokból állt. A sor ugye minél jobban kellett , hogy pörögjön. Volt mondjuk 2008, 2009? Volt egy rakás VIA C7 / 1GHZ-es tetű gép, 1GB RAM + WinXP. Na ezeken mindenki szidta a webes klienst. A .net-es pörgött, mint atom, ugyanezeken. Mondjuk a webes klienssel a sokkal erősebb P4-es gépeken is volt elég baj.
Mivel új gépek nem nagyon voltak, nem volt rossz dolog, hogy a régebbi gépeket be lehetett fogni így, és ez elég sok kiadást feleslegessé tett.

[ Szerkesztve ]

Mutogatni való hater díszpinty

(#24) Kurt Hectic válasza gabor.79 (#17) üzenetére


Kurt Hectic
tag

"Keretrendszer nélkül nem tudsz újrafelhasználható, kompatibilis és egyszerűbb kódot írni?"

Ha kifizeted, tudok.

(#25) gabor.79 válasza Kurt Hectic (#24) üzenetére


gabor.79
aktív tag

Tudom. Erről írtam az egyes hozzászólás első bekezdésében. Q.E.D.

(#26) xTc válasza Drizzt (#7) üzenetére


xTc
aktív tag

Ezt én is láttam, de szerintem ez inkább team leadership-ről szólt, mintsem tech leadershipről. Ettől függetlenül nagyon hasznos előadás volt számomra.

Copyright © 2000-2024 PROHARDVER Informatikai Kft.