Minicube

Share

Amit automatizálni lehet, azt automatizálni kell

Season 1, Ep. 14

Sziasztok, az én nevem Papp Krisztián és ez pedig a minicube podcast tizennegyedik epizódja!

A mostani részt a legutóbbi két háztáji fejlesztésem ihlette, amik közül az egyik már elég régóta elindult. Nem tudom ti hogy vagytok vele, de én piszok lustának tartom magam, legalábbis ha egyszerű, favágó munkáról van szó, különösen ha mindez monoton és többször is meg kell ismételni.

Anno amikor először munkaidőben fejlesztettem, még nem is fejlesztői munkakörben, az is egy ilyen feladatot hivatott kiváltani. Végtére az ipar legnagyobb részében azért írunk szoftvereket, hogy emberi munkát váltsunk ki vele, na meg excel táblákat. Pontosan ez történt akkoriban is, volt egy szoftver, ami megevett egy excel táblát és egy htmlt köpött ki magából, amit aztán lehetett is kinyomtatni és odaadni a termelőknek. Ezzel csak az volt a gond, hogy a programban voltak hibák, emiatt gyakran kellett belenyúlni a kimenetbe, de persze ehhez még számolgatni is kellett. Kb a tizedik ilyen után megelégeltem és nekiláttam írni egy kis sciptet, ami elvégezte ezt az utólagos kozmetikázást. Persze mindezt nem alaptalanul, ugyanis ez évről évre előjövő probléma volt, ugyanis a téli időszakokat a fejlesztési osztály leginkább ilyenekkel töltötte, ezért úgy éreztem a belefeccölt idő megtérül, arról nem is beszélve, hogy adott egy célt, ami mentén kódolhatok és sok olyan rész is volt itt, ahol újat tanulhatok. Excel táblák kezelése, batch feldolgozás, PDF generálás, stb. Ráadásul mivel egyszemélyben voltam a megrendelő és a fejlesztő is, így kellően motivált is voltam, hiszen tudtam, hogy mennyi munkától fogom megmenteni magam és a kollégákat is. Utóbbi csoport pedig biztos hálás is lesz mindezért, ami sosem árt egy munkahelyen. Ez persze eléggé megrészegített, emiatt utána el is határoztam, hogy teljes időben ezzel akarok foglalkozni, amit ott sajnos nem lehetett, így váltottam is. Ez viszont már egy másik történet.

Persze ez később is megmaradt bennem, hogy amit lehet és megéri, azt oldjak meg automatizáltan. Hogy miért mondom, hogy megéri? Mert ha valamivel napi 1 percet töltök, de automatizálni 3 nap munka lenne, akkor annak az automatizálásnak a megtérülési ideje olyan hosszú, hogy valószínűleg bele sem vágok, maximum a kihívás miatt.

Mivel elég sok kis apró projektem van, amiket használok is, ezért a hozzájuk tartozó build és akár deploy folyamatot is részben vagy teljes egészben egy CI szerver - esetemben a jó öreg jenkins - által futtatott scriptek és/vagy erre hivatott eszközök oldják meg. Nemrégiben pont szembesültem azzal, hogy mi is van akkor amikor ez kimarad. Van ugyanis egy régi mobilapp, amit fejlesztettem és ehhez évről évre hozzá kell nyúlni, de igen ritkán. Ennek a buildeléséhez és digitális aláírásához csináltam egy scriptet, tehát az első és legfontosabb lépés már megvolt. Viszont pont amiatt, mert ritkán kell használni nem oldottam meg, hogy Jenkinsen is fusson, hiszen úgy gondoltam ez a kis script elég. Ám időközben újratelepítettem a gépem, emiatt a script habár ott volt, de a megfelelő eszközverziók már kevésbé. Így amikor a legutóbb kellett volna felrakjam, akkor szomorúan konstatáltam, hogy az eszközök már nincsenek meg a gépemen vagy nem olyan csillag eggyüttállásban, amivel ez működne. Úgyhogy a vége az lett, hogy dockerizáltam ezt is és mostmár jenkins futtatja ezt is. Persze ezek nem feltétlenül olyan problémák, amikkel bárki találkozna, hiszen ehhez hobbiprojektek kellenek, vagy saját vállalkozásban kell űzni az ipart.

