Java Architekt - a gyakorlatban

István múlt heti postjára szeretnék egy kicsit bővebben reagálni, mint ahogy kifér egy pár soros kommentben. Technikailag nagyon korrekt definíció egyébként, de egy két dolgot hiányolok belőle és pár dologban buktatót látok.

Szóval szerintem...

Elösször is azt tenném hozzá, hogy amennyiben valaki - az architekt pl - meghatározza a szoftver archiktetkúrát, amiben a szoftver-fejlesztők dolgozni fognak, akkor annak az embernek a felelőssége az is, hogy a szoftverfejlesztők mennyire tudják hatékonyan végezni a feladatukat. Amikor egy java architekt dolgozik, akkor arra kellene koncentrálnia, hogy minnél egyszerűbb és hatékonyabb eszközöket adjon a fejlesztőknek és minden komplexitást csak valami megfelelő haszonért cserébe (customer-value) engedjen be. Én ezzel szemben nagyon sok fejlesztésben láttam valami totálisan elszállt marhaságot. A 97 things - és István is - ezt javasolja architekteknek: ne az önéletrajzodat fejleszd. Persze nem ez az egyetlen oka annak, hogy egyes java projectek krónikusan halálcsillaggá nőnek, van a dologban némi buta ego-fejlesztés is.

Többmillió java szoftverfejlesztő nevében követelem, hogy amikor kiderül, hogy egy java rendszer elcseszett ökörség lett, az architekt szüleit legalább annyira emlegessék meg, mint a szoftverfejlesztőkét!
A hegesztőmunkás is el tudja cseszni, de általában ezek az hibák általában nagyon könnyen javíthatóak. Ellenben architektúrális hibák többnyire végigkisérik a szoftver életét.

A másik észrevételem az lenne, hogy István definíciója nehezen illeszthető össze egy akármilyen agilis, iteratív szoftverfejlesztéssel. Elösször is azért, mert az architekt a definícióban elvágja a fejlesztőket a klienstől. Láttam már olyan embert, aki egész jól játszotta az információfiltert, de ez nagyon ritka, valamennyi infót mindenki elszór, a delay pedig minden embernél nagyobb, mint a másfél másodperces csúszás a telefonvonalban. Másrészt az agilis szoftverfejlesztés nem különít el hosszú tervezési szakaszt. A tervezési szakasz nálam a waterfall modell szinonímája. Aki ezzel jön elő, az általában valami olyasmit forgat a fejében. Aztán tipikusan a fejlesztés alatt kiderül hogy jajj, az úgy finoman fogalmazva is szuboptimális lesz, de akkor már bukó van, mert implementálni köll.

Aztán a harmadik észrevétel: egy-egy cég szokásait és procedúráit kitanulni időnként évekig is eltart, de legalább hónapokig. Én ha nagycég lennék, inkáb a belső emberek között keresném a leendő architektek legalább egy részét. Persze nagyon jól jöhet a más cégtől érkező tapasztalat is, de annak még jó sok idő, amíg kitapasztalja, hogy mi működik és mi nem működik valójában az új helyén.

Aztán még egy utolsó észrevétel a tanulással kapcsolatban: Nagyon jó, ha valakinek volt rá pár milkája hogy meghallgassa az Oracle/IBM/SAP/RedHat/Anyámtyúkja kurzusát, de az katasztrófa, amikor ezek után a kurzusok után, a fenti cégek technológiáit és termékeit lenyomkodja a fejlesztők, a cég, a kliens és a felhasználók torkán, ha jó, ha nem jó. Ilyet pedig már mindannyian láttunk. Én inkáb olyan emberrel dolgoznék együtt szivesen, aki nem csak az Anyámtyúkja technológiáit és termékeit ismeri, nem nyalta be a marketinget, hanem gyakorlati tapasztalatai vannak, látott elcseszett és pöpec projecteket. És ha ez megvan, akkor az architekt kurzus valószinűleg nem éri meg a pénzét.

Ö... oszt ennyi, na kitomboltam magam :-)

selinux

A selinux-szal kapcsolatban mindig volt egy olyan sejtésem, hogy az emberek többsége csak annyit tud róla, hogyan kell kikapcsolni. Erre utalt az is, hogy a gúglinak ha elkezded beírni, hogy selinux, felkínálja a népszerű keresések között a "selinux disable" lehetőséget. Ma hallgattam egy csákót aki a selinuxról beszélt és meglepetésemre tudott a problémáról. Az azért szimpatikus, hogy nincsenek illúziói... Aztán mutatott olyan selinux parancsokat, amiket 2 másodperccel később már nem tudtam volna leírni mert olyan rohadt hosszú volt.
Cifra szopatásnak vannak kitéve a desktop linux felhasználók, nem csoda hogy olyan ritka faj.

Fejlesztői napok februárban Brno-ban

Brno-ban február 17-18.-án lesz a Fedora fejlesztői konferencia, péntek-szombat. Két track linux, egy track JBoss projektek. Kifejezetten érdekel a drools és a infinispan, mondjuk én hülye pont aznap leszek a szomszéd teremben kameraman de megpróbálom elcserélni.

Infók itt.

Ha jösz, szóljál és fussunk össze!

maven, java... és a linux!

Ma tartottam egy prezentációt a Red Hat-nél a maven-ről. Jajj, már megint a maven, már vagy a negyedik vagy ötödik eddig életemben. Nekem már kicsit unalmas, de úgy gondoltam ezzel tudnék segíteni a legtöbbet a projectemnek. Persze megpróbáltam új nézőszögből, hátha úgy jobban átjön. Ugyanis maven-t használunk, de nem vagyunk egészen boldogok. Meg is érdemeljük szerintem, de ne aggódjatok értem, rajta vagyok!

