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á!

2017. október 9., hétfő

checklist project indításhoz

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

Néhány hét kemény munkával több órányi tervezést meg lehet takarítani.

Hát szóval...

Első helyezet: Adatbázis schema verziózás

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

Erős második: forráskód formázó beállítások

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

Bronzérem: CI enforce tests

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

Negyedik: DEV produktívítás

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.
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...
Hogyan bánjunk a ránk kényszerített közös MQ-val, közös adatbázissal.

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.

5: contact list

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.

Biztos van még sok, csak most nem jut eszembe, legyen akkor csak ennyi most.

2017. április 22., szombat

ki 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:
  • 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.
  • Shiro bugfix
  • Kotlin - többnyire apróságok a stdlib-ben, egyszer egy apróság a compilerben, párszor az IDE-ben.
  • 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.

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.

2017. április 10., hétfő

Sky job interview

Egyszer, 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
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:
  • pair programming egy önkéntes alkalmazottal
  • valami kis problémamegoldás
  • architektura design egy pár fazonnal whiteboard-nál
é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.
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.
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:

Kedves Izé,

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...
Dögölj meg,
HR

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.

Az átlagos ember a maga hibáiból tanul, ezt remélem kipipálhatom, ti meg próbáljatok jobbat :)

2017. március 6., hétfő

kerub - a packaging frontról jelentjük

Kerub. Kicsit megint hanyagoltam a blogolást, de a munkára igyekeztem időt szorítani. A nagyobb dolgok amikbe belerúgtam mostanában:
  1. 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.
    Készül az Ubuntu és a Debian csomagoló is.

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

    A csomagolás egyébként olyan, mintha az apolló űrhajót mamutbőrbe
  2. 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.
    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.
    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!!!
  3. 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

Na jó, ennyi bőven sok, dolgozzunk!