De tudnék említeni még egyéb példákat is a közelmúltból. A videós oldalamon az egyes sorozatokhoz és a videókhoz is tartoznak bélyegképek. Az oldal indulása idején még úgy voltam vele, hogy saját magam szerkesztgetek képeket az egyes részekhez, de ez hatalmas effort volt, főleg úgy hogy annyira nem is értek hozzá. Emiatt a következő lépés az volt, hogy csak az egyes sorozatokhoz készül kép, az egyes videók pedig ezt a képet megöröklik és csak egy kis szöveget cserélek rajta. Ez utóbbi cserét gimpben kb két perc alatt elvégzem, ami nem nagy idő, de továbbra is ott a hibalehetőség, hiszen egy ember - mármint én - csinálja mindezt. Arról nem is beszélve, hogy lassan 400 videó van fent az oldalon, ha két perccel számolunk, akkor már több, mint egy munkanapot töltöttem el azzal, hogy képekre írogatok szöveget. Persze ezt nem vártam meg, hanem már hónapok óta egy kis PHP script és a gd-text csomag segítségével csinálom meg mindezt. Hasonló a helyzet a videókkal is. KDEnlive-al vágom meg a videókat, amiket utána fel kell tölteni vimeora, utána láthatósági szabályokat és egyebeket beállítani. Időigényes, meg kell várni mire a program kiköpi magából, utána ki kell várni a feltöltést, mielőtt tudnám a vimeon szerkeszteni azt, sorolhatnám. Így már ezt is egy script tölti fel, ami figyeli a KDEnlive mappáját, sőt utána értesítést is küld. Ezután tudom csak a videóoldalon létrehozni az új epizódot, amit facebookra - ki nem találnátok - automatizmus posztol.

Na de ez még mindig egy kézzel futtatott script, aminek jó bemeneteket kell adni. A készült képet pedig fel kell tölteni az oldalra. Talán itt csúcsosodott ki igazán a “lustaságom”, ugyanis a vége az lett, hogy a sorozatok létrehozásakor töltöm fel a bélyegkép sablonokat, mind az oldalra, mind pedig a facebook megosztáshoz. Amikor új videót hozok létre, akkor elég beírni, hogy pontosan mit is akarok a képre írni, az pedig legyártja a sorozat sablonja alapján, optimalizálja és CDN-re fel is tölti a képeket helyettem.

Hasonló a helyzet az ingyenes videókkal, amiket youtube-ra is feltöltök. Ezt is meg lehet csinálni kézzel, feltölteni, címet, címkéket, leírást beállítani. Ez is inkább időigényes, meg macera, ráadásul ha utólag akarok valamit ingyenessé tenni - és sok ilyen is van -, akkor elő kell keresnem. Ehhez pythonban írtam egy kis flask appot, amivel ezeket az integrációkat kezelem a videóportál admin felületéről. Egy gombnyomással. Ez egyelőre még mínuszos, ha a spórolt és a belefeccölt időt nézzük, de leginkább azért, mert a pythont, flaskot és a köré épült eszközöket gyakoroltam vele, de ez megint csak az én “perverzióm”.

Ezt az automatizálás témát persze nem csak én súlykolom, hiszen manapság akad, amit lehetetlen automatizmusok nélkül elképzelni, az egész devops kultúra erre épül. Arról nem is beszélve, hogy mára már külön szolgáltatások is vannak automatizálásra, mint például a zapier. Ezzel rengeteg különféle appot tudunk összekötni különféle módon, slacket a google cloud printtel, Youtube-ot a Vimeoval és még sorolhatnánk.

Úgyhogy ha legközelebb azon kapjátok magatokat, hogy valamit már sokadjára csináltok meg, unjátok és tudnátok hasznosabban is eltölteni ezt az időt, akkor kis fejszámolás után lehet az első ilyen alternatíva az lesz, hogy kiváltjátok ezt a feladatot valamilyen automatizmussal.

Ez volt a minicube podcast, találkozunk legközelebb! Sziasztok!

More Episodes

10/27/2020

Mit is tesztelünk?

