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

reneszánsz vízesés

A munkahelyemen nyilvánvaló waterfall process alakult ki az utóbbi nagyjából egy évben az azt megelőző agile-féleségből. Ez egy nem túl motiváló, de nagyon tanulságos folyamat, úgyhogy gondoltam megosztom veletek ezt a gondolatot, hátha valaki valami hasznos következtetést von le belőle.

Szóval ugyanarra a problémára két ellentétes választ ad a waterfall és az agilis módszertan, mindkettő teljesen megalapozottnak látja a lépést.

Az ügyfél szeretne minél több hasznos dolgot kapni a szoftverébe. Az agile metódikában erre azzal válaszolunk, hogy gyakrabban adunk ki frissítést. A waterfall-ban az ügyfél ugyanazt akarta, de a fejlesztési folyamat végén a tesztelés során, amikor szegény csóri felhasználóim már tudják, hogy ezzel a cuccal ki kell bírni néhány hónapot onnantól kezdve hogy kibökték azt, hogy "OK". Nos emiatt félelmetes mennyiségű "last minute" feature-t kértek, még az utolsó percekben is. Szó szerint amikor beütöm az release parancsot, akkor még pár percet tengek-lengek, mert egész biztosan csörögni fog az email miután lefuttattam a parancsot.
Ennek nem csak minőségi következményei vannak, hanem oda vezetett, hogy az elég hosszú fejlesztési ciklust minden ciklus után megtoldottuk. A csóri felhasználók pedig mégtöbb "last minute"-t kértek, mert még többet kell majd várniuk a következőre.

Nagyon hasonlóan történik a specifikációval is, egyre hosszabb lesz, és amíg az alá nincs írva, addig egy bitet nem verünk be. Emiatt persze a felhasználó egyre többet ül rajta, nem merik aláírni, amíg a legapróbb részletig minden bele nem kerül. Persze munka közben kiderül, hogy ez nem sikerült, de a következő alkalommal még hosszabb specifikációs ciklus következik.

Ezt nem magamnak, meg a szerény létszámú olvasóközönségemnek mondom, nyilván elmondtam a project vezetőinek is, egyetértés megvolt, de valahogy semmi nem történt. Azt hiszem ugyanazokat a problémákat látjuk, csak más lámpák gyulladnak ki.

Egynemű házasság

Nemrég egy új főnökömnek (gyűjtöm a managereket) próbáltam elmagyarázni hogy mi a szituáció a projecten és valahogy ez a megnevezés jutott eszembe: egynemű házasság.

Az egynemű házasság alatt azt értem, hogy a projectre úgy helyeznek új munkaerőt, hogy az a projecten már meglévő fejlesztők képességeit nem kiegészíti, hanem azt lefedi.

A skálázhatóság témában szokás ezt X-axis-nak nevezni, és ott jól produkál, tipikusan webalkalmazásokat egész könnyű (ha nem csinált valaki valami turpisságot) X-axis mentén skálázni. A lényeges különbség viszont az, hogy a számítógépekkel összevetve az emberek lassan tanulnak és ráadásul sok hibával, azaz mind másként tanulnak meg valamit. Ez oda vezet, hogy kialakul pár vita és persze személyfüggő, hogy mennyi, de egyre több koordináció válik szükségessé. A problémán az sem segít, hogy az emberek természetes viselkedése a versenyzés, ez ugyanis nem minden eset válik a szoftver javára például gyakoribbá vállnak a túlmérnökölt megoldások.

Hát ennyit akartam megosztani ma, hogy én így gondolkodok erről nagy általánosságban véve, a többi bullshitet költsétek ti hozzá :)

többnejű programming

