Rendszerkritika

Avagy tűnődéseim a mai magyar webprogramozói szakma aktuális állapotáról

Mottó: Akinek nem inge, ne vegye magára. Amúgy meg leszarom, ha besértődsz, nem vagy nekem se kutyám, se macskám

Motivációs levél helyett

Immáron évek óta próbálom Magyarországon meghonosítani a frontend kódolás minőségbiztosítását, ami idáig teljes kudarccal végződött. Megállapítható, hogy a teljes magyar szakma kódminőség-igénytelen, a programozók pedig „tökéletesek”, egoisták, és semmi nemű szakmai kritikát, észrevételt nem bírnak elviselni. Így tehát nem is meglepő, hogy QA-ssal nyomokban sem találkozhatunk Magyarországon. Tekintettel arra, hogy webrogramozással a multik nem foglalkoznak, a komolytalan cégek pedig komolytalanok, így a magyarországi középcégeket céloztam be, mivel ott van elegendő számú weboldal project ahhoz, hogy ki tudjam élni a szabványkódolási hajlamaimat. Az eredmény zérus. Azért vannak szabályt erősítő kivételek is. Üdítő kivételként említhetem meg a Jacsomedia-t, ahol bíztató kezdeti lépéseket tettek a minőségi webprogramozás irányába. Eddigi tapasztalataim szerint csak itt találtam QA-sokat, habár igaz, ők is csak elsősorban a végfelhasználói felületek tesztelésével foglalkoznak a különböző eszközökön, és nem a kódminőség revideálásával, de legalább vannak. Gondoltam, emeljük a tétet, és be is jelentkeztem, azonban a CEO kifejtette, hogy én tulajdonképppen túlképzett vagyok ahhoz, hogy neki dolgozzam, tehát paff. Magyarul életkor alapú diszkrimináció áldozata lettem, ami fölöttébb lenyűgöző. A CEO vagy bő 15évvel fiatalabb nálam, és talán nem akarta, hogy a nyakára telepedjek. Szóval itt sem jártam sikerrel. Volt, ahol azt a választ kaptam, hogy erre nincs igény. Ez minden bizonnyal Freud-i elszólás volt, mert én is pont erről beszélek. Az egész magyar szakma igénytelen, de nemcsak hogy simán igénytelen, hanem még a változásra, fejlődésre sincs igénye. Cak az ügyfél lehúzására. És ez - sajnos - meg is látszik a magyarországi weboldalak katasztrófális műszaki minőségén. Nézzük sorban:

Elöljáróban leszögezem, hogy nem az OKJ-sekkel van bajom, mert attól, hogy valaki nem végzett el egy egyetemet, még lehet a tudására és a munkájára igényes, és lehet sokkal tehetségesebb annál, aki az új bolognai rendszerben könyvtár-büfé szakon végigvegetálta az egyetemi éveit. De azokkal az OKJ-sekkel csak bajom van, akik tökéletesek. A továbbiakban - az esetleges félreértéseket és megsértődéseket kerülendő - az OKJ-s jelző alatt azokat értem, akik igénytelenek a munkájukra és a tudásukra. De a jelenlegi helyzet kialakulásért felelős az új felsőoktatási bolognai rendszer is, ahol OKJ-s kaliberű kurzusokért krediteket lehet szerezni, így az egyetemi hallgatók még csak nem is motiváltak a tényleges tudás megszerzésére, de a gondolkodásra sem. Ezeken a kurzusokon „szerzett” „tudás” már akkor elavult, amikor az egyetemről kikerülnek. És erre a lepusztulási folyamatra az utóbbi időben egyre jobban felerősödő munkaerőpiaci „trendek” is ráerősítenek, amikor is a tényleges tudás helyett már csak a „BingóDB” épp aktuálisan felkapott százhuszonikszpontnullás verziójának „ismeret”-ét akceptálják.

A full-stack developer mítosza

Én nem hiszek a full-stack developer létezésének mítoszában, mert aki mindenhez ért, az tulajdonképpen semmihez sem ért. 16 éve fogalkozom a Mozilla fejlesztő csapatában QA tevékenységgel. Főleg a CSS modul fejlesztése, tesztelése, kutatása tölti ki az időmet. Ugyanekkor folyamatosan supportálok front-end webfejlesztőket ugyanennyi ideje, és alkalmanként még a world wide web konzorcium dolgaiba is beleütöm az orromat, a W3C szabvány fejlesztésével kapcsolatos kérdésekben. Tehát van némi közöm a CSS szabványspecifikációhoz. Foglalkoznék mással is, de időkapacitás hiányában úgy alakult, hogy a többi komponensre nem futotta az időmből, és talán a CSS komponens sem egy egyemberes feladat. Emellett, még szakítani tudtam időt a ChatZilla csetkliens fejleszétésre is. Ennek ellenére support-tevékenységem során még mai beleszaladok 1-1 olyan kérdésbe, amire nem tudom promptra a választ, sőt van, hogy néha 1 napot is gondolkodnom kell mire érdemi választ tudok adni egy-egy extrém kérdésre. Továbbá a bugreportok során még ma is előfordul, hogy egyes szabványügyi kérdésben vakra futok, tehát akkor nem állíthatom, hogy mindent tudok, ami CSS. A fentebb említett időkapcitás hiánya miatt, epdig eleve nem érthetek a JavaScripthez, az SVGhez, a Canvashoz, a webxtensionhöz, az user-interfce-hez és még sorolhatnám, hogy milyen komponensekből áll össze egy böngésző. Mivel ez tényleg nem egy egyemberes feladat. Tehát igazából nem is tudom, hogy egyáltalán értek-e bármihez is.

