Developer Conference 2012 Brno, második nap

A fedora konferencia második napjáról jelentjük. Ma főleg (de nem kizárólag) JBoss előadásokat hallgattunk meg. Voltunk páran magyarok, többnyire magyarországi magyarok, a brnoiak csak néha tolták elő az orrukat :-)

Swimming Upstream - Jared Smith

A fedora project vezetője arról beszélt, hogy milyen egy ilyen linux disztró fejlesztését irányítani, igen ezzel az opensource dologgal nem zavarnálak titeket, de megemlítette valahol a java-t, beszéltünk az egyik szünetben és azt hiszem hasonlóan látjuk a helyzetet a fronvonal két szembenálló lövészárkából:
A java fejlesztők és a linux fejlesztők valamit kapni akarnak egymástól, de nem értik meg egymást és a végén senki nem kap semmit. Bukó, nem? Nyomozok a dologgal kapcsolatban, vannak fejlemények, majd mesélek egy másik posztban.

oVirt overview - Alan Pavec

Ez a munkám, imádatom és gyűlöletem tárgya, úgyhogy beültem hogy meghallgassam. Majdnem teltház volt a nagyteremben, örültem neki hogy ekkora érdeklődés volt. Sokan kérdeztek is. Remélem a hibákat sikerül kijavítani mielött ők is megtalálják...

RHQ4 - Lukás Krejci

Igen, a JBoss a redhaten belül egy külön ország. A java általában már csak így van. Szóval a RHQ-val java szervereket lehet igazgatni, több platformon keresztül. Lukás csinált jópár demót is, néha volt egy kis izgalom hogy most mi történik, de mindig jól sült el, pedig baromi nehéz live demót csinálni.

Whats new in JBDS 5.0? - Martin Malina

JBoss Developer Studio. Jaja, erről  a srácról csinálták ezt a vicces képet az üresnek látszó teremmel. Senki nem ült közel, mert akkor nagyon felfele kell nézni a kivetítőre. Közben én laptopon próbálgattam amit a srác mutatott (ugyanis nem vagyok pillanatnyilag képben jboss IDE-ből), meg is akadtam kicsit a forge konzolon, nekem ez ugyanaz volt, mint a springsource roo nevű cucca.

HornetQ - fastest JMS provider - Niroslav Novak

Ideje, hogy erdemben foglalkozzak a HornetQ-val. Ahogy néztem, könnyen beágyazható és szépen muzsikál. Igazából nem a sebesség az első és legfontosabb dolog, amit egy JMS szerver előnyei között fel tudok sorolni, de nem árt egyáltalán. Mondjuk nem annyira gyorsabb az ActiveMQ-nál. Érdekes lenne egy friss összehasonlítás, mit tudhat az ActiveMQ csapat új cucca.

Tomcat 7 and Tomcat 8 - Mladen Turk

Mit kaptunk a tomcat 7-től és mit kapunk majd a tomcat 8-tól? Állítólag a tomcat 7 sokkal jobb minőségű, mint a 6-os széria és ez a legfontosabb a legtöbb fejlesztőnek. (még nem találkoztam senkivel aki az async apit használta volna, annak ellenére hogy nagyon nagy dobásnak tartottam) A tomcat 8 olyan dolgokat tartogat, mint websockets... amire semmilyen standard api nincs, de legalább történik valami.

Egyéb...

Egyébként volt kaja, volt innivaló (kólás pohárból kofola, király), esti parti és voltak magyarok is, Magyarországról jöttek hárman. Páran nem mertek elindulni a hazai úthelyzet miatt sajnos. De akik jöttek, azokkal jót vitatkoztunk pár kérdésben :-)

A 'Presentation Skills' tanárnőt láttam mászkálni a kamerájával, aligha a linux kernel érdekelte, szerintem megpróbálja majd a geek-eket kicsit rocksztárosabbra faragni. Nem baj, rájuk fér :-)

Developer Conference 2012 Brno, első nap

Tegnap a brnoi fejlesztői napon voltam, csak pár prezentációról, ami nagyon tetszett...

Towards Unified Messaging - Frantisek Reznicek

