Utasi Róbert - Front-End QA - WebFejlesztés

CV

Röviden magamról:

  • 16 év QA tapasztalat a mozilla firefox fejlesztői csapatban. Eseti kontribúciós tevékenység a World Wide Web Konzorciumnál (w3c) (angol nyelvű kommunikáció - levelező-chat)
  • 16 év QA tapasztalat a freenode-on , ahol front-end webfejlesztőket supportálok. (angol nyelvű kommunikáció - levelező-chat)
  • 13 év kereskedelmi tapasztalat, saját alapítású cégben (jelenleg cégünk, amit a testvéremmel működtetek, piacvezető a saját szegmensében, főképp webes kereskedelemre alapozva.)
  • 5 év tapasztalat bankszektorban rendszerfejlesztőként. (ez már régen volt)
  • Színkitűnő érettségi
  • Jórendű egyetemi tanulmányok 4+ átlaggal (ELTE - Programozó matematikus)
  • User Experience (UX) research kurzus az UXStudio-nál
  • Szakdolgozat: mártix alapú számrendszerek kutatása rejtjelezéshez

Profilom, hobbim:

  • webszabványositás (szabványkódolás)
  • weboptimalizálás (kódoptimalizálás, redukálás)

Jelenlegi kutatási területeim:

Amire nyitott vagyok:

  • az érdekes (adott esetben extrém) újszerű megoldások, melyeket ki tudok posztolni a blogomon. (a blog a jövőről szól, backwards compatibility okokból nem minden használható „élesben” - egyelőre, de már felkészülünk rá)
  • Kifejezetten kedvelem a kódoptimalizálást, keresve, kutatva a lehetőségeket, mit hogy lehet gyorsabban (processzoridő) és szabványosabban megoldani, így szívesen bíbelődöm kész webstruktúrákkal, weboldalak feljavításával.

Vállalok

Eseti és szerződéses munkákat QA illetve szabványkódolás és kódoptimalizálás (web) területen. (Értsd webfejlesztés)

Díjazás eseti megbízás esetén: 15.000Ft szoftvermérnöki óradíjjal[1][2]
Kiszállási díj Budapest területén belül helyszíni munkára: 1 szoftvermérnöki munkaóra díja/alkalom[1]
Több projectben való közreműködés általánydíjas[1] szerződéssel megegyezés szerint.

[1] Az árak az ÁFÁt nem tartalmazzák.
[2] Érvényes: 2018. 01. 01.-től.

Hosszútávú szerződéses munkák vállalása - tervezés, kivitelezés

Elsősorban olyan középvállalatokat keresek, ahol elegendő számú weboldal-project áll a rendelkezésre, és ahol van (legalább minimális) igény a szakmailag elvárható műszaki minőségű ügyfélkiszolgálásra.

A preferált munkatevékenység: Weboldalak Frontend tervezése és kivitelezése szoros együttműködésben az UX/UI Designerrel

Hosszútávú megállapodás esetén a fizetési igényem belefér a népszámlálásos adatokba.

Amennyiben az adott cégnél nincs elegendő mennyiségű weboldal-project, úgy ez lehet időarányosan kevesebb is. A lényeg a hosszútávú együttműködésen van.

Mivel egyéb elfoglaltságaim és tevékenységeim is vannak, így a Home-Office a preferált.

Recruiterek jelentkezését is várom

Weboldalt mondtam, tehát pl. mobilapplikációkkal - érdeklődés hiányában - nem tervezek foglalkozni.

Én nem akarok „minden”-hez „érteni”. Ha „polihisztor”-t keresel, nem egymást keressük. (További részletekért lásd a lentebb belinkelt - nyomdafestéket épp, hogy megtűrő - értekezésemet)

Állásajánlatok:

Copywriter, marketing-szövegíró (closed)

UX/UI Designer (plan only)

Social Media Account Manager / Designer (closed)

Stream Szerver Implementálás (project)

Elérhetőség:

+36 1 276 6896 (12h után)

utasirobert kukac gmail pont com

CV Letöltése PDF formátumban, katt ide

Motivációs levél helyett: Rendszerkritika cikk, katt ide

About

Mi az a Google? Mik azok a minőségi mutatók?