Ezzel szemben az OKJs full-stack az nagyon ért mindenhez, a bootstraptól kezdve az scss-en át a jquery-ig mindenhez, fene nagy egója van, miközben ilyen weboldalakat fejleszt: www.stegmajer.hu Nem linkelem be, mert nem akarok büntetőpontokat kapni a Google-tól, amiért ipari szemétre mutató hivatkozások vannak a weboldalamon, akit érdekel, másolja be magának a címsorba, és nézze meg. A weboldalt a google kibannolta a keresési listáiból, mivel a weboldal egyáltalán nem felel meg szinte semmilyen műszaki-technológiai követelényrendszernek. Tehát sehol nem jön fel az oldal sem az „ügyvéd budapest”, sem az „ügyvédi iroda budapest” kifejezésekre indított találati listákban. Országosan pedig főleg nem. A weboldalra évekkel ezelőtt egy hirdetés kapcsán bukkantam, akkor még egy kliens oldali React applikcáicó volt, és természetesen a google be sem mappolta, mivel nem volt rajta semminemű statikus content. Ezt minden bizonnyal érzékelték is, mert látom a SEO nyomait a weboldalon, de a fejlesztők ahelyett, hogy kiiktatták volna a teljesen fölösleges React template-ezést az egyoldalas microsite kizárólag konstans adatokat tartalmazó landing-page-éből, fogták, és az egészet berakták wix mögé dupla pénzért, havidíjért. Az eredmény lenyűgöző: egy 700kByte-os generátum, ami mértetét tekintve messze, nagyságrendileg meghaladja a google feldolgozási limitet és a józan ész felső határát. Konklúzió: a google továbbra sem mappolja be, sőt még külön bünteti is a site-ot, mint extrém túlméretes oldalt, ami alapvetően nagyon rossz felhasználói élményt nyújt. És innentől kezdve nincs az a kereső-optimalizálós (SEO) cég, aki kulcsszótrükközésekkel vagy a weboldalra mutató, blogcikkekben elhelyezett hivatkozásokkal vissza tudná varázsolni a site-ot a google találati listájába, ha azt egyszer onnan a google a gyenge minőségi mutatók miatt kibannolta. Ez a site a jelenlegi formájában, mint React-wix kombó, nem más, mint az ügyfél gátlástalan, erkölcstelen és szélhámos lehúzása. A microsite-landing-page hasznosanyagtartalma egyébként kb 5kyte, de még a beágyazott CSS-sel együtt is csak kb 30kbyte volna, így 700kbyte-or generátum a teljes szakmai hozzánemértés tanúbizonysága.

A google mítosz, és ami mögötte van

Manapság egy kis cég, ha a webről akar magának ügyfeleket, nem kerülheti meg a googlet, ami gyakorlatilag monopolhelyzetben van jelenleg a keresők piacán, így nem is kerülhető meg. Tehát, kedves fejlesztő, ne hidd, hogy a google be fogja olvasni a gagyi React appodat. Mert miért is tenné. Nem is fogja betöltögetni a like-buttonokat, a facebook pixeledet és főleg nem fog ajaxon keresztül becsatlakozni a szerveredre, hogy onnan szedje le a content-et, ami alapjáraton hiányzik a weboldaladról, mert erre a világ össze számítógépe sem volna elég, hogy havi szinten bemappoljon minden oldalt teljes feldolgozással. Persze végez a google teljes render teszteket is, de ezt viszonylag ritkán teszi, és akkor sem minden aloldalra, mert költséges. Például mobilkompatibilitás teszt. Ez persze rossz hír az OKJs full-stack fejlesztőknek, mert ha egyszer elrontják a weboldal reszponzivitását például, és felkerülnek a google halállistájára, akkor hiába javítják ki a hibát, a weboldal még jó sokáig halállistán marad, mire a google hajlandó újra lefuttatni a tesztet és az alapján levenni a weboldalt a halállistáról.

Sok a mítosz a googlebot körül, pedig nincs semmi google titkos tudás. A google a szabványos irányelveknek megfelelő, szemantikailag jól struktúrált, és ezáltal részben vagy teljesen akadályementes, redukált HTML dokumentumokat szereti, mert ezeket tudja értelmesen(!) feldolgozni. Ennyi a nagy titok. Például minden dokumentumnak (könyv, újságcikk, stb.) van címe. Ezért a googlebot szereti a <H1> elemet. Ezt nagyon sokan tudni is vélik, ezért biztos, ami biztos, 5 darabot is raknak a weboldalukba. Ezt viszont a googlebot már nagyon nem szereti. Mert ha egy dokumentum még a címében is ellentmondásos, azaz még azt sem tudja magáról eldönteni, hogy fiu-e vagy lány, akkor a tartalma is nagy valószínűséggel egy zavaros katyvasz. És ennek megfelelő besorolást is kap. Továbbá, minél mélyebben van a DOM-fában egy információ, annál kisebb a jelentősége. Valami alapján rangsorolni kell a weboldalakat.

