ugrás a tartalomhoz

Managing Programmers by Douglas Crockford at Silicon Valley Code Camp

Joó Ádám · 2016. Jan. 30. (Szo), 21.21
Hogyan menedzseljünk hatékonyan egy fejlesztőcsapatot
 
1

Hidvégi Gábor · 2016. Jan. 31. (V), 21.29
Jó előadás, jó megjegyzésekkel, ami nagyon tetszett:

"There is surprisingly little science in computer science - unfortunately."

"In fact often the best thing you can do to a software system is to remove lines of code."

Abban is igaza van, hogy a programozók legnagyobb ellensége a komplexitás. Azzal viszont nem értek egyet, hogy a komplexitás problémájára szerinte csak egy megoldás van: a tudás. Pontosabban, ez igaz, csak szerintem az általunk generált problémák összetettsége és a rendelkezésre álló intelligencia között egyre nagyobb a szakadék.

Egy rendszer annál összetettebb, minél nagyobb a benne lévő objektumok, valamint a köztük lévő kölcsönhatások száma. Ha bármelyiket vagy mindkettőt növeljük, egyre nehezebben lesz átlátható a kimenet állapota.

Egy másik megoldás, ha az objektumok és/vagy a kölcsönhatások számát csökkentjük.
2

Ezt a számszerűséget én nem

Joó Ádám · 2016. Jan. 31. (V), 22.28
Ezt a számszerűséget én nem tudom értelmezni.

Induljunk ki az információelméletből. Minden üzenet rendelkezik entrópiával, ami az üzenet által hordozott információ mértéke, és egyben a tömörítés lehetséges alsó határa. Adott információ végtelen számú, tetszőlegesen hosszú üzenetben kódolható, de az információtartalmánál rövidebben nem. A legrövidebb üzenet nem az ember számára legegyszerűbben értelmezhető lesz.

Egy program is rendelkezik egy inherens komplexitással, ami a vele szemben támasztott követelményekből következik, és ugyanígy végtelen számú módon megfogalmazható, de egyszerűbben nem. A számszerűen legegyszerűbb felírása egy programnak nem a fejlesztő számára legegyszerűbben értelmezhető lesz.

Ahhoz, hogy mi emberek kezelni tudjuk a komplexitást, absztrakciókat kell bevezessünk, hogy átláthatóvá tegyük. Az absztrakciók helyes megválasztása az, amihez tudásra és tapasztalatra van szükség.
3

Nem

Hidvégi Gábor · 2016. Feb. 3. (Sze), 23.20
Elbeszélünk egymás mellett, vagy pedig nem fogalmaztam érthetően. Egy példával illusztrálom, amit most találtam:

Itt egy, a Facebook szerverén kihasználható Remote Exploit történetét lehet olvasni, ami röviden arról szól, hogy az azonosításhoz lehetett OpenID-t használni, viszont az implementációkban volt egy bug, aminek a segítségével egy fájlt lehetett eljuttatni a szerverre, s ott fájlokat listázni vagy akár tetszőleges kódot futtatni.

Egy program egyre több objektumból/komponensből áll, viszont a fejlesztőknek se ideje, sem pedig tudása/intelligenciája nincs meg ahhoz, hogy az összes köztes interakciót átlássák, és ezek hatását felmérjék.

Az absztrakciók számának növelésével nő a hibázási lehetőségek száma és a kiszolgáltatottság, erre is hozok egy egyszerű példát:

Az embernek nagyjából 20 celsius fokos hőmérsékletre van szüksége, hogy operálni tudjon, télen emiatt fűteni kell. A fűtéshez szükséges gázra és egy konvektorrendszerre. A gázt elégetem, a melegvíz eljut a konvektorba, így meleg van a szobában.

Régen a kazánból vastag csöveken szállították a melegvizet, ami nem túl esztétikus, viszont a fizika törvénye miatt automatikusan ment benne a keringés. Amikor bevezették a vékony csöveket, a vizet el kellett kezdeni keringetni egy szivattyúval. Ennek a következménye, hogy ha nincs áram, akkor hiába fűtene a kazán, a melegvíz nem tud eljutni a konvektorba.

Ez egy nyilvánvaló absztrakció, aminek az állítása: meleg van, fűtünk. A lényegtelen, elhanyagolt információ az, hogy ehhez gázra és áramra van szükség. Ha ezek közül valamelyik hiányzik, szivárog az absztrakció, és hideg van.

Tegyük fel, hogy továbbfejlesztjük a koncepciót, és az IoT jegyében elektronikus hőmérővel és mikroszámítógéppel váltjuk ki a termosztátot. Ha ez elromlik, vagy már nem szerezhető be, esetleg feltörik az interneten keresztül, megint nem lesz fűtésem.


A fentiekből következik, hogy a rendszerben lévő modulok számát a szükséges minimumon kell tartani, akár rendszerrel szemben támasztott követelmények számának csökkentésével. Fel kell tenni a kérdést: valóban szükség van erre és erre?

Egy ismerősöm autókereskedőknek fejlesztett webshopokat. Itt úgy mennek a dolgok, hogy a kereskedők folyamatosan nézik a konkurencia weboldalait, és amint megjelenik egy újdonság, azonnal kérik a sajátjukba ugyanazt. Ez az ész nélküli komplexitásnövelés beláthatatlan következményekkel jár.
4

termosztát

solkprog · 2016. Feb. 3. (Sze), 23.54
remélem hogy ezt megint sikerült ismételten elmondanod attól most jobban alszol majd. Holnap egy új nap, újra elmondhatod!

Termosztát: egyrészt a hasonlatod sántít, - mert termosztát azért kell, és a régi sima egyszerű is el tud romlani.
De én bevállalnám hogy okos termosztátom legyen, örülnék ha kikalkulálná a kinti, és benti hőmérséklet alapján, illetve hogy átlagosan mikor vannak otthon a család azt hogy mikor kell fűteni, és hogy mennyire! hogy az ember ne érjen haza hideg lakásba, de mégis gazdaságos legyen a fütés. Én ezt bevállalnám cserébe azért mert x évente elromolhat.

Egyébként meg értem mit mondasz, - de akkor meg hol húzzuk meg a határt? Nem kell ahhoz okos termosztás, és szivattyús rendszer, hogy valami gajra menjen. pl a kazán is romolhat, vagy kilyukadhat a cső..
Szóval javaslom hogy csökkentsd az absztrakciót és vágj lyukat a plafonba, majd rakj tűzet a szoba közepén.

Bántás nélkül, tényleg érdekel: neked miért jó ezeket újra, és újra elmondani? Miért lesz neked jobb ha esetleg sikerült meggyőznöd? Néha én pl egyet tudnék érteni _rész_ dolgokban, de szemelemzős stílusod miatt nem vagyok hajlandó támogatni téged.
5

Fordítsd meg

Hidvégi Gábor · 2016. Feb. 7. (V), 10.02
Lehet, hogy én elmondom a mantrám minden alkalommal, de ugyanakkor a másik oldal meg elmondja a magáét. Kinek van igaza? Biztos, hogy a másik oldalnak? Ha egyértelmű lenne a döntés, akkor miért merülhetne fel bárkiben is kérdés?

Ha azt mondom, hogy enni kell, hogy életben maradjunk, azon nem fog filozofálni senki, mert ez az egyértelmű igazság. De ha azt mondom, hogy ne igyunk több energiaitalt, mert hosszú távon megbánjuk, azt már nem árt megfontolni.

A szoftverfejlesztés tele van gyenge lábakon álló elméletekkel és divattal. Érdemes megfigyelni, hogyan gyengül az OOP, ahogy a funkcionális elemek szivárognak be a nyelvekbe és a napi használatba. Öt-tíz éve gondolta volna ezt valaki? A király stabilan ült a trónján. Nos, ezért nem célszerű az alapján dönteni, hogy mit mond a többség.

Hol kell meghúzni a határt? Occam borotvája megmondja, két lehetőség közül általában az egyszerűbb a jobb.

Ott van például a Go nyelv, nincs benne sem kivételkezelés, sem pedig öröklődés, pedig modern nyelv, a node.js-sel egy időben indult. Ez nem véletlen, az alkotói tudatosan döntöttek így.
6

Occam borotvája

solkprog · 2016. Feb. 7. (V), 11.20
Amíg veled megint azon kell vitatkozni hogy az "Occam borotváját" nem szoftverfejlesztésre találták ki, addig nem tudom miről beszélünk.. Ráadásul nem két lehetőség, hanem "két magyarázat közül" szól az elv.
És ezt már szépen elmondták neked korábban itt a weblaboron..

Ha neked a napi munkádhoz megfelel a funkcionális programozás, akkor hajrá. Én továbbra is úgy vagyok fele hogy PHP-ban OOP-vel vagyok hajlandó programozni, - ahol meg kell a sebesség (mert van ilyen) ott meg inkább választok egy másik nyelvet. De erről eszembe nem jutna meggyőzni téged, - max a kollégáimat, de nekik meg van annyi tapasztalatuk/eszük maguktól is.
7

"Occam borotváját" nem

Hidvégi Gábor · 2016. Feb. 7. (V), 13.20
"Occam borotváját" nem szoftverfejlesztésre találták ki
Occam borotvája egy általános elv, amit a szoftverfejlesztésre ugyanúgy lehet alkalmazni, mint bármi msára. Ajánlom figyelmedbe ezt az írást, amit most találtam, nagyon szépen kifejti azt, amit a hármas hozzászólásban leírtam.
8

lehet hogy neked

solkprog · 2016. Feb. 7. (V), 13.40
Akkor megpróbálom máshogy:
Lehet hogy neked funkcionálisan programozni könnyebb PHP-ban, mint OOP-vel. Nekem nem. Nekem sokkal egyszerűbb, karbantarthatóbb, unit tesztelhető, és újra felhasználhatóbb kódot eredményezz OOP-vel programozni nekem PHP-ban.
De erről én nem akarlak meggyőzni.
9

Funkcionális

Hidvégi Gábor · 2016. Feb. 7. (V), 14.21
Sehol nem állítottam, hogy a funkcionális jobb lenne, csak annyit, hogy mindenhova kezd beszivárogni, valamint azt, hogy "A szoftverfejlesztés tele van gyenge lábakon álló elméletekkel és divattal". Sőt, amíg a fordítókat kifejezetten nem optimalizálják rá, lassabb és memóriapazarlóbb lesz a program.
10

google

solkprog · 2016. Feb. 7. (V), 15.39
google

Hát nem tudom, nekem ebből az jött le hogy te a procedurális programozás híve vagy.

Sőt, amíg a fordítókat kifejezetten nem optimalizálják rá, lassabb és memóriapazarlóbb lesz a program.

