Ez a demó videó a Postman oldalán most kicsit megfogott. Azt hiszem, érdemes lesz ezt kipróbálom valamikor, így maradjon itt ez, mint emlékeztető.
Szerző: Attila
Playwright & Typescript cheat sheet
LinkedIn-en találtam. Hasznos tud lenni, bár az ilyet egérpadon tudnám elképzelni.

Kraftie #87 – IT munkaerőpiac: nincs visszaút 2022-be
Hát igen. Elég kellemetlen ezt most megélni. De azért azt erős túlzásnak érzem, amikor a realitás érzését feszegetik. A piac folyton változik. A változás okát ne feszegessük, mert most n+1 lehetőséget lehet rá mondani, a valóság meg valahol középen lehet. Ami tény, hogy egyre több cég épít le, és/vagy nem indít új projektet, nem vesz fel új embereket. Ami érezhető, és a felszín alatt látható, hogy vannak olyan cégek is, akik elküldik az embereket, mert épp a Excel tábla meghúzott vonala alatt vannak, majd pedig később pótolják őket, a jelenlegi helyzet alapán olcsóbb munkaerővel.
De nem kell aggódni. El fog tartani ez is pár évig, aztán valamikor megint fordul a kocka. Csak addig kell kibírni, akár fél lábon.
Ami viszont szörnyű, hogy mindig a kimagasló IT bérekről beszélünk, és ezt a kimagaslót azzal támasztjuk alá, amely szektorok hozzáadott értéke, vagy épp a szükségek kompetencia közelébe sincs ennek. Nem, az IT sosem volt egy könnyű szakma, és ennek megfelelően jó bérezés volt, de más szektorokban is hasonlóan volt jó, vagy több esetben jobb bérezés, miközben a hozzáadott érteke mérhetően kevesebb, vagy épp a kompetencia közelébe se volt ennek.
Na mindegy, lássuk meg, hogy mit hoz a jövő, legyünk bizakodóak!
Leépítések és elpárolgó vidéki lehetőségek jellemzik az IT-szektort 2026 nyarán. Az új valóság már a szakma minden bugyrába eljutott, és egyre kevesebb az illúzió. Itt a 87. Kraftie adás.
A nagy hazai IT-munkáltatók eddig elsősorban úgy sorvasztották a munkaerő-állományt, hogy a távozókat már nem pótolták. Nyár végére azonban a jelenség valódi elbocsátásokban öltött testet. Vidéken sem jobb a helyzet: míg az aranykorban a hazai nagyvállalatok sorra nyitották irodáikat a vidéki nagyvárosokban, mára ezek a telephelyek lassú párolgásra lettek ítélve. A történések azonban már senkit sem lepnek meg. A hazai IT-munkaerő, ha lassan is, de kezdi megismerni az új valóságot.
Playwright struktúra
Néha hasznos tud lenni, ámbár nem gyakran fordul elő, hogy a semmiből kell építkezi, de akkor jól tud jönni, ha követünk egyfajta sztenderdet. Talán azt mondanám, hogy a lokátorokat nem tenném külön, de van az a méretű projekt, ahol van ennek létjogosultsága.