A Google egy minőségi tartalomszolgáltató kereső. Ezt tízszer is alá kell húzni, mert ha nincs tartalom a weboldalon, vagy nem minőségi a weboldal, akkor ne is számítsunk Google-ból érkező forgalomra weboldalunkra. Régebben a Google rangsorolása a weboldalra mutató linkek alapján történt, azonban a sok visszaélés (vásárolt linkek stb.) arra ösztönözte a Google-t, hogy új rangsorolási elveket vezessen be. Ezeket minőségi mutatóknak nevezzük. A weboldal minőségét legnagyobb mértékben a szöveges tartalom határozza meg. Technikai szempontból pedig a kódolás szabványossága és az u.n. reszponzivitás. A weboldal legyen tartalomfókuszált. Kódolástechnikailag ezt redukciónak és szemantikai optimalizációnak nevezzük.

A Bootstrap és a jQuery mellőzésének fontossága

Alapvető fontosságú a tartalom és az arculat elválasztása. Az u.n. library-k azonban súlyosan megsértik ezt az elvet, habár egyszerűbbé teszik és olcsóvá egy weboldal elkészítését. Mégis már a betöltési és renderelési idő jelentősen megnő az ilyen library-kat használó weboldalak esetében. Továbbá futásidőben is jelentős a processzor- és memóriaigényük, ami adott esetben akár használhatatlanná teheti a weboldalt például egy mobileszköz esetében. Ezért a kódoptimlizálási folyamat során elsődleges fontosságú, hogy ezeket a library-kat eltávolítsuk. Napjainkban a HTML5 és CSS3 segítségével a 2 leggyakrabban használt library kiváltható szemantikai jelölőelemekkel és stílusszabályokkal, melyek hardveres gyorsítással működnek. Így tehát a library-k használata nemcsak káros, de fölösleges is.

A CSS preprocesszorok mellőzésének fontossága

A preprocesszorok működési sajátossága, hogy amennyiben változót használunk benne, akkor a változó minden egyes lehetséges értékére kigenerálnak egy statikus css szabályt, amivel iszonyatos mértékben belassítják a layout kirendelerelését, tehát egy nagyon fontos minőségi mutatónak mondhatunk búcsút. Továbbá még mindig ökölszabály, hogy szigorúan tilos a layout-ot scriptfüggővé tenni. Márpedig preprocesszorral csakis és kizárólag script-támogatás mellett jelenik meg a kívánt arculat, arról nem is beszélve, hogy alapvetően lassul az oldalbetöltődés is, hiszen a preprocesszálásra várakozik a kimenet. A preprocesszorok öncélú használata egyébként is ostobaság, csak azért, mert a programozó lusta a kontextuálisokat normálisan legépelni.

Desktop First vagy Mobile First?

Jelentését tekintve a Desktop First kódolás alapértelmezésben asztali gépre van beállítva, és mobil eszközön a struktúra átrendezésével jelenítjük meg a weboldalt. Mobile First struktúra esetében az alapértelmezés a legkisebb mobileszköz és fluid módon ezt terjesztjük ki nagyobb képenyőkre. Ez a utóbbi technika nem igazán alkalmas többosztatú klasszikus megjelenésre, ezért a Mobile First weboldalakon erősen látszik asztali gépen is, hogy milyen technológiát alkalmaztunk, a struktúra továbbra is egyosztatú és scrollozásigényes a képernyőn. Ha a kisebb ellenállás irányába megyünk, akkor a Mobile First elvet követhetjük, de választhatjuk a nehezebb, de több webes ügyféllel kecsegtető megoldást is, ami a Desktop First. Vajon miért kecsegtet több ügyféllel a Desktop First technológia? Egyeszeűen azért, mert kihasználja az asztali látható képernyő szinte teljes terjedelmét, és a tapsztatat szerint (v.ö.: UX) nem szeretnek a potenciális ügyfelek scrollozni az egérrel. Ellenben mobileszközön ennek pont az ellenkezője tapsztalható. A kérdés, ami segít eldönteni, melyik technikát válaszzuk, azon múlik, hogy a végfelhasználók mire használják a mobileszközt. Vajon ott fejezik be a vásárlást például egy webshopban, vagy csak tájékozódnak, és a későbbiekben asztali gépen rendelnek?

Mi a Content First elve és hogy ne essünk át a ló túloldalára?

A Content First egyszerűen azért fontos, mert például a Google-ból a weboldalunkra látogató érdeklődő azt akarja látni, amit keres. Ez pedig a valódi tartalom. Továbbá kódolástechnikailag egyszerűbb valamit alulról felmozgatni a képernyőn, mint fentről lenyomni alulra. Továbbá a Google kereső egy weboldalnak csak az első egy bizonyos részét olvassa be, így ha az a tartalom, ami a valódi tartalom egy weboldalon, kívül esik ezen a Google limiten, egyszerűen nem fogunk feljönni a releváns keresésekre a google találati listájában, és potenciális ügyfeleket veszítünk. Továbbá fontos azért hogy tovább tudjon navigálni a weboldalon például a megrendelés irányába, ha webshopról van szó, ezért nem célszerű ezeket a navigációs elemeket a látható képernyőn kívülre helyeznünk, mert hiába jön be az ügyfél a Google-ból, ha nem tudja mit tegyen a weboldalon, már ki is lépett és ment tovább a következő keresési találatra - a konkurenciához.