Kimérted hogy ez a gyakorlatba mennyit jelent? Mondjuk egy osztály példányosítása? Mert én igen. Szóval a válaszom: lassabb, szinte mérhetetlenül lassabb, na és?
(és én vagyok az aki nekiáll kimérni hogy az array_merge a gyorsabb vagy + operátor)

Te arra a volt kollégámra emlékeztetsz aki megkapta feladatnak hogy gyorsítsa szerver oldalon a kódot. Új volt, én leültem mellé, és elkezdtem magyarázni hogy hol lassú a kód. Ő ezt végighallgatta, majd figyelmen kívül hagyta, és elkezdte törölni a kódból a kikomentezett részeket, és ezt csinálta több napig. Ezzel gyakorlatban mérhető sebesség csökkenést nem tudod elérni..
Mindegy én bekapcsoltam az apc-t, és pár sql query-t becacheltem, pár oszlopra tettem index-et, ezzel kb 30%-al gyorsabb lett a főoldal kb 1-2 órás fejlesztéssel.

Egyébként meg te miért nem programozól mondjuk F#-ban?
13

Igen, a procedurális

Hidvégi Gábor · 2016. Feb. 7. (V), 16.52
Igen, a procedurális programozás híve vagyok, de ez most nem tudom, hogy jött ide. Ismerem az OOP-t és a funkcionális paradigmát is, de egyelőre egyik sem győzött meg.

Kimérted hogy ez a gyakorlatba mennyit jelent? Mondjuk egy osztály példányosítása? Mert én igen. Szóval a válaszom: lassabb, szinte mérhetetlenül lassabb, na és?
Mértem, és emiatt nem ajánlom a funkcionális minták átvételét a natív, jól bevált eszközökhöz képest (array.forEach versus for ciklus). Egyébként meg az ilyen cinikus hozzáállás miatt tartunk ott ma, ahol. Eddig például bármely lassú site esetében, ahol saját js kódot írtam, átlagosan 10-20-szoros gyorsulást értem el úgy, hogy a kód kisebb (fele, harmada), egyszerűbb lett, ráadásul több böngészőn futott.
15

saját js kód

solkprog · 2016. Feb. 7. (V), 18.10
Örülnék ha nem kevernél/mosnál mindig mindent össze.

Persze ha saját js kódot írsz akkor persze jó eséllyel kisebb lesz a kód mérete. Legalábbis ha előtte olyan library-t használtál aminek mondjuk a 70%-át nem használtad.
És igen sok esetben tud számítani a forEach vs for. Ezt senki se vitatja. Esetleg csak arra szeretném felhívni a figyelmed hogy nem feltétlen célszerű mindig ész nélkül optimalizálni. Se mondjuk két hónapot eltölteni azzal hogy újraírsz minden saját kódból, - ezzel mondjuk elérve 10-20% sebeség növekedést, hanem mondjuk meglévőt optimalizálod (amit előtte kimérsz hogy hol lassú) pár hét alatt.
Szóval ameddig te dobáltad ki a munkaadód pénzét az ablakon hónapokon keresztül, addig én mondjuk megszüntettem hogy ne keressük ki minden esetben jQuery('.example') vel az elemet. Vagy megszüntettem hogy ne építsünk elemenként DOM-ot jQuery-vel. A maradék időben amíg te még a saját kódot írtad, - addig én más produktív a cég számára hasznos munkát végeztem.
16

Amit újraírtam, azt magamnak

Hidvégi Gábor · 2016. Feb. 7. (V), 18.22
Amit újraírtam, azt magamnak tettem, saját szórakozásomra, nem más pénzéből; kíváncsi voltam, én mit tudnék kihozni ugyanolyan funkcionalitással. És nem 10-20% növekedést értem el, hanem 10-20 szorosat, ami már a nagyon nem mindegy kategória. Az eredeti kódból pedig lehetetlen lett volna kihozni ennyit a túl sok absztrakció miatt: egy darab listbox létrehozása 6-8 osztály öröklődésén és példányosításán keresztül történt, körülbelül nyolcszáz sornyi kóddal, ugyanezt én megvalósítottam kétszázból.

nem feltétlen célszerű mindig ész nélkül optimalizálni
Ebben tökéletesen igazad van, csak akkor szabad nekivágni, miután mértünk és mérlegeltünk.
12

Lehet, hogy én elmondom a

Joó Ádám · 2016. Feb. 7. (V), 16.33
Lehet, hogy én elmondom a mantrám minden alkalommal, de ugyanakkor a másik oldal meg elmondja a magáét. Kinek van igaza? Biztos, hogy a másik oldalnak?


Hogyha te minden alkalommal amellett érvelsz, hogy egy kérdésre egyszerű igazság a válasz, a másik oldal pedig minden alkalommal érveket hoz amellett, hogy a kérdésre nincs egyszerű válasz, és soha nincs egyértelmű konklúziója a vitának – akkor neked is be kell látnod, hogy kinek van igaza.

Ha azt mondom, hogy enni kell, hogy életben maradjunk, azon nem fog filozofálni senki, mert ez az egyértelmű igazság. De ha azt mondom, hogy ne igyunk több energiaitalt, mert hosszú távon megbánjuk, azt már nem árt megfontolni.


Pontosan milyen összetételű energiaitalokról van szó? Egyáltalán nem szabad energiaitalt inni? Lehetséges, hogy bizonyos mennyiség kedvező élettani hatású? Hol húzódik a határ a kedvező és a káros mennyiség között? Milyen külső tényezők befolyásolják?
14

a másik oldal pedig minden

Hidvégi Gábor · 2016. Feb. 7. (V), 17.05
a másik oldal pedig minden alkalommal érveket hoz amellett, hogy a kérdésre nincs egyszerű válasz
A munkám során a felvetődő problémák megtárgyalásánál mindig kifejezetten törekszünk arra, hogy több megoldást találjunk ki, és ezek közül mindig a legegyszerűbbet választjuk, lehetőleg azt, amit vissza lehet vezetni egy korábbira. Tehát lehegséges, csak akarni kell.

Pontosan milyen összetételű energiaitalokról van szó? (...)
Az átlag energiaitalról, amit leveszel a polcról, ha bemész bármelyik boltba.

Az energiaital nem üdítő, hanem időzített bomba
Az energiaital nem szomjoltó üdítő, nem sportital, az egészségre számos káros hatása van - hangsúlyozta Martos Éva, az Országos Gyógyszerészeti és Élelmezés-egészségügyi Intézet főigazgató-helyettese.
Nyilván tudsz olyat mutatni, amelyikben kevesebb a káros anyag, nyilván vannak emberek, akik számára hasznos lehet a koffein, de ez az elenyésző kisebbség. Mindenki más rosszabbul jár vele.
17

A munkám során a felvetődő

BlaZe · 2016. Feb. 9. (K), 00.39
A munkám során a felvetődő problémák megtárgyalásánál mindig kifejezetten törekszünk arra, hogy több megoldást találjunk ki, és ezek közül mindig a legegyszerűbbet választjuk, lehetőleg azt, amit vissza lehet vezetni egy korábbira.
Nem te mondtad, hogy lecserélted az Ext.JS-t egy saját megoldásra? Az a legegyszerűbb dolog volt? Szerintem sokkal egyszerűbb lett volna tovább használni. Csak más, fontosabb szempontotok volt, így az egyszerűség eléggé háttérbe szorult.

Az egyszerűség csak egy szempont a sok közül, amik mentén döntünk. Erre leegyszerűsíteni egy döntési folyamatot elég öngyilkos megoldás. Nem is csinálja senki. Te se :) Még ha azt hiszed, akkor se.
18

Nem tudtunk az Extnél

Hidvégi Gábor · 2016. Feb. 9. (K), 11.16
Nem tudtunk az Extnél maradni, annyira lassú volt, mivel nagyon nagy számú űrlapelemmel dolgozunk, ami a számlázásnál ezerötszáz-kétezret jelent, ezeknek a renderelése Ext-tel 640ms volt, a sajáttal meg 26.

A programlogika egyébként maradt, de a rajzoló és eseménykezelő eljárást jelentősen leegyszerűsítettük. Hogy egy példát mondjak, az ilyen keretrendszerek egyik jellemző hibája, hogy az eseménykezelőket az elemhez azonnal hozzárendelik, ami egyrészt 10-20%-kal lassítja a megjelenítést, másrészt meg minek? Egy űrlapon általában nagyon kevés interakció van, bőven elég akkor csinálni valamit, ha az elem fókuszt kap.
19

Tudom, csak ez pl jó példa

BlaZe · 2016. Feb. 9. (K), 23.52
Tudom, csak ez pl jó példa arra, hogy nem mindig az egyszerű megoldásokat kell választani. Vannak más szempontok is. Programozásról beszélve meg aztán pláne.
20

Nem értem

Hidvégi Gábor · 2016. Feb. 10. (Sze), 09.54
Ne haragudj, de ezt nem értem. Mi alapján vontad le a fenti következtetést? Mik azok a más szempontok?
21

A válaszod alapján nálatok a

MadBence · 2016. Feb. 10. (Sze), 12.13
A válaszod alapján nálatok a performancia/UX volt a váltás oka.
22

Ez következménye volt az

Hidvégi Gábor · 2016. Feb. 10. (Sze), 12.25
Ez következménye volt az eredeti keretrendszer bonyolultságának: egy listbox kirajzolásához (new Ext.form.ComboBox()) hat vagy hét öröklődési láncon, nagyjából nyolcszáz sornyi kódon kellett végigmenni. Mi ezt megoldottuk hét sorból.
23

Nem tudtunk az Extnél

MadBence · 2016. Feb. 10. (Sze), 12.32
Nem tudtunk az Extnél maradni, annyira lassú volt, mivel nagyon nagy számú űrlapelemmel dolgozunk
Nekem ebből továbbra sem az jön le, hogy a váltás oka elsősorban a kód túlbonyolítottsága lett volna.
24

Akkor közelítsük meg más

Hidvégi Gábor · 2016. Feb. 10. (Sze), 13.05
Akkor közelítsük meg más nézetből, kiindulási helyzet, hogy a számlázó űrlap megnyitása lassú, ami elfogadhatatlan UX és fejlesztési szempontból. A kód elemzése után kiderül, hogy az űrlapelemek kirajzolása a szűk keresztmetszet, mert rengeteg utasítás fut le, mire kikerül egy elem a képernyőre.

Döntést hozunk:
1, marad minden a régiben, ez Blaze szerint az egyszerűbb (hisz nem kell csinálni semmit),
2, újraírjuk, és akkor pontosan az fog történni, amit mi szeretnénk.

Az 1,-es pont csak látszólag egyszerűbb, valójában ez a komplexebb, ugyanis a megjelenítő kód bonyolultsága megmarad az eredetinek.
A 2,-es pont látszólag bonyolultabb, hisz bár újraírjuk a rajzolást, a kód jelentősen leegyszerűsödik, annyit, és csak annyit csinál, amennyire épp szükség van.
29