A csákó az AMQP protokolról és az apache qpid-ról beszélt. Az AMQP egy szabvány message queue-knak, nekünk a JMS protokol miatt nem volt különösebben fontos, hogy protokol szinten szabványos legyen. Elég volt kicserélni a drivert és kis szerencsével működött. Mindenesetre egy egész tucat JMS szerver implementálja ezt a szabványt most már. Pl az ActiveMQ és a  is.

Richfaces: testing on mobil devices - Pavel Pitonak

Érdekes demó a QE csapattól arról, hogy hogyan automatizálják a tesztjeiket mobil eszközökre virtualizált szerverekkel.

What are Drools, Guvnor and Planner - Geoffrey De Smet

Java témában kb etalonnak számító rules engine és a köré épített projektek. Semmi új nem volt nekem, decemberben elkezdtem egy prototipis projektet az oVirt mellett kisérletezésre és az egészen Drools-ra épül. Geofrey viszont jó előadó és a többiekkel ellentétben nem akadozik és nem dadog. Ja meg cseh akcentusa sincs :)

A drools érdemel talán egy kicsit nagyobb figyelmet, szerintem sok gyakori problémát le lehet vele egyszerűsíteni.

Hibernate OGM - Michal Linhard

Ez egy jelenleg alpha állapotú project arra, hogy sima JPA apival és annotációkkal ne csak hagyományos relációs, hanem NoSQL jellegű adatbázisokba is lehessen perzisztálni. Jelenleg csak az infinispannal megy, de az infinispan mögött lehet akármi is: cassandra, mongo, akár relácis adatbázis vagy filerendszer is.

Ez nagyon tetszett, nem tudom hogy fog elsülni ez a próbálkozás, de marha jó ötletnek tartom. Kiváncsi vagyok tényleg sikerülhet-e a gyakorlatban, hogy kihúzod az appod alól a relációs adatbbázist és kicseréled valami NoSQL-re.

Continuous integration with Jenkins CI - Vojtech Juranek

Trükkök Jenkinssel. Virtuális szervereken futó agentek, egzotikus nyelvek (php például), bug detektor pluginok. Mondjuk a statikus analízisre én a sonar-t tartom a legjobbnak, az nagyon pöpec.

Csak én tartom igénytelennek a jenkins webes felületét? Jó, úgyis csak fejlesztóknek kell, de ha ennyien használjuk, nincs egy designer köztünk?

No, most jön a második nap, ma oVirt, GlusterFS, SPICE további JBOSS előadásokat fogok hallgatni.

Gyárlátogatás: BuzzwordClass

Egy kis lista arról, hogy milyen ködösítő jelzőket szedtem össze, amik nem valami design pattern alkalmazását jelzik, hanem csak valahogy belekerülnek osztályok nevébe.

1. Domain - Ez általában olyasmit akar, hogy sokminden lehet benne és úgy ahogy van egészben van. Hát ezt akármire is mondhatnánk. pl weblogic domain, storage domain, satöbbi...
2. Business - Hát ez fogalmam sincs mit jelent, többnyire semmit, simán behelyettesítem BLF-re.
3. Enterprise - Ez azt jelenti, hogy a józan paraszti logika szerint marhaság-gyanús, de karriercélokkal architektúrális okokkal jól alátámasztható.
4. Manager - Ez néha ugyanaz, mint a valódi életben: konkrétan nem ő oldja meg a problémát, de ismeri azt, aki igen.
5. Entity / Bean - Ez egyszerűen csak azt jelenti hogy ő az adat, de ez sajnos nem jelenti a történet végét.

Mit szólnál ehhez az osztálynévhez: EnterpriseBusinessManagerDomainEntityBean? Kemény bullshit, nem? :-)

mongo - eddig

A hétvégén kipróbáltam a mongodb-t és az igazság az, hogy nagyon tetszik. Írtam rá egy kis java webappot, és kicsit meghajtottam, a webapp 3000 request/sec-et simán elvitt mindenféle tuning és cache nélkül egy 1.5 GB-os adatbázissal. Na jó be volt indexelve, de az mondjuk a minimum... A processzorídő túlnyomó részét a jvm vitte el (nyilván mert neki parsolgatnia kellett, meg serializálnia, ami sebesség szempontjából elég haszontalan). Pedig még egy youtube film is fogott a processzoridőből. Szóval sikerült meglepni, nemgondoltam hogy ilyen jól fog pörögni.
A cassandrához képest az is nagyon tetszik, hogy nagyon könnyen ki lehet deríteni egy collection méretét. Cassandrában nem is tudom hogy lehet...
Aztán a springes API is egész klassz hozzá. A plain API se valami bonyolult, a JDBC-hez képest pedig ultraegyszerű.
Egészen kiváncsi lettem, megpróbálom valamikor a cassandrára írt tesztemet átírni mongo-ra hogy lássam hogy néz ki több node-on.

