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

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