Viszlát

A helyzet a következő: Nem nagyon fogok ide már írogatni, bár aki szemfüles észrevehette hogy így van ez már egy ideje. Nem mentem el Vlagyivosztokba halat belezni, vagy Írországba birkapásztornak (ez az utóbbi egyébként jó ötletnek tűnne). Továbbra is kódolok, hackelek, doksit túrok, szart faragok, bugot keresek, fél napokig szakmai emaileket fogalmazok, ez a blog meg itt egy jó kis információforrás lett 7 év alatt. A C#-s bejegyzés például miatt még mindig rengetegen jönnek, ahhoz képest hogy én meg már el is felejtettem dotnetben programozni.

Viszont olvassátok, linkeljétek, kövessétek a kódzaj blogot, az nagyon hasonló tartalomnak ígérkezik.

JUM XVII.

Kicsit égő hogy már szinte csak a JUM-ról írok, de ez van. A tizenhetedik alkalomnál tartunk. A teremben kb. 40 ember volt, ami már majdnem teltház. Az asztalon az Oracle Java Café-ról ismerős szórólapok. Viczi elmondta, hogy az OJC-n is megemlítették a JUM-ot, úgyhogy mi is megemlítjük őket, kölcsönös a szimpátia, stb. Indultak is az előadások:

Verhás Péter - Business Level Testing

A szervezési részéről megfogva a dolgot azt mesélték el, hogyan lehet az ügyfelet bevonni a tesztelésbe. (Nem az ő feladata, nem ért a műszaki dolgokhoz és nincs is rá ideje.)A tesztelés ne műszaki tevékenység és ne “munka” legyen, hanem “játék”. Ne legyen kötelező, viszont érdekes legyen. Így az ügyfél érdekeltté válhat benne. A bevált eszközeiket említették meg: SoapUI, Confluence és Greenpepper. Erről sajnos technikai részleteket nem árultak el. A IX. JUM-on, -amikor egy előadás hangzott el ezzel kapcsolatban- még nem tartozott a jó szokásaink közé bekérni a prezentációkat, úgyhogy technikai részletekkel most nem tudok szolgálni. Egyébként volt Wiki felület, táblázatok és zöld-piros grafikonok.

Auth Gábor – Android SOAP

Gábor egy open source SOAP kiszolgálót írt Android-ra. Elvileg van már egy, de azt igazából MIDP-re csinálták és nem túl bő a funkcionalitása, nem használja ki kódszinten az Android tudását. Ha bárki csatlakozni akar a projekthez, Gábor szívesen látja. A források elérhetőek webes SVN-ből, Maven alapú a projekt egyébként. Illetve szavazzatok rá a StackOverflow-n. :)

Kovács Richárd – Magyar Tamás – EJB3 vs Spring

Szerintem ez egy zseniális előadás volt. Ricsi képviselte az EJB oldalt, mígy Magyusz zöld ingben a Spring oldalán harcolt. Egymásnak néha beszólogatva gyalogoltak végig a mindenféle szempontokon: UI támogatás, biztonság, AOP, DI, rendelkezésre állás, aszinkron hívások lehetősége. A rendelkezésre állással kapcsolatban megemlítették a Terracotta szervert, ami pénzes (drága) és elosztott Spring alkalmzások futtatására szolgál. A visszatérő mondatrészek a “bármit le lehet programozni” és “az XML az ördögtől való” voltak. Megköveztük szegény “evil singleton”-t is néha. A meccs végén nem volt konkért eredményhirdetés, hanem abban maradtunk hogy ha oda kerül az ember úgyis meglesznek a szempontjai ami alapján dönteni kell.

Hiányoltam egy olyan szempontot, hogy a lokális erőforrásokhoz való hozzáférés. Ebben a Spring nyert volna, mert EJB-be ez nem nagyon fér bele. Márpedig néha még szerveren is szükség lehet USB vagy egyéb lokális eszközökhöz, fájlokhoz való hozzáférésre (pl. kulcsok). Elvileg van rá EJB-ben is valami Connector architektúra, de még nem láttam élő embert aki ilyet programozott volna. Hogy olyat is írjak ami kimaradt, de az EJB nyert volna a grafikus adminisztrálhatóság. Tapasztalataim szerint egy rendszergazdát megnyugvással tölt el, ha van egy felület amit nézegethet és pl. form-okon állítgathat be data source-okat screenshot-ok alapján, alkalmazásokat telepíthet, uninstallálhat. Nos, Spring-ben marad az XML bogarászás.