Íme itt van az OKJ-s full-stack HTML kódja:

  <div class="wrap">
    <div class="row">
      <div class="col_sm_3">
        <div class="color_black">
          <div class="align_center">
            <div class="bold">
              <h1 style="color: hotpink !important; float: left;">Na, ennyit tudsz</h1>
            </div>
          </div>
        </div>
      </div>
    </div>
  </div>

Nah ez szó szerint full-stack! Elásva! Mert az OKJ-s full-stack az egyszerre ért mindenhez, a bootstraptól kezdve az scss-en át a jquery-ig és a reactig mindenhez, sőt, még használja is ezeket, ha már ért hozzá. A google pedig annak rendje és módja szerint ki is takarítja a full-stack webszemetet a keresési rendszréből, a google felhasználóinak legnagyobb megelégedésére és örömére, mindannyiunk szerencséjére.

Csak azért mert valami van, még nem biztos, hogy használni kell.
Csak azért, mert valaki kitalálta a carouselt, még nem biztos, hogy minden weboldalba carouselt kell rakni.
Csak azért, mert van react, még nem biztos, hogy minden weboldalt kliens oldali template-ezéssel kell előállítani. Sőt. Látsd fentebb, google.
A fogorvosnak is van fogója, mégsem biztos, hogy egyből húzni kell, mert lehet, hogy csak egy kis fogínygyulladás. Szerencsére nincsenek OKJ-s full-stack fogorvosok.

Egy valami biztos, ha a google a találati listák első oldalain komolytalan találatokat, wordpress Mari néni Bt-ket, webszemetet hozna fel, akkor senki sem használná a google keresőt. Tehát a minőségi szűrő működik és hasznos.

Isten óvjon a tökéletes emberektől

Szokásom, hogy ha egy céghez elsőként jelentkezek be, akkor veszem a weboldalukat, pontosabban annak egy - általam érdekesnek tartott - részét, És azt a design megtartásával HTML-CSS alapon újraírom, és ezt küldöm be nekik, mint prezentáció, vagy nevezzük beugró feladatnak, azért, hogy lássák, én hogyan kódolnám le az adott weboldalt a szabványos irányelveknek megfelelően, amikről beszélek. Azonban volt rá precedens, hogy ettől az eredeti kód készítői egyszerűen besértődtek, hogy beleszóltam a munkájukba. Nos. Annak az embernek nem lehet segíteni, aki tökéletes. A tökéletes emberekkel nem lehet együttdolgozni. Így tehát én nem is akarok olyan cégnek dolgozni, ahol mindenki tökéletes. Az én kódjaim például nem tökéletesek. Akárhányszor befejezek (megunok) egy kódot, mindig belátom, hogyha most kezdeném el, akkor már másképpen csinálnám. Tehát bármit lehet mégjobban csinálni.

A tartalom és az arculat szigorú elválasztásának elve és a tervezési feladat

Vegyük a következő példát: <div class="align_self_justified">. Nos, ilyet nem égetünk bele a HTML kódba, mert dilettáns, kókler megoldás. Azt majd az UX/UI designer megmondja, hogy mit, mikor, hol és hogyan akar látni a képernyőn, és legfőképp melyik képernyőn(!). Ebbe például egy backendes ne üsse bele az orrát. De a frontendes sem.

A weboldal gerince, a HTML-kód, mint web-interface és ennek megtervezése minimálisan mérnöki feladat. Egy OKJ-s full-stack ne akarjon web-inteface-t tervezni. De tovább megyek: aki igénytelen a tudására, az egyáltalán semmit se akarjon tervezni, vagy ha ilyen ambiciója van, akkor előszőr qvalifikálja magát a tudását illetően. Mert különben olyan eredmények születnek, mint fentebb az ügyvédi iroda honlapja. Tehát ipari szemét. A web-interface az egyész weboldal jövőbeli sorsát meghatározza, márcsak a google-beli poziciója által is.

Ha, és amennyiben az UX/UI designer elvárásként támasztja a frontenddel szemben a pixel-azonos megjelenést, akkor viszont a front-end web-interface tervezője joggal várja el a backend-től a byte-azonos HTML-kód kigenerálását. Mert ez a tervezési munka elvégzőjének a feladata és felelőssége. A backendesek úgyis szeretik többre tartani magukat a frontendeseknél (nem tudom, mire föl), miközben alaphangon arra sem képesek, hogy a megadott specifikációban leírt szabványos irányelveknek megfelelő HTML-kódot autodidakta módon kigenerálják. Mert „ezt nem támogatja a wordpress”, mert nem oldható meg 2 kattintással, vagy egy modul betöltésével, vagy pedig mert csak egyszerűen gondolkodni kéne a feladaton egy picit, ami viszont luxus.

