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)
  • 12 é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:

  • Desktop First technológiák, és adaptációik.
  • Kódredukciós megoldások

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 kódoptimalizálás (web) területen.

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.

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

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.

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álastottuk 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.