Mindenesetre a srácok felének annyi köze van a java programozáshoz, mint nekem az ABAPhoz. "Aha, láttam már olyat!" A Red Hat csákók túlnyomó része nyilván kemény linuxer, égget scriptszag terjeng a levegőben, commandlineokban gondolkodnak, satöbbi. Na és a maven dependency resolution dolgára keményen beszólt egy srác, hogy nem akarnak jar fileokat letölteni a maven repositorykból, jöjjön szépen a buildhez a jar file egy szép csomagból az yum repositoryból. Oszt csókolom.
Elmondtuk neki -többen is-, hogy hát vannak még olyan srácok a világon, akik nem fedorát használnak. Ezzel nem akartam megsérteni de ők vannak azért többen, nekem oké a fedora. Is... akár... Szóval mit mondjunk a java fejlesztők és felhasználók többségének?

Sajnálom ez a java program nem fordul le Windows 7/OS-X/MyPetLinux operációs rendszeren, mert még nem csinálták meg a függő jar fileokat tartalmazó exe/msi/dll/rpm/deb/tgz/ fileokat az ő rendszerére.
(Osx-hez mi is a csomagolás? Na mindegy...)

Aztán meg mi java fejlesztők még mindig ott tartunk, hogy a java alkalmazás operációs rendszertől független amennyiben nem csesszük el ugye, és ezt előnyként értékeljük. Ugyanis bátran fel tudod upgradelni a linuxodat a legfrisebb linuxra, a java alkalamzásod még mindig ugyanazt fogja tenni. legalábbis jó eséllyel, de egy rendszer upgrade semmiképpen sem olyan seggfájás, mint ha OS-függő lenne. Ez egy üzleti alkalmazásnál szvsz rohadtul fontos. Míg ha a függűségeidet pl RPM-be csomagolod, a következő rendszer upgrade esetleg agyoncsapja az alkalmazásodat. Oszt csókolom.

Mit szólnál ha ezzel köszöntene reggel a rendszeradminod?

Hoppá, kicseréltem a hibernate-t az alkalmazásod alatt 4.x-re, maradhat?

Megijednél kicsit, nem? :-)

Azért egy pár sráccal beszéltem, azt hiszem még egy pár kört beszélgetnünk kell mielött azt mondjuk hogy oké értjük egymást, de rajta vagyok a témán.

Egyébként a prezi itt található. Sajnos a hangminőség csapnivaló volt, meg hát angolul se tudok. Ja meg beszélni se nagyon.

Alternatív nyelvek

Érdekes az, hogy buzgón új nyelvet tanulnak az emberek, gondolva hogy azzal egyszerűbbek lesznek a kódsorok. Ezzel egyébként egyetértek, de a probléma nem annyira a kódsorokkal van, szerintem inkáb agyhalott architektúrákkal, agyonhízlalt rendszerekkel és az értelmetlen komplikációkkal. Aki most elbonyolított rendszert ír java-ban, az valószinűleg groovyban, scalaban vagy jruby-ban is ugyanazt fogja csinálni.


Valakitől még olyat is hallottam, hogy scala-ban gyorsabb lesz a rendszer. De és mitől lenne gyorsabb? Mondjuk ha nem ugyanazt a marhaságot írjuk bele, akkor elhiszem, de amúgy nem értem mitől lenne.

git

Az utóbbi fél évben több időt töltöttem git parancsok kiadásával, mint tényleges java kód fejlesztésével. Ha így nézzük, a git nem valami hatékony eszköz. Persze könnyen lehet, hogy a leghatékonyabb eszköz arra, hogy patchetekt formázz, átrendezz újraírj, brancheket csinálj lokálisan, satöbbi satöbbi. Csak az a baj vele, hogy én pont ezzel nem akarok sok időt eltölteni. Java szoftverfejlesztő vagyok, java szoftvert fejlesztek és hibákat javítok, elég sok munkám akad és nekem ez a pöcsölés a gittel csak nyűg.
A tanulási idő is kicsit hosszabb. A subversionban mondjuk tudnod kell úgy 3-5 egyszerű parancsot ahhoz hogy egész jól elboldogulj vele. A gitben a duplájával se jutsz sokra, a paraméterezés pedig egészen elcseszett. Ennek megfelelően rengeteg embernek vannak vele nehézségei és úgy tűnik egy kicsi de nagyon elkötelezett rajongótábor nyomja.

Az, hogy teljesen decentralizált, kétségtelenül nagy előny lehet a linux kernel fejlesztésében, de nem hiszem hogy tényleg minden projectnek erre van szüksége. Azt hiszem pont ez a feature hozta azt a komplexítást, ami aztán kinyírta a hatékonyságot. Úgyhogy én a gitet már félig bepakoltam a 'technológiai maszturbáció' kategóriába.

Technológiai maszturbáció: amikor az ember valami nagyon szépre gondol, de valami nagyon csúnyát csinál :-)

One RSS to rule them all

Csináltam egy yahoo pipe-ot, ami összeönti a magyar java blogok tartalmát egybe. Ez van most kint, oldalt, csak van belőle egy változat, amiben nincs benne a saját blogom RSS feedje. Nyilván azt minek ide kitenni :-)

• pipe (ha esetleg clone-oznád)
• rss - ha olvasnád vagy kitennéd valahova
• twitter acc - ha az rss nem elég trendi

Ha valaki blogját kihagytam, szóljatok! Sajnos nem sok az aktívítás, sok blog vált inaktívvá az utóbbi 2-3 évben :-(