Vagyis egy egyszerűnek tűnő

BlaZe · 2016. Feb. 10. (Sze), 23.57
Vagyis egy egyszerűnek tűnő megoldás később rémálommá válhat. Vagy egy komplexebb segíthet hosszútávon. A konklúzió, hogy nem az egyszerűség fogja vezérelni a döntéseidet, hanem egy döntési helyzetben a legfontosabb szempontok szerint mérlegelve ki fogod választani a számodra optimálisnak tűnőt, ami sok esetben nem a legegyszerűbb. Ezért mondta mindenki, hogy az Occam borotvája nincs jó helyen ebben a szálban. Amellett, hogy tényleg nem is döntési modell.
76

Hát én személy szerint

inf3rno · 2016. Feb. 13. (Szo), 12.34
Hát én személy szerint megvizsgáltam volna, hogy tényleg szükség van arra, hogy egyszerre 2000 elem legyen a monitoron. Általában ezt olyan scrollal szokták megoldani, ami csak annyit renderel egyszerre, amennyi a monitoron látszik, mondjuk 25 elemet, aztán görgetésnél ezeket frissíti. Erre szerintem simán lehet gyártani egy ext komponenst, ha valaki még nem csinálta meg helyetted.

Jól sejtem, hogy ez még ext3 volt? Úgy rémlik ext4-től ki vannak gyomlálva ezek a hosszú öröklési láncok, és áttértek a composition over inheritance tiszteletére. De lehet rosszul tudom, nem foglalkoztam már nagyon régóta azzal a rendszerrel.
121

1500 űrlapelemet kirenderelni

Fraki · 2016. Ápr. 2. (Szo), 20.44
1500 űrlapelemet kirenderelni elég nagy UX disasternek tűnik.
75

Ki kell hogy ábrándítsalak,

inf3rno · 2016. Feb. 13. (Szo), 12.32
Ki kell hogy ábrándítsalak, Ádámnak igaza van, a hatás sok esetben dózis függő. Gyógyszereknél is van effektív dózis meg halálos dózis, általában arra törekednek, hogy a kettő között elég nagy szakadék legyen. A koffein sem kivétel, napi 1 kávéra pl azt mondják, hogy jót tesz a szívnek. Egy adag energiaitalban, főleg ha alkohollal kevered valószínűleg már káros lesz a hatás. Na ennyit erről, jobb ha nem visszük el élettan irányába a programozós fórumot.
11

Rendben, vagyük a példádat.

Joó Ádám · 2016. Feb. 7. (V), 16.17
Rendben, vagyük a példádat. Az absztrakció nem a „meleg van”, hanem a „fűtés”. Kétségtelen, ha a fűtéshez a gázkazánon és csőrendszeren kívül villamos berendezés is tartozik, akkor az implementáció komplexebb. Ez a komplexitás a fűtéssel szemben támasztott megváltozott követelményekből származik: a vastag csövekben ugyanis nem a melegvíz jutott el magától a radiátorig (és nem a konvektorig), hanem a forró gőz. Ez a megoldás azonban többek közt rendkívül veszteséges, az energiahatékonyság pedig egyre fontosabb követelménye a fűtésrendszereknek, ezért ma gőz helyett víz a hordozóközeg, a vizet pedig keringetni kell.

A követelmények meghatározásáról a fejlesztés kontextusában beszélni értelmetlen, mert azokat a fejlesztés előtt kell meghatározni, fejlesztés közben azok adottak.

Az implementációban senki nem kérdőjelezi meg az egyszerűség fontosságát, a baj az, hogy az egyszerű szubjektív, de legalábbis sokféleképp értelmezhető. Az azonban egészen biztos, hogy az egyszerűség mértéke nem az absztrakciók száma, mert éppen az absztrakció az eszköz, ami segít az egyre növekvő komplexitású követelményekből fakadóan egyre növekvő komplexitású implementáció átlátásában állandó szellemi kapacitás mellett.
25

Egy program is rendelkezik

Hidvégi Gábor · 2016. Feb. 10. (Sze), 22.06
Egy program is rendelkezik egy inherens komplexitással, ami a vele szemben támasztott követelményekből következik, és ugyanígy végtelen számú módon megfogalmazható, de egyszerűbben nem.
Ebben tökéletesen igazad van, viszont ebből nem következik, hogy az implementáció komplexitása egyenlő a követelményekből származó komplexitással, annál nagyobb vagy egyenlő, de inkább sokkal nagyobb.

Példa:
A már sokat emlegett Ext.js-ben egy űrlapelem létrehozása átlagosan 2-8 számú öröklődési láncon keresztül történik. Az elem konstruktora megkapja a bemenő paramétereket, majd meghívja a szülői fán felfelé az összes többi konstruktorát. Ebből létrejön egy szép nagy objektum egy csomó belső tulajdonsággal.

Igen ám, de a tapasztalat szerint egy űrlapot az adott rekord adatainak kitöltése után már nagyon ritkán módosítanak. Akkor miért hozzuk létre minden alkalommal a fenti objektumot, amikor az űrlapot kirajzoljuk? Bőven elég egy darab divet kitenni a képernyőre, és csak akkor dolgozni, amikor valóban szükség van rá (valamilyen módon fókuszt kap).

Körülbelül két hete merült fel bennem, hogy egy űrlapra tulajdonképpen miért rakunk fel n darab beviteli mezőt, amikor egyszerre úgyis csak egyben lehet a kurzor? Egy ilyen elem kirajzolása elég költséges, ugyanis egy csomó eseménykezelőt rendel hozzá a böngésző; méréseim szerint nagyjából kétszer annyi idő a renderelése, mint egy divé. Bőven elég lenne kirakni mindenhova diveket, aztán, amikor rákattint valaki, akkor felé pozícionálni egy ugyanolyan méretű, átlátszó beviteli mezőt.
26

Egy ilyen elem kirajzolása

bamegakapa · 2016. Feb. 10. (Sze), 22.46
Egy ilyen elem kirajzolása elég költséges, ugyanis egy csomó eseménykezelőt rendel hozzá a böngésző; méréseim szerint nagyjából kétszer annyi idő a renderelése, mint egy divé. Bőven elég lenne kirakni mindenhova diveket, aztán, amikor rákattint valaki, akkor felé pozícionálni egy ugyanolyan méretű, átlátszó beviteli mezőt.


Ez az a szintű mikrooptimalizálás, amin a bölcs, tapasztalt programozók csak mosolyognak. Ha a csapatukban vagy, esetleg lekevernek egy nyaklevest. Bár lehet ezt már csak trollkodásként írtad, nem tudom eldönteni.

Az ExtJS-é szerintem sem okos megoldás (sőt), de te a ló túloldalán fekszel a sárban. Azzal is elbeszélgetnék, aki ilyen mennyiségű formelemhez az ExtJS-t választotta megoldásként.
27

Makro

Hidvégi Gábor · 2016. Feb. 10. (Sze), 23.27
Okoskodni könnyű, de a körülmények ismerete nélkül nehéz bölcsnek lenni. Mint már jeleztem, nagy számú elemmel dolgozunk, az 1600 elemű űrlap, amiből kb. 1300 beviteli mező, a többi checkbox, a rajzolás a leggyorsabb eljárással is 200ms, divekkel meg a fele (jelenleg egy Atomon dolgozom). Egy Móriczka-űrlapon három elemmel nyilván fel sem merülne ilyen.

Ennyi adatot a szerveren össze is kell állítani, ki is kell küldeni. Ezen a szinten már számítanak az ilyen apróságok is.
28

1600 elemű űrlap, amiből kb.

BlaZe · 2016. Feb. 10. (Sze), 23.51
1600 elemű űrlap, amiből kb. 1300 beviteli mező

Teljesítmény szempontjából ez biztos izgalmas feladat. De a felhasználók tudnak kezelni ennyi mezőt? Ez brutálisan sok. Van olyan feladat, amihez rengeteg input kell, de ez koncepcionálisan biztos jó? Erre nyilván semmilyen UI framework nem való.
32

Egyrészt a pufferelés miatt

Hidvégi Gábor · 2016. Feb. 11. (Cs), 10.32
Egyrészt a pufferelés miatt ennek csak a fele látszik, másrészt pedig sajnos nem volt választási lehetőség, ennyi adatot kell kitenni. Koncepcionálisan szerintem is rossz, bár idővel megszokható, és akkor viszont jó, hogy nem kell minden számla részletezőjét egyesével megnyitni.

Az 1600 úgy jön ki, hogy negyven sor van nagyjából negyven cellányi információval. Ebből talán meg lehetne spórolni 5-öt, de akkor is nagyjából ugyanott lennénk.
30

lehet hogy értelek

solkprog · 2016. Feb. 11. (Cs), 00.30
(sarkítva) szóval mert te egy 1600 elemű űrlapon, egy (tényleg) lassúcska library-t sikerült lecserélned egy minimál stílusú saját library-val, és ezzel gyorsítani az oldalon, ezért minden alkalmat megragadsz hogy elmond hogy fúj fúj absztrakciók, fúj oop, és éljen a procedurális programozás?

Off: azért megnézném én is azt a form-ot amin 1300 beviteli mező van. Főleg hogy az adatlapodon ez áll:
"Érdeklődési körök:
Frontend technológiák, felhasználói felületek tervezése, usability, szemantikus web, XSLT."
33

Nagyon jól megértetted a

Hidvégi Gábor · 2016. Feb. 11. (Cs), 10.33
Nagyon jól megértetted a helyzetet, tényleg így van. A webes programozás közben rendkívül sok az absztrakciós réteg, nagyon messze vagyunk a hardvertől, és még távolabb kerülünk, ha a desktop fejlesztésben megszokott, elavult technikákat alkalmazzuk, mint például az objektumorientált megközelítés, vastag kliens felépítés (amikor az alkalmazáslogika a böngészőben van).

Ha megnézed bármelyik keretrendszer saját oldalán lévő példákat, azok tipikusan Móriczka-egyszerűségű alkalmazások, amivel csak annyi a baj, hogy a való életben nem erre van szükség. Nem kihívás infinite scrollt egy olyan listán prezentálni, amiben soronként egy div van. Így viszont fejlesztőként nem lehet felelős döntést hozni, hogy melyiket válaszd egy új projekt esetén.
34

és az számodra

solkprog · 2016. Feb. 11. (Cs), 16.33
és az számodra elképzelhetetlen hogy más életét meg megkönnyíti mondjuk az oop? (úgy hogy lényegében még lassabb se lesz a kód).

Vagyis tudja mikor kell használni, és tudja hogy hogy.

"fejlesztőként nem lehet felelős döntést hozni, hogy melyiket válaszd egy új projekt esetén."
De lehet, én pl mobile verzióba eszembe nem jutna behúzni az ext js-t. desktop verzióba lehet. Függ a feladattól. Feladathoz kell eszközt választani, és nem fordítva. ("fúj minden absztrakció")
35