Season 1, Ep. 12
Sziasztok, az én nevem Papp Krisztián és ez pedig a minicube podcast 12. epizódja.Ma egy kicsit a manuális tesztelőkről fogunk beszélni, illetve arról, hogy mikor és mit nyomkodnak éppen és miként lehet tönkretenni a munkájukat egy tollvonással. Hogy szemléltessem, vegyük például Bélát, aki manuális tesztelőként dolgozik egy nagynevű multinál. A csapatában és az egész projekten úgynevezett SCRUM szerint dolgoznak, ami a valóságban inkább egy egy mini waterfallnak felel meg, de ebbe most ne menjünk bele. Maradjunk annyiban, hogy próbálnak kéthetente releaselni egy új verziót.Ezeket a releaseket sikerül is tartaniuk, ami a mai világban - ahol egyesek percenként, mások meg évente releaselnek - ez még igen jónak számít. Minden ilyen iteráció hétfőn kezdődik és a következő hét péntekig tart. Béla két hete úgy néz ki, hogy eldöntik mik is férnek bele ebbe a két hétbe, a fejlesztők elkezdenek rajta dolgozni, a tesztelők is elkezdik összerakni a teszt planeket, amik leírják hogy miként lehet letesztelni az adott új featuret. Közben persze a product oldalt és fejlesztőket is folyamatosan nyaggatják, hiszen mindig lehetnek fekete foltok a feladatokban.Az egyes featureök külön branchen kerülnek fejlesztésre, a fejlesztők pedig amit tudnak automatizáltan tesztelnek, de közel sem end-to-end. Ha valami kész van, akkor megy be master branchre, ez pedig kikerül egy tesztkörnyezetbe, lehet is nyomkodni a tervek alapján.Ekkorra általában a két hétből már egy eltelt, így a tesztelőknek van egy hetük letesztelni ezt. Hogy biztos legyen elég idő, a második hét keddi napja az utolsó, hogy kód bekerülhet a masterbe, ekkor kezdődik az úgynevezett feature freeze.Ez tök jó, de Béla nem ma kezdte, szóval kedden délelőtt talál valami turpisságot, amiről kiderül, hogy biza egy bug, mégpedig nem is kicsi. Ez így nem mehet ki, meg kell javítani. Meg is kapja a fejlesztő a nemes feladatot, hogy javítsa meg, de vészesen szorít az idő, ráadásul a feature freeze már életben van.Sebaj, mert a feature freeze nem érvényes a hibajavításokra, arra ott van a code freeze, ami szerdán van. A fejlesztő megtolja az igát rendesen, be is kerül a javítás masterbe, el lehet kezdeni tesztelni. Ezúttal szerencséje volt, Béla se talál kivetnivalót a featureben, így pénteken terv szerint kimegy a release, amiben már benne van a hibajavítás is.Aztán vasárnap csörög a telefon valakinél, ugyanis nagy baj van, mert a korábbinál még nagyobb hiba került a rendszerbe. Hát mégis hogy lehet ez? Hiszen a többi csapat tesztelői is tesztelték az alkalmazást.Igen ám, de melyik verziónak és mely részét tesztelték éppen? Ugyanis amit a hét elején teszteltek, az nem ugyanaz volt, mint kedden, vagy a fejlesztőnk módosításai után, hiába halasztják a regressziót a végére.Mit kellett volna tenni? Halasztani a releaset? Hát azt nem szeretik a menedzserek.Esetleg tesztelni külön feature branchen? A feature brancheket kirakni külön teszt környezetekbe és ott le lehet tesztelni. Működhet, de mi a garancia, hogy a módosítások nem akadnak össze valaki máséval a masteren és nem okoznak valami galibát? Sőt, ha már galiba, leteszteli a feature branchen a Béla, rámondja az áment. Frankó, mergeljük be… de valaki megelőzött és most rá kell húzzam a mastert. Ha nincs conflict, az még a jobbik eset, de ha van akkor végképp más szoftvert fogunk kireleaselni, mint amire Bélánk áldását adta.Megvan, revertáljuk a commitokat! Működhet, csak akkor megint visszajutunk oda, hogy a revert mit okozhat? Mikor fog ez kiderülni? Ugyanez a helyzet azzal, hogy cherry pickelgetünk.Feature flagek! Ez lesz a megoldás, ugye? Már majdnem jó, de csak bizonyos esetekben működhet, mikor egy teljesen új funkcionalitást tudunk vele ki/be kapcsolni, hiszen ha valami korábbi logikában valami kapcsoló, akkor a kikapcsolt állapot is rejthet meglepetéseket.Toljuk el a releaset pár nappal, ez még belefér, nem? Na igen, húzzák a szájukat a menedzserek, de ha nem létkérdés, talán benne vannak. Cserébe felborul a rend és ki tudja hány ember számára rövidül meg ez a két hetes periódus. A keddi feature freezeből szerdát akarnak a fejlesztők, a tesztelők pedig inkább hétfőt, hiszen nekik még az elcsúszott release után kell feltakarítani.Ráadásul minden külső függőség újabb csúszás forrása lehet. Tegyük fel, hogy egy másik csapat, aki egy olyan szolgáltatást fejleszt, amit mi használnánk az új featureben nem készül el időre és a projektmenedzser közli, hogy ezt meg ezt ki kéne venni a releaseből. Éééés bumm, kezdődik az egész előlről.Arról nem is beszélve, hogy ahogy hízik az alkalmazás és egyre több funkcionalitás kerül bele, a regressziós tesztelés ideje egyre csak nő és nő. Persze felvehetünk még több tesztelőt, de akkor mit fognak csinálni a hét elején? Mert amit akkor nyomkodnának már nem lesz ugyanaz, mint ami pénteken kikerül, akkor pedig mit is teszteltek?De most komolyan nincs erre megoldás? Dehogynem, csak ahhoz bizony a manuális tesztelés kevés. A tesztelőknek is automatizálniuk kell, legalább részben, hiszen amíg a regresszió is kézzel zajlik, addig bármikor bármi történhet az ilyen-olyan csúszások miatt, hiszen emberek vagyunk.Na de hogy és mit fognak ők automatizálni? Pontosan azt, amit eddig is csináltak, a felület nyomkodását, legyen az valami desktop alkalmazás, weboldal, vagy épp mobilapp. Ráadásul, ha a tesztesetek megfelelően voltak dokumentálva, akkor igen gyorsan össze lehet ezeket rakni, hogy aztán bármikor el lehessen indítani egy folyamatot, ami odanavigál az oldalra, végrehajtja ugyanazt, mint amit a tesztelő tett volna és megvizsgálja, hogy valóban azt látja-e, mint amit kellene.Weben erre való a selenium, amivel a böngészőt tudjuk irányítani. Ha akarjuk futtathatjuk ezt a saját gépünkön, vagy egy úgynevezett headless böngészőben valami szerveren, az eredmény ugyanaz lesz. Ha nemigen van javascript a frontenden, akkor még lehet selenium sem kell, hanem az adott keretrendszer - amiben az oldal íródott - is biztosíthat ere eszközöket, amikkel a űrlapokat tudunk elküldeni és aztán a HTTP választ vagy éppen a HTML-t vizsgálni.Ehhez persze fontos, hogy a UI olyan módon legyen elkészítve, hogy a gombok, mezők, lényegében bármi amit vizsgálni, kitölteni, megnyomni akarunk egyértelműen beazonosítható legyen. Ha ez megvan, akkor nincs más dolgunk, mint bekötni mindezt a saját kis CI pipelineunkba. Tehát bármikor, amikor pl a masterbe bekerül valami, kirakjuk az alkalmazást egy izolált, stabil környezetbe és utána ráengedjük ezeket a teszteket és megnézzük, hogy minden stimmel-e. Ha nem, akkor bizony jelezzen és javítsuk ki a hibát, ez legyen az elsődleges prioritás. Fontos, hogy ez a környezet ne változzon, tehát mindig ugyanbból az állapotból induljon, takarítsuk ki a db-t utána, ne legyenek fals pozitív ereményeink, ugyanis az igen hamar megrendíti a bizalmat a rendszerben és hamar visszatér a teljes manuál tesztelés.Na és mi a szerepe a tesztelőknek itt? Nem egyik percről a másikra megy egy ilyen átállás, nyílván az opsnak is van köze hozzá, meg kell hozzá programozni is.Viszont szép lassan el lehet kezdeni a regresszió elemeit átírni ide, azokat már nem kell a releasek előtt megcsinálni, vagy egyre kevesebbet, aztán el lehet kezdeni az új featureöket is egyre inkább automatizáltan tesztelni és utána már lehet nem is kell várni két heteket a releasere, hanem amint bemergeltük a featuret és zöld lett a build, már lehet is élesíteni azt. Miért? Mert minden buildnél mindent tesztelünk.Ez volt a minicube podcast, találkozunk legközelebb! Sziasztok!
9/1/2020