Egyik nap ebéd közben azt mondtam a munkatársaimnak, hogy szerintem ahhoz hogy valamiből igazán jó legyél, ahhoz erősen fókuszálni kell arra a területre. Emiatt pedig csak 1 dologból lehetsz igazán jó, a többiből csak tűrhető. Például Albert Einstein fantasztikusan jó volt fizikából, emellett még egész tűrhetően hegedült. Ha több dologból is igazán jó akarsz lenni, akkor több dologra is fókuszálnod kellene, ez viszont ütközik a fókusz definíciójával. Milyen fókusz az, hogy fókuszálsz a ruby, a python, a linux kernel és a java technológiákra?

Nos az eredmény az volt, hogy leüvöltöttek. Mint amikor gimiben megkérdeztem hogy a kereszténység miért egyistenhit, amikor van egy rakás szent, angyal, ördög, satöbbi, teljesen kiakadt tőlem a tanár.
Azt mondják az egész csak idő-management kérdése. Ezt én nem értem, megfelelő idő-managementtel ki lehet bővíteni még 8 órával a napot?
Ez a dolog a red hat-nél valószinűleg azért van, mert a java programozónak is egész jelentős bash és linux teszten kell keresztülmenni felvételikor, ellenben szerintem a vizsgáztatók elég keveset tudnak kérdezni java témakörben. A legtöbben tehát a bash rémes szintaxisán és a python követhetetlen csomagrendszerén véreznek el, nem pedig a JPAQL részletkérdésein.

Elhiszem, hogy tűrhető python programozó lesz valaki, míg java programozásban igazán jó, de nem lehet valaki Rambó és Batman egyidejűleg. Még ha agymunkával bírná is, nem fér bele a napba.

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

Agile

Az agile nem egy processz vagy fejlesztési metodika, hanem egy hozzáállás. Olyat lehet csinálni, hogy amúgy is agilis hozzáállású fejlesztők olyan metodikát választanak, ami passzol a stílusukhoz, de ha nem agilis fejlesztők választanak ilyen metodikát, akkor az csak nevében lesz agilis, egyébként inkáb az általuk megszokott munkastílushoz fog hasonlítani. Az ember nem gondolkodik mindig azon hogy most éppen milyen fejlesztési metodikával dolgozik.
Magánvélemény rovatunk jelentkezett, további boldog hétfőt! :-)

Egy szoftver három halálos ellensége

Utálom azokat a postokat, amiknek a címében szám van, de egyszer voltam egy mocsokdrága NLP (ez kb olyan és talán pont ugyanaz mint a scientológia, annyi különbséggel, hogy ufókról nem esett szó) fejtágítón, ahol többek közt ezt tanultam:

• Mindent ossz
• fel hármas
• csoportokra

Ez következik most. Szóval gondolkodtam rajta, hogy mi okozhatja egy szoftverfejlesztési project halálát, és az eddigi szoftverfejlesztéssel töltött kb 10 év után három dolog jutott eszembe különösebb fejtörés nélkül. Jöjjön hát a teljesen szubjektív listám:

1. Az ügyfél. Tipikusan halálos veszély a projectre nézve egy olyan ügyfél, akinek vagy nincsenek elképzelései a célról, vagy nagyon konkrét és hibás elképzelései vannak. Szerintem a legjobb a kicsit bizonytalan de nagyon együttműködő ügyfél. Na igen, on-site ügyfél.
   Az ügyfél anyagi állapota valahogy soha nem volt összefüggésben a project sikerével vagy kudarcával, nyilván én már csak olyanokkal találkozok, akiknek van elég pénzük a projectre.
   Kicsit pontosítanom kéne ezt a dolgot azzal kapcsoltaban, hogy az ügyfél egyenlő-e a felhasználóval és személy-e vagy szervezet :)