Kraftie #86 – Fejvadász tangó: a színfalak mögött
Mit is mondhatnék, miután végig néztem? Egyfelől kerülgetjük azt a bizonyos forró kását, mert senki sem meri a valóságot kimondani, csak folyton utal rá, másfelöl pedig, ha tényleg néhány másodperc alatt dől el egy-egy LinkedIn profi, akkor ott igen komoly bajok vannak. De hát érezhető már lassan 10 éve, hogy a hazai, de akár a külföldi IT-ban is felütötte a fejét valami furcsa hozzá nem értés, ami nem kicsit keseríti meg sokunk életet. Nem értem, hogy miért is játszanak mások megélhetésével.
Energia ellátási probléma és az otthoni munkavégzés
Ma, amikor arra kér a kormány, hogy csökkentsük az energia felhasználásunkat, és a vízfogyasztásunkat, már jó pár cég otthoni munkavégzést rendelt el a következő napokra, hetekre. Kicsit olyan, mint a Covid idején, bár az igen hosszú időszak volt. Én, mint aki 2015. óta különféle munkahelyeken tudtam itthonról dolgozni, sosem értettem a Covid utáni, illetve a jelenlegi időszakot, amikor egyre több irodai napra tartanak a cégek igényt, miközben valós indok nincs mögötte, hanem eszed, nem eszed, nem kapsz mást személet folyik. Szóval, ha végig gondoljuk – mert persze pro/kontra már mindenki szakértője lett a témának, hogy mikor is nagyobb a fogyasztás – én azt hiszem, hogy abba a munkakörökbe, mint amiben én is vagyok, újra engedni kéne, hogy a dolgozó csak akkor menjen be az irodába, amikor az elengedhetetlen.
Miért is mondom ezt?
Egyfelől sok időt és energiát lehet megtakarítani, ha csak az utazást nézzük, azon felül pedig kényelmesebb, komfortosabb, és munka mellett akár egy mosás – nem csúcsidőben – is elvégezhető, miközben, ha magamat nézem, sokszorosan hatékonyabb vagyok, ha itthonról dolgozom, mintha ugyanazt irodából tenném.
Persze, sokan vissza is éltek ezzel, de ne legyünk naívak, az irodai munkavégzés során is igen sokan kerülik a munkát, szóval nem az otthoni munka végzés ennek az oka, hanem az egyén. Ha pedig az egyén így dolgozik, akkor ne mindenki mást büntessünk, hanem őt.
Arról se feledkezzünk meg hogy Covid idején ódák zengek attól, hogy mennyivel hatékonyabb, és mindenki arra számított, hogy később is folytatódik ez a munkavégzés, erre – mint én is – sokan vidékre költöztek. Szóval nézzük csak. Kinek jó, hogy a munkavállaló több órát ingázik oda-vissza? Senkinek igazából, csak képtelenek vagyunk elszakadni céges szinten az irányítás mániától, ami arra kárhoztatja a munkavállalót, hogy többed magával üljön egy zárt – nyitható ablak nélküli – irodában, esetek nagy részében elszigetelten a többiektől, majd pedig munka végeztével irány haza. Lássuk be, ez nem normális.
Szóval most, hogy újra látható, hogy a világ ilyen mértékű változása során egyre fenntarthatatlanabb az energiafelhasználás, szükség lenne, ahol lehet, az otthoni munkavégzés meghagyására. Így legalább talán kisebb tömeg ingázna reggel és este. Na de lássuk meg, hogy mit találnak ki azok, aki ezt az egészet irányítják.
Nézzük is, hogy mit hoz nekünk a következő hét az időkép szerint.