A szabványos webkódolás és az akadálymentesség kapcsolata

Egy weboldal nem attól lesz akadálymentes, hogy duplapénzért leimplementálunk egy olyan tour-t, ahol fekete alapon sárga lóbetűkkel kiabálunk. Az akadálymentes weboldal a HTML webstruktúra akadálymentességét jelenti. Csak a szemantikailag jól struktúrált HTML-kód lehet akadálymentes. A szabványos webkódolás, az ezzel kapcsolatos irányelvek és előírások betartása teszik a HTML-kódot akadálymentessé, illetve akadálymentesíthetővé. Ez az akadálymentesség előszobája. Továbbá jelenleg Uniós direktíva, törvényi előírás például a közintézmények weboldalai akadálymentességének biztosítása. A weboldal akkor akadálymentes, ha a felolvasóprogram értelmes(!) szövegként tudja felolvasni a weboldal tartalmát. Ezzel szemben, amit ma a közintézmények honlapjain láthatunk, katasztrófális. A szemantika teljes hiánya, vagy káosz, extrém mélységű DOM-fák, semminemű szemantikai jelentéssel nem rendelkező, a végtelenségig egymásbaágyazott <div>-ek tömkelege, miközben a hasznos információ a feneketlen mélységbe van elásva, semminemű struktúráltság. Aztán ott van például újabban a twitter bootstrap betöltése, ami egyszerre teszi a közintézményt köznevetség és közbotrány tárgyává, mert jogos adófizetői elvárás egy közintézménnyel szemben - ha már az adóforintokat költik - hogy olyan webfejlesztő cégnél költsék azt el, ahol legalább a media-query-t ismerik 2019-ben. Ezek a mai közintézményi honlapok nemcsak, hogy nem akadálymentesek, nemcsak hogy nem felelnek meg a törvényi előírásoknak, Uniós direktíváknak, de még csak nem is akadálymentesíthetőek.

Amikor a HR-es farok csóválja a kutyát

Ha egy adott pozició kapcsán az IT divizió szakmai vezetője név szerint nem érhető el, az a pozició eleve komolytalan. Így arra - tapasztalataim szerint - bejelentkezni sem érdemes. Történt az eset egy általam konkrétan megnevezni nem kívánt céggel, nevezzük egyszerűen piactérnek. Szokásom, hogy ha egy nem IT céggel veszem fel a kapcsolatot, akkor először kielemzem a weboldalukat, koncepciót dolgozok ki az általam javasolt módosításokra, amit leegyszerűsített prezentációkkal egyészítek ki, és ezt küldöm be, mint vitaalap. Azonban, ha a HR-es hiperaktív, de mivel dilettáns a műszaki-szakmai kérdésekhez (nem ez a dolga, végzettsége), mégis előfordul, hogy elovassa, de nem érti, így kikukázza azt ahelyett, hogy továbbítaná az illetékes szakmai vezető felé. Egyébiránt, már csak az illendőségből, ha már energiát és munkaórákat fektetek be egy konkrét megkeresésbe, annyit illene visszabökni, hogy „Köszönjük észrevételeit, továbbítottuk az illetékes felé, és megfontolás tárgyává teszzük”. De nem. A hiperaktív HR-es dönt. Én pedig elgondolkodom, hogy akarok-e egyáltalán olyan céggel dolgozni, ahol kompetencia-zavaros emberek hoznak szakmai döntéseket a szakmai vezetés helyett. Ha pedig mégis látta a szakami vezető a megkeresést és úgy nem volt érdemi hozzáfűzni valója, az meg már régen rossz. Mindegy is, de egyszer csak azt látom, hogy a linkedin után fél évvel, a facebookon is bepróbálkoznak állásajánlattal, mert azóta sem találták meg a „megfelelő” embert, akkor elgondolkodom. Például feltűnt, hogy az ominózus cég egyszerre keres mindenkit. Mint valami startup. Vajon milyen viszonyok uralkodhatnak egy olyan cégen belül, ahol egyszerre mond fel mindenki, am-block? És miért nem találnak senkit hosszú hónapok sora alatt sem? Itt valami bűzlik... Akárhogy is, most ennek a cikknek az írása közben ismét pillantást vetettem a piactér webes felületeire (semmi érdemi változás) ismét csak azt látom, hogy már megint keresnek valakit ugyanarra a pozicióra ki tudja már mennyi, 1 vagy több év távlatában, még mindig káosz van, mert ilyen magas fluktuáció indokolatlan. Most épp bootstrapos-backened-est keresnek (ami egy önellentmondás), miközben technológiának nevezik a bootstrapot. A bootstrap nem technológia, hanem egy ostoba stíluslap. Így tehát mostmár erős kételyeim támadtak a szakmai vezető alkalmasságát illetően is, amiért eleve egy ilyen álláshirdetés kijöhet, ezt vele meg lehet csinálni, mindezt hagyja, vagy egyszerűen nem veszi észre. Mindezt mondom egy vagy kettő év távlatából, arra alapozva, amit kívülről látok a cégből és a megnyilvánulásaiból.