A minőségbiztosítás QA fontossága webalkalmazások esetén

Más néven Quality Assurance két fő szegmensre bontható. Az egyik a vizuális megjelenés és használhatóság, angolul User Experience, rövidítve UX. A második szegmens a Funkcionális Hibaellenőrzés, angolul Bug Verification. Továbbá ide tartozik az úgy nevezett Akadálymentesítés is. A minőségbiztosítás része továbbá a kliens oldali kódok ellenőrzése is. Miután weben több jelölő- és programnyelvet használunk, ezért ez a folyamat meglehetősen összetett is lehet. Egy kódkészlet minőségének kritériumai lehetnek: szabványosság, redukáltság, kódhatékonyság (memória és processzoridőigény) illetve a Tartalom és a Design szigorú elválasztásának elve. A tesztelés hagyományosan végfelhasználói eszközökön, és különböző Browser Disztribúciókon (User Agent - UA) manuálisan történik. Azonban ismert olyan minőségbiztosító alkalmazás, mint például maga a Google keresőrendszer besorolási algoritmusa, ami a weboldalak vizuális és kódolástechnikai megoldásait automatizálva elemzi. Ezért egyáltalán nem mindegy, hogy milyen minőségű kódot alkalmazunk egy weboldalon, különösen akkor nem, ha a google keresőjében előkelő pozíciót szeretnénk elérni és azt meg is tartani.

Motiv

File-szerkezet

1 file - 5 szkin! Mindez scriptmentesen!

Browsertámogatás

Többféle kódolási technikát is használok ebben a tanulmányban, azonban a Grid szkin Firefox Quantum 57 browser használatát igényli. Cserébe egy maszkolási trükköt is bemutatok a hozzá tartozó carouselben, csak hogy lássuk, a modern böngészőkkel akár ilyet is lehet csinálni. Ennek oka a display: contents; szabály használata. Ez egy néhány hetes fejlesztés, és valójában a Chromiumban is elérhető már, csak be kell kapcsolni a böngészőben a chrome://flags URL alatt az Experimental WebPlatform Technologies flag-et. De most a tesztelésnél elég a Firefox is és elhihető, hogy Chromiumban is ugyanúgy működik. Mivel már évtizedek óta foglalkozom böngészőfejlesztéssel, így mindig szívesen nyúlok az újszerű megoldásokhoz a tanulmánymunkáim készítése során, mert ezzel is tesztelem a megfelelő működését. Ebben a tanulmányban több szkinnél is old kódot használok, így az megfelelő a backwards compatibility szempontok alapján is.

Carousel

Utálom a carouseleket, mivel tartalomhelyettesítő megoldások a valódi tartalom helyett, így Google-gyilkos megoldások. Éppen ezért ebben az esettanulmányban 4 azaz négy féle carouselt is leimplementáltam.

  • Slide
  • Fade
  • Marquee
  • Diagonal fade

Belátható, hogy mindezt csak scriptmentesen lehetett egyszerre megoldani (habár a diagonal fade az történetesen scriptes, és emiatt van egy kis bugja is), mivel a script hardkódolás minden esetben, ami azt jelenti, nem lehetne szkinenként cserélni az animációt.

BootStrap és jQuery mentesség

Természetesen NINCS benne sem ez sem az. Nem is lehetne ezt a tanulmányt elkészíteni - a szkinváltásokra gondolok - mivel a bootstrap egy szemantikai hanyattesés eredményképpen durván megsérti a tartalom és a kinézet szigorú elkülönítésének a szabályát. A flex natív támogatása egyébként is fölöslegessé teszi a BootStrap-ot. Ideje elfelejteni. A töréspontokat pedig hagyományosan mindig a design határozza meg és sosem a bootstrap kód. Ez egy fontos szabály, amit a bootstrap felhasználói szeretnek elfelejteni.

Scriptmentes megoldások