Felmerült olyan kérdés, hogy használt-e valaki együtt Spring-et és EJB-t amire az volt a gyors mondás, hogy az perverz dolog. Nos, én használtam többféleképpen is.

Annó, az EJB2 idejében használtuk a Spring EJB támogatását, de erre már nem nagyon emlékszem. Olyan is előfordult, hogy egy EJB-s alkalmazás teszteléséhez használtunk Spring-et: összeraktunk egy appContext-et a bean-ekből, amit alkalmazás szerver nélkül lehetett meghajtani.A “legperverzebb” dolog viszont az volt, amikor egy Session Bean-en belül akartunk Spring appContext-et létrehozni.Lett volna értelme, de nem valósult meg.

Szóval ez volt a JUM, legközelebb jövőre.

Ma lesz egy Eclipse DemoCamp valami borozóban, amin sajnos nem tudok résztvenni, mert sok lenne már a jóból, de remélem valaki beszámol majd!

JUM XVI.

Amikor az utolsó pillanatban beestem a terembe hirtelen csak annyit tudtam mondani, hogy wow. Jó sokan voltunk, rekordgyanús. Konferálás kutyafuttában, aztán már nyomta is Balogh Zsolt a Liferay előadást és demót.

A hátsó sorok egyikéből nem nagyon láttam a programkódokat, de a Liferay portletek gyors fejlesztésének és deployolásának hangulata átjött. Új alap portletet és service-et tényleg pillanatok alatt össze lehet rakni. Közelebbről még nem találkoztam a témával, mert inkább önálló webalkalmazások fejlesztésével foglalkozom, úgyhogy nem is ismerem a portál motorok legfontosabb karakterisztikáit. Viszont érdekelne, hogy hogyan illik bele a Liferay a legújabb Ajax-os, vastagkliens Javascript-es, HTML5-ös, REST-es trendekbe. Azt még megtudhattuk, hogy belül Spring-re épül. Jó sokan itt voltak a magyar Liferay-tól, vagy az iLogic-tól, vagy is-is. Junior EE fejlesztőt keresnek egyébként.

Csutorás Zoltán visszatérő vendég. Most a Scrum öt alappillérélől nyomta az előadást. Egész jó volt, a forma 1-es képnél még be is lelkesültem. Szó volt mindenféle dologról, ami szorosan és kevésbé szorosan kötődik a módszertanhoz: a laterális gondolkodásról, gondolati sémákról, arról, hogy miért jó sztoripontokkal becsülni embernap helyett, értékfolyamatról, áramlásról, visszaáramlásról -amikor vissza kell pakolni feladatokat a queue-ba, húzóelvről, kiértékelésről. Nehéz lenne ezt így visszaadni. Lényeg, hogy a 40 perces előadás után a kérdésekkel még jól elvoltunk vagy húsz percig. Így a két előadás ki is töltötte a két órát.

Update 2010.09.23: Éppen elindult az Adaptive Consulting honlapja, rajta az előadás anyagával.

Videófelvétel készült, de azt nem tudom hogy mikor hová lesz kitéve. A slide-ok elérhetőek lesznek a JUM honlapjáról.

Mercurial paranccsor alapok

Egyszer már írtam erről a verziókezelőről. Azóta inkább az SVN felé sodort az élet, de most ismét elővettem ezt a remek eszközt. Az online könyv, amit a múltkor említettem még mindig megtalálható, csak az URL változott: Mercurial: The Definitive Guide by Bryan O'Sullivan.

Egy-két alapkoncepció, amit a könyvből tudtam meg:

• Minden fejlesztő gépén van egy history-t tekintve teljes mélységű saját repository. Egy repo-t létrehozhatunk kézzel, de leklónozhatunk egy másikat. Amikor becsatlakozunk egy projektbe, tipikusan leklónozunk valami központi szerveren lévő repo-t. (Mert központi szerver azért itt is lehet.)
• A projekten belül a .hg könyvtárban vannak a Mercurial dolgai, a többi mind a miénk, nem szemetel bele. Ez utóbbit hívják 'working directory'-nak.
  