Elképzelhető, de biztos nem

Hidvégi Gábor · 2016. Feb. 11. (Cs), 16.53
Elképzelhető, de biztos nem ezek között van a Sencha és a Facebook.

Feladathoz kell eszközt választani, és nem fordítva.
Ez igaz, de nem vetted figyelembe azt, amit előtte írtam.
36

Ez szerintem az az eset,

bamegakapa · 2016. Feb. 11. (Cs), 17.01
Ez szerintem az az eset, amikor a feladat rossz. Egy ház esetén ilyenkor ránéz a mérnök, és azt mondja, ácsi, ez a terv hülyeség, nem építünk semmit, vissza a tervezőasztalhoz. Rossz tervhez az eszközök is rosszak lesznek, mert akik tervezték őket, jó tervekhez találták ki. Nem csoda, hogy a frameworkok elhasalnak 1600 form elemnél, mert a készítőknek eszébe sem jutott volna erre tervezni, okkal. Ettől persze még vannak rosszul tervezett frameworkok is.
37

Lehet lenyűgöző egy

Joó Ádám · 2016. Feb. 11. (Cs), 17.10
Lehet lenyűgöző egy látványterv, ha statikailag kivitelezhetetlen :)
39

A saját példámon látom, hogy

Hidvégi Gábor · 2016. Feb. 11. (Cs), 17.50
A saját példámon látom, hogy kivitelezhető elég sokminden, csak akarni kell, meg sajnos meg kell kérdőjelezni pár berögzült szokást.

Anno mindenki szidta az IE6-ot, hogy milyen bugos, de arra nem vették a fáradságot, hogy találjanak olyan módszert, ami működik minden aktuális böngésző alatt, pedig mindegyik hibájára volt megoldás. Vagy hogy nem lehet alatta átlátszó png-ket használni, bezzeg a Mozilla - pedig akkor már évek óta volt kidolgozott módszerem a dologra.
40

Persze, csak nem mindegy,

Joó Ádám · 2016. Feb. 11. (Cs), 19.02
Persze, csak nem mindegy, hogy milyen költséggel. A kerülőmegoldásoknak ára van, meg kell őket valósítani, karban kell őket tartani, át kell látni, javítani kell a velük bevezetett hibákat, és lehet, hogy kezelni kell a teljesítményvonzatukat.
42

+1

solkprog · 2016. Feb. 11. (Cs), 20.32
+1 Ádám

"Anno mindenki szidta az IE6-ot, hogy milyen bugos, de arra nem vették a fáradságot, hogy találjanak olyan módszert, ami működik minden aktuális böngésző alatt"

Gábor te hol dolgozol? Hol mondja meg a fejlesztő hogy milyen böngésző az amit támogat?
Ez szerintem normális helyen úgy zajlik/zajlott IE6-esetében hogy:
- valamit megcsináltunk működött mindenhol kivéve IE6
- ha elvárás volt hogy működjön, és ugyanúgy nézzen ki IE6-ban akkor megcsináltuk, ha nem volt extra erő befektetés.
- ha átlagon felüli extra befektetés volt az IE6 support annál a feature-nél, akkor szóltunk a vezetőnek, PO-nak hogy "két nap lesz az hogy IE6-ban is ugyanúgy nézzen ki, - megcsináljuk, vagy hagyjuk így hogy ott nincs lekerekítve az a doboz?"
és a PO/vezető szépen eldöntötte a kérdést.
Marhára nem "nem vettük a fáradságot"... - ha igény volt rá megcsináltuk, ha nem volt igény rá nem csináltuk meg.

Gábor meg lehetőség szerint kérlek ne nézd már a komplett szakmát hülyének, és lustának.
44

Ezt a mondatot én sem

bamegakapa · 2016. Feb. 11. (Cs), 22.31
Ezt a mondatot én sem értettem. Mindig találtunk megoldást, de attól még szar volt, és nagyon nem sírom vissza. IE7, IE8, IE9 ugyanez, de most már úgy tűnik, egyszer vége lesz és viccelődve fogunk emlékezni. Annál több időt lehet szánni hasznos teendőkre.
78

Hát hálistennek már lassan

inf3rno · 2016. Feb. 13. (Szo), 12.42
Hát hálistennek már lassan kifut ez a rossz széria, az edge egész tűrhető.
84

Pont nemrég játszottam vele,

bamegakapa · 2016. Feb. 13. (Szo), 13.43
Pont nemrég játszottam vele, és kifejezetten elégedett voltam. Ha nem következik be gyökeres változás, anélkül is normális böngészőt használnak majd az átlag júzerek, hogy szomszéd Pistike felrakná nekik a firefox/chrome-ot. Ez nekünk valódi örömhír.
45

Igazad van, bocsánatot kérek

Hidvégi Gábor · 2016. Feb. 12. (P), 14.31
Igazad van, bocsánatot kérek az arrogáns hozzászólásaim miatt. Az nyilván az én bajom, ha találtam olyan módszert, ami nulla, kivételes esetben minimális plusz munkával működött bármely böngészőn, és sosem merült fel, hogy ne támogassam ezt vagy azt a verziót.

Persze, messziről jött ember azt mond, amit akar, úgyhogy beszéljenek inkább a számok! 2009-ben, még a CSS3 éra előtt én készítettem az iWiW egyik sitebuild-jét (talán az utolsó előttit) külsősként. Egy oldalra tettem fel minden elemet, így a backend programozók onnan mazsolázgatták össze a különböző blokkokat.

Mint látható, nem egy manapság divatos, minimalista dizájn, bár nem is igazán bonyolult. A HTML + CSS kód összesen 24411 + 30995 = 55405 bájt, az IE hack-eket tartalmazó CSS 719 bájt, ami a teljes kód 1,3%-a. Ennyi plusz munkát jelentett az IE6 és IE7 támogatása, az oldal IE 5.5 alatt 90%, 5.0 alatt pedig 80%-os volt, azaz teljesen használható, pedig ez utóbbi két böngészőben más a dobozmodell.

Érdekességként megjegyzem, hogy a tervezés fázisában az iWiW részéről felmerült az Ext.JS használata, amiről én beszéltem le őket.
46

és most mit szerettél volna elmondani?

solkprog · 2016. Feb. 12. (P), 16.39
Most gratulálnom kéne hogy pl képeket használtál border radius helyett? Meg úgy egyébként minden helyett képeket használtál? Ami miatt egyrészt pixeles az egész, másrészt lassítottad a pl firefox-os usereket is?

"az IE hack-eket tartalmazó CSS 719 bájt"
tévedsz, az egész egy IE hack.

"iWiW részéről felmerült az Ext.JS használata, amiről én beszéltem le őket."
Okos döntés volt.. Ja, pont az iWiW-et akik korábban indultak mind a facebook, de a végén túl lassan fejlődtek. (és terjeszkedtek)
Szóval lebeszélted őket az ext js-ről, ettől ők lassabban készültek el, - és ráadásul végeredmény meg még felhasználó szempontból is lassú lett.

(megjegyzés: nem tudom hogy 2009-ben iWiW helyében használtam volna-e ext js. de az biztos hogy a gyors dinamikus, gyors release-ek irányába mentem volna el. És igen tudom utólag könnyű okoskodni, de ez már akkor is így gondoltam)
47

Ha pixelesnek látod, az a jó,

Hidvégi Gábor · 2016. Feb. 12. (P), 17.30
Ha pixelesnek látod, az a jó, mert pont úgy volt a látványterven. A border-radiust nem támogatta az akkoriban még eléggé elterjedt IE 7-8 páros.

tévedsz, az egész egy IE hack.
Miért? Csak IE-ben működik? Mindenhol máshol szétesik?

Szóval lebeszélted őket az ext js-ről, ettől ők lassabban készültek el, - és ráadásul végeredmény meg még felhasználó szempontból is lassú lett.
Miért készültek volna el lassabban, hogy nem ext.js-t használtak? Mi közöm van nekem ahhoz, hogy a szerveroldalon milyen gyorsan állítják elő az oldalt?
48

kezdek belefáradni ebbe a beszélgetésbe

solkprog · 2016. Feb. 12. (P), 17.58
"Mi közöm van nekem ahhoz, hogy a szerveroldalon milyen gyorsan állítják elő az oldalt?"
Ki beszélt backend oldalról? iwiw mindenhogy lassú volt. backend, és frontend oldalon is.

És azért IE hack az egész, mert a komplett oldal képekből áll, és azért áll a komplett oldal képekből mert az IE-ben csak úgy lehetett megoldani. (és téged nem érdekelt az akkori modern böngészők _normális_ támogatása)

"A border-radiust nem támogatta az akkoriban még eléggé elterjedt IE 7-8 páros."

És akkor mi van? a firefox meg támogatta, aminek nagyobb volt a részlesedés mint az ie nek összesen. Vagyis te úgy optimalizáltál a kisebbségre hogy a többséggel kitoltál. okos.
(nehéz megérteni hogy mi azért szidtuk az IE-t mert - mondjuk a border radiust témánál maradva - megcsináltuk a lekerekített sarkot css-ből, de az IE-ben plusz munkával meg még csinálhattuk meg hogy ott meg kép behúzással)
50

iwiw mindenhogy lassú volt.

Hidvégi Gábor · 2016. Feb. 13. (Szo), 00.43
iwiw mindenhogy lassú volt. backend, és frontend oldalon is
Ehhez nekem már semmi közöm, csak a HTML-t kellett elkészítenem, a többi már a Virgo feladata volt.

és téged nem érdekelt az akkori modern böngészők _normális_ támogatása
Az akkori modern Firefox 3.5 csak -moz előtaggal támogatta a border-radiust, ami egy dolog, de a kedvedért letöltöttem, és végeztem egy kis mérést nagyjából ötezer elemen: a lekerekített sarkot konkrétan ugyanannyi idő alatt rajzolja ki, mintha ugyanazt háttérképpel csinálom meg, darabonként a jó Atom processzoromon 0,13ms alatt. Mivel én két elemet használtam a háttérképek miatt, így kétszer annyi idő volt a renderelés, ami 18*0,13ms időt vett igénybe, border-radiussal 9*0,13, azaz összesen 1ms időt vesztettem vele, plusz nem is úgy néz ki, ahogy a látványterven.

Én inkább feláldoztam ezt a kemény 1 ezredmásodpercet, és legalább minden böngészőn ugyanúgy nézett ki. Viszont akárhogy nézem, túl sok képet ma sem tudnék megspórolni, tele van az oldal apró ikonokkal.

a firefox meg támogatta, aminek nagyobb volt a részlesedés mint az ie nek összesen. Vagyis te úgy optimalizáltál a kisebbségre hogy a többséggel kitoltál. okos.
Igen, az IE akkori 35%-os "kisebbsége" nem számít, nekik jó lesz a fapados élmény 1 ezredmásodperccel gyorsabban. Igen, ez racionálisan hangzik, jól kitoltam velük : )
52