2. A management. A management ezer féle halálos veszélyt jelenthet egy szoftver projectre nézve. Nekem tipikusan az jut eszembe, hogy proxy-ként próbál játszani a szoftverfejlesztők és az ügyfél között. Kicsit felesleges szerepnek tűnik, de lehet jól is játszani. Ettől függetlenül az esetek többségében fontos információk elvesztek a fordítás során. A súlyosabb esetekben a management átviteli sebessége lezuhan 0-ra és elvesztessz minden kapcsolatot a project környezetét jelentő ügyféllel. Ez egyáltalán nem ritka eset. Ettől még lehet a fejlesztés sikeres a végén, ha magadtól is kitalálod a helyes utat, illetve ha akármelyik út helyes csak legyen valami.
   A másik tipikus hiba a túl beszédes projectmanagement, ebben az esetben annyi meeting-re kell járnia a fejlesztőknek, hogy munkára nem marad idejük. Ez mondjuk a ritkább, de nem elég ritka :-)
   Az is nagyon tipikus, hogy a fejlesztőcsapat több része között próbálnak proxy-t játszani. Na, olyat még nem láttam, hogy ez bárkinek is jól menjen. Bár ezen a szinten inkáb a szervezet fejlesztés a priorítás - úgy tűnik így hívják a végülis teljesen öncélú karrierépítést.
3. A fejlesztők is nagyon veszélyesek, konkrétan a kóderek is lehetnek lámák, de azok a projectek amiket eddig láttam, nem a fejlesztők kezén lettek végleg elcsűrve, hanem általában sokkal elöbb, az architekt kezében. A legsúlyosabb döntések ott születnek. Milyen adatbázist használsz, hogyan történik a kommunikáció a felhasználó (böngésző) és a szerver oldali komponensek között, hogyan lehet ezt az egészet fejleszteni, akár ilyenek is, hogy módosítás és teszt között mennyit kell várni az újratöltésre és mennyit kell kézzel kurblizni rajta... Tipikusan itt következnek be azok a hibák, amikról az előző postban írtam.
   Komolyan, egy szoftverfejlesztő csinálhat bugokat, hülyeségeket, láthatsz a képernyőn stack traceket és törött html templateket, segmentation fault-ot, hibás eredményeket, ezek általában pár perc vagy maximum pár nap alatt javítható evidens problémák, amik általában el is múlnak a következő release-ben. Azok a problémák, amik nem múlnak esetleg az egész szoftver életciklus során sem, azok általában mélyebben gyökerező architektúra hibák.

A zárójeles negyedik a UI designer, aki megnehezítheti vagy megkönnyítheti a felhasználó életét HA a project eljut egyáltalán odáig. HA viszont eljut odáig, csodálatos módon a felhasználók a UI design alapján fogják leginkább megitélni a szoftvert. Három okból nem kapott a UI designer külön pontot:

1. Ritkán okoz tényleges project halált egy hülye UI terv, csak a nagyon nagy közönséget kiszolgáló top weboldalakra, operációs rendszerekre, stb jellemző. Persze attól még nem ritka.
2. Még nem is láttam olyat, hogy hülye UI ellenére ne vették volna használatba a rendszert egy cégen belül. Szét is lehet nézni a céges rendszerek között, kezdjük mondjuk az SAP-vel. Azokon a projecteken, amiket kapok, sajnos a UI a legkisebb fubar.
3. Nem fért volna bele 3 pontba 

Cowboy Coding Manifesto - chapter two

A komplexítás nekem nem haverom. Mindenfajta komplexításnak ára van és ha nem ad értéket, akkor kifejezetten rühellem. De még ha értéket ad is, sokkal jobban szeretném azt az akármilyen értéket a lehető legkisebb komplexitással.