• A branch-elés nem egy kitüntetett művelet, hanem minden egyes revízió gyakorlatilag egy új branch-pont. Az előző ponthoz visszakanyarodva: tetszőleges revíziót le lehet klónozni, nem csak az utolsót.
• A commit csak a saját repo-ba teszi be a változtatásokat (hg terminológiában: changeset). A push paranccsal lehet kiküldeni a változtatásainkat központi repo-ba és a pull paranccsal lehet behozni másik változtatásait.
• Kétféle revízió azonosító van: egy szigorúan monoton növekvő természetes szám ami csak lokálisan érvényes és egy hexadecimális azonosító, ami globálisan érvényes az adott repo-ban. A szám azért nem lenne elég, mert nem biztos hogy minden repository klón ugyanazon az úton, ugyanannyi változtatással jut el egy állapotig. A hexa kódra kell hivatkozni tehát, ha másokkal kommunikálunk.
• A .hg/hgrc fájlban vannak az adott lokális repository-val kapcsolatos információk.

Van egy futó Maven projektem, amiből akarok csinálni egy Mercurial repo-t. Beállok a projektkönyvtárba és kiadom hogy hg init, majd pedig azt, hogy hg add, felsorolva a repo-hoz hozzáadandó könyvtárakat és fájlokat. Pl. a Maven projektem esetében: hg add src pom.xml. (Maven-nél az src könyvtárban van minden forrás, a pom.xml pedig a buildeléshez szükséges információ. Vannak még egyéb könyvtárak is, pl. target, de azt nem kell a repo-hoz adni.) Végül pedig hg commit.

Ilyenkor feljön egy szerkesztőablak (nálam notepad) amibe beírhatom a commit comment-et. A szerkesztőablakban HG prefix-szel ellátott sorokban eleve látható néhány igen hasznos információ, pl. hogy mely fájlok változtak. A HG-s sorok a comment-ben nem lesznek benne. Ha nem írok semmit, a commit nem fog megtörténni.

A commit-oló user-t egy fallback mechanizmus alapján találja ki. A legerősebb megadási mód, ha -u kapcsolót használok a parancsban és explicite megadom. Meg lehet még adni a hgrc fájlban és a lánc legvége, amikor a bejelentkezett felhasználó nevét használja.

A hg tip mond információt a legfrissebb revízióról (a tip Mercurial terminológia), a hg log pedig history-t írja ki. Satöbbi. A hg help kiírja a lehetséges parancsokat, a hg [parancs] help pedig az adott paranccsal kapcsolatos tudnivalókat.

De mi van ha meggondolom magam és mégsem akarok Mercurial-t használni? Kitörlöm a projekt home-ból a .hg könyvtárat (esetleg előtte kiadom a hg revert -ar 0 parancsot ami visszaállítja a working directory-t az eredeti állapotba, majd egy commit-ot) és kész. Nincs szemét sehol máshol, mindenféle alkönyvtárakban.

Azért mégiscsak írogatok az Eclipse pluginekről is:

A HGE Eclipse plugin is megvan még amit a múltkor próbálgattam, de már átköltözött a SourceForge-ra, összenőtt a MercurialEclipse nevű pluginnel és MercurialEclipse néven fut tovább. Ja és mellesleg az Intland fejleszti, aminek erős magyar gyökerei vannak. Amikor installálom a plugin-t az Eclipse-be, be lehet jelölni hogy Windows binaries-t is hozzon le. Ha nincs külön installálva Mercurial akkor érdemes, mert azt később fel lehet venni a path-ba (az eclipse/plugins könyvtár mélyén van egy közönséges Mercurial disztribúció) és ha a plugin zavarba jön, lehet kézzel kiadni parancsokat. Nekem szükségem is volt rá mindjárt az első kanyarban.

Melegvan

Péntek délutáni szösszenet a hőségriadó tiszteletére, külön dedikálva azoknak a döntési pozícióban lévő vezetőknek, akik légkondícionált helyiségben ülnek, a beosztottjaik viszont nem.

24 fok Celsius Valahol -tökmindegy hol- azt olvastam, hogy nagy átlagban ez az optimális hőmérséklet irodai munkához. Induljunk innen, vegyünk egy átlagos kontinentális éghajlaton élő irodai stábot, legyenek mondjuk szoftverfejlesztők. Mindenki serényen dolgozik relatíve maximális produktivitással. Aztán kezdjük emelni a hőmérsékletet és nézzük meg mi lesz.