Not just codemonkeys

Season 1, Ep. 11
A programozói pályát sokan sokféleképpen képzelik el, de azt elmondhatjuk, hogy a középpontban szinte minden ilyen elképzelésben maga a kód áll, emiatt is jött a kifejezés, hogy valaki pl jó kóder. Ezzel nincs is baj, habár számomra a kóder szó inkább pejoratív, de ez egy másik történet. A gond ott van, hogy sokan így is képzelik el a szakmát, vagy éppen így élik meg azt, hogy semmi más dolguk sincs, mintsem kódot írni. Ennél messzebb viszont nem is lehetnénk a valóságtól (legalábbis remélem). Ugyanis a kód az habár fontos produktuma a munkánknak. Álljunk csak meg! Mégis mi a produktuma a mi munkánknak? Mert hogy nem az általunk írt kód az tuti. Na és miért mondom ezt? Mert minket senki sem kért meg soha egyetlen if-else ágra, vagy hogy írjunk SQL-t. Minket egyszerűen nem ezért fizetnek. Hanem azért, hogy problémákat oldjunk meg az ügyfél/ügyfelek számára. Az, hogy történetesen ennek része az, hogy pl. SQL-t írunk, vagy éppen CSS-t hegesztünk, az csupán a szakmánk sajátossága. A cipészt sem kérik meg arra, hogy oda meg oda üssön egy apró szöget, valamit ragasszon meg itt és ott, hanem javítsa meg a cipőt, az hogy mindezt hogy oldja meg, már az ő szakterülete.Viszont azon a bizonyos kódon kívül még rengeteg mást kell tudnia egy jó fejlesztőnek. Az egyik ilyen, hogy tudnia kell, mikor nem is szabad nekiállni valaminek, mert nem fog működni. Sőt, ezelőtt nem árt, ha egyáltalán tudja, hogy mit is kell csinálnia, ugyanis az ügyfelek nem a jól meghatározott üzleti igényekről híresek. Tehát azt már látjuk, hogy nem tudjuk elkerülni azt, hogy kommunikáljunk a projekt egyéb résztvevőivel, akik bizony nem fogják megérteni a technikai részleteket. Ezt tudnunk kell lefordítani másoknak, valamint visszafele is, az általuk megfogalmazott igényeket is tudnunk kell valahogy technikai nyelvre fordítani. Ha ez nem lenne elég, ha nem egyéni vállalkozóként dolgozunk, akkor nagy valószínűséggel csapatban, emiatt egymás közt is kell kommunikáljunk. Bizony, a sarokban ülő programozó, aki egymaga fejleszt valamit egy kihalófélben lévő faj. A tudást meg kell osztani másokkal, dokumentációt kell írni - bármennyire nem szeretjük azt -, hiszen gondoljunk bele mi mennyi ilyet olvasunk? Valaki ugyanúgy beletette az energiát előttünk, hogy ne a kódból próbáljuk kitalálni mi is történik, vagy éppen stackoverflow válaszokból összehalászni azt.Na persze ne feledkezzünk el a meetingekről sem. Itt abba nem mennék bele melyik hasznos vagy éppen haszontalan, ezt cége válogatja, de valószínűleg itt vagyunk a legmesszebb a kódtól, hacsak nem lenémítva kódolunk a másik monitoron közben.Ha már kód, akkor bizony egymás kódját is át kell nézni, a benne talált hibákat érthetően és lehetőleg nem sértőn megírni a másiknak. De gyakran közösen is kell kódolni vagy éppen hibát keresni, logokat, metrikákat bámulni, hogy megtaláljuk a hiba okát, ha nem esünk rögtön a javításának, akkor mindezt felvinni valahova.Ha pedig felvisszük valahova, akkor elő is kerülnek a projektmenedzsment rendszerek, ahol szintén sok időt töltünk el.Képzeljük el, hogy házat akarunk építeni. Van egy elképzelésünk, odahívjuk a kőművest, ácsot, stb. és kiadjuk nekik, hogy ezt kell csinálni, van rá öt nap, ők meg rögtön nekiállnak? Dehogy fognak, hiszen lehet amit elképzeltünk nem is megvalósítható, vagy éppen nem biztonságos, időtálló. Azért ők a szakemberek, hogy megmondják, ha valami szakmailag nem lesz oké. Ők fogják megmondani azt is, hogy mennyi idő alatt lesz kb kész. Ugyanez a helyzet nálunk is, mintha minden egyes ticket a projektmenedzsment rendszerben egy újabb építkezés lenne, viszont nálunk sokkal komplexebb elképzeléseket kell megvalósítani, esetleg azok nem annyira letisztultak, így a konkrét megvalósítás kevesebb időt vesz igénybe, mert inkább nyomozni kell az után, mi is a konkrét feladat.Ugyanezért fontos ismerni magát az üzletet, hogy megfelelően tudjuk ellátni a feladatunkat. Minél jobban ismerjük azt, annál inkább tudunk testreszabott megoldást adni, hiszen nem kódot szállítunk, hanem egy üzleti megoldást. Annak ismerete nélkül igen nehéz lenne. Az információ hiánya, vagy a félreinformálás bizony nagy galibákat tud okozni, ezzel nekem is van egy igen rossz élményem. Amikor egy olyan funkciót fejlesztettünk, ami a felhasználói fiókok megosztását tette lehetővé és felmerült a kérdés, hogy volumenét tekintve egy felhasználóval hány ilyen fiókot is fognak megosztani. Itt azt az információt kaptuk, hogy pár ilyen lesz majd. Ennélfogva a rendszert úgy építettük meg, hogy ezt feltételeztük. Később, mikor élesítettük, akkor bizony kiderült, hogy ezek inkább 200 fölötti számok, amiknél bizony a mi megoldásunk nem teljesített úgy, mert nem erre terveztük az egészet.Persze van olyan hely, ahol nem ez a helyzet, hanem az előbb említett abszurd módon gondolkozik a vezetés. Ezekről a helyekről érdemes mihamarabb menekülni. Szóval ha esetleg projekt menedzserek, product ownerek is hallgatják az adást, akkor nekik is üzenném, hogy ahogy a fejlesztők sem csak kódolnak, úgy nekik sem annyi a dolguk, hogy rátolják a feladatot, mindenféle kontextus, háttér nélkül a fejlesztőre és az majd megoldja, hiszen már láttuk az én esetemből, hogy miket eredményezhet.Jó esetben juniorként nem dobnak be rögtön a mély vízbe és a fenti feladatok nagyját leveszik a vállunkról, de ahogy haladunk előre a pályáján, egyre jobban bele kell magunkat ásni a fenti problémákba. Tehát el kell szomorítsam a hallgatókat, ugyanis senki se remélje, hogy mindig kész, jól megrágott feladatokon kell majd dolgoznia és majd elkódolgat a sarokban egyedül.
8/10/2020