Néhány hír:
- https://444.hu/2026/08/02/a-hokupola-arnyekaban
- https://444.hu/2026/08/02/a-fidesz-kepviseloje-felvetette-a-sziget-korlatozasat-a-szervezok-szerint-nem-lesz-gond
- https://444.hu/2026/08/02/hatezer-paksi-marad-melegviz-nelkul-az-atomeromu-leallasaval
- https://444.hu/2026/08/01/magyar-peter-hajnali-fel-kettokor-az-utolso-elotti-egyseget-is-leallitjak-az-atomeromuben
- https://telex.hu/belfold/2026/08/02/kapitany-istvan-felsorolta-melyik-cegek-sporoltak-a-legtobb-aramot
Kraftie #85 – Az AI ára
Kollégákkal, barátokkal mi is sokat beszélgetünk erről, és hát egyelőre úgy tűnik, hogy az történik, amit ők mondanak. Várom azt a változást, amikor az bizonyosodik be, amire én számítók, de ez az AI téma nagyon érdekel változásokat tartogat.
JAVA method overloading vs overriding
Ez a két, vagy inkább egyként feltett kérdés szinte minden technikai interjú kapcsán előkerül. Miért? Mert nagyon hasznos tud lenni, és átláthatóbb kódot lehet így írni. Na de nézzük meg, hogy mik is ezek! Illetve inkább idézek a saját szavaim helyett, mert nem biztos, hogy ennyire pontosan meg tudnám fogalmazni a definicióját.
Method overloading
Javában a metódusok túlterhelése lehetővé teszi a fejlesztők számára, hogy több metódust definiáljanak ugyanazzal a névvel, de különböző paraméterekkel. Ez a rugalmasság olvashatóbbá és adaptívabbá teszi a kódot, mivel egy metódus különböző variációi különböző argumentumtípusokat vagy -mennyiségeket kezelhetnek. Azonban annak megértése, hogy a Java hogyan választja ki, hogy melyik metódust hívja meg, elengedhetetlen a hibamentes kód írásához.
Egyszerű példa kód
class Calculator { void add(int a, int b) { System.out.println("add(int, int) called: " + (a + b)); } void add(double a, double b) { System.out.println("add(double, double) called: " + (a + b)); } }Mi is történik a fenti példában? Két metódusnak ugyanaz a neve, de a bemenő paraméterinek a típusa különböző, így tehát az lesz használva, ahol egyeznek a paraméterek. Automatizálás során például egy jó példa lehet, ha a metódus integert vagy stringet tud fogadni, és annak megfelelően végrehajtani mondjuk egy kiválasztást. Ilyenkor ugye a bemenő paraméter típusa fogja meghatározni, hogy melyik függvény fut le, és mindkét függvény ugyanarra a névre hallgat.
Method overriding
A metódusok felülírása az objektumorientált programozás (OOP) alapvető koncepciója, amely lehetővé teszi egy alosztály számára, hogy egy olyan metódus specifikus implementációját biztosítsa, amely már definiálva van a szuperosztályában. Kulcsfontosságú szerepet játszik a futásidejű polimorfizmus elérésében Java-ban.
- Öröklődés: A metódusok felülírása csak öröklődés esetén történik, ami azt jelenti, hogy egy alosztály örökli a metódusokat és tulajdonságokat egy szuperosztálytól.
- Ugyanazon metódus szignatúra: Ahhoz, hogy a metódusok felülírása megtörténjen, az alosztályban lévő metódusnak ugyanazzal a névvel, visszatérési típussal és paraméterekkel kell rendelkeznie, mint a szuperosztályban lévő metódusnak.
- Felülírás vs. túlterhelés: A metódusok felülírását nem szabad összekeverni a metódusok túlterhelésével. A túlterhelés azt jelenti, hogy több metódusnak ugyanaz a neve, de paramétereik különböznek, míg a felülírás az alosztályban lévő metódus újradefiniálását jelenti ugyanazzal a szignatúrával.
Egyszerű példa kód
class Animal { void sound() { System.out.println("This animal makes a sound"); } } class Dog extends Animal { @Override void sound() { System.out.println("The dog barks"); } }Miért érdemes metódusfelülírást használni?
- Polimorfizmus: A metódusfelülírás lehetővé teszi egy alosztály számára, hogy egy adott metódushoz egy adott implementációt biztosítson, lehetővé téve a polimorfizmust. Ez azt jelenti, hogy ugyanaz a metódushívás eltérően viselkedhet attól függően, hogy melyik objektum hívja meg. Például mind az Animal, mind a Dog objektum meghívhatja a sound() metódust, de az eredmény az objektum típusától függ.
- Dinamikus metódusküldés: Futásidőben a végrehajtandó metódust az objektum típusa határozza meg, nem a hivatkozás típusa. Ezt a folyamatot dinamikus metódusküldésnek vagy futásidejű polimorfizmusnak nevezik.
- Újrafelhasználhatóság és bővíthetőség: A felülírás lehetővé teszi az örökölt metódusok viselkedésének kiterjesztését vagy módosítását. Ez elősegíti a kód újrafelhasználását, mivel az alosztály örökölheti a közös viselkedést, miközben további funkciókat biztosít, vagy szükség szerint felülírja a viselkedést.
class Animal { void sound() { System.out.println("This animal makes a sound"); } } class Dog extends Animal { @Override void sound() { super.sound(); // Calls the superclass method System.out.println("The dog barks"); } } public class Main { public static void main(String[] args) { Dog myDog = new Dog(); myDog.sound(); // Calls the overridden method } }Metódus felülírásának szabályai
- A metódusnak ugyanazzal a szignatúrával kell rendelkeznie, mint a szuperosztályban.
- A metódusnak az eredeti metódust tartalmazó osztály alosztályában kell lennie.
- Az alosztályban lévő metódusnak ugyanolyan vagy könnyebben hozzáférhető hozzáférési módosítóval kell rendelkeznie. Például, ha egy metódus védett a szuperosztályban, akkor nem lehet privát az alosztályban.
- Nem írhatjuk felül a final, static vagy private metódusokat.
Szeretem a Medium leírásait, számomra mindig is könnyen érhető, és nagyon sok témát dolgoznak fel. Csak ajánlani tudom!
Playwright & expect.poll
Bár nagyon sokat használtam, mégsincs kéznel egy darab példa kódom sem ezzel kapcsolatban. Így hát a Playwright bibliát fogom segítségül hozni a példák bemutatására.
Mire való?
Nekem ez akkor volt nagyon hasznos, amikor API teszteket írtam, és a
GET endpointválaszánál nem volt elég egy200-as válasz kód, mivel a háttérben a szinkronizációs folyamat nem ért be, tehát aGET endpoint-ot addig kellett hívni, amíg a megfelelő válasz meg nem érkezett.Elsőre én is, mint egy kis cserkész, betettem egy
while loop-ba, és működött tökéletesen. Aztán rátaláltam a Playwright által támogatott gyári megoldásra, és azt kell mondanom, hogy zseniálisan jól működőtt.Példa kód a hivatalos oldalról
await expect.poll(async () => { const response = await page.request.get('https://api.example.com'); return response.status(); }, { // Custom expect message for reporting, optional. message: 'make sure API eventually succeeds', // Poll for 10 seconds; defaults to 5 seconds. Pass 0 to disable timeout. timeout: 10000, }).toBe(200);Mi is történik itt? A
GET endpointválaszkódjával térünk vissza, és azt hasonlítjük össze az elvárttal. Teszük ezt addig, amíg tart atimeout-ban megadott érték.Következő példa:
intervalsawait expect.poll(async () => { const response = await page.request.get('https://api.example.com'); return response.status(); }, { // Probe, wait 1s, probe, wait 2s, probe, wait 10s, probe, wait 10s, probe // ... Defaults to [100, 250, 500, 1000]. intervals: [1_000, 2_000, 10_000], timeout: 60_000 }).toBe(200);Ekkor az intervals-ban megadott értékek fogják jelenteni a próbálkozások közt eltelt időt. Ezt érdemes úgy beállítani, hogy lehetőleg ne generáljuk túl nagy extra terhelést a rendszer számára.
Példa a
soft-raawait expect.soft.poll(async () => { const response = await page.request.get('https://api.example.com'); return response.status(); }).toBe(200);Az expect.soft kapcsán nekem az a megélésem, hogy nagyon megoszlanak a vélemények. Vannak, akik teljes mértékben ellenzik a használatát, mások pedig – mint én is – úgy vannak vele, hogy vannak olyan esetek, amikor szükséges lehet. Ugye,
softesetén ha hibára fut, nem áll meg a futás, hanem megy tovább a teszt.Szóval nagyon hasznos tud lenni a Playwright online elérhető dokumentációja. Ha bármi kérdés merülne fel, ajánlom, hogy ott kezdödjön a kutatás.



