IT megmérettetés és DevOps

Van ez az IT megmérettetés, tolja még valaki közülünk?

7 kategóriában vagyok, ebből 2 kicsit általánosabb programozással kapcsolatos: szoftvertechnológia és devops. A szoftvertechnológia még egész jó, a devopsban van pár dolog, amitől igencsak nagyot néztem. Mondok pár példát korábbi feladatokból.

Mire lehet automatikus tesztet írni? Bejelöltem, hogy arra is, hogy a kód nem fordul le, szerintük ez rossz. De már miért ne lehetne? Vagy azt nem tesztnek hívjuk? Nálunk a CI rendszerben van olyan teszt, ami azt nézi, hogy egy adott library vagy valami fordul-e.

Mik a TDD jellemzői? Bejelöltem többek között, hogy a hiba nem a kód hibája, hanem nem lett rá teszt írva. Szerintük rossz, de miért? Minden bugra ráfogható, hogy rossz tesztek miatt van, illetve én pl. minden hibajavítást repro teszttel kezdek. Vagy azért rossz, mert ez nem a TDD jellemzője, hanem valami másé? Másrészt szerintük helyes válasz, hogy a teszteseteket jóváhagyja a megrendelő. WTF, ilyen tényleg van?

Mikor refaktorál a programozó? Az én válaszaim és a helyes válaszok között nem sok a korreláció. Szerintük pl. hibajavításkor, de szerintem a refaktorálás nem változtatja a viselkedést, a bugfix pedig igen.

Hát úgy gondolom, ebben a devopsban elég sok a bullshit, meg az olyan ajánlás, ami a való életben nem teljesen/nem mindig úgy van.

Hozzászólások

Máshol is vannak khm. vitatható dolgok... Az egyik aktuális feladatot "üresen" küldtem be, mert hiába tudom, mit kéne a megadott fájllal csinálni, de nincs a gépemen telepítve a szükséges app, úgyhogy nyaljanak sót :-P

"Mire lehet automatikus tesztet írni?" == "Mit tud a junit?" :D

"Szerintük pl. hibajavításkor, de szerintem a refaktorálás nem változtatja a viselkedést, a bugfix pedig igen."
Szerintem 100% neked van igazad: "Code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior." (wiki Code_refactoring)

Nem is emelek ki többet, jól kivesézted. Elég megnézni a kiemelt támogatókat, vicc.

Ugyanezeket a "hibákat" követtem el én is a DevOps kategóriában. :-)

Tesztesetek vs. megrendelő: szerintem itt az acceptance tesztre gondolhattak, mert az kizárt, hogy minden unit teszttel rohangálnának az ügyfélhez/megrendelőhöz.

Sok esetben a feladat/kérdés nyelvezete van elrontva. Én például nagy naívan jelentkeztem az IT Security témakörre is. Sajnos eddig elég messze van a korábbi évek Hacking témakörétől, az inkább ilyen manageres dolog.

Én idén is 10 kategóriában indultam, de van már pár olyan, amiből jövőre inkább nem kérek.

Mondjuk az is megér egy misét, hogy írtam nekik 2 emailt - a legelsőt 2 hete -, de eddig még semmi reakció. Szóval kicsit úgy tűnik, hogy az első két évben meg lelkesek voltak.

Security: egyet értek, ilyen rizikó elemzéssel meg mittudoménmivel hagyjanak már :). Azért valamennyire kisakkoztam az eddigieket. A mostani 4. kör viszont kifejezetten érdekes volt.

Nekem a 7-ből a 6 elég jól megy, ami nagyon gáz, az a Python. Mert hogy ez igazából nem alap Python programozás, hanem NumPy és Pandas. Úgyhogy aki ismeri konkrétan a libraryt, annak sima ügy, aki nem, az így járt, mert 10 perc alatt még utánaolvasással se fog menni.

Egyszer írtam nekik emailt, jött rá automatikus válasz, hogy ticket készült belőle, aztán jött igazi válasz is. Hibás volt egy pontozás és javították.

De az említett DevOps kategóriában nem fogok vitát indítani, annyira vitatható néhány kérdés, hogy nincs is egyértelmű válasz. Van a programozásnak egy művészet része, azt nem lehet keretek közé szorítani, és azt mondani, hogy azt csak így vagy úgy lehet megoldani. A DevOps mögött olyannyira nincsenek még szilárd alapok, hogy maga a szó devops fogalom jelentése is sokszor vita tárgya, a HUP-on főleg :).

- "Milyen hiteles forrásokra támaszkodhatunk, ha egy sérülékenységről részletes információkat szeretnénk megtudni?"
- Twitter ("Mindegyik")
- False

Hat oke, gondolom a vendor altal kozze tett CVE nem eleg hiteles/reszletes.

Security: itt egy google drive link, tolts le onnan egy .rar-t

Erre csak az lenne elfogadhato magyarazat, hogy a feladat valojaban az, hogy nem szabad rakattintani a honeypotra. En pl. itt engedtem el a kategoriat.