Mikor lesz a nodeJS webszerver?

Egyik ismerősöm keresett fel egy problémával, volt egy többcsatornás csetalkalmazása, amit socket.io angular alapon tettek össze, viszont nem úgy működött, ahogy elvárható lett volna. Például a csatornák közötti váltások akár 1 percet is igénybe vettek, mire az angular újra kigenerálta a korábbi üzenetekből álló nézetet. Ez így logikusan nem volt használható. A feladat tehát ennek kioptimalizásáa volt. El is kezdtem nézegetni az angular tutorialját, amiből eléggé siralmas következtetést vontam le - ez egy logikátlan szar - továbbá, mire ez a nyakatekert működési elvet megértem, addigra simán leimplemetálom nativ js-ben az egészet. És így is tettem. A socket.io amúgy is deprecated, helyette az RFC szabványban definiált websocket protokollt illik használni, így tehát az ment a lecsóba. Az angularra nem is voltam hajlandó időt fecsérelni, tehát az is kuka. Körülbelül 2 hete vett igénybe, mire megírtam natív js-ben a kliens oldalt, miközben olyan extrákra is futotta, mint a saját grafikus szmájlik használata az üzenetekben text-minta-illeszkedés alapján. És még mással is foglalkoztem ezen idő alatt, nem csak ezzel. De fokozzuk az élvezeteket. Jött a server oldal nodeJS websocket alapon természetesen mysql alapon, mert a mongoDB is hetente összeomlott a cset-archivum alatt teljes adatvesztéssel. Ez is hozzávetőleg 2 hetet vett igénybe 0-ról kiindulva a kész kódig, egyedül a vmware tesztszerverem bekonfigurálásába segitett be a devops, mert ahhoz már végképp nem akartam érteni. Úgy látszik, jó érzékem van ahhoz, mivel ne foglalkozzak fölöslegesen, mert mire végeztem, addigra ki is jött at angular újabb verziója, amivel az eredti alkalmazás már el sem indult. Ennyit a backwards-compatibility irányelvekről. Mindenestre megállapithatom, hogy RFCszabvány alapján nativ JS-ben kódoloni jobb, mert a szabványt legalább nem irják át félévente a használhatatlansága miatt, ellentétben az angularral. Ez volt az én websocketes, nodeJS-es „Hello World”-öm. Ezzel a kis kirándulásom a nodeJS világában időlegesen véget is ért, mert egyelőre nem alternatíva, mint webserver. És amíg az egy adott weboldal megjelenését alapvetően befolyásoló INSERT-ek és UPDATE-ek kényszerszinkronizálása nem megoldott az aktuálisan futó linuxdisztribúciókon elérhető nodeJS verziókban, addig, mint http server, nem rúg labdába. Az ugyanis nem járja, hogy az egész weboldalt egy többsztörösen egymásba ágyazott, kusza Promise-hell-be kelljen csomagolni callback-hell feloldás címszó alatt. (a promise csak egy nyakatekert pótmegoldás). Majd később...

CMS vagy nem CMS?

Bő tizeniksz évvel ezelőtt, az egyik volt kollégám keresett meg azzal, hogy itt van ez az új CMS filozófia, és a Drupal. Vettem is egy Drupal könyvet, de a 3. fejezetnél rájöttem, hogy mire ezt a könyvet elolvasom, annyi idő alatt tudok írni egy ugyanilyet ugyanennyi hibával. Így a továbbiakban nem foglalkoztam vele. Mindenesetre megjegyzendő, hogy a jelenleg használt klasszikus CMS-ek közül messze a drupal a legstabilabb és legbiztonságosabb. De ennek ellenére a CMS-ek egyáltalán nem lopták be magukat a szívembe, így azóta sem jelentkezem be sehova se backend-esként, mert ezzel egyszerűen nincs kedvem szórakozni. Egyedi CMS, ami átírható, az még talán szóba jöhet.

Milyen template-ezőt használjunk kliens oldalon?

A nagy nyilvánosságnak szóló - tehát a googlebot által is bejárandó - statikus adatokat tartalmazó oldalon semmilyet sem. De vannak jelszó által védett adminfelületek, vagy "noindex" oldalak, például egy kosár, ott már lehet használni. Az angular nálam kiesett a pixisből fentebb említett okok miatt. Viszont tudom javasolni a Vue template-ezőt, ami teljesen letisztult filozófiával rendelkezik, a HTML-be ágyazott template élesen elkülönül a javascript kódtól, és már (majdnem) kompatibilis az XHTML-lel is. Tehát a Vue-re szavazok.

Fluent Speech English