számolni az tudsz.

solkprog · 2016. Feb. 13. (Szo), 01.15
Zseniális a számolásod, csak épp elfelejted leszámolni azt a féltucat (és akkor nagyon jó indulatú voltam) képet amit az IE-miatt kellet behúznod. Egyébként meg komolyan gondoltad hogy lassabb lesz mérhetően a kép vs border radius _kirajzolás_. Hogy ezt meg kell mérned. Ki a fene beszélt a kirajzolás sebességéről?

"túl sok képet ma sem tudnék megspórolni, tele van az oldal apró ikonokkal."
Komolyan? 60 kép betöltésből ma se tudnál sokat megspórolni? Ezt most tényleg komolyan mondod?
10, max 15 nél több képet nem lenne szabad behúznod. tudod sprite is van a világon. (és akkor arról most már nem beszélünk hogy talán már te se csinálnád a box kerekítést képből, vagy a szín átmeneteket képpel. bár ezek után ebbe se vagyok biztos)

Én : "iwiw mindenhogy lassú volt. backend, és frontend oldalon is"
Te: "Ehhez nekem már semmi közöm, csak a HTML-t kellett elkészítenem, a többi már a Virgo feladata volt."

Tényleg behúzul 60 képet a felhasználókkal és semmi közöd hozzá hogy lassú lesz?
53

Hmm, egy tucat képen

Hidvégi Gábor · 2016. Feb. 13. (Szo), 01.33
Hmm, egy tucat képen vitázunk, konkrétan két kilobájtról, ezek kirajzolása igazán processzorizzasztó és sávszélességfogó művelet.

tudod sprite is van a világon
Ha megnézed azokat a képeket, az összes azonos méretű, azonos szerepű ikont sprite-tal oldottam meg. A hirdetéseken kívül a képek mérete 73 kilobájt. Emiatt volt lassú az iWiW? Az én 1,3GHz-es Atom processzoromon (kikapcsolt turbóval) az oldal 65ms alatt renderelődik le IE alatt. Ez sok?

Egyébként meg komolyan gondoltad hogy lassabb lesz mérhetően a kép vs border radius _kirajzolás_. Hogy ezt meg kell mérned. Ki a fene beszélt a kirajzolás sebességéről?
Akkor viszont nem értem, hogy mivel van gond.
55

http

solkprog · 2016. Feb. 13. (Szo), 02.03
"ezek kirajzolása igazán processzorizzasztó és sávszélességfogó művelet."
Szerintem elégé világos hogy nem a processzorizzasztásról beszélek. De ha nem lett volna világos az előbb már egyszer leírtam. De akkor újra: nem erről beszélek.

"azonos szerepű ikont sprite-tal oldottam meg"
Miért az nem azonos szerepű sprite-okat nem lehet sprite-olni? technikai akadálya lett (pár éve nem frondendezek), vagy vallási oka van?

".....sávszélességfogó művelet"
Ugye tudod hogy működik a http?

Ferdíteni azt tudsz. te 1ms ról beszélsz hogy annyival lassabb a kirajzolás.. (úgy hogy senki se beszélt a kirajzolási sebességről)
Akkor elmondom a bajom: 1 darab kép betöltése még ha csak 1x1 px-eles is, akkor is kb 50ms (mert kb ennyi idő kell neki mire leér a szerverről)

Ajánlom tanulmányozásra ezt:
http://www.webpagetest.org/result/160212_J8_1WRC/1/details/
a 160KB fél másodperc lehúzni, mert 60 darabban van
57

Csak az azonos jellegű és

Hidvégi Gábor · 2016. Feb. 13. (Szo), 09.05
Csak az azonos jellegű és méretű képeket szoktam kirakni sprite-ba. Tisztában vagyok vele, hogy minden http kérésnek van ára, sőt, azt elfelejtetted írni, hogy 2009-ben még a szélessáv is jóval lassabb volt, mint ma.

Ez viszont az oldal kirajzolási sebességét és a felhasználói élményt biztosan nem rontotta, hisz egyrészt a böngészők egyszerre több párhuzamos http kapcsolatot tudnak nyitni (az 500ms-t oszd el nyugodtan néggyel), másrészt fix elemmérettel és - ha nem átlátszó a kép, - fix háttérszínnel dolgozom, ahol lehet, azaz a háttérképek leérkezése előtt a böngésző már ki tudja rajzolni az elemet a végleges méretével.

Az első betöltés után meg már minden gyorstárból jön.
59

párhuzamosítás

solkprog · 2016. Feb. 13. (Szo), 10.06
Csak az azonos jellegű és méretű képeket szoktam kirakni sprite-ba.
Szerintem vizsgáld felül ezt a megszokásod.

"Ez viszont az oldal kirajzolási sebességét és a felhasználói élményt biztosan nem rontotta, hisz egyrészt a böngészők egyszerre több párhuzamos http kapcsolatot tudnak nyitni (az 500ms-t oszd el nyugodtan néggyel), "

Ez a 4 honnan jött neked? az IE6-7 nél az kettő volt.

Másrészt miért kéne elosztanom akármennyivel is? Megnézted a linkem? a valós körülmények között volt fél másodperc a képeid betöltése IE 11-ből - frankfurból

Igen van gyorsítótár is a világon, de azért azt tudni kell hogy nem telepátiával tudja meg a kliens hogy mi a legfrissebb verzió az adott tartalomból. Ez 60 képnél 60-kérés.
61

Ha a háttérképeket fix méretű

Hidvégi Gábor · 2016. Feb. 13. (Szo), 10.21
Ha a háttérképeket fix méretű elemen használom, valóban még több mindent össze lehet vonni egy sprite-ba, de ha változhat a dimenziója, akkor ezt nem lehet megtenni.

Egyébként nem értem, hogy kapcsolódik a szálhoz ez a sprite-os dolog, hisz ez nem böngészőspecifikus.

Igen van gyorsítótár is a világon, de azért azt tudni kell hogy nem telepátiával tudja meg a kliens hogy mi a legfrissebb verzió az adott tartalomból. Ez 60 képnél 60-kérés.
Szerencsére feltalálták az Expires fejlécet.
65

sprite

solkprog · 2016. Feb. 13. (Szo), 11.02
Ha a háttérképeket fix méretű elemen használom, valóban még több mindent össze lehet vonni egy sprite-ba, de ha változhat a dimenziója, akkor ezt nem lehet megtenni.

Már miért ne lehetne megtenni? Legfeljebb lesz egy üres rész a sprite-ba később, és?
Pl nézd meg a google egyik sprite-ját:
https://www.google.hu/images/nav_logo242_hr.png


A sprite meg onnan jött a szálba hogy azt mondtad hogy ma se tudnád sokkal kevesebb képpel megoldani azt a design. Én meg közöltem hogy sprite is van a világon.

És igen ha normálisan be vannak állítva a cache-ek akkor a második kérésnél már "gyors" lesz. Csak ezzel a logikával az a gond hogy ha lassú a site, akkor nem lesz második kérés, a felhasználók ott hagyják az oldalt.

Most komolyan pont te próbálod megvédeni a fél másodperces lassúságot? Pont te?
67

Sprite

Hidvégi Gábor · 2016. Feb. 13. (Szo), 11.19
Megnéztem, átgondoltam, igazad van, a képek egy részét bele lehetne tenni egy darab sprite-ba.

Csak ezzel a logikával az a gond hogy ha lassú a site, akkor nem lesz második kérés, a felhasználók ott hagyják az oldalt.
Emlékeztetlek, hogy háttérképekről van szó, amik a tartalomtól függetlenül töltődnek le, így ez az érved nem állja meg a helyét, a böngészés ettől nem lesz lassabb, csak első betöltéskor az ikonocskák nem egyszerre jelennek meg.
69

háttérképek

solkprog · 2016. Feb. 13. (Szo), 11.34
"Emlékeztetlek, hogy háttérképekről van szó, amik a tartalomtól függetlenül töltődnek le, így ez az érved nem állja meg a helyét, a böngészés ettől nem lesz lassabb, csak első betöltéskor az ikonocskák nem egyszerre jelennek meg."

Ez csak akkor lenne igaz ha az egész oldal hátterekből állna. Tudod az iWiW-en volt némi tartalom is, pl az ismerőseink képei. Na most ha te 60 háttérképpel töltöd ki az időd akkor a fontosabb tartalom később fog leérni a userhez.

Nem tudom már hogy mondjam, nem a processzor idő, nem is a képek mérete a fontos, hanem hogy a sok apró fájlak fogtad a böngésző szálait amik tartalmat töltötték be.
71

Először

Hidvégi Gábor · 2016. Feb. 13. (Szo), 12.02
Az első alkalommal. Most hadd képzeljem el a szituációt: egy kedves ismerősömtől meghívót kapok az iWiW-re, megnyitom a linket, és az oldalon fél másodperces késéssel jönnek be legrosszabb esetben a nem a dizájnhoz tartozó képek. Ezen felháborodok, az ismerősömmel örökre összeveszek, majd szépen átmegyek a Facebookhoz.
74

fél másodperc.

solkprog · 2016. Feb. 13. (Szo), 12.18
Aha fél másodpercről beszélünk. A te egyik kedvenc példáddal array.forEach versus for ciklus -al mennyit is vesztünk?


"jönnek be legrosszabb esetben a nem a dizájnhoz tartozó képek."
Azt ugye tudod hogy a gyakorlat a legrosszabb esetről szólt? A css-be voltak megadva a képek, - a css html elején volt megadva, azért a böngésző először azokat töltötte be, és nem később a html-ben szereplő képeket.

"Ezen felháborodok, az ismerősömmel örökre összeveszek, majd szépen átmegyek a Facebookhoz."
Szeretem ezt a fajta érvelést, közlőd hogy az 1ms lassulás, elmondom hogy az fél másodperc, kicsit vitatkozunk, majd közlöd hogy "áá a fél másodperc se számít"

De akkor segítek rávezetni: a gyakorlatba nem 1 másodperc alatt jött be az iWiW. Nem mondom hogy csak miattad, - de közre játszott az is hogy 60-képet behúztál, mert nem sprite-oltál normálisan, és olyanokat is képpel oldottál meg amit css-ből is lehet volna oldani a többségnek.
77

Továbbra is érzékenyen

Hidvégi Gábor · 2016. Feb. 13. (Szo), 12.42
Továbbra is érzékenyen kerülöd, hogy az első betöltésről beszélünk, ami egy landing page, ahol regisztrálni lehet, még felhasználók képei sincsenek rajta.

