tag:blogger.com,1999:blog-37392197557522558382024-03-05T14:09:10.301+01:00I will work for foodpublic static void mainKockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comBlogger395125tag:blogger.com,1999:blog-3739219755752255838.post-62155079921687748112024-02-08T19:53:00.000+01:002024-02-08T19:53:17.628+01:00AWS kaland<p>Van egy érdekes adathalmaz, sajnos 2 TB bz2 tömörítve. Csináltam egy kis programot az elő feldolgozásához. Hát elég kínkeservesre sikerült, rettenetes türelem kellett hozzá hogy az első szeletét a laptopomon feldolgozzam. Lenne igény új IT felszerelésre, csak éppen válság van és másra még nagyobb szükség van.<br />Gondoltam meghúzom amazon-on. Indítottam egy VM-et, 4 epyc core, 16 GB RAM. A munka tizedével végzett kicsit több mint egy hét alatt, közbe 50 dollárnyi számlát csinált. Tehát a teljes munka nagyjából 500 dolláerba kerülne.</p><p>500 dollár az elgondolkodtató, mert az egy használható munka-laptop árának a fele lenne. Szóval akkor elgondolkodtam rajta, hogy vajon hol lenne jobb helyen a pénz. Válság van, ha nem jutna eszembe minden szaros percben.</p><p>Akkor milyen egyéb opció van? Csináltam pár éjszaka JMH teszteket a program részeire és találtam is pár dolgot, amit igazán jobban is meg lehet csinálni, tulajdonképpen ezek vitték el az idő túlnyomó részét. Sikerült leküzdenem a feldolgozás idejét 5 napra. Újabb tiz százalékkal közelebb a célhoz, annélkül hogy újabb 50 dolcsiba került volna. Mert most már nem AWS-en folytattam, hanem egy öreg használaton kivüli NUC-on. Lassan odaérek majd hogy raspberry-n fut minden.</p><p>Még egy optimalizációt találtam, azzal már a feldolgozás ideje leesett 1 napra a nyomi öreg kis NUC-on. Ezzel már néhány nap alatt befejezem. Az 500 dollárnak majd találok valami más helyet.</p><p>Végülis nem olyan rossz egy válság, legalább az ember elkezd végre értelmesen gondolkodni, ahelyett hogy minden problémát a hitelkártyájával intézne el.<br /></p>Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-23407536405228524222023-12-03T19:58:00.001+01:002023-12-03T19:58:33.633+01:00Valamire jó lesz<p> </p><p>Vasárnap esti sztori.</p><p>Régebben egy magyar cégnek dolgoztam. A
főnököm egyik ötlete az volt, hogy csináljunk egy riport generálót ami
PDF-be köpi ki a riportot. Végigmutogattam neki az akkori open source
cuccokat, egyik se tetszett neki, azt mondta mind túl lassú. Nem győzött
meg igazán, de engem nem is kellett meggyőzni mert ő volt a főnök.
Azért nem szokunk ilyet csinálni, mert<br /></p><ol style="text-align: left;"><li>Igyekszünk
a munkánk eredményét minnél elöbb eljuttatni a
felhasználóknak/vevőknek. Ha mindenből sajátot csinálunk, azzal ez
messzire eltolódhat - vagy esetleg valaki beelőz és nézhetünk szomorúan.<br /></li><li>Ha
felhasználjuk azokat a komponenseket, amiket mások is használnak, talán
azok a mások már megtalálták és kijavították a hibákat benne.</li><li>Sajnos
tényleg, a szoftverfejlesztő gyakran sokkal drágább, mint a CPU-idő.
Például ezért van maga a JAVA is. Hiszen amit assembly-ben nem lehet
megcsinálni, azt nem lehet megcsinálni.<br /></li></ol><p>De akkor nem
volt más, nekiláttam egy PDF-et generáló riport komponesnek, ehhez át
kellett olvasnom a PDF formátum dokumentációját.</p><p>Pár hónappal
később a főnököm autóbalesetet szenvedett, kórházba került több hónapra,
és a végén az orvosok nem tudtak rajta segíteni, meghalt. Vigyázzatok
az utakon :( Az új főnöknek nem volt erről a projectről és az
előzményeiről lövése se, kicsit zűrös fickó volt, úgyhogy én elbúcsúztam
tőlük. Aki átvette tőlem ezt a PDF generáló cuccot, az egyetlen kérdése
az volt a dologgal kapcsolatban, hogy "te hülye vagy, bammeg?" Én is
valahogy úgy ástam el az agyam valamelyik zugában a PDF formátum
technikai részleteit, hogy na ezt egészen biztosan soha többé nem kell
előássam.</p><p>Eltellett 20 év, mint egy pillanat.<br /></p><p>Idén
valamikor egy felhasználó panaszkodott, hogy a feltöltött dokumentumából
valami hiányzik, kevesebb oldal van, mint amennyit ő feltöltött. A
panaszelhárítók második védelmi vonala nem tudott mit kezdeni a
dologgal, átírányították hozzám, nézzem meg nem szúrt-e el valamit a
becses szoftverünk. Elkértem feltöltött a dokumentumot tőlük, megnéztem
egy szővegszerkesztővel és ezt még fejből el tudtam mondani válaszként
gyorsan:<br />A PDF dokumentum a végén kezdődik, ott van egy katalógus,
amelyikben minden oldal fel van sorolva. Ha nincs ott a PDF katalógus,
akkor a PDF olvasód sem tud mit kezdeni a dokumentummal, akkor az
sérült. Ha viszont ott van a katalógus, akkor látod benne az oldalak
számát, tehát nem veszthettünk el belőle semmit. A felhasználót tehát
elküldtük más balekot keresni magának. Akkor jutott eszembe, hogy mikor
és hol olvastam a PDF formátum párezer oldalas specifikációját.<br /></p><p>Talán
tényleg nincs teljesen felesleges tudás. Talán ha nagyon sokat várok
rá, az egyetemi dolgoknak is megtalálom a kicsi kis értelmét, valahol
majd megtakarít nekem napokat, vagy talán csak egy órányi fejtörést.</p><p><br /></p><p>Vagy ahogy a költő mondta "tegyetek el befőttet, lesz még a világ jövőre"<br /></p>Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-8070376927776705332022-10-10T15:13:00.000+02:002022-10-10T15:13:20.446+02:00Ha a szoftvered egy ház lenne<p>Az ember évezredek óta épít házakat, a ma élő emberek életük legnagyobb részét falak között töltik. Nem vagyok történész, de azt gondolom, hogy ez a civilizációnk egyik sikertörténete. Kb 7 milliárd embernek van ötlete arról, hogy ezeknek a falaknak milyennek kell lennie és bár különbözőek az igényeink és elképzeléseink (pl legénylakás, családi ház, művészgarzon, hippitelep, gengszterbarlang) nagyon sok ponton egyetértünk pl hogy ne nyíljon a wc a konyhába, hogy ne a hálószobába nyíljon a főbejárat, satöbbi. Néha láthatsz valamit, ami nagyon meglepő. Akikkel együt nézed, azokkal könnyen meg tudod beszélni az élményeidet, van rá egy közös nyelvünk és szavaink amit mindenki ért, hiszen ezt csináltuk egész eddigi életünkben: falak között vagyunk. Ennyire alapvető közös élmény talán csak az evés lehet, vagy az utazás. És ha esetleg valakivel nem beszélünk egy nyelvet, még akkor is látja a házainkat. Egy teljesen átlagos napon többszáz házat megnézhetsz, el se fáradsz és hamar véleményt alakítassz ki róluk.<br />Még ha az árak szempontjából nézzük is, a legtöbb embernek van ötlete vagy legalább véleménye egy ingatlan áráról, hogy egyáltalán ér-e annyit vagy teljesen irreális. Az árakat általában az telekár, az anyagköltségek és a munkaerő ára határozza meg. Ha ugyanarra a dologra két különböző beszállítótól kérsz ajánlatot, várhatóan a különbség esetleg 10-20% körül lesz, nem tizszeres árat kérnek.<br /></p><p><br /></p><p>A szoftver architektúra sajnos eléggé más kérdés. Alig néhány évtizede használunk szoftvereket, bár egyre aktívabban, de azért a valahol lakás élményével szerintem nem lehet összehasonlítani. Még mindig van egy csomó ember, aki egyáltalán semmilyen szoftvert nem használ. Pl Magyarországon még lehet a vonaton jegyet venni, ha a vasútállomáson nem lehetett.<br />A legtöbb ember csak használ szoftvert, azoknak az aránya, akik módosítanak vagy esetleg teljesen újat írnak viszonylag alacsony a felhasználókhoz képest.<br />A szoftver-fejlesztés nyelve nem igazán része a hétköznapi kommunikációnak. Látsz valami furcsát, nincsenek rá szavaid hogy egszerűen elmondd a családodnak. Ha megpróbálod, sokág tart, nem értik, furcsán néznek rád, nem is tudják a szoftver furcsa-e, vagy inkáb te. Egy idő után talán te se tudod.<br />Emiatt viszonylag kevés konvenció van. Nap mint nap találkozol olyan megoldásokkal, aminek az építészeti megfelelője talán egy iglu lenne a szaharában, viszont elég sok időre van szükséged ahhoz, hogy akár a projektmanagerednek megmagyarázd, hogy ez nem oda való. Elmondja, hogy járt a sarkkörön és egy iglu megmentette az életét, hosszasan magyarázhatod, mi a különbség a sarkkör és a szahara között és hogy ez egy tényleg fontos különbség. Nem látható, nem tapintható, a legtöbb ember számára nem egyértelmű. A marhaságnak néha se eleje, se vége.<br />Ja és végül a szoftver ára... nyilván ez is piacelven működik, de nincs rá tradíció, hogy mennyibe kerülhet egy jó CAD szoftver, vagy mennyibe kerül egy jó IDE, mennyit adnál egy relációs adatbázis szoftverért, az árkülönbségek egészen döbbenetesek.<br /></p><p><br /></p><p>Ha a szoftvered egy ház lenne... hát igen, az nagyon klassz lenne.<br /></p><p>Kapcsolódó: <a href="https://kodzaj.blog.hu/2020/11/07/masvalaki_kodja">Tvik írása többek közt a lakásfelújításokról</a><br /></p>Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-6438574614157836452022-07-28T23:10:00.002+02:002022-07-28T23:10:55.001+02:00Review Antipattern: a sötét oldal<p>Ma egy kis anti-pattern csoportról írnék</p><ol style="text-align: left;"><li>fenyegetés</li><li>félelem</li><li>bosszantás</li></ol><p>Példa: a szoftverben, amin dolgoztam, elkezdett felhamozódni egy rakás kód, ami teljesen más konvenciókat és ötleteket követett, mint a többi. Python név-konvenciók. Küldtem rá pár patchet és valaki gyorsan be is mergelte. Azt hiszem már másnap meg is jelent egy mérges szoftverfejlesztő és azzal fenyegetett (<span style="background-color: #fcff01;">első pattern</span>), hogy ha nem csinálom vissza, akkor azzal aláz meg, hogy ő reverteli. Hagytam, had dühöngjön. (<span style="background-color: #fcff01;">harmadik pattern</span>: bosszantás, mit gondoltál, hogy valami szent-ember vagyok, aki odatartja a másik orcáját is?) Értelmesen beszélni nem lehetett vele sajnos.<br />Közben odajött egy ismerős srác és mondta, hogy ne hergeljem fel azt a pythonos csókát, mert ő a "nagyfőnök kis kedvence". Az, aki a patcheimet bemergelte szintén pánikszerű visszavonulót tartott, még elnézést is kért. - <span style="background-color: #fcff01;">második pattern</span>: beparáztak a nagyfőnök kis kedvencétől.<br /></p><p><br />Szép kis alakok vagyunk, mindenki mást csinált, mint ami elvárható lett volna tőle. És hát jaaa, a cég is olyan... más mint a marketinganyagokban. Nagyfőnök kis kedvence? hmm...<br /><br />Nagyon szeretném, ha ez egy extrém és ritka helyzet lenne, de nagyon sokszor láttam már hasonló helyzetet, máshol is. A másik baj pedig az, hogy nem is tudom volt-e olyan, amikor nem működött. Sajnos talán nem. Ha a szinvonal már odáig züllött, akkor simán be lehet vetni.<br />Döntsd el, hogy mit csinálsz vele, de én látok némi igazságot abban a mondásban, hogy többet ront rajtad egy gáz munkahely, mint amennyit te javítassz rajta.</p><p><br /></p><p>Szóval a pattern nagyon egyszerű, nem kell mást csinálni, csak üvölteni, viszont az ehhez szükséges pozíciót el kell foglalni - nagyfőnök kis kedvence, jótékony diktátor, 10x developer, vagy a többi marhaság. De látod milyen sokan megcsinálták.<br /></p>Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-69288393329526121082022-07-26T00:21:00.000+02:002022-07-26T00:21:18.301+02:00Review Antipattern: köpj bele és hagyd ott<p>Ez egy nagyon gyors és rendkívül hatékony antipattern, arra az esetre, ha pl szabadság elött még valakinek tönkre akarod tenni a munkáját.</p><p>Ihlető történet: kollégiumokban kaját nagyon nem volt célszerű elölhagyni, rárepülnek a legyek, vagy mégrosszabb. Hogy ezt megelőzzék az ocsmány bentlakók, mielött elhagyták a helységet beleköptek a saját levesükbe. Persze lehet aztán más is, de valószinűleg egyáltalán nem azt akarta az emberünk elérni vele, hogy később ő megehesse, hanem azt, hogy <b>más se</b> egye meg.<br />Ez nem annyira kedves emlék nekem Magyarországról. Valljuk be gusztustalan, mint egy anti-pattern, de magyarabb akárhány pusztai gémeskútnál akár még szürkeménessel együt is.<br /></p><p><br /></p><p>A pattern: nagyon egyszerű, csak egy kommentet írj egy nagyon nagyon nagyon általános és bizonyíthatatlan ellenvetéssel. Például:</p><ul style="text-align: left;"><li>ez a változás ellentétben áll az OOP alapelveivel (ha úgy nézzük, minden a világon)<br /></li><li>sérti a REST szabályait</li><li>egy anti-pattern-en alapul (hát persze, hiszen minden pattern valakinek antipattern, de melyik az és miért)</li></ul><p><br /></p><p>A lényege az, hogy ilyenkor senki sem meri majd elfogadni a változást, mert van egy ellenvetés, ami bár homályos, de nem kezdődik majd róla vita, mert akkor elöbb a saját tájékozatlanségukat kellene beismerniük az embereknek, legalább egymás elött. Na igen, ez az anti-pattern akkor nem működik, ha az emberek őszintén és félelem nélkül be tudják egymásnak vallani azt, hogy fingjuk nincsen miről beszél ez a marha. Ez nem mindenhol van így. Hála istennek, ilyen anyagot nyom az ipar nagy része, hogy rock-star engineer, meg 10x engineer, ja meg persze senior mindenki.<br />Szóval kis kivétellel mindenhol bevethető, gyors, hatékony.<br /></p><p><br />Ennyi. Buenosz étvágyosz.<br /></p>Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-181234554590790282022-07-25T23:40:00.001+02:002022-07-25T23:41:20.505+02:00Review Antipatterns: Egy tonna ez-az<p> A code review kiválló eszköz arra, hogy egy csapat szoftverfejlesztő<br /></p><ul style="text-align: left;"><li>átnézze és tesztelje egymás változtatásait, megelőzzön hibákat<br /></li><li>megossza egymással a felelősséget</li><li>megosszon egymással ötleteket</li></ul><p>Bár a fentiekre is lehet használni, lehet arra is hogy:<br /></p><ul style="text-align: left;"><li>egyébként működö fejlesztést szabotálj vele</li><li>karriert építs a cég és a csapatod kárára</li><li>te legyél a domináns izé, a vezérfarkas, a matriarcha, ilyesmi <br /></li><li>bosszút állj valakin, aki bosszút állt rajtad valamiért... lehet ez egy hosszú és bonyolult történet, de biztosan ő kezdte<br /></li></ul><p><br /></p><p>Gondoltam összeszedek pár mintát azokból az esetekből, ami a másodikra jó. Ezeket önkényesen anti-patternnek nevezem el, mert azért a jó arcok mégis az elsőt próbálják. Szoftvert csinálnak is vele, de karriert azt nem.<br /></p><p><br />Itt jön az első anti-patternem:<br /></p><p><br /></p><h3 style="text-align: left;">Egy tonna ez-az</h3><p><br /></p><p>Egyszer gyerekkoromban édesanyám tökfőzelékkel várt haza. Természetesen még most is rühellem a tökfőzléket, főleg ha van benne kapor is és persze volt. Csak ültem felette és nem csúszott le. Édesanyám kérdezte, hogy mi a baj vele. Mondtam hogy semmi íze nincs, talán egy kis só kellene még hozzá. Kaptam egy kis sót rá, akkor azt mondtam hogy most már túl sós és inkáb egy kis cukrot kérnék rá. Aztán megint sót, fahéjat, kecsapot és így tovább amig nyilvánvalóan még a legyek se szállnának rá többé az eredetileg teljesen szabványos tökfőzelékre. Természetesen az volt a vége, hogy édesanyám lecsűrt egy nyaklevest és kidobott a konyhából.<br /></p><p>Ez azért egy kedves emlék, édesanyám rájött egy perc alatt arra, amivel szoftverfejlesztők szivatják egymás éveken és évtizedeken át, pedig soha nem írt egy betűnyi szoftvert se.</p><p><br /></p><p>A pattern: addig-addig kérj újabb és újabb kiegészítéseket a munkatársadtól, amíg a munkája nyilvánvalóan egy teljesen megmagyarázhatatlan szerencsétlenséggé nem válik. Innentől már ott is hagyhatod a többi reviewernek, hogy ők hánnyák le, vagy csak valami marhasággal palástold el saját felelősséged az üggyel kapcsolatban "nem halad a megfelelő irányba"<br />Persze ha valaki rászánná az időt és végigolvasná a review menetét, akkor kiderülhetne, hogy mit csináltál. De hát nem fogja úgyse soha senki végigolvasni, meg mit kezdene vele ha mégis.<br /></p><p><br /></p><p>Kész. En guete :)<br /></p>Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-26399930053881194562022-06-20T22:40:00.000+02:002022-06-20T22:40:53.546+02:00post-covid post<p>Szia, te vén blog!</p><p>Ezer éve nem írtam ide (vagy akárhova is), <a href="https://kodzaj.blog.hu/2022/06/10/poszt-pandemia_poszt">Tvik cikke</a> inspirált, hogy újra billentyűzetet ragadjak és én is megírjam, mik változtak az életemben és a munkámban az utóbbi 2-3 évben.</p><p>Örülök, hogy túl vagyunk rajta. Másfél évig nem voltam Magyarországon. Ilyen már volt velem máskor is, de magamtól ennél gyakrabban kukkantanék be kakaós csigáért és kaukázusi kefírér. Vagy esetleg egy teljesítmény túrára, átúszni a Balatont, bringázni egyet valahol. Szóval hiányzott egy kicsit Magyarország is, legalábbis ami jó belőle.<br /></p><br /><p>A járvány kitörésekor a kisfiam 3 éves volt és egy panelházban laktunk. A gyerekmegörző szinte azonnal bezárt. A cég felajánlott fizetett szabadságot az alkalmazottainak a bölcsik/ovik újranyitásáig, de én külsős vagyok, az outsourcing cég természetesen semmi segítséget nem ajánlott, ők csak a pénzt teszik el. Egy háromévessel egy légtérben a munka igazi kihívás volt. Ha a pozitív oldalára akarok koncentrálni, az is van: a srác megismerte minden munkatársamat, hogy mit csinálunk mi együt, hogyan dolgozunk. Nekem ilyen idős koromban nagyon kevés fogalmam volt a szüleim munkájáról. A hátrány: a család összekavarodott a munkával, sok bajlódás olyan feladatokkal, amik egyébként rutin, extrém multitasking, messze éjszakákba lógó munkaidő, általában hajnali 3-4 óráig, krónikus kialvatlanság. Aki ismer, az valószinűleg nem a megtörhetetlen és felhőtlen optimizmusomról, én az elején arra tippetem, hogy ez vagy évekig, vagy örökké fog tartani. Semmi kedvem nem volt így megdögleni.<br /></p><p></p><p><br /></p><p>Ezért aztán vettem egy házat. A vásárlás önmagában is elég sok meló, a bankárok is próbáltak egy kicsit lebeszélni róla, hogy ez itt nem szokás. Megrögzött keleteurópai vagyok, 2 évbe tellett mire találtam olyan házat, amire a bank is igent mond, meg nekem is elfogadható. Már a bank is azt mondta rá, hogy ez nehéz szülés volt. Minden szabadságomat rászántam a felújításra, igazán szép fizikai és szelemi kihívás volt. És még lesz is pár évig :-D<br />Btw: Ha távolról is lehet, vagy kell dolgoznunk, akkor miért kellene drága városi ingatlanokra költeni? Illetve miért nem outsourceolnak ki mindent a világon más, olcsóbb országokba?<br /></p><p><br /></p><p>A házban egy külön emelet van a munkámnak, ez elég izolációt ad nekem. Innen hallom, hogy mit csinál a kiscsákóm, kinézhetek a kertbe is, ha éppen ott van, de nem zavar, oda tudok figyelni a munkámra. Meg persze már nagyobb is, most már érti, hogy ha nappal hagy dolgozni, akkor este játszhatunk együt.<br />Azért még mindig sokat dolgozok éjszakánként, de nem legalább nem hajnalig.<br /></p><p></p><p></p><p></p><p></p><p>A hobbim nekem is megszünt. A legtöbb időm akkor volt, amikor a vonaton ültem. Mostanában elkezdtem újra bejárni, de csak hetente kétszer. </p><p>Összefoglalva: 2 nehéz év van mögöttem, sok munka van még elöttem, de most jól érzem magam. Még meg kell találnom, hogy az új környezetemben hogyan találok időt magamnak és a tanulásnak, de biztos vagyok benne, hogy el fogok jutni oda 1-2 éven belül.</p>Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-67610489367721290222020-12-29T21:55:00.004+01:002020-12-29T21:56:34.795+01:00Amikre nem számítottam<p></p><p></p><p></p><p>A következő írás talán hasznos lehet a következő szituációkban:<br /></p><p>Szituáció 1: felszolgáló vagy egy elit étteremben, személyesen az Elnökúr
jön a babájával vacsorázni. Kis pánik tür ki a management
körében amikor az elnök úr panaszkodik a terítő tisztaságára (ő ette
le), újrateríteni macerás, rövid ötletelés után úgy döntötök, hogy gyorsan kirántjátok a
terítőt a lecsóspacalpörkölt alól és ugyanazzal a mozdulattal gyorsan be is
csűritek a tisztát. <br />Én a saját szememmel láttam ilyet a tévében.<br /></p><p>Szituáció 2: heggesztőmunkás vagy egy pénzügyi cégnél. A JEE halott, a
cég kidobja a szemétbe 20 évi befektetését és áttelepül spring boot-ra. Ja... és microservices.<br />Aki dolgozott már ilyen helyen, az tudja milyen csillagászati összegek forognak kockán ha valamit elrontunk. Ahogy a BBC dokumentumfilmek unalomig ismételt konklúziója is megfogalmazza: failure is not an option.<br /></p><p><br /></p><p>Volt pár dolog, amire persze a legelején számítottam:</p><ul style="text-align: left;"><li>Minden EJB cókmóknak búcsút kell mondanunk örökre - jajjdesajnálom<br /> </li><li>A library függőségek portolása fáj.<br />A spring boot sajnos ugyanolyan mint a webklotyi meg a többi JEE kövület abból a szempontból, hogy van egy sor támogatott library amit ad, az ember használhat saját librarykat, de ha valami ütközésbe kerül a JEE szerver vagy a spring boot által adott librarykkal, akkor elég nehéz feloldani a konfliktust.<br />Ez nyilván szubjektív, de nekem úgy tűnik, a webklotyiban mégiscsak könnyebben volt lehetséges. Sebaj. Webkoltyi, becstelen halált halsz.<br /></li><li>Nehéz átállni spring fejlesztésre olyan fejlesztőkkel, akik elötte egész életükben JEE platformra fejlesztettek.<br /></li></ul><p><br /></p><p>...és amikre NEM számítottam:</p><p><br /></p><h3 style="text-align: left;">Header limit</h3><p>Látszólag a webklotyi nem alkalmazott megszorításokat a header-ek méretén, 128 KB-ig próbáltam, mindent bevett.<br />A tomcat viszont default-ból 8 KB korlátot használ. Ez is a teszt rendszeren derült ki, sok consumer minden kéréséhez a jóhiszeműség bizonyítékaként egy headerben elküldi a Biblia teljes szövegét.<br />A megoldás egyszerű: felhúztam minden spring boot appban a korlátot egy tisztességesen magas korlátra.<br />Kis magyarázat: sok szoftver, ami a szoftverünknek küld REST hívásokat nem rendelkezik állandó fejlesztőcsapattal, valamint nagyon sok is van belőlük, viszont "failure is not an option", azaz nem csinálhatok olyan változtatást, amitől hanyattesnek egyes furcsa kliensek, ezek is fontosak valakinek.<br /></p><h3 style="text-align: left;">Gzip</h3><p style="text-align: left;">Miután sikerült az agytranszplantáció és felbootolt a rendszer, minden úgy tűnt, hogy működik, bedobtuk az új alkalmazást tesztelésre és mindenkit nagyon szépen megkértem, hogy vagy futtassa a tesztjeit, vagy manuálisan teszteljen. Pont a legeslegfontosabb consumer csapat jelzett vissza, hogy időnként nem működik. Időnként... az mi?<br />Néztem a logokat és úgy tűnt, részünkről minden oké, HTTP 200, sehol egy hiba mi lehet a baj?<br />Sok "egyeztetés" (pöcsölés) után végül úgy döntöttem, legegyszerűbb, ha magam próbálom ki a consumer appot. És akkor kiderült, hogy az alkalmazás mindig is küldött egy Accept-Encoding: gzip headert, ezt a webklotyi app és container folyamatosan figyelmen kívül hagyta (korrekt).<br />A spring boot setupban viszont a zuul konfigurációban volt egy gzip opció engedélyezve, és ha kb 60 KB felett volt a válasz, akkor bekapcsolt. A consumer app viszont hiába kapta meg, hogy "Encoding: gzip" a tömörített tartalmat próbálta json deserializálni.<br />Megoldás: kikapcsoltam a gzip opciót, mivel nincs lehetőségem minden consumer appot debugolni.</p><h3 style="text-align: left;">Szemaforok, timeoutok<br /></h3><p style="text-align: left;">Az első terhelési tesztek után figyeltem fel arra, hogy egyes http kérések fentakadtak a zuul szemaforain. Megbeszéltük a kollégákkal és felhúztuk a szemaforok számát annyira, amennyi az éles rendszer terhelése alapján értelmesnek tűnt, illetve megszoroztuk kettővel a biztonság kedvéért.<br />A teszt rendszeren ezután a terhelési teszt szépen átment, semmi probléma.<br />Aztán az első éles üzem napon azonnal beütött a szemafor probléma. Felemeltem megint duplájára és igazán reméltem, hogy többet soha az életben nem látom ezt a hibát, és egy pár hétig tényleg béke volt, aztán megint beütött.<br />Egy újjabb emelés következett, most már hónapok óta nem jött a hiba.<br /></p><h3 style="text-align: left;">Oktatás</h3><p style="text-align: left;"></p><p style="text-align: left;">A teljes csapatot JEE fejlesztőből spring fejlesztővé konvertálni... mivel a tét csillagászati, a legeslegelején megkértem mindenkit, hogy kérjen időt és eszközt átképzésre. Ezek az emberek mind különböző outsourcing cégek alkalmazottai, mint ahogy én is. A cég, ahol valójában évek óta dolgozunk, minden ilyen kérést azzal hárít, hogy a képzést az alkalmazó cégeknek kell állniuk.<br />Így történt, hogy egyáltalán senki sem kapott támogatást a munkaadójától. Se idő, se training. Ezek az outsourcing cégek büdös lófaszt nem érnek.</p><p style="text-align: left;">Egyébként a fejlesztők oldaláról pozitív meglepetés volt, hogy a saját idejükből igazán sokat rászántak, pedig gyakran hallottam videóhívások közben, hogy gyerek sír mellettük.</p><h2 style="text-align: left;">Tanulságok</h2><ol style="text-align: left;"><li>Legyen teljesítmény teszted. De ne csak hogy legyen teljesítmény-teszted, hanem olyan legyen, amit a fejlesztők tarthatnak karban és használhatnak a saját környezetükön. Sőt, fusson rendszeresen, és frekventáltan is, ha kell ha nem. Gatling vagy akár a rühes JMeter.</li><li>Az jó, ha vannak integrációs tesztek a REST API-ra, de nem elég. Az sokkal fontosabb, hogy a felhasználó alkalmazásokra is legyenek integrációs tesztek.<br /></li><li>Széllel szembe pisilés:</li><ol><li>Évek óta próbálok változtatni azon a teszt-mentalításon, hogy ha egyszer működött a rendszer, akkor oké. Szerintem ha egyszer nem működött, akkor nem oké, álljunk meg és derítsük ki a hiba okát.</li><li>Még mindig nem értem miért pazarolja bárki is a pénzét outsourcingra.<br /></li></ol></ol><p style="text-align: left;"><br /></p><p style="text-align: left;"><br /></p>Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-62267669590162978042020-04-13T21:52:00.000+02:002020-04-13T21:52:14.355+02:00full stackKétféleképpen voltam full stack developer eddig...<br />
<br />
<h4>
A: Az egyetlen ember a projekten</h4>
A nyilvánvaló eset. Amikor nincs rá más ember, én is szivesen megcsinálom a felhasználói felületet. Soha nem kaptam rá szépségdíjat, de nagyobb panaszokat se. Kis-project vagy utolsó túlélő, egyre megy: egy-emberes projekteken igazán kivállóan működik a full stack developer, legalább addig amíg az az ember ugyanaz, lehet néha még utánna is.<br />
<br />
<h4>
B: Fallback opció</h4>
Voltunk úgy 100-an a projekten, sok-sok komponens, volt közöttünk linux buherátor, python hívő (mind 2-, és 4-space python) volt nyilván DBA-jellegű ember és sok sok java fejlesztő, köztük én...<br />
De mindig amikor valamelyik modul komponens csapatával együtt kellett működni, pl a python-os program fejlesztőivel, akkor rettenetes háború volt munkára bírni az embereket illetve találni bárkit is aki elvégezte volna a munka rájuk eső részét. Volt, hogy a távoli munkatársamat úgy 3 hétig próbáltam elérni emailben, IRC-en, telefonon... és már azt hittem hogy súlyos beteg vagy lepattant, amikor valaki említette hogy éppen az elöbb találkozott vele a konyhában (alig párezer kilóméterrel arrébb lévő konyhában). Oh mondom, hát él? Megpróbáltam a manageremet kérni, hogy a másik csapattól kérjen olyan embert aki tud és akar foglalkozni a kérésünkkel, de csak ez az ember volt... Heteket csúsztunk, utánna amolyan válságmeetingnek nevezhető megbeszélés következett hogy ezt hogyan tudjuk így folytatni és igazán barátságtalan, amolyan adok-kapok hangulatban fejeződött be.<br />
Ez nem csak egy eset, hanem minden eset ilyen volt.<br />
<br />
Erről persze több mint eleget beszéltünk a managerekkel, ők is képben voltak a helyzettel, elő is álltak a megoldással. Ez volt a nagy ötlet: Jó, ha a csapatok együttműködése nem egy sikertörténet, akkor rendezzük át és az új csapatok egy-egy feature-ért vagy funkcionális területért lesznek felelősek, minden komponensen / modulon keresztül ez az egy csapat felelős azért az egy feature-ért. Tehát: 100 ember egy reggel full-stack fejlesztőként ébredt fel, legalábbis a munkabeosztásuk és/vagy business title szerint.<br />
<br />
Na és ez talán értelmes ötletnek tűnik annak, aki nem próbálta még, de nekem az volt a tapasztalatom, hogy ha az emberek nem tudtak (és őszintén szólva nem is akartak) együtműködni addig, amíg mindenki a saját szakterületével foglalkozott, akkor már igazán reménytelen próbálkozás az, hogy mindenki belenyúlkál mindenbe.<br />
<br />
Minőségi változáshoz nem vezetett a transzformáció, de gyorsabb se lett a fejlesztés.<br />
<br />
<br />
<br />Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-16222915563904035812019-04-20T00:55:00.000+02:002019-04-20T00:55:02.660+02:00software serviceability checklistAz utóbbi néhány évben többnyire úgy hivatkoztak rám, hogy "on site" engineer. Ez annyit jelent, hogy legalább ugyanabban az országban lakok, ahol a felhasználók többsége. Érdekes dolgokat tanultam, de nagyon ne irígyeljetek, mert néha fájt, meg nem ritkán hétvégémbe is került. <br />
<br />
<br /><h3>
Logging</h3>
Korábban ennyire nem érdekelt, hogy mit logol a szoftver.
Miután elég sok esetben kell túrkálnom az éles rendszerek logját és
bosszús, türelmetlen emberek kérdéseire válaszolnom, kicsit kevésbé
vagyok már liberális a logolással kapcsolatban.<br />
<ol>
<li>Például ha a felhasználók / kliens alkalmazások hülyeséget csinálnak, legyen ott a logban, hogy milyen bemenő adatokat küldött a felhasználó és hogy feküdt el a feldolgozás</li>
<li>Nem rossz például minden a klienseknek adott hibához egy egyedi azonosítót (talán a legkézenfekvőbb egy UUID) rendelni, és azt a logba is megadni, így nem kell annyit keresgetni</li>
<li>Nagyon szép és kedves dolog a fejlesztőktől megkönnyíteni a logok gépi feldolgozását, pl CSV formátumban elmondani a mondandónkat</li>
<li>Azt a hülyét, aki hangosan üvölti, hogy log aggregálóra semmi szükség nincs, gyorsan kivégezni, a hullát eltüntetni.</li>
<li>Még egy technikai apróság, ilyet sokan csinálnak:<br /><span style="background-color: #cccccc;"><span style="font-family: "Courier New", Courier, monospace;">if(LOGGER.isEnabled(LogLevel.INFO)) {<br /> LOGGER.info("akármi: " + valami.getName().getFirstName())<br />}</span></span><br />Csodálatos, hogy megpróbálod elkerülni, hogy fölöslegesen összeállítson a gép egy stringet. Biztosan valaki észre fogja venni hogy mit megtakarított a cég az áramon. Most viszont a szoftvered a logolás szintjétől függően működik vagy nem. Elég bosszantó, ha hibakeresésnél megváltoztatod a log szintet és ettől bedől a rendszer.</li>
</ol>
<br />
<h3>
Health-check (alias 'ping')</h3>
Ez egy gyakori feature a legtöbb szoftverben, általában egy egyszerű text, html vagy JSON oldal, ami felsorolja<br />
<ol>
<li>a szoftver verziószámát</li>
<li>minden backend (adatbázis, rest service, EJB gányolmány, CORBA dinoszaurusz) elérhetőségét - illetve a hiba jellegét ha nem sikerült elérni.</li>
<li>vagy ha ilyesmi szükséges: helyi disk space (például a lognak) vagy a szabad memória információk</li>
</ol>
Ezt sikerült idáig mindenkinek összehoznia, de mit lehet benne elszúrni:<br />
<ol>
<li>ha a ping <b>túlságosan nehéz műveletet</b> akar végrehajtani az adatbázison - nem csak egy <span style="background-color: #cccccc;"><span style="font-family: "Courier New", Courier, monospace;">select sysdate from dual</span></span> hanem konkrétan táblák méretét lekérdezni: <span style="background-color: #cccccc;"><span style="font-family: "Courier New", Courier, monospace;">select count(*) from all_i_have_ever_done;</span></span><br />Ilyen esetben ahogy nő az adatbázis, az ember többé már nem meri használni a health-check oldalt, mert esetleg az dönti be a rendszert.</li>
<li>ha egy backend hibája miatt a ping nem képes továbbhaladni - vagy beblokkol (lásd előző pont) vagy hiba esetén a többi kapcsolatot már nem ellenőrzi. Ez félmunka.</li>
</ol>
Publikus rendszerek esetében érdemes levédeni a health-check oldalt, különben fantasztikusan hasznos információkat tud adni az illetéktelen érdeklődőknek.<br />
<br />
<h3>
Reverse Onboarding</h3>
Általában üzleti rendszereknél van egy bürokratikus procedúra, amikor egy új szoftvernek engedélyt adnak egy másik rendszer vagy infrastruktúra használatára. Ezt hívják onboarding-nak. Ilyenkor az új szoftver fejlesztőinek kell mindenfélét bemutatnia, például a tesztek eredményeit, a várható terhelést, a kapcsolattartó emailcímet, satöbbi.<br />
<br />
Van aki furcsán néz rám, amikor megfordítom a dolgot. Ugyanezeket a dolgokat kérjük szépen mi is, feljegyezzük és bármilyen probléma esetén használni fogjuk. Volt aki azt mondta erre hogy "De hát mi vagyunk a világ legnagyobb XYZ rendszere". Klassz. Akkor ezeket már biztosan sokan kérdezték :-)<br />
<br />
Ezek az infók nagyon hasznosak lesznek probléma esetén, ezt sajnos szó szerint érdemes a párna alatt tartani.<br />
<br />
<ol>
<li>Tervezett Outage esetén hol kapsz értesítést, mennyi idővel előre</li>
<li>Nem tervezett kiesés esetén hol kérhetsz segítséget - és ez ne egy személy legyen lehetőleg, mert mindig az lesz az eredmény, hogy pont egy pár hónapja lepattant az ember</li>
<li>Ha sikerül ilyesmit kicsikarni az emberekből: átlagos és maximális válaszidők, elérhetőség, satöbbi (SLA technikai részletei) </li>
</ol>
<br />
<h3>
Dashboards</h3>
Nagyon hasznos, ha van valamilyen dashboard / info radiator ahol összegyüjtheti az ember akár a health-check oldalak eredményeit, vagy a log aggregáló riportjait a hibákról, teljesítmény adatokat. Reggelente ez a legizgalmasabb oldal.<br />
<br />
<h3>
JAVA: Exception handling</h3>
Ezt sajnos gyakran kell magyaráznom a kollégáknak, de nem az a baj, ha hibát adunk vissza a felhasználónak. Néha a hiba a helyes válasz. Az a baj ha egy infrastruktúra hibát figyelmen kívül hagyunk és például null-t adunk vissza helyette.<br />
Sajnos a checked exceptions egy tragikusan rossz ötlet volt. Eggyel több ok kotlinra váltani.<br />
<br />
<br />
Ennyi pillanatnyilag. Egy profi supportos biztosan tudna hozzábökni pár dolgot, de én még mindig főleg hegesztésből élek.Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-71880571624698755612019-01-22T00:02:00.001+01:002019-01-22T00:36:48.191+01:00Kotlin null-biztonságA kotlin mellett még mindig a szuper-barátságos null-safety a legjobb érvem. Aki esetleg nem ismerné a kotlin nyelvet, Annak röviden:<br />
A kotlin <b>fordítási időben</b> ellenőrzi a változók és értékek típusát.<br />
Azaz mindent úgy kell deklarálnod (a kotlin erősen típusos nyelv) hogy lehet-e null vagy sem.<br />
<br />
Például:<br />
<br />
<span style="font-family: "courier new" , "courier" , monospace;">var neverNull : String = "bla bla bla"</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">var maybeNull : String<b>?</b> = null // hoppá alapból pont null</span><br />
<br />
Lehet próbálni a széllel szembe pisilni:<br />
<br />
<span style="font-family: "courier new" , "courier" , monospace;">var amISmarterThanTheCompiler : String = null // compiler error</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"><br /></span>
A compiler pedig kikényszeríti a null értékek tiszteletét, azaz mindig kell valami null-ellenőrzést beiktatni. Lehet old-school if(blah<span style="font-family: "courier new" , "courier" , monospace;">!</span><span style="font-family: "courier new" , "courier" , monospace;">=null</span>) a kotlin elvis-operátorával, vagy a null-safe navigációval, pl<br />
<br />
<span style="font-family: "courier new" , "courier" , monospace;">person.taxId<b>?.</b>startsWith("1234") <b>?:</b> false</span><br />
<br />
A legeslegesleg szeretetre-méltóbb dolog az, hogy ezt adatreprezentációban, a kotlin data osztályokban.<br />
<br />
<span style="font-family: "courier new" , "courier" , monospace;">data class Person (</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"> val firstName : String,</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"> val lastName: String, </span><br />
<span style="font-family: "courier new" , "courier" , monospace;"> val taxId : <b>String?</b> </span><br />
<span style="font-family: "courier new" , "courier" , monospace;">)</span><br />
<br />
<span style="font-family: inherit;">Millió órányi NullPointerException-kergetés után könnyes szemekkel hüppögve kérdezhetjük:</span><br />
<br />
<h3>
<span style="font-family: inherit;">Akkor most meg vagyunk mentve?</span></h3>
És a korrekt válasz: lófaszt. Illetve már majdnem, csak még nem.<br />
<br />
Persze azzal kezdtem, hogy <b>fordítási időben</b> ellenőrzi a null-biztonságot. Ebből következően bármi ami nem kotlinból jön, hanem java, groovy, akármi, az megsértheti ezt a szabályt és egy ideig ez ki sem derül.<br />
<br />
<br />
<h3>
1. számú gyanúsított: Serialization</h3>
A legnyilvánvalóbb tréfát serializationnel lehet elkövetni.<br />
<br />
<span style="font-family: "courier new" , "courier" , monospace;">data class Person (</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"> val firstName : String,</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"> val lastName: String, </span><br />
<span style="font-family: "courier new" , "courier" , monospace;"> <b>@Transient</b> val name = "$firstName $lastname" </span><br />
<span style="font-family: "courier new" , "courier" , monospace;">)</span><br />
<br />
Tessék kérem serializálni, deserializálni, majd<br />
<br />
<span style="font-family: "courier new" , "courier" , monospace;">person.name.startsWith("Meglepi") // bang</span><br />
<br />
<h3>
2. számú gyanúsított: Jackson </h3>
A jackson egyébként az evidens esetekben kedvesen szól, hogy nem lehet null valami...<br />
<br />
<span style="font-family: "courier new" , "courier" , monospace;">data class Person (</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"> val firstName : String,</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"> val lastName: String </span><br />
)<br />
<br />
<span style="font-family: "courier new" , "courier" , monospace;">objectMapper.readValue(""" </span><br />
<span style="font-family: "courier new" , "courier" , monospace;"> {</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"> "firstName":"Kakukk",</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"> "lastName": <b>null</b> </span><br />
<span style="font-family: "courier new" , "courier" , monospace;"> }</span><br />
<span style="font-family: "courier new" , "courier" , monospace;">""", Person::class.java)</span><br />
<br />
És itt a jackson felháborodik, amitől mindenki megnyugszik, hogy tessék, biztonságban vagyunk. Igen, majdnem...<br />
<br />
<span style="font-family: "courier new" , "courier" , monospace;">data class Person (</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"> val firstName : String,</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"> val lastName: String,</span><br />
<span style="font-family: "courier new" , "courier" , monospace;"> val titles : List<string> </string></span><br />
)<br />
<span style="font-family: "Courier New", Courier, monospace;"><br /></span>
<span style="font-family: "Courier New", Courier, monospace;"><span style="font-family: "Courier New", Courier, monospace;">val person </span><span style="font-family: "Courier New", Courier, monospace;"><span style="font-family: "Courier New", Courier, monospace;">=</span> objectMapper.readValue(""" </span></span><br />
<span style="font-family: "Courier New", Courier, monospace;"><span style="font-family: "Courier New", Courier, monospace;"> {</span></span><br />
<span style="font-family: "Courier New", Courier, monospace;"><span style="font-family: "Courier New", Courier, monospace;"> "firstName":"Eugene",</span></span><br />
<span style="font-family: "Courier New", Courier, monospace;"><span style="font-family: "Courier New", Courier, monospace;"> "lastName": "Cuckoo",</span></span><br />
<span style="font-family: "Courier New", Courier, monospace;"><span style="font-family: "Courier New", Courier, monospace;"> "titles" : ["dr",<b>null</b>,"sir"] </span></span><br />
<span style="font-family: "Courier New", Courier, monospace;"><span style="font-family: "Courier New", Courier, monospace;"> }</span></span><br />
<span style="font-family: "courier new" , "courier" , monospace;"><span style="font-family: "Courier New", Courier, monospace;">""", Person::class.java) // nahát, működött...</span></span><br />
<span style="font-family: "Courier New", Courier, monospace;">person.titles.forEach(::println) // bang</span><br />
<br />
Erre többször nyitottak bugot a jackson-kotlin modul bugtrackerében, összegyűlt tekintélyes mennyiségű szavazat. Minden alkalommal a fejlesztő pár hónap után lezárta ugyanazzal a kommenttel: wont fix. A jackson egy java komponens, nem érdekli a kotlin nullsafety.<br />
<br />
Egyébként egyre népszerűbbek az egyéb JSON libraryk, mint a moshi... meglátjuk, van időm. Inkáb egy jól ismert lókötő, mint egy civilizált idegen, nem?<br />
<h3>
3. számú gyanúsított: mindenki</h3>
De legyen elég mára ennyi a paranoiából, mert végülis csak annyit akartam mondani, hogy<br />
<ol>
<li>Semmi baj, túl lehet élni, csak <b>figyelni kell rá</b>.</li>
<li>Mindent addig kell kínozni, amig a kívánt vallomást meg nem teszi.</li>
<li>Oké elég, takarodó</li>
</ol>
Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-54363020807843433402018-09-08T11:43:00.002+02:002018-09-08T21:50:08.296+02:00ApályA nagy vállalatok szoftverfejlesztési gyakorlatában az az egyik legnagyobb kihívás, hogy nem a feladat komplexítása, hanem az üzleti priorítása határozza meg a költségkeretet. Ennek következtében még akkor is, ha egyébként a feladat egyszerű lenne, a kelleténél több szoftverfejlesztőt és egyéb munkatársat kap, mindenki hozzáteszi a saját elképzeléseit és mivel a keretet ki kell tölteni, a keletkezett megoldás hozzáadott komplexítása rendesen megnő.<br />
Idáig minden rendben is lenne, de az üzleti priorítások változnak. Amikor végre valami "kész", új dolgokat kell építeni és nem várhatja senki a cégtől, hogy örökké top listán tartsa a projektet. Itt kezdődnek a problémák, mert innentől kezdve a csapat évekig vonszolja maga után a keletkezett komplexítást. A befektetett összegért a cég produktivítást várhatna, de hát mit csináljunk ha pont az ellenkezőjére fordítottuk?<br />
<br />
<br />
Nos a leggyakoribb megoldás az, hogy a csapatot is lecserélik, ettől lesz mégrosszabb.<br />
Illetve egy okosabb cég egy idő után arra a következtetésre juthat, hogy ez nekik nem megy valami jól és ideje inkáb beszálítókkal és dobozos termékekkel kielégíteni a szükségleteiket. Sok szerencsét hozzá :-D<br />
<br />
<br />
Kevésbé okos cégek esetében: örökké ismétlődő <a href="https://iwillworkforfood.blogspot.com/2011/05/halalcsillag-design-pattern.html">Halálcsillag Design Pattern</a>.<br />
<br />
Illetve elvben létezhet olyan, hogy valaki nem megy bele ebbe az egész csapdába, csak még nem láttam ilyet. Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-67980213886389890012018-08-16T23:18:00.001+02:002018-08-16T23:18:17.358+02:00Outsourcing magyarázat - ötletSzóval van ez az outsourcing dolog: Évekig dolgozunk a vevőnél, a munkáltató céget akkor látjuk utoljára, amikor a szerződést aláírjuk, a pénz jelentős százalékát leveszik és kirúgnak ha a vevőnek nincs rád szüksége. A vevőnek nyilván így kétszer-háromszor annyiba kerülsz, mintha alkalmaznának, a te fizud meg nagyjából ugyanannyi. Magyarországon ehhez még olyan sajátosságok is jöttek, hogy konkrétan az outsourcing cég hónapokig lógott a fizuval, pedig a vevő elégedett volt és időben fizetett, de a górénak új kocsit kellett venni.<br />
Nem hangzik olyan jól, igaz?<br />
<br />
Azokban akik ezt csinálják évekig, nyilván felmerül a kérdés, hogy ennek ugyan mi értelme van, miért megy bele még így is a vevő? Gondolom nem hülyék, nem gyerekesen gonoszak, illetve a kapzsiságnak is fursa módja lenne hogy többet fizetsz ugyanannyi munkáért. Logikus magyarázat kell...<br />
<br />
Na és erre van egy friss összeeskövés elméletem, ezt szeretném megosztani veletek, tessék:<br />
<br />
<blockquote class="tr_bq">
Amikor az emberek még alkalmazottak voltak, egy csomó idő ment el arra, hogy a pozíciójukat védték a munka helyett, karriert építettek szoftver helyett, meg persze marakodtak.<br />
Most nincs se karrierünk, se pozíciónk, meg igazából le is vagyunk szarva. 3-6 hónapra vesznek fel, szóval mindenképpen elveszítjük a projektet. Egyszerűen túl drágák vagyunk ahhoz, hogy így bármelyik projekt meg akarjon tartani minket hosszabb távon. Viszont annyi különbséget tudunk tenni, hogy sikeresen vagy sikertelenül veszítjük el a projektet. Ha sikeresen veszítjük el, az ügyfél nagyon köszöni, jó eséllyel lesz másik munka. Ha sikertelenül veszítjük el, elcsesszük a határidőt vagy a vevő elhúzza a száját, akkor az valószinűleg az utolsó volt. Max 6 hónapod van, csinálj csodát!<br />Tehát hajrázunk örökké. Nincs baszakodás, nincs okoskodás, nincs állóháború, megy a meló.</blockquote>
Ennyi lenne.<br />
<br />
<br />
A hátulütő persze nyilvánvaló, az átadásnál elveszik az infók nagy része is, de hát akinek nem kell ezzel közvetlenül foglalkoznia, annak ez nem hiszem hogy álmatlan éjszakákat okozna.<br />
<br />
Azért ez szerintem jelentős különbség. Lehet, hogy megéri. Nagy cég, ufó-logika. Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-61566499987561787932018-05-27T23:29:00.001+02:002018-05-27T23:29:30.535+02:00optimalizációGyakran zárnak rövidre egy-egy vitát szoftverfejlesztésben azzal a rövid kifejezéssel, hogy "premature optimization" vagy "early optimization". A probléma az, hogy kicsit elcsépeltük ezt a kifejezést. Bármikor bárki teljesítménnyel kapcsolatos kifogást mer megfogalmazni, szinte biztos, hogy valaki a fejéhez vágja. Nem azt mondom, hogy bitek, hálózati csomagok, vagy megszakítások szintjén el kellene kezdeni kitaposni több sz-t a számítógépekből, hanem:<br />
<br />
<ol>
<li>Legyen a fejlesztőknek képe arról, hogy milyen teljesítményt vár el felhasználó / megrendelő a rendszertől<br />És persze a megrendelő legyen udvarisasan tájékoztatva arról, ha irreálisak az elvárásai</li>
<li>Legyen legalább az architektnek és a vezető fejlesztőknek elképzelése arról, hogy az az architektúra, amit megterveztek a sok kis nyomorult kockával az Enterspájz Architekt-ben, az hogyan lehet képes ezt a teljesítményt biztosítani némi biztonsági tartalékkal.</li>
<li>Legyen a rutin tesztelés része az, hogy nagy terhelés alatt is korrekt eredményeket gyártson a szoftver.</li>
</ol>
<br />
Ezeket azért írtam össze, mert olyan ritkán láttam a gyakorlatban, együt pedig még soha.<br />
<br />
A problémák, amiket én tapasztaltam:<br />
<ol>
<li>Általában fogalmunk nincs a komponenseink teljesítményigényéről. Nem tudjuk mennyi idő, amíg az adatbázis válaszol, vagy a hálózaton átverekszi magát egy IP csomag, vagy hogy egy JSON dokumentumot parsoljunk. Csak annyit tudunk, hogy marha gyors. Mire pislogtam kész volt. Mire ezret pislognék biztos az éles rendszeren is lefutna.</li>
<li>A technology hype kifejezetten nem tesz jót, az emberek hajlamosak azt hinnni, hogy a legújabb/legdrágább technológia tényleg jobban muzsikál, mérés nélkül. Ilyenkor egy faszpörgettyű, aki lefikázza a drága / awesome rendszert egy pár órás teszt alapján, kifejezetten idegesítő tud lenni.<br />Például egy régi főnököm mondta ezt a nyafogásomra: "Az Oracle végtelenül skálázható" - jó persze 2000-ben még sokan ezt hitték</li>
<li>Van egy kifejezetten kedvezőtlen légkör jól pénzelt/priorításos projektek körül, valahogy az emberek összekeverik azt, hogy a "szoftver jól teljesít" azzal, hogy "a szoftvernek nagyon jó teljesítményű hardverre van szüksége... és sokra persze".</li>
</ol>
<br />
Megoldás: a természetes szelekció elvben ki kell hogy küszöbölje a problémát még mielött a Tejút ütközik az Androméda köddel.Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-71916400646329396972017-12-14T22:47:00.000+01:002017-12-14T22:47:29.377+01:00szevasz ebook2009-ben vettem egy hanlin típusú ebook readert. Akkor elég borsos ára volt, ha jól emlékszem majdnem 80ezer forint. Sokáig bírta, igazából még most is működik, csak nem lehet már aksit kapni hozzá, folyamatosan töltőn kell tartanom. Meg a borítója lefoszlott.<br />
<br />
A halál oka 1: csere alkatrészek hiánya<br />
<br />
2012-ben vettünk egy Kindle olvasót. 2015-ben a newcastle-i repülőtér biztonsági ellenőrző röntgene kinyírta. Úgy tűnik ilyen van, ugyanakkor a fenti hanlin kibírta ugyanazt a röntgent.<br />
<br />
A halál oka 2: röntgen<br />
<br />
A megöregedett hanlin readerem lehelyettesítésére leptem meg magam egy PocketBook Aqua readerrel. Az extra benne az, hogy víz- és nyálvédett. A bosszantó benne az, hogy töcskscreen-es. Erre rájöttem, hogy egy ebook readeren ez nemcsak haszontalan, de bosszantó is. Nem volt különösebben sok alkalma arra, hogy a vízállóságát bizonyítsa, egyetlen egyszer nem ázott meg. Fogalmam sincs mi történt vele, egy átszállás elött még működött, utánna már nem.<br />
<br />
A halál oka 3: Hauptbahnhof<br />
<br />
Ennyit a hardware minőségéről, a szoftver általában sokkal bosszantóbb. Mindegyik típusnak megvan a maga betegsége, néha lefagynak.<br />
<br />
Szóval bár 2009-10 körül azt mondtam, hogy optimistán látom a technológia jövőjét: néhány év tapasztalattával már kicsit más, teljesen elment tőle a kedvem hogy akár csak még egy ilyen eszközt vegyek.<br />
<br />
Amúgy az ára nem lenne vészes, de a minősége az sajnos gáz.Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-57227752790015206542017-10-20T00:26:00.001+02:002017-10-20T00:30:21.968+02:00Informatika oktatás<a href="http://www.jtechlog.hu/2017/09/25/menjek-e-egyetemre.html">István írására</a> egy komment...<br />
<br />
<br />
Ezt csak összehasonlításként mondanám el, mert a középiskolai szintű
oktatást én sem tartom alkalmasnak arra, hogy szoftverfejlesztőket
képezzen.<br />
Középiskolába infós szakra jártam, nekünk volt valamiyen tantárgy, ahol elmondták az összes rendezési algoritmust, kereséseket, és pl a backtrack algoritmust, ami rémesen egyszerű, majdnem primitív. Kb 20 perc alatt mondta el a tanár az órán ismétlésekkel együt, utánna mindenkinek kellett egy példafeladatot megoldania a backtrackkel (válaszhatsz labirintus vagy a 8 királynő közül), utánna mindenkinek ment, egymásnak is el tudtuk magyarázni, semmi nehézség.<br />
<br />
Évekre meg is feledkeztem az egészről, egész addig amig be nem íratkoztam ELTE progmat esti tagozatára. Progmaton pedig Fóti tanárúr szánt rá az "Bevezetés a programozáshun" elméleti előadásokból egy egész estényit, az egész fejezetnek ez volt a címe, hogy "Backtrack". Absztrakt számrendszerekkel kezdte, aztám a korábban megismert állapotterekre fordította le a témát, majd végül felírta a backtrack csodálatos matematikai definícióját, alig 2 óra alatt. Eközben mindenki szorgosan jegyzetelt, de ráncolt homlokok és a ködös tekintetek mögött látszott, hogy az emberek egyetlen kérdése a témával kapcsolatban egy általános "WTF". Az előadás után néhány embert megkérdeztem, hogy hol vetnék be a backtrack algoritmust. A reakció volt érdekes, mert a legtöbb embernek nem esett le, hogy itt most valami olyat hallottunk, amit bármire is be lehetne vetni, páran mondták csak azt, hogy "hú, azt még nem tudom".<br />
<br />
Ha ismered egyébként a "Bevezetés a programozáshól" 1-6 tárgyat, akkor ezen talán nem lepődsz meg. Sok vita tárgya, de azt hiszem a legtöbben egyetértenek abban, hogy a hétköznapi szoftverfejlesztés gyakorlatától távolabb áll, mint a művészettörténelem.<br />
<br />
Végeztem még egy pár kisérletet, és egyébként informatikában és algoritmuselméletben nem jártas embereknek (például édesanyámnak) elmagyaráztam az algoritmust, nyilván nem írattam velük ZH-t vagy gyakorló programot, de megkérdeztem, hogy pl milyen feladatra lehetne ezt a módszert bevetni. A magyarázat kb 2 percet vett igénybe, és működött.<br />
<br />
Tehát nem kalapácsot adnak a kezünkbe, hanem megtanítanak gondolkozni... Igen, látom hogy kalapács nincs, de gondokodni megtanultunk vajon? Vagy komplkálni tanultunk meg? Vagy az ugyanaz? Vagy csak hisszük, hogy ugyanaz? Vagy most mi van?<br />
<br />
A gyakorlati téren, már amennyire van gyakorlati oldala az ELTE progmatnak, sokkal kiábrándítóbb tapasztalataim voltak. Például egy C++ zárthelyin a leadáskor kellett megpróbálnom elmagyarázni a tanárnak, hogy mi a unit teszt (a kérdésére, hogy mit lát a képernyőn). Feladta és elmenekült, de itt nem volt vége, a következő tanárnak azt kellett elmagyaráznom, mi a standard input stream. Ezt követően egyetértésben nullásra értékelték a ZH-mat, pedig addig nem mutattam jelét annak, hogy szivesen feldarabolnám a két barmot.<br />
<br />
Nem ott és azonnal, de <a href="https://iwillworkforfood.blogspot.ch/2017/01/it-szegregacio.html">hasonló esetek</a> sora lassan leamortizálta a türelmemet. Munkám nyilván volt már, egyébként nem tudtam volna kipengetni a tandíjat. A pénzt nem sajnálom, de az időmet nagyon.<br />
<br />
De egyetértek Istvánnal: ha van rá pénzed, menjél egyetemre. Tanuld meg, felejtsd el! Ez egy jó gyakorlat. Mi mást csinálnál 18-19 évesen? :-)<br />
Hajrá!Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-43313019952400636332017-10-09T23:39:00.003+02:002017-10-09T23:39:54.273+02:00checklist project indításhozPár dolgot összeírtam, amit az ember bán az egész projekt során hogy nem lett meg a legelején. Nem vagyok én se híve a sok pöcsölésnek, de ismeritek azt a mondást, hogy...<br />
<br />
<blockquote class="tr_bq">
Néhány hét kemény munkával több órányi tervezést meg lehet takarítani.</blockquote>
<br />
Hát szóval...<br />
<br />
<h3>
Első helyezet: Adatbázis schema verziózás</h3>
Kár vitatkozni hogy, old school liquibase vagy az újabb flywaydb, a saját buherált script is csak ritkán rosszabb a semminél :)<br />
Ezen már évek óta sokat bosszankodok, hogy hogyan lehet ilyet bénázni, de sok megörökölt projektemen egyszerűen totál másmilyen volt a teszt schema a prod schemához képest és az embereknek olyan ködös elképzeléseik voltak hogy "A DBA nem tudja másolni a teszt schemát amikor upgradelünk?"<br />
<br />
<h3>
Erős második: forráskód formázó beállítások</h3>
Csodálatos módon az eclipse és az intellij értik egymás kódformázó beállításait. Pontosabban az intellij érti az eclipse-t, az eclipse meg jobbára érti önmagát.<br />
Annyi tennivaló marad, hogy azokat az igazhitű junixereket, akik vimmel meg emacs-szel akarnak szoftvert fejleszteni, szóval őket egy tompa nehéz tárgyal jobb belátásra téríteni.<br />
Aztán még a space-nácik és az alternatív tab-pártiak összecsapását is gyorsan helyre kell tenni, de ehhez a tompa nehéz tárgy helyett inkább valami gyorsan használhatót ajánlanék, pl lángszóró.<br />
<br /><h3>
Bronzérem: CI enforce tests</h3>
Amikor már fél éve törött egy teszt és senkit nem érdekelt, így ment élesbe akkor már igazán késő sajnálkozni.<br />
Persze mostanában dolgoztam olyan kollágával is, aki eltörte a tesztet és írt egy levelet, hogy "a junit teszt nem működik, javítsd már meg" Ezek ilyen kultúrális kompatibilitási problémák.<br />
<br />
<h3>
Negyedik: DEV produktívítás</h3>
Szerintem érdemes valami egyezségre jutni, vagy megpróbálni egyezségre jutni, hogy milyen eszközöket használunk és azokkal mekkora overhead-et kap az egész fejlesztés. Amikor egy tool már bent van, akkor már késő, az többnyire ott marad.<br />
Pl hogy beéred-e egy gyors jetty-vel a fejlesztőkörnyezetben vagy muszáj legyen megvárni, hogy a websphere felemelje a seggét, esetleg elég ha a tesz környezet websphere...<br />
Hogyan bánjunk a ránk kényszerített közös MQ-val, közös adatbázissal.<br />
<br />
Ezeknél szokott elcsesződni a produktívítás, amikor hosszú perceket várhatsz egy buildre. Vagy pl sokan másolgatnak fileokat a dev folder és a webszerver között. Ez nekem már 2000-ben is a rühes 90-es évek maradványának tűnt.<br />
<br />
<h3>
5: contact list</h3>
Egy egész sor projecten dolgoztam úgy, hogy vakon mentünk. Fogalmunk sem volt, hogy ki a felhasználó, ki a DBA, ki fogja a support feladatokat ellátni, és nyilván hogy ők hogyan szeretnének velünk együt dolgozni. Egy ilyennel garantált a későbbi probléma.<br />
<br />
Biztos van még sok, csak most nem jut eszembe, legyen akkor csak ennyi most.Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-85494878677810182022017-04-22T23:48:00.000+02:002017-04-22T23:48:21.738+02:00ki profitált a kerub-ból idáig...Mivel intenzíven használok pár szoftvert, bugreportok és patchek formájában néhány project már profitált abból, hogy a vonaton munkába menet nem csak a tájat nézem. Pár közűlük, amikre emlékszem:<br />
<ul>
<li>Jetty és CXF bugreportok, ezek a csákók igazán rendesek voltak és pár nap alatt kijavította mindkét csapat a hibákat. </li>
<li>Shiro bugfix</li>
<li>Kotlin - többnyire apróságok a stdlib-ben, egyszer egy apróság a compilerben, párszor az IDE-ben.</li>
<li>Infinispan bugreportok - bár utóbb rájöttem hogy nem érdemes sietni az infinispan upgradekkel mert a release után úgyis találnak pár hibát és kiadnak rá egy javítást. Egy kis türelem sok időt megtakarít.</li>
</ul>
<br />
Már csak azért is meg akartam ezeket a projekteket említeni pozitív példaként, mert negatív példa is akad bőven az OSS projectek között.Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-64322002433131505632017-04-10T23:31:00.002+02:002017-04-10T23:31:53.586+02:00Sky job interviewEgyszer, amikor a brexit még a posztapokalpitikus sci-fi horrorpornókomédia kategóriába tartozott, voltam a Sky tévétársaságnál állásinterjún. Az jutott most eszembe, hogy ettől esetleg megmentselek titeket :-D<br />
Elég nagyipari mennyiségben hívták be az embereket, délre kellett odaérni és a portán nyolcan ültünk az időpontban, azt hiszem 2 nő, voltak környékbeliek és távolabbról érkezők, fehérek és feketék, idősebbek fiatalabbak, ufók és alienek. Szerencsére azért jó arcok voltak és szendvicseket lehetett választani. Az elején gyorsan elmagyarázta a HR-es arc a szabályokat, aki nem teljesít úgy, ahogy elvárnák, annak szólnak és mehet. Ez kellemetlenül hangzik, de végülis jobb egy délutánt várostnézni Londonban, mint még pár órát kuksolni egy cég irodájában. Egyébként elég hosszú procedúra volt. Ilyen körök voltak, hogy:<br />
<ul>
<li>pair programming egy önkéntes alkalmazottal</li>
<li>valami kis problémamegoldás</li>
<li>architektura design egy pár fazonnal whiteboard-nál </li>
</ul>
és így tovább, mindenesetre este 6-ra ketten maradtunk, mindenki másnak mondták hogy kezitcsókolom, ekkor véget ért a program és a túlélőket körbekisérték a studióban. Ez jó volt legalább, mert tv-studióban még soha nem jártam. Kicsit lepukkantnak tűnt, de oda se neki, láttam már rosszabbat.<br />
Elbúcsúztam és igyekeztem elkapni az utolsó repülőgépet hazafelé, akkor úgy tünt, minden oké. De aztán soha nem hívtak. Pár héttel később írtam a HR-es csókának, hogy gondolom hogy "nem" a válasz, csak érdekelne hogy miért.<br />
Azt válaszolta, hogy mert nincs tapasztalatom a pair programmingban. Ez egyébként tényleg így is van, sehol nincs ilyesmi a CV-ben, de ez a válasz volt az, ami nogo listára tette nálam a sky-t, mert ezt így értettem:<br />
<br />
<blockquote class="tr_bq">
<i>Kedves Izé,</i> <i><br /><br />Miután eljöttél az interview-ra, végre elolvastam a CV-d és akkor jövök rá: baszod te egyáltalán nem is vagy édzsájl! Valamiért azt hittem hogy na mindegy...</i></blockquote>
<blockquote class="tr_bq">
<i>Dögölj meg,</i><br />
<i>HR</i></blockquote>
<br />
Szóval azért, hogy a HR-es végül elolvassa a CV-t az interview után, azért szerintem kár kidobni a pénzt repülőjegyre.<br />
<br />
Az átlagos ember a maga hibáiból tanul, ezt remélem kipipálhatom, ti meg próbáljatok jobbat :)Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-24986008620643740132017-03-06T20:59:00.002+01:002017-03-06T20:59:21.983+01:00kerub - a packaging frontról jelentjükKerub. Kicsit megint hanyagoltam a blogolást, de a munkára igyekeztem időt szorítani. A nagyobb dolgok amikbe belerúgtam mostanában:<br />
<ol>
<li>yum/dnf repok CentOS 7-hez és Fedora 23-hoz. yum (vagy dnf) install után a kerub elindul és megy ugyanúgy, mint a fejlesztőkörnyezetben. A házi jenkins buildjei fel is küldik minden változtatás után a friss RPM-eket.<br />Készül az Ubuntu és a Debian csomagoló is.<br /><br />A csomagokról annyit el kell mondanom, hogy bár amennyire tudom, korrekt módon csomagolok (nem kell kikapcsolni a selinuxot, lecsapni a firewallt, stb), a disztrók csomagolási útmutatóját egyszerűen betarthatatlannak találom és figyelmen kívül hagyom. Konkrétan az, hogy az infinispant és a jgroups-ot is rpm csomagokból oldjam fel a WEB-INF/lib helyett, az esélytelen.<br />Ezt alighanem más is így találta, mert a disztrók összesen 0 db java webalkalmazást tartalmaznak. A kerub se lesz benne soha.<br /><br />A csomagolás egyébként olyan, mintha az apolló űrhajót mamutbőrbe <br /></li>
<li>Egy teljesen új projectet kezdtem integrációs tesztekhez. Bár egész sok integrációs teszt található a fő projektben, ami simán a maven embedded jetty-jével elszalad, ezek nem képesek olyan eseteket lefedni, mint pl cluster, de akár még olyat sem, hogy virtuális gépben futó "host", mert futniuk kell jenkinsben, a linuxos desktopomon, travis-ban, meg a halál répáján.<br />Az új projekt ilyen integrációs teszteket tartalmaz, csinál egy virtuális gépet, feltelepíti a kerub webappot, tesz elé load balancert, ad hozzá hostokat, feltölt egy virtuális merevlemez imaget, elindít egy virtuális gépet, satöbbi.<br />Nyilván ez úgy magában is elég lassú lesz, úgyhogy karrier szempontokat szem elött tartva úgy gondoltam ez most had legyen groovy-ban. Grooovy!!!<br /></li>
<li>Már majdnem ott tartok, hogy a web**cket biztonsági teszteket befejezzem. Hozzá kell tennem persze hogy nem csak a tesztekről van szó hanem konkrétan az implementációról is :-D</li>
</ol>
<br />
Na jó, ennyi bőven sok, dolgozzunk!Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-61228232370677646502017-01-10T20:39:00.001+01:002017-01-10T20:39:44.886+01:00IT szegregációKözépiskolában kb 20 fős osztályban volt 5 lány, ez talán még ma sem számítana egy döbbenetesen rossz aránynak egy informatikai középiskolában. Az 5 lányból 4 alkotta az osztályelsők csoportját, ők mindenből jók voltak. Ennek ellenére az utolsó év végén a szak egyik vezető tanára az értékelésben elmondta, hogy bár ez nagyon szép eredmény, ez egy "férfi szakma".<br />
Ezt lehet úgy is nézni, hogy persze ez is egy vélemény, de ezek tizenéves lányok voltak és szerintem komolyan szivükre vették. Csak ültünk és kussoltunk, ahogy szoktuk, senki nem kérdezte hogy mire gondol, kell-e 50 kilós szervereket felcipelni a tizedikre gyalog, vagy tettlegességig elmenni a singleton pattern feletti vitában.<br />
<br />
A másik iskolai élményem a témában az ELTE-ről Lakatos László tanárúr munkássága, aki matematika gyakorlatot tartott akkoriban. Ő egy ijesztően furcsa alak, az elejétől a végéig görcsösen vigyorgott órákon, szúrós megjegyzéseket tett a hallgatókra általában de a lányokra határozottan rászállt. Ribancnak és suttyónak nézett mindenkit és nem tartotta vissza a véleményét, én valamennyire megszoktam azokat, akik nincsenek magas véleménnyel rólam, de a lányok máshogy viszonyultak ehhez. Egész kemény csajok jártak az esti szakra, de az első félév második felére már egyetlen lány se járt be az óráira, kénytelen volt minket szórakoztatni olyan kérdésekkel, mint hogy biztosan százezreket fogunk keresni (höhh...), milyen fasza autónk lesz, mert a suttyókat mivel lehetne ugratni.<br />
Nálam már messze túl lenne a határon az amit ő csinált, de az ELTE-nek ez a 2000-es évek elején még teljesen oké volt, meg ahogy nézem a kar dolgozóinak névsorát még most is az.<br />
<br />
Azt hiszem ennyi elég is lenne ahhoz, hogy ne csodálkozzunk a helyzeten.<br />
<br />
Munkahelyen nagyon ritkán dolgozok együtt szoftverfejlesztő nőkkel. Legutóbb az előző munkahelyemen ült mellettem egy lány néhány hónapig. Ő szándékán kívül a külsejével nagy figyelmet vont magára. Illetve hagyjuk ezt az érthetetlen hiper-korrektséget, egyszerűen nagy mellei voltak, ez egyszerűen matematikai tény. Érdekes volt, hogy mennyi hülyét vonzott oda. Persze voltak normálisan barátai is, de jöttek rá a hülyék, és bár egyébként barátságos nő volt, időnként határozottan el kellett küldenie valakit a halál farkára. Úgy tűnik, ez a képesség nőknek alapfeltétel a túléléshez a szakmában.<br />
<br />
Szóval annyira nem lehet frankó nőként ezt a szakmát hajtani, de lehet másikat se könnyebb.<br />
<br />
<br />
Ötletek a korrekcióra...<br />
<br />
Szerintem nem csak a nők kedvéért, hanem a magunkért is, visszább kellene venni a munka kocsmai verekedés jellegéből. Nekem sincs hozzá semmi kedvem.<br />
<br />
Talán már iskolákban tisztázni kellene, hogy a munkahelyi csajozás nem annyira pöpec ötlet. <br />
<br />
Az, hogy külön közösségeket és cégeket hozzanak létre nőknek, az nekem teljesen abszurd.<br />
<br />Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-69564853224456967372017-01-01T23:53:00.000+01:002017-01-01T23:53:05.045+01:00lights out<div class="separator" style="clear: both; text-align: center;">
<a href="https://upload.wikimedia.org/wikipedia/commons/c/c7/Hochspannungsmast-chtaube050207.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="149" src="https://upload.wikimedia.org/wikipedia/commons/c/c7/Hochspannungsmast-chtaube050207.jpg" width="200" /></a></div>
Lights Out Management. Ezt túrom mostanában amikor van kis időm, érdekes téma egy régi, de nem elfelejtett <a href="http://iwillworkforfood.blogspot.com/2012/12/elszallt-otletek-powersave-license.html">ötletemmel</a> kapcsolatban.<br />
<br />
<h4>
A desktop-gagyi</h4>
A legtöbb PC, még a nyomi kis NUC is tartalmaz egy Wake ON Lan nevű feature-t. Ez elég egyszerű, egy UDP broadcastot kell küldeni a hálózatra, legyen benne egy speciális header és utánna 6-szor megismételve Csipkerózsika MAC address-e. Lássanak csodát, Csipkerozmária felébred és bootolni kezd... ha engedélyezve van ez a BIOS-ában persze.<br />
A nyilvánvaló hátrányok:<br />
<ul>
<li>akárki megcsinálhatja, semmilyen azonosítás nem kell hozzá</li>
<li>csak a helyi hálózaton működik mert a router valószinűleg eldobja</li>
<li>semmilyen választ nem kapsz róla</li>
<li>megbízhatatlan, pl ha kihúzod a dugót és visszadugod, lehet hogy nem kapcsol be újra egészen egy teljes indításig</li>
</ul>
Célszerű kikapcsolni :)<br />
<h4>
A gáz...</h4>
Szervereknél elterjedt szabvány az <a href="http://www.intel.com/content/www/us/en/servers/ipmi/ipmi-home.html">IPMI</a>. Ez majdnem minden szerverben megvan - illetve a OpenCompute minimalista cuccokban alighanem nincs, de olyan senkinek sincs.<br />
Az IPMI nem csak arra jó, hogy ki-be kapcsolgasd a szervert, tudsz vele:<br />
<ul>
<li>konzolhoz csatlakozni</li>
<li>sensor információkat olvasni</li>
<li>akár boot médiumot is feltölteni - például erről már szivesen lemondanék</li>
</ul>
A problémák pedig:<br />
<ul>
<li>UDP - vajon miért?</li>
<li>Sajnos nem biztonságos, és a világon mindent meg lehet vele csinálni (lásd fent)</li>
<li>A legtöbb vendor egy kis java applettel teszi hozzáférhetővé - ne tessék... java applet 2017-ben!!! </li>
</ul>
Előnye: könnyen beszerezhető a használtas boltokból, fillérekért.<br />
<h4>
A trendi</h4>
Az IPMI trónfosztására készül egy <a href="http://redfish.dmtf.org/">RedFish</a> nevű specifikáció. Ez egy REST, http + JSON alapú dolog, amihez egyszerű akármilyen klienst fabrikálni. Elég érdekes, például lehet vele blade szervereket is buherálni, egyetlen management felület ad hozzáférést az összes blade-hez. A hátrányait még senki sem ismeri, annyira új, de nyilván emiatt csak újonnan lehet beszerezni, tesztelésre és fejlesztésre ez kicsit talán drága nekem. Az az ötlet, hogy egy szoftveres megoldással helyettesítem, egy vagy több VM-et indítana el libvirt-en keresztül, de végül úgyis igazi hardverrel kellene tesztelni. Sebaj, majdcsak megszán valaki...<br />
<h4>
Helyzet</h4>
Szóval a következő években érkező új szerver típusok többnyire
redfish-sel érkeznek majd, de ott lesz rajtuk az IPMI is, mert azt
mindenki ismeri és támogatja. Gyanús, hogy nem lehet választani, hogy csak redfish legyen vagy IPMI. Van az alaplapon egy jumper, azzal lehet kikapcsolni a teljes BMC-t, akkor nem lesz egyik se.<br />
<br />
Az oVirt-ben például ez úgy történik, hogy a management szerver egy host-ot kér meg, hogy az ébressze fel a másik hostot. Nyilván legalább egy hostot mindig ébren kell tartani, de nem ez a kifogásom ellene. Nem tetszik az at ötlet, hogy a hostok számára elérhetővé teszik a management interface-t, túl nagy felületet ad a támadásra. <br />
<br />
A kerub-ban inkáb a kontrollert akarom használni erre a célra, ehhez viszont írnom kell egy minimalista IPMI klienst, valamint a fenti redfish dev env szintén nagyon jó lenne... Jó sok meló lesz, lássunk hát hozzá :)<br /> Boldog buékot.Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-19490985585363126572016-12-24T22:56:00.000+01:002016-12-24T22:56:43.725+01:00planner - scheduler kerub módraEbben az iparban olyan factory-k vannak, amiknek nincs kéményük, managerek, akik nem járnak meetingre és engine-k, amik nem vontatnak semmit. Nyilván kicsit lököttek is vagyunk. Ebbe fog most az alábbi is passzolni egy kicsit, elég absztrakt lesz és annyi időt szánok rá a magyarázatra, amíg a managerem fel nem ébred.<br />
<br />
Az előző bejegyzésekben már említettem a 2000es évek IaaS architektúrájának egy tipikus elemét, a schedulert. <br />
A különbség az oVirt, a Cloudstack és más IaaS platformok schedulere és a kerub plannere között az, hogy míg a schedulereket akkor hívja meg a rendszer, amikor be kell ütemezni egy új virtuális gépet, a planner minden eseményt megkap. Minden eseménynél értékeli, hogy az új helyzet minden expectationt (azaz SLA contract) kielégít-e. Például a virtuális gép, aminek futnia kell, az tényleg fut, és olyan környezetben és hardweren amit kért a felhasználó.<br />
<br />
Minden event az tényleg minden eventet jelent, amikor a szerver jelenti az éppen aktuális terheltségét az egy event, amikor a VM módosult, az szintén egy event.<br />
<br />
Amikor az expectation nem teljesül, akkor a planner lépéseket gyárt le lépés-factory-k segítségével. A factory egyetlen dolgot kap: a jelenlegi helyzetet, ami magába foglalja a VM-ek, virtuális merevlemezek satöbbi, valamint a fizikai eszközök statikus (nem változó), dinamikus (állapot) és konfigurációs adatait. Ez alapján egyetlen dolgot csinálnak: listát a <b>lehetséges</b> lépésekből. A factory-k teljes mértékben tesznek arra, hogy van-e valami értelme a műveletnek, csak legyártják a lépéseket és kész.<br />
<br />
Minden legenerált lépés az aktuális állapotot transzformálja egy másik állapotra. A progmatos állapottér-model elkötelezett hívei azonnal vegyék le a kezüket a farkukról, fúj gusztustalan! Szóval például egy bizonyos fajta lépés az egyik hostról átpakolja a másik hostra az egyik VM-et (nevezzük migrációnak), egy másik egy hostot kapcsol ki, (nevezhetjük power managementnek, de bug is lehet)<br />
<br />
A lépéseknek persze van költsége, különböző költségtípusok, például idő, számítási és IO igény, vagy akár a kockázat, hogy valami gixer üt be, az is egyfajta költség.<br />
<br />Ezen kívül a lépéseknek vannak erőforrás igényei is, például egy host osztott vagy kizárólagos használata, tárhely vagy számítási kapacítás, illetve a virtuális erőforrások, amit használnak. Ez a feladatok koordinálásához kell, pl hogy ne tervezzen keresztbe már folyamatban lévő ügyek végrehajtásával, ne kapcsoljuk ki azt a hostot amit egy másik terv éppen bekapcsolt valamilyen célból, ilyesmi.<br />
<br />
Nyilván minden lépéshez kell egy végrehajtó kód is, mert a lépés önmagában olyan absztrakt hogy fingja nincs melyik lábbal induljon el, csak az állapotteret transzformálja. A végrehajtónak viszont van kapcsolata a konkrét anyagi világgal, ez többnyire egy ssh kapcsolat egy vagy több kiszolgálóhoz.<br />
<br />
hmm mi hiányzik még... ja persze, hogy ez mitől kezdene működni... Az már egyszerű, csak egy kereső algoritmus. Egy depth-first backtrack-et csináltam rá, ezt nevezhetjük átmeneti megoldásnak, mert valószinűleg más keresés gyorsabb lenne, de ez is tűrhetően párhuzamosítható.<br />
<br />
Ennek az eredménye az, hogy a kerub <b>keres</b> egy módot arra, hogy a kéréseknek megfelelően futtassa a virtuális gépeket, merevlemezeket, hálózatot, satöbbi. A többi IaaS megnézi, hogy van-e passzoló host és ha nincs akkor pl nem indul a vm, csókolom.<br />
<br />
Az biztosan gyanús már az elejétől, hogy a planner elég rendesen busy-box, mert minnél több a VM és a host, annál több event érkezik és annál több expectation-t kell ellenőrizni. Másrészt az egyre több factory egyre több lépést generál az egyre több VM-re. Ezek sajnos problémák, bár van rá ötletem, a keresési probléma egyébként is exponenciálisan növekedik. Jelenleg egy pár szűkítés van érvényben a factory-kra a kielégítetlen elvárások típusa alapján, de sokat az érne, ha nem kellene minden elvárást mindig kiértékelni, ha a factory-k listája lazy módon értékelődne ki.<br />
Meglátjuk meddig jutok el vele, de a cél egyébként nem matematikai értelemben vett optimális állapot hanem csak egy egész jó :)<br />
<br />Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-26363345048286460512016-12-04T13:04:00.001+01:002016-12-04T13:04:41.292+01:00final code-review-reviewVannak érvek a codereview mellett és ellene is. Kellett hozzá néhány év türelem, had gyűljenek az élmények. Ragyogó elméletek kontra szőrös valóság. Legyenek akkor elöbb a pro, mert az egyszerűbb, és sajnos sokkal rövidebb is.<br />
<br />
<h4>
Pro - ami működött</h4>
<br />
Egyik régi munkaadómnál a külső beszállítók gyakorlatilag review nélkül, és a management nyomására nem elég ritkán tesztelés nélkül is élesbe állították a rendszereiket. Mindenki boldog volt, amíg el nem szállt. És akkor jött a körkérdés: "Ért itt valaki groovy-hoz?" mire a legtöbben: "Mihez?"<br />
Élesben fut egy rendszer, azt se tudtuk hogy mit csinál és ki használja, de elhasalt és fel kell támasztani.<br />
<br />
Ugyanitt önként és meghívásos alapon elkezdtünk egymás között egy code-review szerűséget. Tea vagy narancslé, két szék, egy képernyő, együtt átnéztük a szoftver egy részét. Az ötlet az volt, hogy a review-er egyúttal backup ember is lehet, ha az eredeti fejlesztő nem elérhető, mert mondjuk elütötte egy autó. Például ez meg is történt velem.<br />
A review során a review-erek inkáb csak ötleteket adtak, nem kötelező jellegű utasításokat. Jópár nagyon jó és hasznos ötletet kaptam és ezeket a review-ket úgy tünt mindkét oldalon pozitívan értékeltük. Mindkét fél ott ült, mindenki csak erre figyelt, elég gyorsan ment. A pár-hetente pár óra aligha lassította a fejlesztést, ugyanakkor viszont arra nem volt jó hogy konkrét hibát találjon.<br />
<br />
<h4>
Kontra</h4>
<br />
A szorosabb review process ötlete főleg, de nem kizárólag az open source projektek jellemzője. Mondjuk egy open source projekten tényleg át kell nézni az akárkiktől érkező patcheket, de ezzel sok probléma akadt:<br />
<br />
<br />
Elösször is léteznie kellene egy alap kritérium listának, ami alapján elindul az ember, amolyan checklist. Ilyesmiket, mint kódformázással kapcsolatos szabályok. Ilyen többnyire nincs és helyette olyanokat szoktak mondani, mint "common sense", "well known traditions". Ez nem működik, ami az egyik kultúrában értelmes, az a másikban nem. Pl ami a spring-ben normális, az Java EE-ben nem az.<br />
A helyzetet súlyosbítja, ha több reviewer is lehet, ugyanis többnyire ők sem értenek egymással, ami átmegy az egyiken fennakad a másiknál és fordítva.<br />
<br />
Aztán a másik dolog ami a code review igéretei közűl megmaradt igéretnek az a párbeszéd. Egy webappon keresztül akarunk beszélgetni? Ne tessék viccelni, már a shared desktop + skype is elég szűkös néha, mert nincs hova rajzolni, lag-el a vonal, nem értjük elég jól egymást, esetleg a nálam már hajnalodik, a másik fél viszont még nem ebédelt.<br />
Itt egy kicsit a kultúrális különbségek bejátszottak. Például sok izraelli munkatársam még mindig aktív katonai szolgáltaban állt, ők a command chain-hez voltak hozzászokva, az ő napi megszokásuk az volt, hogy a besztottak végrehajtják a parancsot. Abból lesz ám fasza dolog :)<br />
Más kultúrákban is van így, például sok indiai is ha egyszer mondott valamit, akkor nagyon nehezen, vagy egyáltalán sehogy se tud kihátrálni. Persze ismerek kivételeket köztük is, de ez a rugalmatlanság amerikaiaknál és európaiaknál ritkábban fordul elő.<br />
<br />
Harmadik beteljesítetlen igéret a kevesebb bug a kódban. A probléma talán onnan jön, hogy egy webappon keresztül nézegetik a reviewerek a kódot. Az hogy letöltsék és ki is próbálják, az opcionális, és mivel sok időt vesz igénybe, úgy látom többnyire nem is történik meg. Ezt a legtöbben be is vallották és azt mondták, a patch fejlesztőjének a felelőssége a tesztelés. Ebben nem értek egyet, teszt nélkül szerintem a review teljesen irreleváns.<br />
Egy esetben pl 5 hónapig pöckölgettünk egymásnak patcheket, a végén a management nyomására lett vége a sztorinak. Bár egy délután alatt bőven le lehetett volna tesztelni a kódot, sajnos ez alatt az idő alatt én voltam az egyetlen aki kipróbálta.<br />
<br />
A negyedik elmaradt igéret a tisztább kód. Bár a code review elvileg kivállóan betartatná a konvenciókat, a valóságban gyakran ez sem így történt. A már meglévő kód takarítása gyakorlatilag megvalósíthatatlanná vállt. Nem maradt rá idő. Amikor mégis beküldessz egy kis patchet, akkor a review gudelines hiánya miatti félreértések következnek: vedd még mást is hozzá illetve már így is túl sok, várj még a patch-csel illetve elavult és légyszi rebaseld.<br />
<br />
<br />Az ötödik probléma a review-val a határidő. Sajnos a reviewerek a gyakorlatban teljesen leszarták a határidőket. Ez már management hiba, de meg is tehették, mert rajtuk senki sem kérte számon. Gyakran hetekig vagy akár hónapokig is eltartott egy review, közben nem történik semmi. Ez két további problémát vet fel:<br />
<ul>
<li>Nagyon gyakori task-switching. Ebben a gépek a nyerők, az embernek sok időbe tellik és a párhuzamos taszkok számával exponenciálisan nő a valószinűsége annak, hogy elcseszi. Csinálj egy dolgot, csináld addig, kész nem lesz!</li>
<li>Ha nem tudok igéretet kapni a reviewerektől a határidőkre, akkor hogyan tudnék én igéretet adni határidőkre? Ez a legsúlyosabb probléma a code review-vel a hétköznapi életben.</li>
</ul>
<br />
<h4>
Szóval...</h4>
A code review mögötti ötlet érthető, csak a gyakorlati megvalósítása elött van egy pár akadály, amit a projekt vezetők gyakran figyelmen kívül hagynak. Nem tartom elképzelhetetlennek azt, hogy működjön, csak valószinűtlennek. Túl könnyű szarba lépni, mint egy gyanútlan túristának a nyóckerben.<br />
Mindenesetre a tavalyi év végére eldöntöttem, hogy olyan munkát akarok, ahol ezt veszélyt kiküszöböltük. Az elműlt egy évben ilyen helyen dolgoztam. Nyugodt volt a hangulat, bár pár alkalommal rendesen bele kellett húzni, végül mégis kényelmesen elértük a határidőket, az ügyfél boldog és nagyon jó fej velünk. Nekem ez bevállt és megtartom ezt az irányelvet: amíg találok olyan munkát ahol nincs potenciális probléma, addig olyat vállalok!<br />
<br />
Code Review: Good Bye!Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.comtag:blogger.com,1999:blog-3739219755752255838.post-54750635838847537792016-11-13T18:13:00.001+01:002016-11-13T18:13:16.529+01:00No kerub-agentA legtöbb IaaS egy agent nevű szoftverre épít, ami minden host-on fut. Ez egyrészt egy olyan szoftver, ami a kommunikációt bonyolítja a controller és a host között, másrészt egy absztrakciós réteg is.<br />Az ovirt-ben ez egy VDSM nevű python script, ami XML-eket kap a kontrollertől és azt lefordítja másféle XML-be, konkrétan a libvirt XML formátumába, másrészt pedig néha operációs rendszer parancsokra, szóval kicsit többet csinál mint egy XSLT processzor :)<br />A cloudstack-nek egy java agentje van. Elsőre kicsit soknak tünhet akár fél gigát is beáldozni a host memóriájából egy ilyen, viszonylag erőforrásigényes processznek, de tipikusan a cloudstack felhasználók TB-ben mérik a host memóriát és fél giga nem kategória. A java-t inkáb azért nem tartom szuperfrankó választásnak agenthez, mert brutálisan béna az operációs rendszerekkel az integrációja, például a processz kezelés, meg persze mindenkinek vannak ellenérzései a JNI-vel szemben. JNI pedig van, persze hogy van...<br />Viszont itt nyilván előny, hogy a java fejlesztő, aki a kontrollert buherálja, az az agentet is simán buherálhatja minden további tanulmányok nélkül.<br /><br />Mindkettő http protokolt használ: kapcsolódunk, kezetrázunk, bemutatkozunk, valami teljesen minimális dolgot közlök veled aztán elbúcsúzunk és fél másodperc múlva újrakezdjük. Az oVirt még emellett egy döbbenetes dolgot is csinál a tranzakciókkal, ami a MS-SQL-ből PostgreSQL-re való áttérés (és talán egy súlyos félreértés) eredménye.<br /><br /><br />Amikor azon gondolkodtam, hogy hogyan tudnék jó agentet a kerubhoz, elösször is inkáb azon gondolkodtam hogyan lehetne megúszni az egészet, mert nincs rá időm. Másodszor pedig szerettem volna megszabadulni a kommunikációs overhead-tól, pl xml parsing.<br /><br />Végülis az, hogy nincs agent, azt nevezhetjük félrevezető marketing-baromságnak, mert valamilyen szoftvernek futnia kell, amivel kommunikálunk. Ennyi lett: OpenSSH, az OpenBSD klasszikus SSH szervere, ami fut linuxon, windowson (cygwin), mindenféle BSD-n és solarison, ráadásul többnyire része egy szerver alaptelepítésnek.<br /><br /><br />Az absztrakciós réteg... egy része ott van a kontrollerben, mert annak tudnia kell, hogy milyen operációs rendszerhez beszél, az absztrakciók nagy része viszont elment. Eleinte csináltam abstrakciót a hypervisor-elé, de később találtam jobb megoldást és mostanában lassan eltávolítom ezeket a kerub-ból.<br /><br />Ez most hosszú lett, mert vasárnap van, legyen legközelebb például az, hogy mit csinál a planner és miért nem kellenek az absztrakciók.<br />Kockahttp://www.blogger.com/profile/10505773298750628833noreply@blogger.com