25 fok Celsius Nem nagyon történik semmi, talán egy-két ingujj (ingujj?) felgyűrődik vagy egy-két tized százalékkal megnövekszik a folyadék fogyasztása az embereknek, de alapvetően marad a maximális produktivitás. Csattognak a billentyűk, pörögnek az agyak.

26 fok Celsius Gyenge hatékonyság-csökkenés figyelhető meg. Bonyolultabb kódrészek, mint például a párhuzamos szálkezelés, nem sikerülnek olyan jól, vagy kicsivel több idő kell a lefejlesztésükhöz. Az emberek többsége nem foglalkozik a körülmények változásával, de a szűkebb toleranciaküszöbbel rendelkezők szóvá teszik, hogy "gyerekek, nincs itt qrva meleg?"

27 fok Celsius A produktivitás érezhetően hanyatlani kezd, nemcsak azért mert az emberek kezdik kényelmetlenü érezni magukat, hanem a kreativitásuk egy részét a körülmények javítására fordítják, úgymint árnyékoló, légterelő és ablakkitámasztó eszközök barkácsolása irodában fellelhető alapanyagokból (iratok, gémkapcsok, számítógép alkatrészek). Ha van klíma de nem csinálja az elvárt hőmérsékletet, szükségképpen kialakul az eszmecsere a működéséről, elkezdődik a csesztetése, megindul a nyitott ablak vs légkondi vitaparti.

28 fok Celsius Az irodában mediterrán hangulat kezd úrrá lenni a testek kipárolgása és (jobb esetben) a fokozott illatosítók használata miatt, de mivel olyan emberek vannak összezárva, akik között a szexuális vonzódás nem értelmezhető -legalábbis nem egy teljes gráf formájában - ez nem egy szórakoztató környezet. A figyelem elkalandozik, megszaporodnak a beszédtémák: Miért nem működik rendesen a klíma? Miért nincs egyáltalán klíma? Vajon egy klíma, vagy legalább egy ventillátor fogyasztásának költsége hogyan viszonyulna a termeléskieséshez? Elégedett-e az ember a munkájával és a fizetésével? Aki elégedett az még rendesen dolgozik, legalábbis próbál.

29 fok Celsius Tiszteletem a bányászoknak, öntödei munkásoknak, építőmunkásoknak, tűzoltóknak, meg akikek kihagytam és melegben kell dolgozniuk. Szerintem fizikai tevékenyégnél a szervezet valami másik üzemmódba kerül, valahogy jobban el lehet viselni a meleget. Talán azért mert van valami légmozgás. A székbe ragadva viszont érzem ahogy nagy kövér izzadtságcseppek gyülekeznek a hátamon és néha egyik-másik legurul az alsónadrágomba. Izzadás közben azon gondolkodom, hogy vajon büdösebb vagyok-e mint a szomszédom és hogy ilyen hőmérsékleten bizony a kisgatya az adekvát viselet. Otthoni melónál ez nyilvánvaló, azzal a kitétellel hogy ott nem pörgeti magát azon az ember, hogy miért nincs klíma, valamint bármikor vehet egy frissítő hideg zuhanyt. Visszatérve az irodába: már az igazán motivált emberek sem tudnak hatékonyan dolgozni, a többiek meg csak pöckölgetik a feladataikat.

30 fok Celsius Zsírtól csillogó bőrű és csatakos szőrzetű homo sapiens példányok próbálkoznak a rájuk osztott feladatok megoldásával egy trópusi klímájú helyiségben. Produktivitásról nincs értelme beszélni, mert a cél egyre inkább az életfunkcióik fenntartására koncentrálódik, valamint bizonyos egyedeknél elrévedő tekintetek figyelhetőek meg, ahogy az elkövetkezendő hétvégére, szellőre, vízpartra, vagy éppen egy jó hideg fröccsre koncentrálnak igazi szódával, hatalmas buborékokkal, száraz fehérborból, üvegpohárból, fák alatt árnyékban, kockás terítős zöldre mázolt vasasztal mellett fogyasztva.

Egészségünkre!