Mi a cél?

Season 1, Ep. 10
Sziasztok, az én nevem Papp Krisztián és ez itt a minicube podcast tizedik epizódja.Az elmúlt időszakban kicsit megakadt a podcast és videókészítés is, aminek az oka roppant egyszerű, ugyanis vizsgára készültem, de igyekszem bepótolni a lemaradást.A mostani epizódban megint egy kicsit elmélkedni fogunk, ezúttal az interjú folyamatokon. Mindez onnan jött, mert a minap láttam egy gyakorlati repülős vizsgát még régről, ahol a repülés előkészítést és hasonlókat ellenőrizték.A vizsga során szépen végig kell menni a folyamaton és bemutatni azt, mindezt gyakorlati szemszögből. Sok döntést kell meghoznia a vizsgázónak ezzel és azokat a döntéseket megfelelően meg is kell indokolnia. Ezekből igen hamar kiderül, ha valaki nem látja a teljes képet.Erről eszembe jutott, hogy volt egy hasonló tárgyam még a mesterképzés alatt, amitől mindenki rettegett. Volt aki csak azért költött el egy vizsgaalkalmat, hogy beülhessen meghallgatni valakit, aki vizsgázik, ugyanis erre nem lehetett a szokásos módon felkészülni, mert hasonló volt, mint egy tantárgyakon és éveken átívelő szigorlat.A neve is utalt erre, integrált szántóföldi növényvédelem. Nyílván a hallgatók többségének nincs sok köze a mezőgazdasághoz, de a lényeg, hogy nemigen vannak kőbe vésve a dolgok. Tehát nagyon sok tényező határozza meg akár csak a vetésidőt is az adott növény esetében, kezeléseket, stb. Az oktató kedvenc kérdése pedig az volt, hogy “mi a cél?”. Ez pedig szinte bármely kérdésre adott választ meg tud menteni, ha meg tudjuk indokolni azt.Ha a saját szakmánkra tekintünk, akkor nem hasonló a helyzet itt is? Nem az van, hogy egy adott cél eléréséhez százféle módon el tudunk jutni? Szinte minden technikai döntés mögött van valamilyen ok vagy cél.Legyen mondjuk a cél egy videómegosztó szolgáltatás. Rengeteg technikai kérdés fel fog merülni a fejlesztés során. Milyen nyelvben írjuk, milyen adatbázis lesz mögötte, a frontendre kell-e valami keretrendszer, ha igen akkor melyik? Hol fogjuk hostolni, satöbbi. Mennyi minden derülne ki a jelöltről, ha ilyen kérdéseket megválaszolna?Persze egy juniortól nem várhatjuk el, hogy ilyen távolról lássa a dolgokat, ezért az esetükben más módszerekhez kell fordulni. Igaz egyfajta szintfelmérésre is alkalmas lehet, hiszen ha az indoka egy adatbázis mellett annyi, hogy azt ismeri, az sem egy rossz válasz, de máris tudjuk, hogy nem kell nagyon nyüstölni szegényt az adatbázisok összehasonlításával.Akkor most gondoljunk abba bele, hogy mi hogy felvételiztetünk? Milyen kérdéseket teszünk fel, hogy néz ki ez a folyamat, mi képezi a részét? Tegyük fel, hogy van egy online tesztünk. Mi bizonyítja, hogy az adott ember oldotta azt meg? A személyes körön vagy egy online call alkalmával rákérdezünk erre-arra, hogy kiderítsük az illető írta-e a kódot/tesztet? Simán csak megnézhetjük a rossz válaszokat és megnézhetjük, hogy egy kis rásegítéssel megy-e, ezzel legalább nem csak eldöntendő kérdésekre kapunk bináris eredményt, hanem kicsit belelátunk abba is, hogy az illető jelölt hogy gondolkodik és úgy is érezheti ezzel, hogy van lehetősége javítani, mint egy szóbelin az írásbeli után.Sajnos a legtöbb interjú teljesen személytelen, kitöltünk valami tesztet, adnak valami feladatot, ami alapján egyik nap felhív valaki, hogy bocsi, nem te voltál az igazi, vagy épp fordítva. Ez alapján már meg se fogjuk próbálni újra annál a cégnél, mert semmi irányt nem kaptunk, hogy vajon mit rontottunk el. Olyan ez, mintha annyit mondanának arra a kérdésre, hogy miért nem feleltünk meg, hogy “csak”.Természetesen ez lehet azért is, mert rengeteg embert futtatnak át a rendszeren és nem lenne idő mindenkivel személyesen foglalkozni, ezt aláírom. Azonban akikkel foglalkoznak is, azokkal tényleg foglalkoznak? Nem ők a századik ember, akivel megoldatják ugyanazt a feladatot és várják a csodát?Pontosan emiatt kényelmesednek el a cégek, mert rengeteg jelentkező van és nem igazán érdekli a legtöbbjüket a negatív marketing az interjúk minősége miatt. Hiszen úgyis van annyi jelentkező, mit számít, ha emiatt elvesztünk párat? Kérdés, hogy vajon abban a pár elvesztett jelöltben lenne-e az, aki csont nélkül átmegy az interjún és értékes tagja lenne a csapatnak?Anno, mikor még én is fiatal voltam és kellett a pénz, jelentkeztem egy full stack JS állásra. Sajnos ez nem jött össze, de egyáltalán nem rossz szájízzel fogadtam a hírt, ugyanis annak ellenére, hogy nem sikerült, nem egy bináris választ kaptam telefonban, hanem szépen pontokba szedve kaptam egy igen részletes értékelést arról, hogy mi volt jó vagy éppen mi volt rossz a megoldásomban. Innen lehetett érezni, hogy valaki tényleg foglalkozott ezzel és vette a fáradtságot, hogy kb fél órában összeírjon róla egy rendes feedbacket.Nem fogok cégnevet elárulni, meg lehet nem is a cég, hanem egy igazán elhivatott ott dolgozó érdeme mindez, de az biztos, hogy nagyon jó példát mutatott és ha újra JS-re vetemednék, akkor lehet ott próbálkoznék először.Szóval a felvételi eljárásokra is igaz a mondás, némileg átértelmezve, hogy aki sokat markol, keveset fog.Ez volt a minicube podcast, találkozunk legközelebb, sziasztok!

Comments