16 éve dolgozom nemzetközi szintéren, de úgy, hogy ez a 16 év alatt egy árva szó sem hagyta el a torkomat angol nyelven, tehát azt teljesen el is felejtettem. És nagyjából fölösleges is újra megtanulnom. Nem vagyok tolmács, hogy élőszóban angolozzak. Pszichológus meg főleg nem vagyok, hogy bárkivel is társalogjak. Inkább egy bölcsészt kéne keresni. A bölcsészeket pont az ilyen munkakörök betöltésére és az ilyen munkafeladatok ellátására tenyésztették ki. Írásban viszont bárkivel nagyon szivesen kommunikálok angolul is, ha kell.

Néhány gondolat a megöregedésről

Ha az a tény jelenti azt, hogy megöregedtem, hogy senkivel sem vagyok hajlandó elmenni a szabadidőmben paint-ball-ozni, akkor büszkén vállalom, igen, megöregedtem. Értelmetlen dolgokra elvből nem fecsérelem az időmet. Arról nem is beszélve, hogy egy munkaadó ne mondja meg, hogy mit csináljak a szabadidőmben, mert nem vagyok a felesége. Disztingváljon már! Majd ha unatkozom, akkor majd lesupportálok néhány usert, vagy matatok néhány bugreportban, de paint-ball-ozni garantáltan nem fogok.

Kinek a dolga az Adobe Photoshop és az Adobe Illustrator ismerete?

Természetesen csak az UI designeré. A frontend kódolója az Adobe termékcsaládból kódvisszafejtésre az Adobe DreamWeaver-t használja, mert arra a munkafeladatra az való. A DreamWeaver a jól struktúrált PSD állományt dolgozza fel és konvertálja át. Itt a jól struktúráltságon van a hangsúly. Így tehát, ha az UIdesigner slendriánságból az egérrel gondolkodik, azaz az egérrel ide-oda huzigálja az objektumot, majd egérrel átméretezgeti, akkor a DreamWeaver is csak egy transform-ra tudja azt átkonvertálni, amit ugyan „megenne a css”, de a kódminőség szempontjából a beintegrálása nem fogadható el. Legyen a tervezési folyamat tudatos. Tehát minden ilyen esetben visszakérdezek, hogy igenis mondja meg egzakt módon, hogy most konkrétan hány pixeles betűméretet talált oda ki, hány pixeles margóval és hány pixeles behúzással.

Továbbá a jelenleg használatos böngészőkben van gradient támogatás, így ha gradient-tel találkozom, akkor konkrétan kérni fogom az átmeneti színkódokat is a UIdesignertől, mert nem a 90-es években vagyunk, hogy képet illesszek be a kódba. Továbbá a jelenleg használatos böngészők nem támogatják sem a mesh, sem a conic gradient-et, így ezek használata az UIdesigner részéről kerülendő, még akkor is, ha azzal jobban nézne ki. Technológiai korlát.

Továbbá bizonyos objektumokat vektoros SVG formátumban kérek, aminek az előállítása Adobe Illustratorral ugyancsak az UI designer feladata. Esetleg bemenő paramétereket adok meg, hogy mekkora viewBoxban kérem például.

Milyen böngészőket támogassunk 2019-ben?

Alaphangon már csak a szabványkövető böngészőket. Az Edge bőngésző a 18-as főverzióval végleg megszűnik, helyette az új Edge már a chromium blink motorjával fog futni, így tehát tulajdonképpen a továbbiakban egy chrome böngésző lesz alapértelmezett Bind keresővel és Microsoft-os nyitólappal. Az Internet Explorer támogatása már évekkel ezelőtt megszűnt. Ennek ellenére még van statisztikailag kimutatható felhasználása, ezért bizonyos esetekben mérlegelendő a további időszakos támogatása is, de már csak az IE11 verziónak, és ott is már csak annyira, hogy ne omoljon benne össze végzetesen a layout. Az Egde a 19-es verziójától kezdve, mivel blink motor, nagy valószínűséggel elérhető lesz a régebbi Windows platformokon is, így az Internet Explorertől záros határidőn belül végleg megszabadulhatunk.

Most már 2019-ben nem elrugaszkodott gondolat azt mondani, hogy amennyiben a megrendelő ragaszkodik a különböző Explorer verziók támogatásához, akkor bizony a feladat mostmár egy önálló Explorer-tour leimplementálása (természetesen ennek megfelelő felárral), mégpedig úgy, hogy ez a tour legyen élesen elkülönítve a weboldal normális(!) részétől, például egy lehetséges megoldás saját aldomain használata "noindex,nofollow" oldalakkal a keresőrobotok kiiktatása végett, és cloaking, redirektálás segítségével dobni át oda azt a néhány embert, aki még - tévedésből - Explorert használ. Talán az erre vonatkozó kiegészítő árajánlat eltántorítja a megrendelőt egy rossz igény megfogalmazásától, mert az Explorer támogatás 2019-ben már többet árt a weboldalnak, mint amennyit használ.

Library-mentes webprogramozás

Minden korszaknak megvannak a maga kóklerei. És megvannak a maga tiszavirágéletű, divatból felkapott library-jai is.
Kezdetben volt a prototype (ki emlékszik ma már erre a library-ra?)
Aztán jött a jquery.
Aztán jött a bootstrap
Most meg feltűnt a fellegekben az SCSS