A te egyik kedvenc példáddal array.forEach versus for ciklus -al mennyit is vesztünk?
A kettő között a különbség, hogy a forEach egy szinkron művelet, a háttérképek letöltése és megjelenítése aszinkron. Az első lassítja a fő szál futását, a második nem.

A css-be voltak megadva a képek, - a css html elején volt megadva, azért a böngésző először azokat töltötte be, és nem később a html-ben szereplő képeket.
Tévedsz, a böngésző a megjelenítés sorrendjében kezdi el betölteni a képeket. Ha egy stílusdefiníciót sosem alkalmaznak azon a lapon, a benne lévő háttérképet a böngésző nem tölti le. Ha nem hiszed, próbáld ki.

Szeretem ezt a fajta érvelést, közlőd hogy az 1ms lassulás, elmondom hogy az fél másodperc
Elég szelektíven emlékszel. Az 1 ms lassulást a border-radiusnál írtam, a fél másodperc pedig a háttérképek betöltése.
81

aszinkron ?

solkprog · 2016. Feb. 13. (Szo), 12.58
A kettő között a különbség, hogy a forEach egy szinkron művelet, a háttérképek letöltése és megjelenítése aszinkron. Az első lassítja a fő szál futását, a második nem.

Annyira teljesen aszinkron hogy az IE6-7 kettőt is hajlandó volt párhuzamosan csinálni. Vagyis párhuzamosan két szinkron dolgot csinált.


Továbbra is érzékenyen kerülöd, hogy az első betöltésről beszélünk, ami egy landing page, ahol regisztrálni lehet, még felhasználók képei sincsenek rajta.

1, a userek nem mindig a landing page-re érkeznek.
2, a landing page ha jól rémlik marhára nem így nézet ki. ergo ezeket az apró 1x1 -el képeket nem ott töltetted le velük.
3, nem lehet végtelen ideig cache-lni a statikus tartalmat. (ha csak nincs kezelve a verziózás normálisan)
82

A háttérképek letöltése és

Hidvégi Gábor · 2016. Feb. 13. (Szo), 13.08
A háttérképek letöltése és renderelése független a fő száltól Internet Explorer alatt is.

Emlékeztetlek, hogy a fentebb linkelt oldal tartalmazta az összes elemet, amit a teljes iWiW site-on használtak. Az egyes oldalakon ezeknek csak egy része jelent meg. Az meg, hogy mennyi ideig tart a gyorstárazás, majdnem teljesen indifferens a probléma szempontjából. Ha rosszul csinálták, akkor rövid ideig, ha jól, akkor sokáig. Ez most már sosem fog kiderülni.

Lehet ezen még rugózni, abba a tizenhárom képbe és stílusdefinícióba elég jól belekapaszkodtál mint utolsó szalmaszálba, de valahogy továbbra is az az érzésem, nem ezen múlott, hogy az iWiW gyors volt-e vagy lassú.
83

60 fájl

solkprog · 2016. Feb. 13. (Szo), 13.26
"A háttérképek letöltése és renderelése független a fő száltól Internet Explorer alatt is."
Szerencsére a modern böngészőkben a JavaScript-et is lehet async módon betölteni, és lehet aszinkron módon számoltatni javascriptben. (úgy hogy nem akad meg a főszál)


"tizenhárom képbe"
nem 13. 60.

De mindegy. Tőlem mikró optimalizálj továbbra is 1ms-okat, és veszítsz máshol fél másodperceket. mert az nem számít, mert csak egyszer kell, mert csak landing page, meg egyébként is..
Bánom én.
88

Szerencsére a modern

Hidvégi Gábor · 2016. Feb. 13. (Szo), 14.37
Szerencsére a modern böngészőkben a JavaScript-et is lehet async módon betölteni, és lehet aszinkron módon számoltatni javascriptben. (úgy hogy nem akad meg a főszál)
Persze, lehet, bár nem tudom, hogy jön ide. Te a .forEach-et így szoktad futtatni?

Akkor zárásként foglaljuk össze:
  • A 2009-es iWiW gyakorlatilag minden böngészőn ugyanúgy jelent meg, ennek az ára, hogy 13 képet kellett pluszban betölteni első alkalommal
  • a képek egy további részét egy sprite-ba lehetett volna tenni, így az első töltésnél meg lehetett volna spórolni böngészőtől függően 100-200 ms-t, amíg ezek a háttérképek betöltődtek
Ennyibe tudtál belekötni. Most lássuk neked pár 2009-es munkádat! Csak hogy legyen mivel összehasonlítani.
89

Te honnan szülöd a számokat?

solkprog · 2016. Feb. 13. (Szo), 14.52
100-200 ms-t, amíg ezek a háttérképek betöltődtek

Ezt a 100-200ms honnan szülted?

Fél másodperc. kérem szépen, már sokadszor mondom, fél másodperc.


"ennek az ára, hogy 13 képet kellett pluszban betölteni első alkalommal"
Az ugye világos hogy ha (had használjam a te szavaid) "vetted volna a fáradságot" akkor ezt a 13 -képet megsporolhatad volna az akkori modern böngészők használóinak (akik már akkor többségben voltak). és akkor sprite-olásról nem beszélünk.
90

Az ugye világos hogy ha (had

bamegakapa · 2016. Feb. 13. (Szo), 14.57
Az ugye világos hogy ha (had használjam a te szavaid) "vetted volna a fáradságot" akkor ezt a 13 -képet megsporolhatad volna az akkori modern böngészők használóinak (akik már akkor többségben voltak). és akkor sprite-olásról nem beszélünk.


Ennyi, be lehet mára zárni az internetet.
99

Fél másodperc. kérem szépen,

Hidvégi Gábor · 2016. Feb. 13. (Szo), 15.26
Fél másodperc. kérem szépen, már sokadszor mondom, fél másodperc
Nem lehet mindent egy sprite-ba betenni, akárhogy erőlködsz. De ha mégis, akkor javaslom, hogy szólj a juna.hu és az edigital.hu sitebuildereinek, hogy van még min csiszolni (de ha nem ismered őket, akkor bocsánat). Meg akárhogy rugózol, ezek a képek egyszerre egy oldalon úgysem jelennek meg. De ha még kicsit nézegeted a kótod, biztos találsz mást is, amibe bele tudsz kötni.

és akkor sprite-olásról nem beszélünk
Ha mégis sikerült volna beszuszakolnom ezt a tizenhárom képet az összes többivel egy helyre, akkor meg ugyanott vagyunk, ahol a part szakad.
106

edigital?

solkprog · 2016. Feb. 13. (Szo), 15.56
Jöhetsz egy olyan oldallal amit kb 17 évesen csináltam kb egy éjszaka alatt:) És azóta se nyúltam hozzá:) Igen szar, már akkor se volt szép, - ellenben sok pénzt kerestem vele:)


edigital.hu meg backend oldalt csináltam nagyrészt. És mellesleg amikor ott voltam akkor megcsináltam hogy fele annyi legyen az oldalbetöltés a user-eknek. Csak szólok. (és amikor ott voltam egyszer se döglődött le az oldal pl black friday alatt se)

És csak hogy értsd ez a sprite: edigital sprite
(igen ezt én csináltam, igen az urlben a verziózást is, és az subdomain-ezést is) (bár ahogy nézem az urlben a verziózást kicsit elszúrták azóta:)
107

Csak azért hoztam fel a

Hidvégi Gábor · 2016. Feb. 13. (Szo), 16.00
Csak azért hoztam fel a juna.hu-t, mert ha már a múltról beszélünk, és annyira ragaszkodsz a sprite-oláshoz, bizony ott is lehetett volna még összébbvonni a dolgokat. Az vesse rám az első követ, aki maga is bűntelen! Na, hát szerintem ilyen mikrooptimalizáláson vitatkozunk már egy ideje, és nem igazán látom az értelmét.

És akár hiszed, akár nem, még délelőtt láttam az itt linkelt sprite-ot, és az alapján írtam, hogy igazad van.
109

Az a különbség, hogy ő nem

bamegakapa · 2016. Feb. 13. (Szo), 16.07
Az a különbség, hogy ő nem jött ide, köpött a "lusta" programozók csizmájára, majd hencegett el azzal, hogy ő már akkor is hány kilobájt CSS-ből csinálta meg az iWiW-et (érted, az iWiW-et, arra nem akárkit kérnek ám fel!). Olvass vissza. A követ te vetetted, most meg sunyi módon döntetlent ajánlasz. Gratulálok.
110

iwiw vs személyes weblap?

solkprog · 2016. Feb. 13. (Szo), 16.13
Kérlek ne egy személyes weblapot amire beesett néhány száz user per hónap. vs napi milliós látógátóságú oldal-al vesd össze. Igen az egy fos. főleg mai szemmel.

Ott az edigital-ál. lehet az köpködnöd. (bár egyáltalán nem az a legnagyobb site ahol dolgoztam, közel sem.)

Csak ami az eszembe jut (ezeket én csináltam, és ennél fontosabb hogy az kezdeményezésemre csináltuk)
- optimalizáltam a css, js behúzást.
- a termék képeket betöltését oldalbetöltés utánra időzítettem.
- sprite-oltam a képeket
- tömörítettem a css, js-t
- megcsináltam az urlben a verziózást.
- kiküldtem a cache header-öket
- elkezdtünk használni cdn-t
- külsős js script-eket átírtam aszinkron működésre. (ha ők lehalnak ne haljon meg az edigital)
- elkezdtünk használni több sub domain hogy párhuzamosan tudjanak lejönni a statikus tartalmak.

De fogalmam sincs hogy ezekből mi maradt meg azóta.

(és egyáltalán nem vagyok büszke az edigital-ra. - sok mindent rendbe raktam ott én úgy érzem, sok mindent szabad időmben, - de nagyon sok mindent lehetne még ott tenni)
113

Én ezt elhiszem, de pont

Hidvégi Gábor · 2016. Feb. 13. (Szo), 16.23
Én ezt elhiszem, de pont olyanba kötöttél bele, amit az általad készített oldalakon is elkövettél vagy elkövettek mások. De akárhogy is nézem, nem hiszem, hogy ezen múlt az iWiW lassúsága.
115

nem én ezeket kijavítottam

solkprog · 2016. Feb. 13. (Szo), 16.40
"az általad készített oldalakon is elkövettél vagy elkövettek mások."

Amiket én kijavítottam. - úgy hogy marhára nem tartom magam frontend fejlesztőnek..

edigital sprite

iwiw egyik sprite a sok közül

Látszik a különbség?


A lassúság meg sok esetben apróságokon múlik. az előző hozzászólásomban a listán szereplő tételek megcsinálásával (kb 1 hét volt) felére esetet az oldalbetöltési idő.

Optimalizálok én is, sokat, de először ott kezdtem ahol sokat tudok nyerni vele kis erőbefektetéssel. És erre szerettem volna célozni hogy ha már foreach sebességén lovagolsz állandóan akkor talán másol is lehetne optimalizálni
117