Viszont a kód komplexítása szép a teremtője szemében, vagy akinek a nagyságát kifejezi. Konkrétan erre gondolok: Steve Talbott írta a Devices of the soul című könyvében egy olyan délamerikai törzsről, amelyik az 1950-es évekig a világ többi részétől elszigetelten élt. Kicsit agresszív nép, az első néhány évben senki nem élte túl a kapcsolatfelvételt velük, aztán sikerült velük békés kapcsolatot nyitni és "civilizálni" őket. Ez persze hatalmas változásokat hozott a népcsoport életében, például a köpőcsőről átszoktak a puska használatára. A szerző kiemeli, hogy mennyire rossz választás volt ez, ugyanis a puska ezen az éghajlaton hamar rozsdásodik, nehéz és költséges a lőszer beszerzése, a zajával elijeszt minden esetleges zsákmányt és az esőerdőben egyébként se lehet messzebb látni, mint amennyire a köpőcső elvisz. A benszülöttek azzal magyarázták a választásukat, hogy a puskának "olyan szép a hangja".

További ajánlott olvasmány Sean Hastings God Wants You Dead című irása - egyik kedvenc olvasmányom, ajánlom mindenki figyelmébe. Tulajdonképpen memetikáról szól egész bőven, API dokumentáció az emberi agy operációs rendszeréhez. Legálisan is le lehet torrentezni :-) Érdemelne egy magyar fordítást....

Nagyon gyakran fordul elő az, hogy nem a cél lebeg a fejlesztő/architekt szeme elött, hanem az eszköz: egy böszmenagy tankkal akar odamenni. Tökmindegy, hogy hova, de tankkal, egyszerű önkifejezés céljából. Ezt hívják úgy is, hogy a tisztelt engineeringnek elszállt az agya.

Annotation hell

Gyorsan még az is eszembe jutott, hogy elmagyarázzam, miért gondolom azt, hogy az annotációkkal átestünk a ló túloldalára. Úgyis mindjárt reggel van, már jár a villamos.

A nagy XML konfigurációk helyett csodálatos dolog annotációt használni, amikor úgyis csak az az egy konfiguráció lett volna értelmes. Például JPA és más ORM annotációk. Még soha olyat nem láttam, hogy meggondolod magad és nem jó az a név annak a táblának. Kutyát nem érdekelnek a táblák nevei. Persze konkrétan a JPA lehetőséget ad arra, hogy felülbíráld XML konfigurációval az annotációkat.
Hasonlóan lelkesedek azokért az egyszerűsítésekért, amiket a JSR-181 REST annotációk, a JAXB annotációk ésatöbbi hoztak. Az így felannotált osztályokat és interfaceket az ember tipikusan egy pacakge-be dobálja. Igen, helyenként kicsit cifrán néznek ki az osztály-, metódus- és paraméterannotációk. Sebaj, az XML se lett volna kevesebb.

A másik esetben pont a szétszórtsággal van a probléma. Például a non intrusive IoC-nek pont az volt az előnye, hogy nem összeintegrált komponenseket gyártsunk, elég ha POJO, ennek megfelelően tradícionálisan szét lettek szórva a service osztályok, és nincs is nagyon remény a rendszerezésükre. Szóval ezért nem szeretem az annotált IoC-t, beleértve a spring annotációkat is, és tartok tőle hamarosan a servlet 3.0 annotációival is lesz problémám. Képzeld el így a problémát: átveszel valakitől egy spring annotált projektet, nem a dokumnetációtól működik a szoftver tehát dokumentáció nincs, a fejlesztőtől se várhatsz segítséget. Melyik projectet látod át hamarabb? Szerintem az XML-hell egy-két helyen jobb abból a szempontból ott legalább minden egy helyen van. Nyilván ettől lett hosszú. Attól, hogy szétkentük az XML file tartalmát csillió osztályba, attól nem lett se kevesebb, se átláthatóbb, csak az XML lett rövidebb. Sovány vígasz.

Cowboy Coding Manifesto

Annak ellenére hogy már másfél éve egyedül dolgozok (ami elég unalmas) és emiatt a scrum metodikát -vagy legalábbis jó részét- a sutba dobtam, a munkaadóm elküldött egy scrum trainingre. Azért nem volt tejesen haszontalan, nem írnék most róla részletes beszámolót, csak pár dolgot gondoltam vele kapcsolatban:

• Kell-e egy scrum csapatnak dokumentálnia? - Erre nekem az lenne a válaszom, hogy HA a ügyfél kéri és csak azt amit kért. Amit senki sem fog elolvasni az ugyebár "waste". Például az OpenSSO-val hogy hogyan integrálódik a webalkalmazásom, nem hiszem hogy bárki elolvasná amit erről írok, de ha egy fejlesztő belenéz a kódba, szerintem értené (nagyon remélem :) ). Mindenki más állította hogy egy feladat akkor kész, ha dokumentálva van. Én ezt kivenném a kész definíciójából. A user doksin kívül egy ilyen feladathoz nem nagyon kell doko. Architektúra doko? Egy ennyire plain webapphoz?
• Mondjuk azt meg is beszéltük, hogy ha nem adottak a feltételek (mint esetemben) akkor kár is erőltetni a scrumot. Szóval ennyiben maradtunk.
• Egy processz nem hoz tavaszt. Az emberek visszazökkennek a megszokott munkatempójukhoz. Mondjuk ezért kell egy dedikált scrum master, de hát kinek van erre pénze?
• Azért ahhoz bátorság kell, hogy idomítsd a munkaadód magas beosztású képviselőit. Pedig erre szükség van.
• A scrum egy elég szigorú process és a training után már nem tartom annyira minimalistának. Szerintem ez már kicsit ellentétben áll az agile kiáltvány első pontjával.

JUM XV log

Tegnap esti Java felhasználók találkozója. A democamphez hasonlóan viszonylag kevesen voltunk, erre az eseményre viszont sajnálhatja aki nem jött el, nekem nagyon tetszett a két előadás. Mindkét előadást szakmai bloggerek tartották, nekem is itt vannak a google reader végén.

Kovács Richárd: btrace

A btrace egy trace eszköz, olyan mint a dtrace solarison (ez a legtöbb embernek azért nem mond sokat, nem egy mainstream oprendszer még a szervereken sem). Egyszerű kis scripteket lehet rá írni annotációkkal és nagyon kevés kóddal, ami a hotspot vm-hez kapcsolódik és bizonyos esetekben meghívódik. Például csinálhasz egy scriptet, ami a DriverManager.getConnection() metódusra ráakaszkodik. Tipikusan olyan komponensek tuningolásánál jól jöhet, amik nem logolnak és nem mi írtuk. Őszintén szólva tegnap került csak a látőterembe a cucc és most már nem tudom hogy élhettem eddig nélküle :)

Marhefka István: Domain Driven Development

István egy hosszabb előadást tartott a Domain Driven Developmentről, ami egy nagyon elméleti téma de nagyon sok gyakorlati tapasztalat is volt benne. A DTO pattern körül a végén sok kérdés volt, azt hiszem az említett fintorgók tábora nagy számban volt jelen. Én csak akkor szoktam bevetni, ha már nincs más választásom.

Egyébként nem is tudtam hogy van még a munkaadómon kívül teamcity felhasználó itthon. Elég borsos ára van :-)

Ez volt most az időny utolsó jum-ja, szeptemberig szünetelünk és akkor újjult lendülettel :)

Eclipse DemoCamp frissen

Ma este betértem az Eclipse DemoCamp 2009 rendezvényre, szocializálódni és telepakolni a szatyromat információkkal. A hely egy kellemes kis teázó a vár aljában, a hőmérséklet és a népsűrűség is sokkal kellemesebb volt mint tavaly. Persze nem azért, mert kevesebben voltunk :) Kicsit lassan rázódtam bele a hangulatba, inkáb már csak az első előadás után kezdtem kommunikálni emberekkel.

Előadások...

Bocsi, még mielött nekivágok... Nem próbálom hitelesen visszaadni az előadások tartalmát, az biztosan elérhető lesz majd valahol, a saját reakcióimat írnám le ide velük kapcsolatban.

