Review Antipattern: a sötét oldal

Ma egy kis anti-pattern csoportról írnék

1. fenyegetés
2. félelem
3. bosszantás

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 (első pattern), hogy ha nem csinálom vissza, akkor azzal aláz meg, hogy ő reverteli. Hagytam, had dühöngjön. (harmadik pattern: 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.
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. - második pattern: beparáztak a nagyfőnök kis kedvencétől.

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

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

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.

Review Antipattern: köpj bele és hagyd ott

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.

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 más se egye meg.
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.

A pattern: nagyon egyszerű, csak egy kommentet írj egy nagyon nagyon nagyon általános és bizonyíthatatlan ellenvetéssel. Például:

• ez a változás ellentétben áll az OOP alapelveivel (ha úgy nézzük, minden a világon)
  
• sérti a REST szabályait
• egy anti-pattern-en alapul (hát persze, hiszen minden pattern valakinek antipattern, de melyik az és miért)

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.
Szóval kis kivétellel mindenhol bevethető, gyors, hatékony.

Ennyi. Buenosz étvágyosz.

Review Antipatterns: Egy tonna ez-az

 A code review kiválló eszköz arra, hogy egy csapat szoftverfejlesztő

• átnézze és tesztelje egymás változtatásait, megelőzzön hibákat
  
• megossza egymással a felelősséget
• megosszon egymással ötleteket

Bár a fentiekre is lehet használni, lehet arra is hogy:

• egyébként működö fejlesztést szabotálj vele
• karriert építs a cég és a csapatod kárára
• te legyél a domináns izé, a vezérfarkas, a matriarcha, ilyesmi
  
• bosszút állj valakin, aki bosszút állt rajtad valamiért... lehet ez egy hosszú és bonyolult történet, de biztosan ő kezdte
  

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.

Itt jön az első anti-patternem:

Egy tonna ez-az

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.

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.

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"
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.

Kész. En guete :)

post-covid post

Szia, te vén blog!

Ezer éve nem írtam ide (vagy akárhova is), Tvik cikke 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.

Ö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.

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.

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
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?

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.
Azért még mindig sokat dolgozok éjszakánként, de nem legalább nem hajnalig.

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.

Ö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.

Amikre nem számítottam

A következő írás talán hasznos lehet a következő szituációkban:

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.
Én a saját szememmel láttam ilyet a tévében.

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

Volt pár dolog, amire persze a legelején számítottam:

• Minden EJB cókmóknak búcsút kell mondanunk örökre - jajjdesajnálom
  
• A library függőségek portolása fáj.
  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.
  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.
  
• Nehéz átállni spring fejlesztésre olyan fejlesztőkkel, akik elötte egész életükben JEE platformra fejlesztettek.
  

...és amikre NEM számítottam:

Header limit

Látszólag a webklotyi nem alkalmazott megszorításokat a header-ek méretén, 128 KB-ig próbáltam, mindent bevett.
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.
A megoldás egyszerű: felhúztam minden spring boot appban a korlátot egy tisztességesen magas korlátra.
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.

Gzip

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?
Néztem a logokat és úgy tűnt, részünkről minden oké, HTTP 200, sehol egy hiba mi lehet a baj?
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).
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.
Megoldás: kikapcsoltam a gzip opciót, mivel nincs lehetőségem minden consumer appot debugolni.

Szemaforok, timeoutok

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.
A teszt rendszeren ezután a terhelési teszt szépen átment, semmi probléma.
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.
Egy újjabb emelés következett, most már hónapok óta nem jött a hiba.

Oktatás

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.
Í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.

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.

Tanulságok

1. 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.
2. 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.
   
3. Széllel szembe pisilés:
1. É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.
2. Még mindig nem értem miért pazarolja bárki is a pénzét outsourcingra.
   

full stack

Kétféleképpen voltam full stack developer eddig...

A: Az egyetlen ember a projekten

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.

B: Fallback opció

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...
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.
Ez nem csak egy eset, hanem minden eset ilyen volt.

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.

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.

Minőségi változáshoz nem vezetett a transzformáció, de gyorsabb se lett a fejlesztés.

software serviceability checklist

Az 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.

Logging

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.

1. 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
2. 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
3. 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
4. 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.
5. Még egy technikai apróság, ilyet sokan csinálnak:
   if(LOGGER.isEnabled(LogLevel.INFO)) {
      LOGGER.info("akármi: " + valami.getName().getFirstName())
   }
   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.

Health-check (alias 'ping')

Ez egy gyakori feature a legtöbb szoftverben, általában egy egyszerű text, html vagy JSON oldal, ami felsorolja

1. a szoftver verziószámát
2. 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.
3. vagy ha ilyesmi szükséges: helyi disk space (például a lognak) vagy a szabad memória információk

Ezt sikerült idáig mindenkinek összehoznia, de mit lehet benne elszúrni:

1. ha a ping túlságosan nehéz műveletet akar végrehajtani az adatbázison - nem csak egy select sysdate from dual hanem konkrétan táblák méretét lekérdezni: select count(*) from all_i_have_ever_done;
   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.
2. 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.

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.

Reverse Onboarding

Á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.

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 :-)

Ezek az infók nagyon hasznosak lesznek probléma esetén, ezt sajnos szó szerint érdemes a párna alatt tartani.

1. Tervezett Outage esetén hol kapsz értesítést, mennyi idővel előre
2. 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
3. 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)

Dashboards

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.

JAVA: Exception handling

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.
Sajnos a checked exceptions egy tragikusan rossz ötlet volt. Eggyel több ok kotlinra váltani.


Ennyi pillanatnyilag. Egy profi supportos biztosan tudna hozzábökni pár dolgot, de én még mindig főleg hegesztésből élek.