Optimalizálok én is, sokat,

inf3rno · 2016. Feb. 13. (Szo), 18.53
Optimalizálok én is, sokat, de először ott kezdtem ahol sokat tudok nyerni vele kis erőbefektetéssel.


Azt hiszem érdemes kiemelni a lényeget, hogy más is lássa. :-)
116

Sprite-ot miért nem

inf3rno · 2016. Feb. 13. (Szo), 18.48
Sprite-ot miért nem generáltatsz? Vannak tök jó algoritmusok, amik becsomagolják neked optimálisan.
118

ritkán frissült

solkprog · 2016. Feb. 13. (Szo), 19.14
Erősen gondolkoztam rajta anno. De ott nem hiányzott a generálás hiánya, ritkán kellett hozzányúlni a sprite-hoz, és nem volt macera megcsinálni kézzel.
Illetve valami miatt valószínűleg most is kézzel csinálnám az edigital alá a sprite-ot, - de azt nem nem mondhatom el sajnos. :(

(ahol most dolgozok ott szerintem generálják a frontendessek a sprite-ot. nagyon helyesen)
54

(Balázs, kicsit kevesebb

Joó Ádám · 2016. Feb. 13. (Szo), 01.53
(Balázs, kicsit kevesebb indulattal, ha lehet.)
56

elnézést

solkprog · 2016. Feb. 13. (Szo), 02.08
(szimplán az indulatom oka hogy gyakorlatilag lustának titulálta a szakmát mert nem szerettük az IE 6-ot. Illetve azt érzem hogy vagy hülyének nézi a komplett szakmát, vagy troll.)

Elnézést, és Gábortól is ha megbántottam.

(
Viszont részemről még pár hozászolást szentelek neki, - ha nem sikerül nála elérni valamit (vagy neki nem sikerül meggyőznie az igazáról)
Akkor jó eséllyel én léptem a weblabor-ról. :-(
)
58

Nem fogsz nála elérni semmit.

bamegakapa · 2016. Feb. 13. (Szo), 09.56
Nem fogsz nála elérni semmit. Kinyilatkoztat, nem vitázik.
79

Miből gondolod, hogy egy

inf3rno · 2016. Feb. 13. (Szo), 12.46
Miből gondolod, hogy egy akkori gép teljesítménye hasonló volt, mint a "jó atom processzoré"? Simán lehet, hogy nem csak 1 ms-et vesztettél rajta, hanem sokszorosát...
49

Számold hozzá a képfájlokat

bamegakapa · 2016. Feb. 13. (Szo), 00.34
Számold hozzá a képfájlokat is, amik kiválthatóak lettek volna, ha nem kell az IE-vel szenvedni. De ha azokat nem is vesszük, értelmes böngészőkre ez kevesebből is kihozható, az IE hack CSS kicsit nagyobb lesz, de az kit zavar, a legtöbb felhasználó le se tölti.

Mindez persze már nem számít, a pattintott kőkorszaknak vége.
51

Összeszámoltam, 13 képről van

Hidvégi Gábor · 2016. Feb. 13. (Szo), 00.49
Összeszámoltam, 13 képről van szó, tekintélyes mennyiség, a többi (77) mind ilyen-olyan ikonocska és egyéb háttérkép, amit nem lehet kiváltani CSS-sel.
60

Valami okból azzal hencegtél

bamegakapa · 2016. Feb. 13. (Szo), 10.19
Valami okból azzal hencegtél hány bájt a CSS. Te tudod miért fontos ez. Csak szóltam hogy lecsaltál ezt azt.

A számok alapján nem győztél meg, hogy a te módszered jobb volt. Egy biztos. Ha mindenki úgy gondolkodik mint te, nem lenne minden böngészőben ma pl border radius. Én pedig már nem lennék frontendes. A szobrász aki kanállal faragja a követ, bár valahol szép teljesítmény és rohadt büszke rá, mégiscsak sültbolond.
62

Tizenhárom kép és kettő egész

Hidvégi Gábor · 2016. Feb. 13. (Szo), 10.34
Tizenhárom kép és kettő egész kilobájt, ezen múlik, hogy 2009-ben Magyarország egyik legforgalmasabb oldalán a látogatók 35%-a ugyanazt az élményt kapja, mint a modern böngészőket használó maradék ötven (-moz- prefix-szel). Elfogadom, hogy téged ez nem győzött meg : )

A szobrász aki kanállal faragja a követ, bár valahol szép teljesítmény és rohadt büszke rá, mégiscsak sültbolond.
Balázs legalább próbálkozik és érvel, de te eddig csak személyeskedtél. Persze ezt már megszokhattuk tőled.
63

Minek érvelnék. Eddig sose

bamegakapa · 2016. Feb. 13. (Szo), 10.45
Minek érvelnék. Eddig sose működött. Személyeskedem, hátha észreveszed magad, mert azt már elfogadtam, hogy megszabadulni nem fogunk tőled.

Az említett sültbolond akkor problémás, ha prófétának képzeli magát.

Balázs a te malmodra hajtja a vizet, és hamarosan őt is sikerül elüldöznöd innen. Hosszú a lista már.
66

Na de ha már felhívtál

bamegakapa · 2016. Feb. 13. (Szo), 11.11
Na de ha már felhívtál keringőre, végül is miért ne. A te számaidat fogom használni, mást úgyse hinnél el. Szöveges feladat:

Józsi elkészíti IE hackek nélkül ugyanazt a sitebuildet (a web akkori fejlettségi szintje szerint), amit Gábor készített. A 30kb CSS-ből így 5kb-ot (direkt kicsit írtam) megspórol. Ez az 5kb átkerül az IE-only CSS-be. A látogatok 35%-a így ugyanannyi adatot tölt le, a többiek 5kb-tal kevesebbet. Egy nagy látogatottságú oldal esetén, mint például az iWiW (ide jöhet egy adat az oldaletöltésekkel, nem nézek utána), egy év leforgása alatt a szerver mennyivel több/kevesebb adatot fog így kiszolgálni? Mit szól ehhez Gábor, aki köztudottan híve a környezettudatos munkavégzésnek?

Mint látod, nagyvonalúan kihagytam azt a 2kb-ot (és a vele járó lekéréseket, amik szintén csak 35%-ot érintenének), ami itt szerinted elhanyagolható, más threadekben technológiák bukását követelted miatta.
68

Jó lenne a példa, ha

Hidvégi Gábor · 2016. Feb. 13. (Szo), 11.27
Jó lenne a példa, ha nagyvonalúan a gyorstárazásról nem felejtkeztél volna el. Gondold át még egyszer!
70

Módosítsd nyugodtan a

bamegakapa · 2016. Feb. 13. (Szo), 11.46
Módosítsd nyugodtan a feladatot az iWiW vonatkozó statisztikái szerint (első oldalletöltések aránya). Így is elfogadom a benyújtott pályamunkát.

Reméltem elsőre meglátod a lényegét annak, amit írtam.
72

Előbb írj ki rendesen egy

Hidvégi Gábor · 2016. Feb. 13. (Szo), 12.04
Előbb írj ki rendesen egy feladatot, majd utána tárgyalunk.
73

Miért menekülsz el mindig,

bamegakapa · 2016. Feb. 13. (Szo), 12.11
Miért menekülsz el mindig, amikor szakmai érvekkel szembesülsz?

Az én szótáramban benne van, hogy "tévedtem".
80

Milyen szakmai érvek?

Hidvégi Gábor · 2016. Feb. 13. (Szo), 12.46
Milyen szakmai érvek? Felteszel egy kérdést, amiről két pillanat alatt kiderül, hogy nem gondoltad át, ráadásul olyan követelménye van (iwiw statisztika az első látogatókról), amihez nincs egyikünknek sem hozzáférése.
85

Ez még mindig menekülés. Az

bamegakapa · 2016. Feb. 13. (Szo), 13.56
Ez még mindig menekülés. Az iWiW akkor még jócskán számolt bővüléssel. Tehát az első letöltés nem elhanyagolható. De mivel eddig is nagyvonalú voltam veled, számolhatsz akármilyen százalékkal, ami neked tetszik. Legyen 1%.

Hány terabájt forgalmat tosztál ki az ablakon, energiatakarékos programozás élharcosa? Vagy nem tudtad, hogy többmilliós forgalmú oldal sitebuildjét készíted?

És a fő kérdés: mit nyertél azzal, hogy IE-re optimalizáltad a fő stíluslapot? Tényleg kíváncsi vagyok. Mert bár mi nem vettük a fáradságot, hogy megoldásokat keressünk problémákra, lusta disznóként szlopáltuk az egészségtelen kólánkat, de a mi oldalaink is működtek minden böngészőben, és nem voltak nagyobbak se, mint a te oldalaid, sőt a többségnek (az általad elfogadott 65% számára) kisebbek voltak, akkor mégis mi a francot nyertél az egészen?

Tudod az még nem lenne olyan nagy baj, legfeljebb neked, ha a saját dogmatikus hülyeségeidet előbbre helyezed a tényeknél, a tényeket pedig csak akkor veszed figyelembe, ha épp alátámasztják az álláspontodat, de hogy emellé még folyamatosan az ellenkezőjéről prédikálsz 0-24, az baromi szánalmas, unalmas és destruktív. Maradj csöndben, tedd félre a berögzült elméleteidet és figyeld a világot. Tök jó.
87

Mondj konkrétumokat, minek az

Hidvégi Gábor · 2016. Feb. 13. (Szo), 14.29
Mondj konkrétumokat, minek az 1%-áról beszélünk, utána lehet számolgatni. A fő stíluslap IE-re való "optimalizálása" 13 képet, azaz 13 stílusdefiníciót érintett a 315-ből.

a mi oldalaink is működtek minden böngészőben
Tudnál párat linkelni? Hadd nézzük már meg!

folyamatosan az ellenkezőjéről prédikálsz 0-24, az baromi szánalmas, unalmas és destruktív
Nem muszáj olvasni.
91

Válaszolj a kérdéseimre.Azt

bamegakapa · 2016. Feb. 13. (Szo), 15.00
Válaszolj a kérdéseimre.

Azt is elfogadom, ha beismered, hogy tévedtél és ostoba módon fikáztál olyanokat, akik nálad okosabbak voltak.

Elég már belőled. Vagy húzz el innen, vagy tanulj meg viselkedni, kommunikálni, vitatkozni. Sajnálom, hogy erre nekem kell figyelmeztesselek.
93

Azt is elfogadom, ha

inf3rno · 2016. Feb. 13. (Szo), 15.02
Azt is elfogadom, ha beismered, hogy tévedtél és ostoba módon fikáztál olyanokat, akik nálad okosabbak voltak.


Ez nem ennek az Istennek az idejében fog megtörténni. Mondjuk már jön be az iszlám, úgyhogy lehet, hogy még a te életed során. xd
95

Mert ki vagy te, hogy

Hidvégi Gábor · 2016. Feb. 13. (Szo), 15.11
Mert ki vagy te, hogy bármilyen következménye lenne a figyelmeztetésednek? Még egy kérdést sem tudsz feltenni normálisan, pedig szakembernek tartod magad, aztán meg követelőzöl, hogy válaszoljak.
98

A közösség egy tagja. Annak a

bamegakapa · 2016. Feb. 13. (Szo), 15.22
A közösség egy tagja. Annak a közösségnek, aminek te folyamatosan fölé helyezed magad. Nincs a kezemben semmilyen hatalom, így nem ígérhetek következményeket. A személyemet támadhatod, mert nem tartom különösen nagy szakembernek magam, így ez lepereg.

De ismét felszólítalak: vagy viselkedj, vagy menj és ne gyere vissza.
100

Kibic

Hidvégi Gábor · 2016. Feb. 13. (Szo), 15.30
Felszólítalak: fejezd be a személyeskedést, vagy menj, és ne gyere vissza!
102

Akkor egyikünknek mennie

bamegakapa · 2016. Feb. 13. (Szo), 15.46
Akkor egyikünknek mennie kell. Én nem tűröm tovább, amit művelsz és nem békülök, ha nem változtatsz. Várom a felsőbb erők döntését.
105

Távozz innen sántán!

Hidvégi Gábor · 2016. Feb. 13. (Szo), 15.51
Távozz innen sántán!
111

Urak, ezt a szálat tényleg az

Joó Ádám · 2016. Feb. 13. (Szo), 16.18
Urak, ezt a szálat tényleg az örökkévalóságnak szánjátok?
112

Részemről igen, lássa

bamegakapa · 2016. Feb. 13. (Szo), 16.20
Részemről igen, lássa mindenki. Előbb-utóbb döntened kell.
114

Ádám, válaszút elé kerültél,

Hidvégi Gábor · 2016. Feb. 13. (Szo), 16.30
Ádám, válaszút elé kerültél, mint a stafétával : )
92

"Nem muszáj olvasni."

solkprog · 2016. Feb. 13. (Szo), 15.01
"Nem muszáj olvasni."

Aha, tényleg nem. El lehet üldözni az embereket innen. Ahogy már az összes kollégám (akit személyesen ismerek) sikerült.
És én is határán vagyok. 2016-ban azzal hogy vesszen az oop, vesszen az ajax, meg minden ami modern, azzal nem tudok mit kezdeni. Főleg egy olyan emberrel akit meg kell győzni hogy sprite-olni jó dolog.
97

Nem is kell mit kezdeni,

inf3rno · 2016. Feb. 13. (Szo), 15.17
Nem is kell mit kezdeni, ignorálni kell, mert feleslegesen pazarlod hülyeségekre az energiáidat. Ő egy párhuzamos dimenzióban él, és valamiért az ottani net az ittenire csatlakozik. Fizikusok jobban el tudnák magyarázni. A lényeg, hogy minden fordítva van, ami itt hülyeség, az ott teljesen valid best practice...
101

Én is pacifista vagyok, de

bamegakapa · 2016. Feb. 13. (Szo), 15.40
Én is pacifista vagyok, de van az a pont és károkozás, amin túl már nem lehet ignorálni valamit, hanem fel kell lépni ellene. Ez a pont nálam eljött. Nem kell ebből nagy ügyet csinálni, számtalanszor megkértük, hogy változtasson, magasról tett rá. A figyelmeztetések ideje lejárt, nem használtak.

Én is azt tapasztalom, mint solkprog. A Weblaboros bögrémet vagy megmosolyogják, vagy szomorú nosztalgiával tekintenek rá.
104

Harcolj!

Hidvégi Gábor · 2016. Feb. 13. (Szo), 15.50
A végén még ki is közösítenek emiatt, ad absurdum ki is rúgnak, hisz saját bevallásod szerint sem vagy egy nagy szakember : ( Sőt, még új munkahelyet sem fogsz később találni, a kezedben lévő Weblaboros bögre mementóként emlékeztetni fog arra a sok kárra mindenkit, ami itt történt.
108

Szóval úgy véled, hogy annak

bamegakapa · 2016. Feb. 13. (Szo), 16.02
Szóval úgy véled, hogy annak ellenére, hogy elég sok vallomást olvashattunk már különféle helyeken (Twitter, Tumblr, vagy itt is), hogy miattad vált vállalhatatlanná ez a hely, a közösség még mindig jobban jár, ha tovább folytatod eddig tevékenységed? Törődsz bárkivel magadon kívül? Amíg van bármekkora hallgatóságod, neked mindegy?
103

évekig megtettem, ignoráltam

solkprog · 2016. Feb. 13. (Szo), 15.47
Évekig ignoráltam. Kezdetben érdekes volt (még nagy ritkán elgondolkoztató is), néztem hogy sorra leálltok vele vitatkozni. Néha már én is nehezen bírtam (nem hozzászólni), de láttam hogy nincs értelme, racionális érvekkel nem lehet meggyőzni, ha meg sarokba szorul akkor elkezd félrebeszélni (vagy csak szimplán nem válaszol)

Látszik is hogy az utóbbi pár évben szinte nem is szóltam hozzá a weblabor-on..:( (pont miatta)

Viszont én eddig bírtam, már alig van értelmes arc a weblaboron, - és már szinte nincs értelmes topic. És nem csak komolyabb topic-ok - amit szinte már csak te küldesz be -, hanem már kezdők se írnak ide szinte. De azt a pár topic-ot is szét offolja.
119

Hát én sem nagyon küldök már

inf3rno · 2016. Feb. 13. (Szo), 19.19
Hát én sem nagyon küldök már semmit, néha egy-egy blogmarkot. Az igazság az, hogy már talán két éve beletörődtem, hogy a weblabor lemegy a süllyesztőbe, így sok értelmét nem látom. Ami éppen érdekel, arról bloggolok, ha van rá kapacitásom, ott úgysem olvassa senki, úgyhogy bármit írhatok bármilyen stílusban. Nem titkoltan részben magamnak szoktam összefoglalókat írni egy-egy témában, mert nálam sokkal jobban megragad így, mintha csak olvasok róla. Rövidesen erre se lesz időm, mert visszatérek az orvosi biotechnológiához, és amellett inkább statisztikára meg befektetésekre akarok több időt szánni. Hogy a szoftverezést milyen formában viszem tovább a saját célú projekteken felül, az még nem kerek. Egy darabig valószínűleg sehogyan.
86

Menekülés a konkrétumok elől...

T.G · 2016. Feb. 13. (Szo), 14.08
Sajnos Gábor barátunkra ez a menekülés igen jellemző. Közel három és fél évvel ezelőtt kérdeztem tőle, hogy tudna-e végre valami konkrétumokat is mondani, nem csak mindenre sz.rt dobálni? De konkrétumokig azóta sem jutottunk. Lelkesen évente belinkelem ugyanazt a bejegyzésemet, hogy hátha azóta lett egy kis ideje azzal a projekttel is foglalkozni (ami már három és fél éve is készen volt), ám sajnos a sok trollkodás mellett eddig erre nem jutott szabadidő... Gábor, tényleg nem lehetne valami konstruktív dologgal előállni? Azt már mindenki tudja, hogy mik azok a dolgok, amelyek neked nem tetszenek. Oké, szerintem mindenki megértette, de mik azok, amelyek pozitív példák lehetnének? Ami mellé oda lehetne állni? Ami nem csak a meglévő technológiák fikázása?
94

Ja, Gábor, a próféta, a

bamegakapa · 2016. Feb. 13. (Szo), 15.11
Ja, Gábor, a próféta, a zseni, akit saját kora sajnos még nem értett meg... az a helyzet, hogy a nagy zsenik le is raktak valamit az asztalra. Én nem látom azt a teljesítményt, aminek alapján ezt a stílust itt folytatnia lehetne. A tudásáért, a tapasztalatáért kár, ha a közösség érdekében kamatoztatná, nagy nyereség lenne. Én csak rombolást, támadást látok tőle és most már elegem van. Nem teszem meg azt a szívességet, hogy én is lelépek.
96

Nehogy elmenj, inkább maradj

Hidvégi Gábor · 2016. Feb. 13. (Szo), 15.13
Nehogy elmenj, inkább maradj itt személyeskedni, meg "szakmai" kérdéseket feltenni.
38

Látom, nem érted a dolgot. A

Hidvégi Gábor · 2016. Feb. 11. (Cs), 17.40
Látom, nem érted a dolgot. A feladat nem rossz, hanem adott. Írtam korábban, hogy átnéztem, és legfeljebb pár elemet lehet lespórolni soronként, de mindegyik mező fontos információt hordoz.
41

És nem lehet ezt az űrlapot

Joó Ádám · 2016. Feb. 11. (Cs), 19.03
És nem lehet ezt az űrlapot szétbontani?
64

Sajnos nem

Hidvégi Gábor · 2016. Feb. 13. (Szo), 10.49
A könyvelők miatt lehetne külön űrlapra tenni 10 mezőt, ami a kontírozással és a feladással kapcsolatos, viszont a cégvezetés számára fontos, hogy egy helyen lássanak minden adatot.
43

Értem a dolgot, és együtt is

bamegakapa · 2016. Feb. 11. (Cs), 22.27
Értem a dolgot, és együtt is érzek, mint írtam. Láttam már Góliát űrlapokat de láttam UX-eseket is, ahogy Dávidokat készítettek belőlük.

Ha olyan házat kell építeni, aminek alul van a teteje, akkor érthető, ha az általános házépítő technikák nem fognak működni. Ez nem azt jelenti, hogy a technikákkal baj van, és azoknak is szopni kéne, akiknek nem kell 1500 elemet kipakolni egy űrlapra.

Ez a folyamatos haragvás a világra, a programozókra, a cégekre, a technológiákra meg mittomén még mire nem tesz jót. Lazíts kicsit.
31

Okoskodni könnyű, ez igaz. Ha

bamegakapa · 2016. Feb. 11. (Cs), 10.09
Okoskodni könnyű, ez igaz. Ha 1600 elemű az űrlap (vagy akár csak 50, számomra már az is elképzelhetetlenül sok), és ez egyszerre ki is van cseszve a képernyőre, akkor a tervezésben volt a hiba, lehet az implementáció apróságain pörögni, de minek. Nem az OOP meg a HTML a te ellenséged.

Viszont így már értem a keserűséget, ezúton biztosítalak együttérzésemről.
120

Rendben, urak, miután

Joó Ádám · 2016. Feb. 13. (Szo), 19.27
Rendben, urak, miután sikerült szétflémelni a témát, és aki akart az oldalba is belerúghatott egy párat, a hozzászólások itt szünetelnek. A felmerült kérdésekre hamarosan visszatérünk.