Kezdetben mindenkinek prototype-os ember kellett. Hiába mondtuk neki, hogy ezt nem kéne erőltetni, ő makacsul ragaszkodott hozzá, hogy prototype-os ember kell neki. Vagy nem kellett az ember. (Ki emlékszik ma már ezekre a webfejlesztő cégekre?)
Aztán mindenkinek jquery-s ember kellett. Hiába mondtuk neki, hogy ezt nem kéne erőltetni, ő makacsul ragaszkodott hozzá, hogy jquery-s ember kell neki. Vagy nem kellett az ember.
Aztn mindenkinek boostrapos ember kellett. Hiába mondtuk neki, hogy ezt nem kéne erőltetni, ő makacsul ragaszkodott hozzá, hogy bootstrap-os ember kell neki. Vagy nem kellett az ember.
Most pedig az SCSS-t kezdik el felkapni, mint gyöngytyúk a taknyot.

A jquery egy workaround és polyfill könyvtár. Nem teljesen haszontalan, mert nem kell minden alkalommal újra és újra feltalálni a spanyolviaszt. Így tehát érdemes bogarászni a forráskódjában. Akárhányszor belefutok a jquery-be, és nem tudom promptra a szabványos választ, mindig kiemelem belőle az érintett kódrészletet. De kapásból azzal kezdem, hogy máris gyopálom kifele belőle az Explorer6-kompatibilis polyfill kódokat, mert ezeknek a használata 2019-ben nemcsak fölösleges, hanem egyenesen káros is. Ma már irányelv, hogy ha például egy animációnak nincs natív támogatottsága egy adott eszközön, akkor ott nem animálunk. Ezek az eszközök elavultak, feltehetően rosszul karbantartottak és belassultak, tehát az erőforrásait indokolatlanul kiterhelő hardkódolt kamu animációk rendkívül rossz felhasználói élményt nyújtanak ezeken az eszközökön. Sőt, például a scrollhijack (parallax,smoothscollig) használatáért ma már a google kőkeményen büntet, ha ilyet detektál a render-teszteken, mivel ez a hardkódolás teljes mértékben osszeegyeztethetetlen a böngészők beépített optimalizációs algoritmusaival, mint például a lazy-scroll mobilon. A jquerynek már a puszta betöltése is jelentősen megnöveli a weboldal memóriaigényét és mindent belassít, mivel alaphangon a prototipusokat definiálja felül, így ha kell, ha nem, minden DOMcsomópont érintetté válik. De sokszor csak azért töltötték be, hogy a document.getElementById helyett $-t használjanak, mert azt gondolták, hogy ettől majd szépnek és okosnak fognak látszani.

Aztán jött a twitter bootstrap. Ez a stíluslap arra lett kitalálva, hogy a twitter felhasználói klikk-klakk-módszerrel egyedi profilokat tudjanak maguknak létrehozni. És másra nem is jó.
Aki valamaelyest is ért a bootstraphoz, az nem használja. Konklúzió: azok használnak bootstapot, akik semmit sem értenek az egészhez, így tehát az eredmény is borítékolhatóan webszemét lesz. Egy programozótól elvárható, hogy 2019-ben értsen a media-query-khez. Ha mégsem, akkor talán keressen magának egy másik OKJ-s gyorstalpalót (pl. targoncás), mert ez a mostani OKJ-s próbálkozása egyszerűen nem jött be.

Azoknak pedig, akik most kezdenek ráizgulni az SCSS-re, már előre szólok, hogy még mindig érvényben van az az irányelv, hogy szigorúan tilos a layout-ot script-függővé tenni. És mindezt csak azért, mert lusta begépelni a kontextuálisokat. Mert míg a bootstrapnak volt annyi értelme, amikor a mobileszközök robbanásszerű elterjedésével gyorsan kellett hozzánemértő emberekkel reszponzívvá tenni a már meglévő weboldalakat, de már ennek az új projectekbe történő beletolása fölöttébb ostobaság. De viszont az SCSS (SASS, LESS, Stylus) beletolása a projectekbe, már nem ostobaság, hanem egy nagyon súlyos szakmai hiba, sőt bűn. A CSS nem programnyelv, és soha nem is lesz az. És tilos programnyelvesíteni sznobizmusból.

Azt, hogy egyáltalán használunk-e library-t, és ha igen, milyet, mindig a konkrét project dönti el, mint ahogy azt is, hogy adott esetben semmilyen library-t sem használunk. De az, hogy divathullámoknak felülve minden projectbe, ha kell, ha nem, beletoljuk az éppen aktálisan felkapott tiszavirágéletű kreatív hulladékot, nemcsak indokolatlan, de szakmailag elfogadhatatlan, és a teljes hozzánemértésről tesz tanúbizonyságot.

Az ügyfelek lehúzásáról

Tudni kell nemet is mondani egy ügyfélnek. Ha az ügyfél nem tudja, vagy nem akarja megfizetni a minőségi webfejlesztés árát, akkor azt kell neki tanácsolni, hogy nincs szüksége weboldalra. Meg kell győzni, hogy bizonyos költségkeret alatt csak olyan megoldás születhet, amit saját magán, a közvetlen hozzátartozóin és a barátain kívül úgysem fog megnézni senki sem. És ők is csak egyszer. Így tehát fölösleges pénzkidobás. Inkább költse azt a pénzt a gyerekeire.