project reset

Nem egyszer állítottam azt utóbbi X évben, hogy egy bizonyos szoftvert egyszerűbb lenne újraírni, mint debugerrel piszkálgatni nagyon sokáig, hamarabb lenne belőle simán futó rendszer. Biztosan nem volt mindig igazam, de ilyesmi nagyon nagyon ritkán történik, így ez ilyen "mi lenne akkor" maradt jobbára. A parát megértem:

• Mi a garancia arra, hogy az újraírt rendszer jobb lesz? Nem csak valami trendibb izét akarnak a fejlesztők? Pl valami NoSQL-t az Oracle rojszrojsz-adatbázis helyére. (btw éppen mongo-t tanulok)
• Az újraírás idejét miből gazdálkodja ki a fejlesztő cég? (inkáb kiscégeknél)
• Illetve az eddig beleölt időt és pénzt hogyan írjuk le? (tipikisan nagy cégeknél)

Ennek ellenére biztos vagyok benne, hogy

• A legtöbb informatikai project építget olyan komplexitásokat, ami nem kell egy megrendelőnek sem.
  Ide tartoznak azok a feature-k, amiket senki se használ és az olyan kódszervezési megoldások, amik a design patterns könyvben UML diagrammon jól néztek ki de az editorban már kicsit átláthatatlanok.
• A szükségtelen bonyolítások jelentős részétől általában gyakorlatilag nincs lehetőség megszabadulni, a fejlesztést pedig rémesen lelassítják.
• Ebből következőleg egy from scratch project gyorsabban képes fejlődni, ha tanult az elődje hibáiból és nem próbál meg újabb trendi ingyombingyomokból építkezni.

Jó megoldás nincs. Vagy megszabadulsz a technológiai adósságodtól, vagy az egész project alatt fizetheted a költségeit. Egyszerűen kiszámolható. Napi 8 óra munkám 8 kiló banánba kerül, de ebból a nyolc órából 2-t rebuild-redeploy, akkor napi 2 kiló banánért a cég nem értéket kap, hanem a technológiai adósság fizetésére fordít.
Ha így nézzük a jrebel a legtöbb JEE projectben a legfontosabb program a javac után. Azért lehet élni nélküle is, otthon elő nem veszem...

Ötlet megoldásra:

• Ismertesd meg a főnököd a tech debt fogalmával. Nem kell szégyellni, mindenkinek van!
• Tartsátok rajta a szemeteket, tudjátok hogy mi mennyi időbe (tehát mennyi pénzbe) kerül A sonar szerintem klassz kis játék ehhez is, csak persze be kell paraméterezni...

Egy tipushiba, amit megfigyeltem, az az volt hogy amit a beszállító hozott, azt elfogadták amennyiben a funkcionális követelményeknek megfelelt. Így aztán pl groovy-ban írt csoda is érkezett, amikor a srácok többsége még életében nem látott groovy-t. A beszállító elfutott a pénzével, az üzemeltetés meg járkálhatott körbe, hogy "helló, valaki hallott már groovy programnyelvről?" Aztán újraírták más nyelven, de abba se vonták bele cég szoftverfejlesztőit tudtommal. Vajon ismétli magát a történelem? Vagy csak bizonyos problémák időnként jelentkeznek ha egyfajta hibát nem tudunk megérteni? :-)

Egészen pontosan egyszer történt velem az, hogy a management beleegyezett egy újraírásba, de elöbb ki kellett javítanom az előző rendszer kritikus hibáit, hogy legalább az újraírás alatt legyen valami. Ezt mondjuk gondoltam előre, de ez a hibajavítás úgy fél évet vett igénybe, az újraírt verziót is ugyanennyi idő alatt fejlesztettük le, a 6 hónapnyi áthidalt időben viszont senki sem merte használni a régi alkalmazást. Szóval a javítgatással nem nyertünk semmit.