Valószínű nem a verseny szervezőkön múlik, hanem a hitelesítőkön aki vállalta, hogy kitalálja a kérdéseket, válaszokat. Amúgy biztos mindenki jobb kérdéseket tudna írni, hisz mindenki ért a focihoz _is_ Mo-n :-).
Aki csak itt puffog és nem a hivatalos csatornákon jelez vissza (érvényes ez szoftverek bugreportjaira is...), annak nem lesz semmi következménye, javítása.
Amúgy az IT közösség mindig is egymástól, egymás hibájából tanult, így nekem belefér, ha hiba van, csak vizsgálják ki. Az megint egy másik kérdés, hogy ugyan azt a hibát hányan jelzik és hányan tudják feldolgozni :-D bizonyára itt lesz némi szűk keresztmetszet. Én is jeleztem egy hibát, kaptam is választ hogy türelem vizsgáljuk.

Egyébként a fenti kérdést én is amikor először néztem elgondolkodtam mit is tanultam annó erről, mert mind pro mind kontra érvekkel ki lehet állni mellette is és szemben is.
Sajnos több kérdés is volt idén _is_ ami nem 0 / 1 hanem 0,5, amit ha akarom ide ha akarom oda kerekítek.

1. Automatikus tesztet bármire lehet írni, valószínű itt a TDD/BDD módszertanra kérdez rá, amit kódolás közben a fejlesztő folyamatosan futtat pl kódmódosításakor. Az ilyen tesztnek nincs értelme, ha nem fordul le a kód vagy szintaktikai hiba van és az IDE már visít, hisz akkor nincs mit tesztelni.

2. A hibajavításkor egyébként kimondottan javasolt, hogy teszt esetet kell létrehozni a hiba előidézésére, majd miközben megkezded a hibát javítani, akkor refaktorálj, hisz az eddig teszt esetek amik elvileg 100%-os lefedettséget adnak biztosítanak arról, hogy a refaktorálás végén a refaktorált kódrészlet úgy fog működni ahogy eddig, de a hiba nélkül. Feltétel persze, hogy nem legacy kód és a teszt esetek valóban a kód fejlődése előtt bővültek nem pedig utólag.

Szűk keresztmetszet: a számokból kb. látszik, hogy évről évre kb. ugyanannyi a jelentkező az egyes kategóriákban (értsd: nincs 10x szorzó, de sok helyen még 2x sincs). Ehhez képest az első két évben volt reakció 1-2-3 napon belül. Most még egy automata válasz sincs.

Az egyik észrevételem egyébként az volt, hogy egy pedagógiai szempontból normális checkbox kérdésnél legalább 1, legfeljebb N-1 lehetőség a helyes. Tehát pedagógiailag hibás a feladat, ha nem kell pipálni semmit. Ellenben az már helyes, ha be kell pipálnod az "Egyik sem" opciót. Ugyanígy pedagógiailag hibás, ha mindet végig kell pipálni. Ott illene lenni egy "Mindegyik" pipálható opciónak ilyen esetben.

Na most ugye az 5-6-7. fodulot “biztonsagi okokbol” (lol) csak egy meghatarozott idoablakban lehet megcsinalni.

Az otodik fordulonal belepni sem sikerult mar, ugy le volt terhelve a szerver, majd nem sokkal kesobb erkezett az email, hogy egy csunya gonosz csiter megdosolta a szervert, tonkreteve ezzel masok jatekat.

A hatodik fordulonak ugy alltunk neki, hogy mar a CloudFlare vedte a jatek tisztasagat, guess what, error 522, timeout. Kivancsian varom, mi lesz a magyarazat.

(ha valaki olvassa onnan ezt a kommentet: az nem DDoS, hogy szandekosan betereltetek az osszes jatekost egy 20 perces idokeretbe)

Ez igy eleg cringe, le is iratkoztam, nehogy artson az image-emnek a ket bukott fordulo okozta deficit a tabellan.

Az ötödik fordulónál is volt már CloudFlare, legalábbis én 1 hete onnan kaptam 520-522-524-et vegyesen.

Ha jól emlékszek, akkor indulásnál közölték, hogy melyik kategóriában hány induló van. 10 kategóriára jelentkeztem, 9 kategóriában 250-570 fő, a Szoftvertechnológiában nekem 1000-es szám dereng. Lehet, hogy ezt az 1000-es számot már nem bírja a jelenlegi rendszer.

A hatodik fordulónál a kérdéssort nagynehezen kiköhögte a CloudFlare, de hogy sikeres volt-e a submit, az már más kérdés... 2 perc tekerés után kaptam egy 524-et.

Érdekes, nálam egy-két szám kicsit eltér, talán a leiratkozások miatt: IT sec (565), SWtech (998), web (491).

Illetve kiegészítésül: frontend (351), python (551), unity (167), a jövő programozója (821). Ez utóbbinál külső domainen vannak a feladatsorok, ami jobban állja a sarat.

Nekem sikerült egyik témából más fontos dolog miatt lemaradni, egy másikról meg hasonló gondok okán, úgyhogy leíratkozás nálam is megvolt... :-/