• Nagy Gergely: Dependency Management with Ivy and IvyDE
  Demókkal megtűzdelt előadás volt arról, hogy az Ivy-t hogyan lehet fejlesztőbarátabbá tenni egy eclipse plugin segítségével. Volt is benne apróbb bug, egyszerű javítással. Ahol kicsit nekem elakadt a lélegzetem, az a repository modell volt. Miért lett ez ilyen bonyolult?
  Feltettem az a kérdést, hogy ha "csak például :)" én mavent használok, de a cég egy másik csapata ivy-t és ant-ot, tudnak-e ők nekem olyan mavenes descriptort generálni a ivy dependency-kből, amivel az én mavenes projecteim tudják használni az ivy+ant kombinációval buildelt cuccot. Gergely mondta, hogy nincs ilyen megoldás és Jason hozzátette hogy igazából nem is lehet, a két project classloader rendszere teljesen más és összeegyeztethetetlen.
  
  Kövekeztetés: a Cégen belül ha valaki ilyet használ, az nekem nem segítség. Továbbra is hímezhetem kézzel a pomokat.
  
  
• Jason van Zyl: Next Generation Enterprise Builds: Maven, Mercury and Tycho
  Külföldi sztárelőadóval folytatódott a build eszközök harca :)
  
  Szóval Jason elegánsan átsiklott a maven 3.0 téma felett, ahol én meglepődtem, mert a maven 3.0-ról most hallottam elösször és nagyon érdekelt volna erről minnél több infó, de ennyit kaptunk: minden működni fog a maven 2.x-ből 3.0-on is.
  A m2eclipse alias Tycho igazán meggyőző demó volt. Persze volt benne pár apróbb hiba, mint minden live demóban, de talán végre eljött az ideje, hogy beálljak a sorba és elfelejtsem az 'mvn eclipse:eclipse' parancsot. Amúgy is túl geek-es volt, windowson meg rettenetes.
  A nexusról nem sok újat tudtam meg, mondjuk azon amennyire tudtam rajta tartottam a szemem. Az első pár feature requestet én dobtam be rá és igazából elégedett vagyok azzal amit kaptam ingyen :) A kérdésem az volt hogy mi az, ami kiemeli a nexus-t a maven repository managerek versenyéből. Jason alapvetően a stabilítást és a teszteltséget emelte ki, valamint hogy az archiva igazából bebukóban van.
  További információmorzsa: a nexus a jsecurity-t használja azonosításra és csak 1 hét volt beintegrálni, ami jobb mint a spring-security. Volt nekem is pár problémám a spring-security-vel, de soha nem szúrtam el rá 1 hetet. A rekord egy régi grails-es projectemen volt 2 estényi gubancolás, mert akkor még a grails is gyerekcipőben járt, meg groovy-ban is az volt az első dolog amit írtam. Házi feladat: jsecurity
  
  
  Félig meddig ide tartozik, és a következő blog postom arról fog szólni hogy milyen torkos szívás volt generált JPA kódra írt teszteket futtatni mavennel. Pff, a kódgenerálás a múlt század. Nekem az idl compilerek jutnak róla eszembe.
  
  
• Bánfai Balázs, Török Zsolt: Transition from classroom to real-life software engineering
  Nos ebből a szempontból az én karrierem - ha beszéljetünk ilyenről- nem a szokásos dolog. Soha semmi hasznosat nem tanultam iskolában főleg nem informatikáról, és bár jártam egyetemre, úgy érzem hogy -persze csak intellektuális- pofonokon kívül mást nem kaptam. Persze kell a karó a virág mellé, de hát... kéne a virág a karó mellé.
  Úgyhogy erről kimentem dumálni a teázó elé, aztán pedig hazatekertem.
  

Köszi a szervezésért és a kajáért a B2 International-os arcoknak!

Sziasztok, boldog csütörtököt!