A modern webböngészők lekövetik a trendeket, amik a különböző animációs trükköket előszeretettel alkalmazzák. Ebben a tanulmányban kifejezetten fókuszáltam arra, hogy scriptmentes legyen. Scriptmentes a szkinváltás, az animációk, jellemzően minden. A scriptes megoldások működésüket tekintve nem tudják kihasználni a hardveres gyorsítást, tehát minden változás esetében újrarenderelik a layoutot, ami rendkívüli mértékben kiterhelik a processzort és a memóriát, tehát például egy kisteljesítményű mobilszközön akár a böngésző összeomlását is eredményezhetik, illetve olyannyira lassú, ami már károsan befolyásolja a felhasználói élményt. A korszerű fejlesztési irányelv, hogy javascript helyett a beépített CSS funkciókat használjuk, a régebbi böngészőkön pedig, ahol nincs natív támogatása ezeknek, nem használunk animációkat. Ezek a böngészők amúgy is jellemzően elavult, kisteljesítményű eszközökön futnak, tehát a pontosan a felhasználói élmény és használhatóság megtartása érdekében mellőzzük rajtuk az animációkat.

A javascript ördögtől való?

Nem feltétlenül, de a jóból is megárt a sok. Elsősorban amit lehet scriptmentesen kódoljuk le, mert így tartalomfüggetlen tud maradni a kód. Itt, ebben a tanulmányban 2 scriptet használok. Az egyik mobilnézetben becsukja a szkinválasztó panelt, miután kiválasztottuk az új szkint, mert elég idegesítő volt, hogy ott maradt a panel az új szkin esetén is. Ezt a egy eseménykezelővel megoldottam. A másik script pedig a diagonal fade script. Eléggé hardkódolt, de érdekes.

Konstans HTML struktúra

Amennyiben követjük a tartalom és az arculat szétválasztásának szigorú szabályát, könnyen tudunk csinálni szkinezést. Tkp. minden, ami a stílus része, a CSSbe kerül bele, a HTML kód csakis és kizárólag szemantikai jelölőelemeket tartalmaz. Semmi fölösleges DIV elem, meg ehhez hasonló, a megjelenést befolyásoló jelőlőelem nincs és nem is lehet a kódban.

A Grid Szkin

Miután folyamatosan kutatom az új alkalmazásokat és azok kihasználási lehetőségeit, a Grid szkinben egy olyan technológiát alkalmazok, ami jelenleg full supporttal csak a Firefox Quantum böngészőben érhető el. A Grid lehetőséget biztosít az overlapping technológia alkalmazására, ami azt jelenti, hogy jelen esetben a tartalomleírások ugyanabba az areába kerülnek mégpedig flowed contentként, ami az jelenti, hogy allokálja a helyet a képernyőn. Hártánya, hogy ha nem egyforma magasságú a 3 tartalom, akkor az allokált hely a legmagasabb content mérete lesz, így a többinél alul egy üres tartomány lenne látható. Ennek kiküszöbölésére úgy állitottam be a gridet, hogy csak a tartalom scrollozódik, az area magassága pedig megegyezik a látható képernyőn a rendelkezésre álló hellyel. A grid további előnye, hogy minden elemet oda rakunk tetszőlegesen, ahova csak akarjuk, jelen esetben a szkinválasző modult fullképernyőn, a jobb oldali sávba, ennél kisebb képernyőn a balsáv aljára tettem. Vessük össze ezt a lehetőséget a Content First elvvel. Gyakorlatilag gond nélkül kivitelezhető, pontosan a rugalmas lepakolás miatt. Reszponzivitás is kényelmesen megoldható, hiszen csak a grid-template-et kell átdefiniálni, és máris lehet sokosztatú vagy akár 1 osztatú a layout. Trükk: a tartalomlapozás fade átmenettel történik, ami egy modern megoldás.

Az Easy és a Hard Szkin

Klasszikus old kódolástechnikával összerakott 2 osztatú struktúra. Fejléc, a menü bal oldalt, a Hard szkinben az aktív menüelem kijelölő háromszöge animált. Koncepció, mint a nevük is mutatja könnyen olvasható, illetve nehezebben olvasható kisebb kontrasztos megjelenés.

A Classic Szkin

Klasszikus old kódolástechnikával összerakott 3 osztatú struktúra. Fejléc, a menü bal és jobb oldalt egyaránt, egy klasszikus 3as felépítésű webstruktúra, ami a Desktopon ideális. Trükkök: a menű és a headig szépen a fejlécbe került be, holott struktúra szerint a bal oldali doboz részei, illetve a leíráshoz tartozik.

Mobilnézetek

Mindegyik szkinhez tartozik mobilnézet is, a korszellemnek megfelelően, elsősorban a szkinválasztó modult csináltam meg popupra, ami hol fade, hol slide, csak az izgalom kedvéért. Lehet benne gyönyörködni mobilon is - except Grid szkin, az csak Firefox Mobile bőngészőben működik, mint ahogy korábban már kifejtettem.