A múltkori (5. forduló, okt. 25 péntek 20:00 ) -nél az volt az érzésem, hogy a rendszer elérte a teljesítőképessége határát. Nem ddos jellegűen halt meg, hanem normál túlterhelésjellegűen. Most (nov.1 péntek 20:00) nem tapasztalható az ok, ugyanis egyszer sem volt reszponzív az oldal. (pontosabban 20:03 táján bejelentkezni be tudtam, de pár másodperccel rá a rendszer elesett).

Úgy néz ki, hogy a fejlesztőjük/üzemeltetésük a user oldali (böngészőben implementált) dolgokban otthon van, de a szerver oldalban elég gyengus. Fizetnek egy CDN szolgáltatást (cloudfare) az oldja meg minden teljesítményigényt. (nem fogja).

Nézzünk pár régi trükköt a megbízhatóság növelésére!

- valami CDN megoldás (ezük van, ugorjunk)
- a bejelentkeztető egy önnálló domain, van benne állítható limit, hogy hány usert engedje be. Nem dependál sem az arculati oldal, sem a verseny oldal működésére
- A versenyoldal a 'submit' gomb esetén letárolja az adatot. Akkor is, ha elmúlt a 10 perc. Lehetőleg valami olyan helyre, ahova bőszen lehet írni. (független a feldolgozó DB-től) ez azért kell, hogy elvi lehetőség legyen az értékes adatok utólagos  kinyerésére, ha elesett a DB
- A log nem tartalmaz névfeloldást. Semmi nem végez hálózatfüggő névfeloldást. (sem ldap, sem bind)
- DB backendet meg kellene tolni. Egyrészt programozó oldalról (lockok hogyan is vannak, van-e long query) másrészt DB admin oldalról (ott van-e index, ahol kell, táblaterek hogyan vannak) harmadrészt rendszergazda oldalról (dedikált DB gép, elég-e a memória, SSD van-e alatta, hogyan is van a DB cluster, nem véletlenül péntek este 8-kor indul a heti full backup?)
- A verseny oldal másik domain, másik vas, mint a ithon.info. Az egyikre beeső terhelés ne egye el a CPU-ját a másiknak.
- Itt most nem jelentkezett, de nem ártana, ha a versenyoldal minden kiszolgált elemét (összes js, összes css, összes font) saját kézben lévő szerver adná. Az is elég arcvesztés, ha egy harmadik féll összedőlése miatt áll a verseny.

Egyébként —ha csak nincs valami algoritmukusan elszúrva, amikor is "n" konkurens felet deadlockol a DB— egyszerű és nagyszerű segítség a DB táblaterét (adatfájljait) berakni egy frissen vásárolt NVMe storage cardba. Néha az is segít, ha leállítod a multi-master DB replikát :-)

 

egyébként köszi a blogbejegyzést, így legalább nem indítok másikat.

Akkor ezek szerint nem csak nekem tűnt fel, hogy jellemzően a péntek esti finálé fordulókkal van para. :-)

Érdekes módon a hétfő-kedd-csütörtök fordulóknál maximum egy picit megemelkedett az oldalbetöltés, de annyi.

Egyébként egész jó kis listát szedtél össze.

Most volt a szoftvertech pótforduló, megin' túlterheltnek tünik a rendszer.

Nagyon sokáig tartott a feladatlap betöltés (20 sec).

A feladatlap elküldés is (1-2 perc!)

Viszont most nem dobott ki időtullépés miatt, ezekszerint reszeltek az időtúllépés-ellenőrzésen. Jó.

Befogadta a beküldésemet, hurrá.

Nekem azt dobta, hogy "Már korábban kitöltötted a tesztet.", utólag megnéztem a "megoldásaimat", a 2., 3. és 5. feladatokat "elrontottam", meg "állítólag" majdnem az összeset. (Ez az eddigi helyes válaszok százalékos arányának ismeretében vicces.)

A probléma csak annyi, hogy ezek a kérdések korábban már szerepeltek Devops, Szoftvertechnológia és Weboldalkészítés témakörben és ott hogy-hogynem helyeset küldtem be. Jeleztem feléjük, roppant kíváncsi leszek a végeredményre. Érdekes, hogy ez a Szoftvertechnológia témakör ennyire mumus.

Azt írta a noreply@ithon, hogy

A ma esti fordulót ismét ellehetetlenítette a kedves "barátunk", pedig az új feladatokkal is igyekeztünk humorral kezelni valakinek a furcsa zavarát, ebbe sok energiát beleölve. Elküldhetnénk a "pokolba", de szerintem ő már ott van. A harag olyan, mintha egy pohár mérget innál annak reményében, hogy a másik fog meghalni, így ez most részünkről elmarad. Inkább hálát adunk, hogy ennyi fejlődni akaró, a tudására sokat adó ember választja a játékot, ezzel is jó példát mutatva egy olyan ágazatban, ami ma a világot leginkább mozgatja. Tegyetek így ti is.
Pontosan hogyan kezeljük erről rövidesen küldünk információt egyeztetve a partnerrel. Újabb pótforduló már biztosan online nem lesz, mivel a díjátadóig erre már nem lesz idő, de valamilyen kreatív megoldással fogunk előállni.

 

Az egész játék valódi célja fejvadász adatbázis építése, így várjatok ettől bármi minőséget.