Aki pedig hajlandó megfizetni az árat, azt nem kéne gátlástalanul átverni és lehúzni, mint például azt fentebb az ügyvédi iroda honlapja esetében láthattuk.

Néhány zaftos kritikai észrevételem az álláshirdetések gyenge minőségéről

Egy ideje figyelgetem az újonnnan megjelenő álláshirdetéseket, és elég lehangoló képet festenek.

Mindig lenyűgöznek az olyan pozicióajánlatok, amik úgy kezdődnek, hogy „Elvárásaink”, majd pedig következik egy három képernyőoldal hosszúságú lista. Szögezzük le, polihisztorok nincsenek és nem is lesznek. Fentebb kifejtettem mind a full-stack mítosszal kapcsolatos véleményemet, mind pedig az „elvárásokkal” kapcsolatos véleményemet. Mármint, hogy mire „áll be” a munkerőpiac a szakmai felhígulás ereményeképpen. A „BingóDB” százhuszonikszpontnullás verziójának ismerete nem tudás. Kérdés: a delikvens érti is a működését, adott esetben tud-e írni egy ugyanolyat vagy hasonlót, mert gyanítom, hogy nem. Már pedig, ha nem érti még a működését sem, akkor nehezen várható el tőle, hogy optimális kódot írjon vele. Valójában nem programozó, hanem csak egy alkalmazás felhasználója.

Nekem egy emberrel szemben csak egy elvárásom van: legyen igényes a tudására és a munkájára, a többi úgyis kiforrja magát egy-egy adott konkrét projekt kapcsán, hogy most milyen megoldást, alkalmazást használ hozzá. Például dönthet úgy - szakmai alapon - hogy betölt valami library-t. Természetesen felvállalva annak ódiumát, hogy onnantól kezdve többlet-karbantartási költséggel azt is karban kell majd tartani. De dönthet úgy is, hogy nem használ library-t.

Talán inkább azt sorold fel, hogy eddig milyen alkalmazásokat használtatok és milyen arányban. Mondhatod például azt, hogy nálatok eddig tulsúlyosan a WordPress a használatban lévő alkalmazás. Ez máris nagyon fontos információt hordoz magában, én ugyanis nem akarok Lúzer Bt.-knek 20ezer forintos weboldalakat fejlesztgetni google 120. oldali helyezésekkel, mert értelmetlen, fölösleges, lehangoló, sikertelen és eredménytelen munka. Tehát a projectjeidnek ez a része alaphangon nem érdekel. Ha pedig ezen kívül érdemi munkával szolgálni nem tudsz, akkor talán be sem jelentkezem.

Vagy sűrgősen kell neked a Simfony-s ember? Talán teremtettél volna normális munkafeltételeket, és fizetted volna meg az alkalmazottaidat rendesen, akkor nem hagytak volna faképnél, és nem lennél most „Adj Uram Isten, de rögtön kell” alapon gázban.

Ha egy adott pozíció kapcsán nincs semmi érdemi mondanivalód, akkor inkább meg se szólalj. De az üres közhelyektől mindenképp tartózkodj. Ezek közül szemezgetnék most néhányat a teljesség igénye nélkül.

Csapatjátékos: ez meg mi? Nem vagyok focista! Ha focistát keresel, ne itt hirdess, hanem az MLSZ-nél
OOP szemlélet: ez alatt mit értesz? Azt, hogy a delikvens a kódbázis minden egyes vackára külön class-t definiál, azt lepéldányosítja függetlenül attól, hogy csak egyszer és egy példányban futtatja és nem is származtat belőle semmit? Mert ez alapvető probléma.
És még sorolhatnám.

Ha még egy normális állásajánlatot sem tudsz összerakni, ideje elgondolkodnod a hogyan továbbról. Egyszerűen lásd be, hogy ez nem neked való. Fizetős ügyfeleid már alig vannak, az alkalmazottak is faképnél hagynak, ideje váltani. Hagyd abba! Jó szívvel és tapasztalatból mondom ezt neked. Tapasztalatból, mert huszoniksz évvel ezelőtt, vezető beosztásban dolgoztam a BKV-nál ahol 130 alkalmazott és 3 csoportvezető volt a beosztottam. De amikor abbahagytam, és úgy döntöttem, befejezem, és az életem hátralévő részében csak programozással kívánok foglalkozni, egyszerűen nem volt hiányérzetem. Sőt, még egy csomó stressztől is megszabadultam. Ezt az intermezzot egyébként a CV-ben fel sem tüntetem, mert teljesen irreleváns a jelenlegi szakmai előmenetelemtől és az általam preferált munkatevékenységektől, továbbá eszem ágában sincs újra karrier-menedzserként elhelyezkedni és újra 130 motiválatlan emberrel napi szinten küzdeni. A nyugalmam ennél többet ér.