2019. április 20., szombat

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.

2019. január 22., kedd

Kotlin null-biztonság

A 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:
A kotlin fordítási időben ellenőrzi a változók és értékek típusát.
Azaz mindent úgy kell deklarálnod (a kotlin erősen típusos nyelv) hogy lehet-e null vagy sem.

Például:

var neverNull : String = "bla bla bla"
var maybeNull : String? = null // hoppá alapból pont null

Lehet próbálni a széllel szembe pisilni:

var amISmarterThanTheCompiler : String = null // compiler error

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!=null) a kotlin elvis-operátorával, vagy a null-safe navigációval, pl

person.taxId?.startsWith("1234") ?: false

A legeslegesleg szeretetre-méltóbb dolog az, hogy ezt adatreprezentációban, a kotlin data osztályokban.

data class Person (
  val firstName : String,
  val lastName: String, 
  val taxId : String?
)

Millió órányi NullPointerException-kergetés után könnyes szemekkel hüppögve kérdezhetjük:

Akkor most meg vagyunk mentve?

És a korrekt válasz: lófaszt. Illetve már majdnem, csak még nem.

Persze azzal kezdtem, hogy fordítási időben 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.


1. számú gyanúsított: Serialization

A legnyilvánvalóbb tréfát serializationnel lehet elkövetni.

data class Person (
  val firstName : String,
  val lastName: String, 
  @Transient val name = "$firstName $lastname"
)

Tessék kérem serializálni, deserializálni, majd

person.name.startsWith("Meglepi") // bang

2. számú gyanúsított: Jackson 

A jackson egyébként az evidens esetekben kedvesen szól, hogy nem lehet null valami...

data class Person (
  val firstName : String,
  val lastName: String
)

objectMapper.readValue(""" 
 {
   "firstName":"Kakukk",
   "lastName": null
 }
""", Person::class.java)

És itt a jackson felháborodik, amitől mindenki megnyugszik, hogy tessék, biztonságban vagyunk. Igen, majdnem...

data class Person (
  val firstName : String,
  val lastName: String,
  val titles : List
)

val person = objectMapper.readValue(""" 
 {
   "firstName":"Eugene",
   "lastName": "Cuckoo",
   "titles" : ["dr",null,"sir"]
 }
""", Person::class.java)         // nahát, működött...
person.titles.forEach(::println) // bang

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.

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?

3. számú gyanúsított: mindenki

De legyen elég mára ennyi a paranoiából, mert végülis csak annyit akartam mondani, hogy
  1. Semmi baj, túl lehet élni, csak figyelni kell rá.
  2. Mindent addig kell kínozni, amig a kívánt vallomást meg nem teszi.
  3. Oké elég, takarodó

2018. szeptember 8., szombat

Apály

A 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ő.
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?


Nos a leggyakoribb megoldás az, hogy a csapatot is lecserélik, ettől lesz mégrosszabb.
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


Kevésbé okos cégek esetében: örökké ismétlődő Halálcsillag Design Pattern.

Illetve elvben létezhet olyan, hogy valaki nem megy bele ebbe az egész csapdába, csak még nem láttam ilyet.

2018. augusztus 16., csütörtök

Outsourcing magyarázat - ötlet

Szó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.
Nem hangzik olyan jól, igaz?

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

Na és erre van egy friss összeeskövés elméletem, ezt szeretném megosztani veletek, tessék:

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.
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!
Tehát hajrázunk örökké. Nincs baszakodás, nincs okoskodás, nincs állóháború, megy a meló.
Ennyi lenne.


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.

Azért ez szerintem jelentős különbség. Lehet, hogy megéri. Nagy cég, ufó-logika. 

2018. május 27., vasárnap

optimalizá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:

  1. Legyen a fejlesztőknek képe arról, hogy milyen teljesítményt vár el felhasználó / megrendelő a rendszertől
    És persze a megrendelő legyen udvarisasan tájékoztatva arról, ha irreálisak az elvárásai
  2. 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.
  3. Legyen a rutin tesztelés része az, hogy nagy terhelés alatt is korrekt eredményeket gyártson a szoftver.

Ezeket azért írtam össze, mert olyan ritkán láttam a gyakorlatban, együt pedig még soha.

A problémák, amiket én tapasztaltam:
  1. Á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.
  2. 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.
    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
  3. 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".

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.

2017. december 14., csütörtök

szevasz ebook

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

A halál oka 1: csere alkatrészek hiánya

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.

A halál oka 2: röntgen

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.

A halál oka 3: Hauptbahnhof

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.

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.

Amúgy az ára nem lenne vészes, de a minősége az sajnos gáz.

2017. október 20., péntek

Informatika oktatás

István írására egy komment...


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

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

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.

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.

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?

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.

Nem ott és azonnal, de hasonló esetek 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.

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? :-)
Hajrá!