2011. december 21., szerda

hype-görbék

A múlt héten a google publikálta a google zeitgeist oldalt. Kiválogatott top keresések igazából a hirtelen emelkedések voltak, a folyamatosan nagy forgalmat generáló kulcsszavak mellett igazán jelentéktelennek tűnnek, ha összeméred őket. Tanulságok:

  1. Bulvár témáknál egyetlen dolog érdekel több embert: a pornó.
  2. Ezen belül nem tudom megállapítani hogy mi miért lett falkapott. Steve Jobs-on kívül ezekről az emberekről még az életben nem hallottam...

De hamár google trendsnél tartunk, pár másik trendet is akartam mutatni a szociális hálók világából.


iwiw: 3-4 év emelkedés után most már második évben zuhanórepülésben van az iwiw népszerűsége. 


Nem hiszem hogy meg tudnák állítani ezt a bukást, pláne nem a döbbenetes mennyiségű bannerrel és egyre nehezebben átlátható felülettel. (legalábbis ha félévente egyszer bejelentkezek)



Myspace: Az elöregedés elörehaladottabb állapotában van. 
És megintcsak valami kárörömet érzek a dolog miatt. A világ legrondább weboldalai tűnnek majd el, ha a myspace meghal egy napon. Ezt a dolgot az iwiw is megirígyelte a myspace-től, de szerencsére addigra már a kutyát nem érdekelt az egész.



Facebook: szintén 3-4 év nagyon komoly emelkedés után, de nekem úgy tűnik, hogy ez az első év stagnálás.
A facebook azért érdekes, mert mindenhova beintegrálta magát, és egészen ügyesen csinálták. Websiteok milliói építenek valamilyen facebook funkcióra. Pl a like. Vajon ez megakadályozza majd a bukást?
Vagy az hogy kiregisztrálni nehezebb mint egy kötélen egyensúlyozva adóbevallást kitölteni? (A szar nyomtatványkitöltővel akár.)
Nagyon kiváncsi vagyok, hogy mit látok majd ezen a görbén jövőre. Most azt tippelném, hogy esést. Valahogy most elérte a csúcsot, kaptak érte oszkárdijat, címlapcikket a times-ban meg pármilliárd dollárt és kész, leereszt a lufi.


Google plus: a forradalom érdeklődés hiányában elmarad
Ezt mondjuk most még korai temetni, de 1 év múlva már valószinűleg nem lesz az.

Ami nekem nem tetszik a szociális hálók világából az az együttműködés és nyíltság tökéletes hiánya. Ez a google-plusra is igaz. A buzz megtörte kicsit a jeget ezen a téren, de ez a projekt már alulról szagolja. A jelenlegi helyzet ugyanis az, hogy a google nem csak az apit gyalulta le és a gmail-ből szedte ki, de google plus oldalakról is eltüntette. Szóval valószinűleg a legtöbb a kisérleti szerverem merevlemezén maradt meg belőle. Majd megpróbálok valami tréfás grafikát kerekíteni belőle (illetve bárkit érdekelne egy ilyen project?)

Szóval úgy tűnik a "social web" végre a zuhanórepülés státuszba kerül. Ha hihetünk a hype görbének, most egy recesszió után a produktív fensíkra kerülhet a technológia. Vagy egyszerűen csak megdöglik és kész :-)

2011. december 2., péntek

Java kétségek

A múlt héten két ismertebb java podcast, elösször a basement coders, majd a java posse is azzal a kérdéssel foglalkozott, hogy vajon van-e jövő a java programozásban. A basement coders egyszerű választ adott, had fordítsam le magyarra:
Java programozással több pénzt lehet keresni, mint python vagy ruby programozással. Ebből a pénzből lehet piros ferrárit venni, ti meg python köcsögök biciklizzetek...
Söt -ezt is elmondta az arc- a legkirályabb cobol programozónak lenni mert abból már nemcsak ferrárit, de akár űrhajót is vehetsz, saját parkolóval az ISS-en. Szivesen pofánvertem volna, ha lehetne remoteból is, viszont sajnos jól mondta. A pénz jelentős motiváció ha munkáról van szó, és pedig munkáról van szó. Azt azért nagyon sajnálom, ha egyeseknek ez az egyetlen motivációjuk.
A java posse azért kicsit intelektuálisabban közelítette meg a kérdést, ennek megfelelően a véleményüket nem tudnám pár sorban összegezni.

De a lényeg elég pofonegyszerű. A java közösség nagyon elbizonytalanodott az utóbbi 2-3 évben. Ez nem is igazán most kezdődött:
  • Az utóbbi 2-3 évben elterjedt egy csomó alternatív JRE nyelv: groovy, scala, clojure. A groovy persze itt van már jó 6-7 éve.
  • Már korábban elterjedt egy alternatív alkalmazásfejlesztési módszer az Enterprise cimke nélkül. Ez a lightweight és az enterprise nem nagyon fér meg egy cimke alatt.
  • Az Oracle opensource stratégiája nem mindenkinek tetszik. Meg hát nem csak az opensource stratégiája nem, de a Sun alkalmazottak jó része is elmenekült az egyesülés után. Az Oracle pereket és jogvitákat hozott, nem valami olyasmit, ami nagyon hiányozna bárkinek is.
  • A java nyelv fejlődése nem a régi, a java 7-re 5 évet kellett várni (és még mennyit kell majd) és ami benne van az hát elég szerény. Azért remélem ezen a téren lesz még javulás, ha az Oracle nem vágott volna ki egyes speckókat a java 7-ből, még ennyi se lenne. 5 évig vártunk a clojure-kre és nem lett belőle semmi. Hatalmas meglepetés lesz ha valaha egyszer meglesz.

2011. december 1., csütörtök

timetraktor

Sajnos nem láttam még értelmes timetrackert, pedig láttam néhányat. Például a D-nél egy fél évre lehalt a timetracker szervere. Amikor visszajött, megint kérték mindenkitől, hogy visszamenőleg is írja be. Fél évre visszamenőleg :-) Az egyik tesztelősrác összeütött egy zseniális tesztet, ami kitöltötte autómatikusan. Innetől a bürokraták megint boldogok voltak. Ennyi kellett csak hozzá! Az üzemeltetőknek ennél sokkal durvább volt, nekik 10-15 percenként be kellett írniuk, hogy mivel foglalkoznak. Szintén bevetették a saját megoldásukat, az egyik csákó ott egy pythonos GUI-t dobott össze (egész profin nézett ki), ami bár felpopuppol neki időnként, de volt rajta egy gomb, hogy "The same as previous". Ez bemásolta az előzőt és el is tünt az ablak azonnal.
Klassz megoldások.
Volt egy saját megoldásom is. Nem klassz, csak vicces: egyszerűen csak abbahagytam a timesheet írását - ez amúgy jellemző rám, nekem tavasszal se az adóbevallás jut eszembe. Eredmény: semmi, a következő 2-3 évben senkinek sem tünt fel. Azaz valószinűleg ez egy riport volt régről, amit már senki sem olvasott el amikor ott dolgoztam. Pedig egész sok időm került elba...ra ott. Mellesleg a projectem se volt felvéve, szóval úgyis csak kamuzni tudtam volna benne.
A jelenlegi timetrackernek még kell valami hegesztés. Azt látom hogy sikítanak érte, ha nem töltöm ki, de akármi is lehet benne. Például egy irodán kívüli munkanapot beírtam, és szóltak hogy írjam be hogy mikor jöttem és mikor mentem. De hát nem jöttem be, nem mentem el, egyáltalán nem voltam itt. Akkor mit írjak be? :-) Akármit. Az jó, mert az nagyon könnyen automatizálható.

Én ezt tartanám értelmesnek:
Az idő nem számít, gazdálkodj vele úgy, ahogy tudsz. Csinálj valami értelmeset, vidd elöbbre a projectet.

A szoftverfejlesztés nem gyártási folyamat.

2011. november 29., kedd

Java vs Oprendszer

Ma a gerrit-ről volt szó ebéd elött egy megbeszélésen, az egyik srác itt keményen próbálja betolni a fedora fejlesztői infrastruktúrára, hogy lehessen használni, de nagyon nehéz dolga van. Az előadás második felében tulajdonképpen egy vita bontakozott ki, hogy miért ilyen rohadtul nehéz java szoftvereket a linux disztrókba bejuttatni. Annyit elmondtak, hogy nekik újra kell fordítaniuk a forrásból a szoftvert. Ugyanaz a jar/war file lesz a végeredmény, de nekik akkor is újra kell fordítaniuk. Ezzel eleve van problémájuk, mert a GWT-hez van valami speciális dependency, amit alig tudnak megoldani. - kicsi flame szál a gonosz gúgliról. Aztán meg a fedorának nincs is policy-je a java war fileok telepítésére. Szóval egyhamar nem is lesz ilyen.

No eddig az, hogy a linuxosoknak mi a problémájuk a java programokkal. Nézzük csak nekem mi bajom van a linux-szal, annak ellenére hogy önként évek óta semmi mást nem hajtok...
A linuxokba örökké idióta kiherélt java futáskörnyezeteket telepítenek. A gcj egy tragédia, körülbelül semmi sem működik korrekten vele, az icedtea kicsit jobb, de konkrétan pár jboss termék is anyázik rá, ha azon indítják el. Egy új gépet mindig úgy kezdek használni, hogy leszedek egy használható sün/oracle jdk-t és mavent. Az már nem is érdekel érdekel , hogy yum-mal vagy apt-tal telepítsek jetty-t.

A java úgy indult el, hogy egy teljesen oprendszertől föggetlen nyelv és futáskörnyezet. Persze a linuxos rendszergazdák jobb szeretnének oprendszerbe integrált csomagokkal foglalkozni. A java viszont még mindig oprendszerfüggetlen és a szoftverfejlesztők nem igazán foglakoznak azzal, hogy akármilyen operációs rendszer vagy disztribúcióhoz csomagolják a cuccukat. Valljuk be elég sok meló lenne solarisra, debianra, ubuntura, fedorára ésatöbbi  linuxra is külön csomagokat legyártani.

Kicsit megpróbálok elmerülni a rpm/deb packagelés és a linuxerek lelki világába, hátha meglátom a fényt az alagút végén. Ehhez valószinűleg most vagyok a legjobb helyen :-)

Egyébként visszatérve a gerritre: hogy lehet hogy GWT-vel csinálják és mégis ilyen szarul néz ki?

2011. november 27., vasárnap

VDay 2011 Budapest

Pénteken Budapesten voltam a VDay konferencián. Ingyenes konferencia létére marha jó, minőségi konferencia volt. Nulla bullshitelés, live demók és valós tapasztalatok, nem pedig marketing-fényezés. Gondoltam röviden beszámolok azoknak, akiket érdekelt volna de nem tudtak eljönni.

Klock László - Amit tudni akartál a vShieldről de soha nem merted megkérdezni

A vShield architektúrális felépítéséről és történetéről, biztonsági hibáiról. Hát ami igaz az igaz, rendesen le lett szidva a vShield. A hibák súlyát átérzem, de nem nagyon tudok hozzászólni mert soha nem használtam. Na és persze nem jött meg a bátorságom az előadástól.

Zrubecz László - VmWare vCenter Server Applience - vCenter linuxon

Másik VmWare technológia, amivel soha nem foglalkoztam :) Ezt tudtam meg róla: már régebben volt egy ilyen szoftvere a VmWare-nek, de abbahagyták és Windows-on árulták inkáb. Most, hogy a Microsoft inkáb a Hyper-V-t szereti, a VmWare is újragondolhatta a stratégiáját és most előjöttek újra a linuxos termékkel. Ez tulajdonképpen egy java-s webapp tomcaten (szóval ha egy ici-pici időt rászántak volna, mehetett volna ez a termék egyébként) alatta DB2 adatbázissal. Na ezen nem csak én buktam ki, hanem kábé mindenki. A DB2-vel horror-élményeim vannak. Láttam már mindenféle adatbázis szerverből hardware meghibásodás nélkül hanyattfeküdt példányt, de DB2-ből láttam a legtöbbet ahhoz képest hogy mennyire ritka egyébként.
Nos emellett a vCenter linuxos verziójának volt pár elszúrt része: iptables üresen, install csomagok rajtahagyva, statikus méretű partíciók a lognak és idióta syslog setup az stunellel. Hát, elég sok munkát ad még egy embernek ez a cucc, mire tényleg használhatóvá válik. De legalább van, a következő verziókban remélhetőleg meghallgatják a felhasználók imáit.

Lajkó Attila - A Red Hat Enterprise Virtualization 3.0 újdonságai

Ez a prezentáció érdekelt a legjobban (ugyanis ezen a szoftveren dolgozok napi 8+ órát). Kicsit mosolyogtam magamban amíg Attila a screenshotokat mutogatta, mert tudtam hogy a windowsos (.Net-es) user interfaceről készült képeket látjuk, egy ponton Attila ezt meg is említette. Na ekkor egyszerre 3 különböző embertől hallottam valami olyasmit hogy "Pffff..." :-D Hát ez van, de persze jön a szép GWT-s felhasználói felület, a srácok ott írják elöttem. Amúgy az újdonságok: multi level administration, host hooks, rest api, satöbbi. Nekem kicsit hiányzott az oVirt az előadásból, de nem kellett arra se sokat várni.

Kunszt Árpád - IPv6 biztonsági kockázatok

Hát, mégegy előadás, amintől okosabb és boldogtalanabb lesz az ember. Pár demóval (pl hup.hu hijack) megfűszerezett beszámoló. Nem szivesen lennék hálózati rendszergazda, de tágult a tudatom.

Deim Ágoston - Futás a végtelenbe

Ago eredetileg egy munkatársával ketten akarta bemutatni linuxos és windowsos virtualizációs megoldásokat, kvm vs hyper-v. A kolléga viszont beteget jelentett, így csak kicsit lettem okosabb a Hyper-V-vel kapcsolatban (sebaj, úgyse veszek windowst) jópár élő demót láttunk viszont a kvm parancssori és grafikus felületeiről. Egy ponton Ago az oVirt-et is megemlítette (Köszi Ago!), mint érdeklődésünk potenciális célpontját, amennyiben elég bátrak és türelmesek vagyunk hozzá. Azért ne aggódjatok, nagyon dolgoznak rajta a srácok, lesz packagelve mindenféle distróra: ubunturól, gentoo-ról és suse-ról tudok. (a fedora _nyilván_ beleértendő :-) ) Szóval csak a nagyon egzotikus disztrókra kell sokat váni talán.
Ago előadása egyébként talán a legszórakoztatóbb volt pedig a többi előadó is jó szöveget nyomott. Például amikor su - után mégse kért jelszót a szerver, de Ago elkezdte begépelni a jelszóként használt trágár szót a kivetítőre párszáz ember elött, az elég tréfás volt :-)

Egyéb

Több előadó használta az "Enterprise" szót pejoratív értelemben. Ezt meg tudom érteni. Sajnos viszont a java programnyelvet is lenézően említették. Szomorú, nem kellene, hogy így legyen. Az hogy java-ban programozunk, nem jelnti azt hogy totál idióták vagyunk. Legalábbis azt még nem.

Volt gépmutogató asztal, az Inteles srác mutogatta a félelmetes virtualizációs célszervert, amibe egy unitba 16 core és 196 GB memória passzol, és persze 6 unit fér el benne. Közös SAS diskarray és beágyazott management rendszer. Szóval egy atomerőmű. Gondoljatok csak bele mennyi passziánsz futhat ezen, már alig pármillió forintért.

A szomszéd teremben esküvőipari konferencia zajlott. Gázul hangzik, remélem soha nem leszek az ügyfelük.

Valamint baró jó volt a hazai kaja. A csehek nagyon tudnak élni de én a szakácstudományukat nem tudom annyira értékelni :-) Ezt ne mondjátok meg nekik! :-D

2011. november 12., szombat

Virtualizáció határok

Mindenki virtualizál és szerverkonszolidál ésatöbbi ésatöbbi... Pár ötlet arra, hogy mit ne virtualizálj :-)


  1. Olyan szolgáltatásokat, amikre a hostjaid építenek, azt elég rossz ötletnek tűnik virtualizálni. Igazából marha fontos, hogy a virtuális és a fizikai gépeken futó cuccaidat elkülönítsd egymástól és a fizikai gépek közül azok, amik a virtuális gépeket hajtják (hostok) sehogy se függjenek azoktól a szolgáltatásoktól, amiket a virtuális gépek adnak. Ez remélem logikusan hangzik.
    Példák: DHCP, TFTP, DNS, Proxy, satöbbi.
  2. Többnyire az IO-intentzív appok, adatbázisszerverek tipikusan, ftp, nfs szervereketet nincs nagyon sok értelme virtualizálni, mert az IO sebesség a virtuális szervereken nem különösebben jó. Amennyiben pl valami teszt instance a MS SQL Server leges-legújabb verziójának, akkor persze oké, csak hogy kipróbáld hogy műxik-e.
    Ha nem nagyon számít, hogy milyen szoftver van azon a szerveren (ftp, nfs) vagy a kliens akármit tolerál (pl hibernate vagy más JPA esetében az adatbázisok is ilyesmik lesznek) akkor értelmesebb a fizikai vason futó akármit használni a virtuális szerveren futó űberspeciális verzió helyett.
    Amennyiben van fizikai vason futó szolgáltatás persze.
  3. A virtualizáció egy apró kamuról szól. Több memóriát, CPU-időt és merevlemez területet adunk el, mint amennyi tényleg van. Ez nem egészen új az informatika történetében, a virtuális memória is ilyen. Ez többnyire oké és senki sem jön rá, még boldog is hogy ilyen olcsón megkapta. Addig tart a boldogság, amíg egyszerre nem akarják kihasználni a nem létező részt is.
    Emiatt olyan dolgokat, amik nagyon határidősek, nem hajthatunk veszély nélkül virtuális szervereken, mert a szomszédaink terheltségétől függünk. Ha éppen beakadt egy végtelenciklus a szomszédos virtuális gépben, akkor emiatt nekünk pl nem jut annyi, amennyit szeretnénk. A teljesítménytesztek meg összevissza mutatnak mindenfélét.
  4. Ha kifejezetten olyan rendszered van, amivel totál lefoglalod előre láthatólag sokáig a szervereidet, a terhelés folyamatos és előre kiszámítható, vagy esetleg a rendszered maga generálja a terhelést (pl crawlerek vagy akár valami JMS sorból jövő feladatok, satöbbi), az app hibatűrő, akár több szervered kiesését is jól viseli, akkor nem tudom a virtualizáció milyen előnyökkel járna. Pl hadoop, cassandra szerverek, egyebek.

Szóval nekem ezek tünnek a virtualizáció jelenlegi határainak és ezek nem igazán múlandóak. De persze egy technológia akkor jó, ha a határait is ismeri az ember és nem csinál vele valami ökörséget.

2011. november 11., péntek

Kormányzat VS informatika

Ma reggel egy e-mailt kaptam az ügyfélkaputól, hogy az APEH dokumentumot küldött nekem. Szívroham és újraélesztés után keresni kezdtem a dokumentumot, sehol. Rájöttem, hogy a pontosan évente 1 alkalommal használt ügyfélkapunk kellene belépnem és ott találom meg a nagyon bizalmas dokumentumot. Nos nézzük, vajon mi is lehet a felhasználónevem... X próba után sikerült eltalálnom, még pár kör, amig lereseteltetem a jelszavam és végre hozzáférek a titokzatos dokumentumhoz, amellyben ez állt:


Tisztelt Adózó!
Ezúton tájékoztatjuk, hogy a 2010. évi személyi jövedelemadó meghatározott
részének 1%-áról szóló 2011. évi rendelkezésében megjelölt, az Szf. tv. 4. §-ába
sorolható (civil) kedvezményezett részére az átutalást az állami adóhatóság
teljesítette.
Nemzeti Adó- és Vámhivatal

Anyátokat.



  1. 2011 van, és annak is már kicsit a végefelé járunk! Közben elköltöztem Magyarországról, eltellt egy nyár, egy ősz, satöbbi. Már ötletem sincs, hogy milyen civil szervezet azonosítóját írtam a lapra.
  2. Miért kell szívatni ilyenekkel a kedves adófizetőt? Nem lehetne egyszerűen csak csatolni az emailhez? Vagy akár beletenni az email szövegébe? Nem kötelező háromszor becsomagolni.
    Az ügyfélkaput tényleg évente 1 alkalommal, adóbevalláshoz használja valószinűleg az emberek tólnyomó része. Másra ugyanis nem nagyon használható.
  3. Ugyanakkor fantasztikus, hogy az APEH 2011 végére eljutott oda, hogy már képes emailben értesíteni az ügyfeleit. Még ha ilyen beteg módon is. Senki ne merje állítani, hogy nincs haladás!


A kormányzatnak még mindig rettenetes szüksége lenne egy usablity expertre. Igazából ezt az alábbit már régebben összeszedtem és itt várt hogy egyszer meggondoljam magam és mégis kitegyem.

A kormányzati informatika gubancai

Amikor a kormányzat kijön egy új informatikai projectjével, ilyen tipikus reakciók voltak az utóbbi tizenakárhány évben:
  1. mit tud: semmi érdekes, semmi hasznos
  2. kitudódik a költségvetése: döbbenet, botrány, klónok háborúja (ahol a klónok persze rendesen lealázzák az eredeti rendszert)
  3. hosszú távon vissza az első ponthoz.
    Van más dolgunk is, meg ezt a pénzt már akkor elbuktuk amikor befizettük az adót.
A saját reakcióm még az mellette, hogy leég a pofámról a bőr, amikor ezek történnek, mert én is dolgoztam ilyen kormányzati projecten. És ti is, legalábbis néhány volt kollégámról tudom, hogy néha beleolvas a blogomba.
Szóval arra gondoltam, hogy összeírnám azokat a javító szándékú ötleteimet. Amúgy a kódot Auth Gáborék csapata már régen lenyugdíjazta szerencsére, úgyhogy én semmi titkos információt nem tudok.

Szóval:
  1. A célt az határozta meg, hogy mit szerentne a miniszterelnöki hivatal akármelyik illetékes bizottsága a weboldaltól. Semmi kapcsolatom nem volt soha az MEH illetékesekkel, de nekem nagyon úgy tűnt, hogy hétköznapi internetes járókelőket nem kérdeztek meg arról, hogy mit szeretnének a kedves kormányuktól. - Amúgy a megkérdezettek több mint fele azt mondta volna hogy csak rohadjon meg és kész, de a maradékból biztos le lehet szűrni valamit.
  2. A választási ciklus diktálta a fejlesztés ütemét és ezt senki se titkolta. Szerintem ez már szar, de a szó technikai értelmében még lehetne tortát csinálni belőle, ha nem 3 hónappal a döntő ütközet elött kezded el a halálcsillagot építeni. Természetesen halálcsillag volt a terv, nehogymár szakadt szputnyikot csináljon egy komoly kormány. Halálcsillag építéséhez legalább 20 év kell a CERN szerint is és a Lucasfilm szerint is. Ha nem is 20 év, de azért 6-9 hónap biztosan kellett volna ahhoz a fejlesztéshez. És hát kellett is végül.
  3. Integráció és integrálhatóság teljes hiánya. Pl a saját azonosítási rendszer (ügyfélkapu) amit csak a kormány használ de ők is csak nagyon limitáltan és jobbára nem tudsz vele semmit se csinálni azon kívül hogy feltöltöd az adóbevallásodat. Azzal a botrányosan szar swinges nyomtatványkitöltővel, ami ontja magából az érthetetlen hibakódokat és amibe saját XML parsert írt valaki!
  4. Publikus webes programozó interface? Bármi érdekes, amivel lehet játszani annak, akit érdekel. Például a hivatalkeresőhöz akár? Hallottatok ti már ilyenről? Egyébként pl a hivatalkereső megbízható adatokat nem igazán szolgáltatott.
  5. 3 teljes újraíráson ment át a rendszer, egyik sem adott hozzá lényeges újdonságot az előzőhöz. Csak egyszerű from scratch, project reset. Talán még el is vettek, leszedték a kommentelhetőséget mert csak az anyázás ment, de még az is csak elhanyagolható mértékben. Alig maréknyi ember alkotta a közönséget.
  6. A költségvetésről nekem úgy tűnt (konkrét számadatoknak szerencsére nem vagyok birtokában), hogy egyszer sikerült erre a projectre pénzt szerezni és gyorsan azt a pénzt el kell költeni, vagy különben vissza kell adni. Amiből egyrészt a jól ismert waterfall modell lett, másrészt meg ott lett hagyva a rendszer hogy na most "kész" és gondoskodjon önmagáról - ugyanis elfogyott a pénz.
    Harmadrészt pedig pazarlás lett belőle. Az erre vonatkozó számokat úgy nagyságrendben mindenki jól ismeri. Ez olyan, mintha január elsején kapnád meg az egész éves fagyipénzed és január 30.-án lecsekkolnánk hogy mennyit költöttél belőle, látják hogy semmit és akkor visszavonják.
  7. Összeszedetlen csapat. Csak ehhez az egy feladathoz szedték össze a csapatot és aztán szélnek is eresztették. A következő projecthez kerestek másikat. Forming, storming, performing... Jó ha az első pontig eljutottunk.

Nem az volt az oka, hogy rossz programozók csinálták.

2011. november 9., szerda

oVirt @ Budapest

November 25.-én (péntek) lesz Budapesten a vday konferencia, amin Lajkó Attila, az ULX embere fog beszélni a Red Hat Enterprise Virtualization 3 (ahogy mi ismerjük RHEVM, de ne lepődjetek meg rajta, ha nogah, vdc, rhev vagy egyébb elnevezéssel találkoztok bárhol benne) újdonságairól. Remélem nem lövöm le az előadó egyetlen poénját sem, de az egyik újdonság az, hogy most már nyílt forráskódú oVirt néven. Az IRC csatornákon komoly tevékenység zajlik, vannak akik más rendszerekre (pl debian) csomagolják, sokan tesztelnek, satöbbi-satöbbi.
Ingyen konferencia, de több nagy játékos lesz jelen: Vmware, Microsoft, Novel, Citrix - szóval remélem nem lesz marketing bullshot. Annyira bízok benne, hogy én már be is regeltem, és kaptam rá egy munkanapnak számító napot. Biztos móka lesz megnézni hogy más milyennek látja a rendszert.
Ha jöttök, majd fussunk össze!

2011. november 7., hétfő

Favicon

A banános favicon tisztelgés 11 évvel ezelötti főnököm elött, akinek határozott véleménye volt, hogy a programozó egyfajta majom. Így is hívott minket, hogy majomcsapat. Messze túltett az én halálcsillagomon, a "törpök életén" meg a többi közhelyeimen, ő ha beszélt, percenként kétszer biztos bevágta. Körülbelül úgy használta, mint a mélyen művelt honfitársaink a B+-t. Bár nem hiszem, hogy mind személyesen találkoztatok vele, gondolom ez az elképzelés senkinek sem új.
Vita tárgya lehet viszont az, hogy milyen ok-okozati összefüggésben áll ez a termék minőségével. Persze nem jó, ha űbermenschnek képzeljük magunkat, de még ha szükséges is némi negatív 'feedback' a munkánkról a helyreigazítás céljából, abban biztos vagyok, hogy ez már kicsit túllő a célon.

Lásd:
Köszi a blogger.com programozóinak, hogy lecserélhetővé tették a favicont :-)

Egyébként az 'I will work for food' eredetileg nem akart utalás lenni a kódmajom életformára. Valami olyasmi volt, hogy az első Sárga-70 túra útvonalára mentem ki útvonalat mérni, toltam a rohadt sárban hegynek felfele a mérőkereket (mint a jól ismert filmben), marha éhes lettem és közben találtam ki ezt a blogot.

2011. október 29., szombat

Cassandra: további kisérletek

Tanulgatok. Már egy pár hete hajtom a cassandrát és igazából egészen elégedett voltam vele 1 node-on. Összetúrtam 30 GB adatot hozzá a netről, meg írtam egy kis crawler jellegű programot, ami folyamatosan túr további adatokat hozzá. Mondjuk napi 2-3 GB adattal nő. Szóval az adatbázisomat szorgalmas írásnak is és olvasásnak is alávetem. Gondoltam kihúzom az adatbázisomat 2 node-ra. Ez valami marha egyszerű dolog. Felstartolsz mégegy processzt mondjuk egy másik gépen, aminek azt mondod, hogy az elsőtől ismerkedjen a cluster topológiájával. Azonnal ránéztem nodetool ring-gel, láttam hogy cassandra úgy döntött, az adatbázisom 40%-át, 9 GB adatot átküld a másik node-ra. Villámsebesen átmásolta, gigabites hálózat van a kettő gép között, sajnos inkáb a vincsi volt a szűk keresztmetszet. Az első érdekes dolog az volt, hogy bár az második node-on létrejött 9 GB, az elsőn nem tünt el. Aztán lekapcsoltam a második node-ot nodetool decommission parnaccsal, elkezdett visszareplkálni az első node-ra. Pár perc alatt kész lett, de ahelyett, hogy az adatbázis mérete megmaradt volna 30 GB, megnőtt úgy 40 GB-ra. Mégegy ugyanilyen kör után már 50 GB körül volt, aztán 60 GB körül. Ami azért bosszantó, mert még mindig csak 30 GB adatot tartok benne :-) Itt már kicsit bosszús voltam és nem akartam tovább rontani a helyzetet, hagytam ott az adatbázist, ahol van. Közben a cassandra őrült módon tekerte a merevlemezt, a crawler futott tovább, én meg elslattyogtam egyet sétálni. Most nem mentem 50 kilómétert, csak a parkba mentünk le. Mire hazaértem az adatbázis mérete visszaesett 30 GB-ra. Akkor esett le, a cassandra gyorsan szedte át az adatokat  a második node-ról, de aztán viszonylag sok időbe tellett neki újraoptimalizálni a saját adatstruktúráját. Szóval erre figyelni kell akkor, amikor a clustert buheráljuk.

A másik számomra bosszantó jelenség az az, hogy startkor valamiért végignyalogatja az összes adatfilet. 30 GB egy gépen az nem valami sok úgy egyébként, de azért nem szivesen várom meg amíg azt mind felolvassa arról az öreg sata vincsiről. Erre a dologra még nem találtam magyarázatot...

Ja és a cassandra nyithatott volna egy saját kis fejezetet a konfigurációs témánkban is, yaml konfig. Hogy szinesebb legyen a kép :-)

Amúgy idáig nagyon tréfás kis adatbázis, jó móka játszani vele. Vettem hozzá könyvet is, hogy jobban haladjak.

Lecseréltem a favicont. Hogy tetszik? :-)

2011. október 19., szerda

multitenancy

Egyik este miután a több munkatársamtól is okosodtam virtualizációról és cloudról, operációs rendszerekről, kicsit már kiégett aggyal ez a történet állt össze a fejemben (bár valószinűleg nem első alkalommal)

Úgy kezdődött, hogy célgép. Mint pl az IBM csodálatos lyukkártyás rendszere még az 1940-es években amivel (a Corporation cimű film, emlékeztek... és más források szerint) oly sok embert továbbítottak a másvilágra. Ezek csak erre az 1 dologra voltak jók, nem volt cserélhető programjuk. Ahhoz képest azért igazán drágák voltak, de még így is sok pénzt takarítottak meg.
Ahogy tellett az idő, az emberek szerettek volna jobb befektetést csinálni, azzal, hogy többféle dologra használják a gépet. Így született a program. Eleinte 1 program futott egy időben egy gépen, de cserélhető volt. Ennél nem nehéz jobbat elképzelni: szeretnénk, ha egy időben egy gépen több program is futhatna.
Hát rohadtul leegyszerűsítve valami ilyen igényből született az operációs rendszer. Persze az OS pár szép dologgal jön még: filerendszer, hogy ne kelljen a disk-kezeléssel a programnak foglalkoznia, felhasználók, I/O, hálózat, felhasználók, memóriakezelés, sorolhatnám... tök jó helyen vannak ott. Kell mind.

Amikor viszont már több felhasználó több programja fut az 1 szál drága vasunkon, akkor igen valószinűvé válik, hogy össze fognak veszni az erőforrásokon. A felhasználók is, de a programok még inkáb. Gondolom nem kell példákat hozni memória-zabáló programokra, vagy CPU-zabólókra. Ez még a kissebbik baj lenne, de a konfigurációjuk is igencsak elburjánzott. Itt példaként említeném a hosts filet, amibe mindenki mindenféle ocsmányságot beletol, amit a DNS admin nem akart megcsinálni. Aztán vannak a szoftver-függőségek, kifejezetten az enterprise genyákon pl az SAP-nek meg az Oracle-nek kötelező valami olyan oprendszert venni, ami tanúsított ésatöbbi. Az adminisztrációval is kezdtek bajok lenni. Szóval oda jutottunk, hogy majdnem minden nagyobb rendszerünkhöz mégiscsak külön szervert veszünk. Bár mostanra nem egetrengetően drága egy szerver, azért mégiscsak drága _minden_ szoftverünkhüz külön szervert venni. Valahogy tényleg egyre több és több szoftvert használunk ahogy egyre több dolgot próbálunk számítógéppel csinálni.

Kis kitérő: amit a java csinál több szoftver-rendszer békés együttélése címén egy VM-en belül az a gyakorlatban ritkán vezet boldogsághoz. Igen, nem nyúlhatsz bele immutable objektumokba, nem babrálhatsz bele másik webapp kódjába, de ennyi és kész. A másik app felzabálja a memóriát vagy agyonhajtja a GC-t, felstartol 1000 idióta szálat, beblokkolja az összes http listener szálat, elfelejti zárni a streameket és kifutsz a file handle-kből, sorolhatnám. Van még itt ez az extrémebb eset is a the daily WTF-ről, nagyon gonosz. Ezer módon lehet az együttélés két java webapp között zűrös. Persze a jó programokra ez nem vonatkozik, de azokkal nincs is semmi gebasz, most a hülyékről van szó. Nem tudom a hülyék többen vannak-e, de azok több időmet viszik el.

A kis kitérő után eljutottunk a virtualizációhoz, ami lehetővé tette, hogy egy vason több oprendszer is futhasson a saját agyontákolt konfigurációival, a összebuherált szoftvereivel és nem vesznek össze, nem is tudnak egymásról.
Egyvalami nagyon nem tetszik még ebben: Rohadt nagy, drága szerverek. Ellentétes az általam tapasztalt valósággal.  Egy hazai Pince Programming Kft-nél, de akár a százmilliós kormányzati projecten is a következőképpen működik a fejlesztői infrastruktúra: a rendszergazditól elkunyizzátok azt a Juliska néni leselejtezett gépét, amit már odacsűrt a kukára de még nem vitték el. Kicsit köhög a vincsi de még megy. Toltok rá Kedvenc Linuxot, Jenkinst, subversiont, gitet, sonart vagy amit akartok, berúgjátok az asztal alá és hajtjátok. Néha a takinéni kirángatja belőle a drótot (miközben letörli a képernyődet vizes ronggyal, pl amivel felmosott), ilyenkor kicsit kurblizni kell. Néha a rendszergazdi ellopja és kidobja megint, a kukásoktól visszaszerzitek. Ez így nektek ismerősen hangzik?

A másik probléma a nagy szerverekkel: egyszer minden gép befosik. Én olyat még nem láttam, ami nem. Jöhettek a legendákkal a befalazott gépekről, amit a nagybátyád unokatestvérének régi munkatársa másodkézből hallott. Amikor a crash megtörténik, nem 1 rendszered fekszik hanyatt, hanem mind. Kellemetlen.

Szóval magánvélemény erről a sima virtualizációról:

  • Szerintem tipushiba 1 böszme nagy gépet venni és arra tenni az összes VM-et. Ez mainframe-szerű maszturbáció. Ott fog állni az összes engineer és fogdossák a nagy gépet hogy jajjdejó. Persze jó én is birom ezeket a nagy böszme dobozokat, de több kicsi géppel jobban jársz teljesítmény és biztonság szempontjából is.
  • Az nagyon fontos, hogy a virtuális gépek ne legyenek szerverhez kötve, mert amikor égnek, együtt megy füstbe a valódi vassal a virtuális géped.
Szóval végülis odajutottunk a cloud-hoz. A virtualizáció csak egy lépés volt és a következő lépés a cloud. Vannak publikus cloud-ok, amik egész olcsón rohadtul nagy számítási kapacitást árulnak. Vannak private cloud-ok, amik a saját vasadon lehetővé teszik, hogy a virtuális gépeidet futtasd.

Ami nekem az egészben furcsa, hogy pl egy virtuális gépen egy java VM-et futtatunk. A host OS is és a Guest OS is virtuális memóriát kezel. Hány layer virtualizáción mentünk keresztül? Meg mennyire is lett ez az egész komplex?

2011. október 17., hétfő

OFF: Döglött méhecske

A múlt héten a google bejelentette, hogy leállítja a buzz-t és pár másik API-ját, mert nem termeltek elég forgalmat. Nem vagyok tisztában azzal, hogy mi az "elég" egy google-méretű galaktikus birodalomnak, de ez nem az első eset, hogy "így jártunk". Néhány példa, amiből tanulhatunk:
  • A wave programot leállították, azóta az apache incubatorban látható (nem akarom olvasgatni, nálam a trehány kód kategóriába tartozik)
  • A translate API fizetőssé vált. A translate nagyon igéretes dolog volt annak idején, de aztán sehova se fejlődött. Ma a google translate a félrefordítás szinonímája, nem olyasmi amiért az ember igazán szivesen fizetne is akár. A translate toolkit is évek óta gondozatlanul áll, pedig az is nagyon hasznos kis eszköz lenne.
  • Többezer feltöltött maplet után a google maps is egyszerűen kidobta azt a soksok időt amit a rá fejlesztők beleöltek, megtartottak pár layert.
  • A google books talán amazon-killer akart lenni. Hát, azt hiszem lecsúszott róla. A book preview azért klassz.
  • A google checkout szintén megragadt amerikában és a britteknél. Akkor meg a boltok nyilván inkáb paypal-hez integrálódnak, az van kb mindenhol. Nem szeretném megpróbálni visszatartani a lélegzetemet addig, amig Magyarországon használhatóvá válik.
  • A buzz-t twitter-killernek szánhatta talán a google. Ha annak szánta, akkor eleve bukásra volt itélve.
  • A google+, aminek a javára kinyírják a buzz-t, alighanem ott lesz valamelyik a jövő évi takarítás áldozatai között. Már most ha bemegyek, a legfrissebb új dolog amit látok talán pár hetes. Jó oké van benne egy-két jó ötlet, amiből tanulhat a lófacebook ha akar.
Szóval ha azt a célt tűzik ki minden új projectüknek, hogy csak akkor tartják életben, ha totálisan átforgatta a teljes internetet és kinyírta a facebook-ot és a twittert, akkor kát a gőzért, egy-két éves periódus után minden projectjüket le fogják állítani. A google+-t is, ez gondolom már most gyanús a legtöbb embernek.

Ebből mindenesetre azt a következtetést vontam le, hogy túlságosan is google-fan voltam idáig. Túl sokat építettem a google szolgáltatásaira és aztán ezeket a szolgáltatásokat a google szépen egyenként kihúzta. Az ember kicsit másra számít egy nagy cégtől. Az nagyon szimpi, hogy a google nem áll be a sorba, nagyon becsülöm érte, de én a jövőben N+1-szer meggondolom, mielött bármilyen API-jukra építek valamit.

Pillanatnyi ötlethiányban szenved az informatika. A social networkok kiábrándulási fázisba érkeztek, Steve Jobs, az apple mágusa meghalt. A microsoft úgy 10 éve nem jött elő semmi újjal. A google nem tud olyan ötlettel előállni, ami túlél egy telet. A sun behalt. Az Oracle képtelen foglalkozni a java közösséggel. Szerintem most kell keresni a következő hullámot. Vajon mi lesz az?

2011. október 11., kedd

Platform

Folyik a platform háború...

A platform filozófia kicsit más, mint a szolgáltatás filozófia. A szolgáltatód ha kifexik vagy nem sikerül egy vitás kérdésben egyetérteni, akkor szépen átmész egy másik szolgáltatóhoz, csókolom. Ilyen pl egy internet-szolgáltató, video-encoder, DNS-szolgáltató. Fáj, nyilván, de pótolható, csak egyetlen dolgot csinált neked, a többi ezret másikat valaki más. Mindenesetre amikor a platformot húzzák ki a lábad alól, akkor sokkal nagyobb gebaszban vagy. A platform egy rakás integrált szolgáltatás. A válogatás többnyire nagyon limitált lehetőség, egy csomagban kapod az egészet és boldogulj vele ahogy tudsz. Nekem ez az ellenszenves vele, én jobban szeretek válogatni.
Azért persze igérik, hogy minőségileg ezek a platformok jobbak, mint amiket összebuherálnak az emberek amúgy. Ez szerintem kb ezt jelenti: az általános problémákat (hálózat-kiesés, adatvesztés, session replikáció problémák, satöbbi) ami mindenkit érint, legnagyobb priorítással kezelik, míg a speciális esetekkel kapcsolatban jó eséllyel magadra maradsz. Ez érthető, ilyen egynek lenni a millóból. Nekem ez őszintén szólva szimpatikusabb is. Nem fognak a management éppen aktuális legmagasabb priorítású projectje miatt speciális httpd url rewrite-okat megcsinálni, senki sem kap külön gépeket, ahol csak az ő cókmókja fut, nem dobnak be egy külön JAR filet valakinek az appszerverbe, csak azért mert szerinte az kell. Mindenkire ugyanazok a szabályok vonatkoznak. A házi-platformok örökké halálra vannak hackolva. Izgalmas proxy beállítások és url-rewriteok, nem is beszélve a összepatchelt appszerverekről, amibe beledobálták a xerces tizezer évvel ezelötti verzióját, mert az jó volt valakinek, a többiek meg majd megszokják. Persze mindegyik PaaS-nak megvan a saját problémája, pl a cron cuccok a gúglinál.

Lényegében nincs más kifogásom a PaaS ellen, csak az a cefet-nagy bizalom és lelkesedés, amivel az emberek belemennek (hype). Ezt a platform kérdést mindenki úgy képzeli el, mint a bal oldali képen (ahol persze ő nem a sikoltozó tinilány a szinpad elött, hanem természetesen szólógitáros énekes rockmetálisten) aztán X hóbap eltelltével baromi sokan érzik úgy, hogy inkáb a jobb oldali képen látható objektumhoz hasonlít a platformjuk.

Platform
Platform
Uram, a halálcsillag platformja támadásra készen áll, várjuk az utasításait.

2011. október 7., péntek

Átkeresztelés

Amíg fordul a GWT-s csoda és újraindul az appszerver, de még nem feküdt meg totálisan a gépem, ezt a kis ötletemet osztanám veletek:

Jó, muszáj a termék nevét beleírni a packagekbe, de ne írd bele se osztályokba, se változókba, adatbázis táblák és view-k neveibe, konfigurációs paraméterekbe ha lehet. Semmibe, amit nem akartok majd átírni minden egyes installációban, amikor átnevezik a projectet. Minnél kevesebb, annál jobb :-)
Olyan projecten dolgozol, amit nem neveznek át? Jajj, dehogynem nevezik. Van, aki semmi mással nem foglalkozik. Majd meglátod! :-)

2011. szeptember 21., szerda

oVirt

A melóhelyi főnököm éppen most jelentette be az oVirt projectet. Ezen dolgozok én is és hamarosan open source lesz. Csak ennyit akartam mondani, mert amúgy ilyen projecten még nem dolgoztam, hogy mindenkinek ott lesz és használhatjátok. Annyi biztos, hogy ebből a szempontból szórakoztatóbb meló. Szóval majd figyeljetek :-)

2011. szeptember 19., hétfő

Átlag

Egy csomó olyan programozóval volt dolgom, akik úgy építettek szoftvert, hogy egy rakás komplexítást toltak bele, amire mindenhol figyelni kellett. Persze ezerszer belebotlottak saját maguk is. A varázsige az volt, hogy a szoftverfejlesztő nagyon inteligens és egyáltalán nem felejtékeny. Legalábbis mindkét képessége az átlag-ember felett van. A botlások alkalmával pillanatra feélretették ezt a feltételezést, és aztán csavartak mégegyet az architektúrán, megint végígtúrták az egész kódot és közben megerősitették hitüket, hogy cefet jó programozók.

Ez a megfigyelés (ami igyekezett objektív lenni, de csak eddig a pontig), és most a magánvélemény. Én ezt kapcsolatba hozom ezeknek a szoftver-projectkenek a problémáival. Azt feltételezték magukról a programozók, hogy nagyon nagyon okosak. És hát kétségtelenül azok is, csak nem annyira, amennyire hiszik. Egészen biztosan feledékenyebb vagyok az átlagnál és talán butább is. Lustaság szempontjából nem tudom hogy állok, annyi biztos, hogy a repetatív munkát nagyon hamar megunom és akár pár perc múlva már sorozatban szúrom el, annak ellenére hogy hamar ráállt a kezem és az elején egész jól ment. Előfordulhat, hogy lusta is vagyok. Szóval én inkáb arra szavaznék, ne építs semmit arra a feltételezésre, hogy zseni vagy és a munkatársaid is mind legalább géniuszok.
És ez a lényeg: a sok magamfajta hülye karbantarthatóbb, átláthatóbb és megbízhatóbb rendszert fog csinálni, mint azok, akik zseniknek hiszik magukat, de nem annyira azok, mint amenyire hiszik. Természetesen ez az igazi zsenikre nem vonatkozik, de idáig a guru egy mitosznak tűnik, soha nem találkoztam guruval. Pedig már tolom egy ideje a szekeret.

Hozzáállás: Én vagyok Gipsz Jakab. Minden fán ilyen terem.

Kicsit emészthetőbb formában egy hasonló vélemény itt: http://97things.oreilly.com/wiki/index.php/Don%27t_Be_Clever
A 97 things nagyon kedves kis gyüjtemény, érdemes olvasgatni. Van pár extra is hozzá, ami a könyvben nincs benne. (Megvan otthon a nyomtatott könyv, példaként arra, hogy CC tartalmat is el lehet adni)

Még egy hasonló lelkületű alapozó itt :-)

2011. szeptember 11., vasárnap

Gyárlátogatás: Logging

A logging megintcsak egy érdekes és gubancos kis szál a java történetben. Nagyon szerény elvárásaim ezek lennének:
  • Legfontosabb: Ha a logging el van csűrve, azért az alkalmazás még csak menjen!
  • Lehessen konfigurálni a logging szintet
  • Lehessen konfigurálni azt, hogy hova menjen a log - többnyire file, valami archiválós megoldással vagy méret vagy idő bontásban, fejlesztőknek stdout, had kapjuk az arcunkba :) Vannak egzotikusabb megoldások is
  • Az nagggyon jóóó, ha nem kell újraindítani az appot a logging konfigurálása után. Ugyanakkor belátom, hogy egy évben csak egyszer van karácsony.
Mostanra sikerült odáig is eljutni, hogy a Logger-t kb így deklaráljuk:
private final static Logger logger = ...kakukk...

Ezt várja el a checkstyle, a PMD és a satöbbi. Nem tűnik nagy dolognak, de pl az avalon framework implementációi még bedobálták volna a komponenseknek egy setLogger metóduson keresztül. Persze nem kötelező így használni :-D

Nekem igazából nagyon szimpatikus ez a private final static dolog. A logger legyen a kód számára elérhető mindig. Ne írhassa felül semmi és ne lehessen null se. Amennyiben sikerült az osztályt betölteni, alighanem loggered is van. Innentől már nagy baj ezzel nem lehet.

Mit kellene logolni?

Hát kicsit izlés-codestandard-hitvita tárgya az, hogy mit mikor és hogyan kell logolni. Én nem hiszek a policy-kben, azt hiszem a józan paraszti ész valami ilyesmit diktálna, ha kellene a parasztoknak bármi ilyesmivel foglalkoznia: logolni azt érdemes, ami érdekelni fog hibakeresés közben, és persze csak olyan szinten, amilyen szinten keresni fogsz. Minden más csak a helyet fogja zabálni a szerveren. A logging frameworkok között enyhe eltérés van a szintek tekintetében. Azt hiszem van, ahol nincs trace szint, hanem debugnál kezdődik. Nekem a nagyon sok szint használata nem tetszik, nem tűnik praktikusnak.

Ja igen, bonyolult és anyázásig menő viták tárgya az is, hogy ha esetleg valami stringet hozunk létre a loggernek, amit logolunk, akkor csekkoljuk-e körülötte a debug szintet egy if-fel. Erre gondolok:

if(logger.isDebugEnabled()) {
  logger.debug("Baromira fajt osszerakni ezt a stringet: "+getTerribleString());
}

Szerintem ezzel a legtöbb alkalmazásban nem lehet mérhető teljesítményjavulást elérni. Inkáb csak a kód komplexitásának növekedését. Illetve akinek tényleg már csak ez segített, annak had gratuláljak a kiválló termékhez.

System.[out|err].println()

Na ez a logging elötti logging volt. Már rég megástuk a sírját, már rég ott térdel a szélén, de még mindig nem húztuk meg a ravaszt. Nagyon sokan használnak még ma is ilyesmit. Ezt azt hiszem korrekt tudatlanságnak és/vagy igénytelenségnek nevezni.
Na jó, szóval ez trehányság, de akkor mit kellene használni helyette? A válasz erre kb 2-3 évente változik akár még egyetlen fejlesztő esetében is.

log4j.properties - köszi Bocinak a megosztásért :)
Log4j

Ha jól emlékszem a log4j volt az első komolyan elterjedt logging api.
A log4j-ről tudni érdemes dolgok 99 százalékát tudod, ha tudsz egy log4j.properties file-t írni. Na, ez az a dolog, ahol kiválló alkalmak adódnak a dolgok elcseszésére: illik nem belecsomagolni a log4j.properties file-t a csomagodba. Ezt azért a mainstream opensource libraryk tudják, de enterprise körökben frekventált elcseszés tárgya. Ez még mehetne a multkori konfigurációs kérdéskör boncolgatásához.

Ennyi: Igen, kell a log4j.properties file - pontosabban jó ha van. De ez a konfiguráció része, nem csomagolhatjuk a kódhoz.

Alternatív...

A log4j sikere után sok alternatív logging api jött. Az alternatívok közül legtöbbet a commons-logging projectet lehetett látni. Ha jól tudom a sikerének oka az, hogy az apache projectekben kötelező (volt?). Ez elég sovány ok :-) Mindenesetre a commons-logging már végülis facade jellegű. Azaz az API mögött végülis valamibe logol bele. Valamelyik másik logging frameworkbe.

java.util.logging

A java.util.logging így visszatekintve rá egy szomorú példa a JCP töketlenségére. Aki ragaszkodik a szabványokhoz, az biztosan használja is, de más okot nem is tudnék rá. Az az egy nagyon tetszett benne, hogy a jconsole-n keresztül lehet babrálni a logging szinteket. Még talán akkor veszi az ember használatba ha valamilyen oknál fogva nem akar semmilyen dependency-t. Ultra-minimalista cuccokhoz, aminek nem kell semmi, csak egy JRE, és megy.

slf4j

Simple Logging Facade for Java. Itt tart a történet. Ma kb mindenki slf4j-vel logol, én is. Egyszer valami podcastot hallgattam ennek az előnyeiről, és ilyeneket említett a csákó, hogy végre Loggernek hívják a loggert, nem Log-nak, mint a commons-logging. Hát ez elég sovány ok azért, ebben azt hiszem egyetértünk :)
A slf4j-nél tipikus elba, amikor valakinek az APIja nem csak a slf4j-api-n dependel, hanem berántja valamelyik logging rendszerhez kötő részét (pl tipikusan slf4j-log4j13-at amikor te már berángattad a slefn-log4j12-t). Ugyanis nem, ezek a dolgok nem férnek meg békésen egymással a classpathon. Természetesen ez egy gyógyítható betegség (pl maven dependency exclude), de néhány bosszús pillanatot sikeresen össze tud hozni.

...és végül: log4j :-)

Akárhogy is, de az összes konfigurációban, amit eddig láttam a facadeken keresztül a végén a logging üzeneteidet a log4j kapja meg, és file-be nyomja be. Az üzemeltető csapatok a log4.properties-t keresik, ha debugolni kell valamit. Ennyi.
Szóval ebből a szempontból a történet marha hosszúra nyúlt, de a lényege nagyon keveset változott.

A java elött

Nem tudom mennyire rendelkeznek a java elődei logging apival, amennyire emlékszem amit a CGI scriptekben stderr-re írtunk, na az volt a log, a stdout-ra, na az meg a kimenet. Nem túl kultúrált. A C kultúrám megintcsak félelmetesen alacsony, C/C++-ban úgy logoltunk, hogy precompiler direktívaként megadtuk a log szintet. Nyilván újrakonfignál újra kell fordítani, ezt nem nevezném valami baráti megoldásnak.

Update: átneveztem ezt a postot, hogy kicsit kiemeljem azt hogy nem arról szól, hogyan kell logolni, hanem arról, hogy miket láttam tényleg. Többi ilyen.

2011. szeptember 2., péntek

OFF: Red Hat és Brno

Kicsit OFF. Nem szoktam fejvadászattal foglalkozni, de egyrészt sokan kérdeztetek emailben, linkedinen, satöbbin, hogy milyen itt és keresnek-e embereket, másrészt a HR-es lány is nagyon érdeklődik a magyar szakemberek iránt. Gondoltam akkor egy kicsit megpróbálok segíteni:

A brnoi Red Hat nagyon keres

  • JAVA programozókat, főleg GWT-s arcokat nagyon. (Itt mellettem dolgoznak a GWT-s arcok velem egy projecten, igyekszek kicsit ellesni tőlük valamit :)
  • QE pozíciók: rengeteg embert keresnek nagyon sokféle munkára és beosztásba script buherátorokat, bash, perl, python
  • Külön és kiemelten ruby arcokat

Ennyiről tudok én, de ez valószinűleg nem a teljes lista. Ha érdekel, akkor vagy dobj nekem egy emilt (firstname.lastname@gmail.com), vagy kérdezd közvetlenül a HR-es lányt, Tylert.

Kitelepülés: Nem vészes, de segítünk. A cég is segít, meg az itteni magyarok is segítettek egy csomót, szóval dobjatok levelet és megpróbálok segíteni én is!

Brno: Nekem tetszik, kellemes kisváros. Csendes, tiszta, baró jó közlekedéssel.

2011. augusztus 24., szerda

Halálcsillag Design Pattern - implementációk

Halálcsillag Brno felett
Tényleg nagyon gyakran elmondhattam ezt a halálcsillag dolgot a régi munkahelyemen. Ezt kaptam ajándékba: egy kicsi halálcsillag. A képen éppen Brno felett lebeg.
Köszi :-)

Gyárlátogatás: konfiguráció

A következő dolog, amit mindenki totál máshogy csinál a java/j2ee/jee környezetben az a szoftver konfigurációja. A téma sajnos nem annyira "egyszerű" mint az a képesség, hogy a verziószámot meg tudjad mondani, így hát igen szép számban van rá megoldás. Ezek a megoldások még csak nem is diszjunktak, simán átfedik egymást. Egészen biztos, hogy nincsen két ugyanúgy konfigurálható java szoftver. Illetve csak ha pont ugyanaz az ember írta mondjuk 1 héten belül. Szóval oltári buhera zajlik a téren. Mint mindig.

Elvárások a konfigurációval kapcsolatban

Ha én lennék az admin, most így fejből ezeket várnám el az appoktól és fejlesztőiktől:

  1. Legalább az minor release-k között őrizze meg integrítását. Azaz a 1.0-hoz bütykölt konfig had menjen már el a 1.0.1-gyel is.
  2. Ne az alkalmazásba legyen belebuherálva (WEB-INF/classes, satöbbi), hogy amikor az upgrade során rm -rf paranccsal kezeled a régi verziót (ja, backup, csókolom!) ne vesszen el a régi bugokkal együt a konfiguráció is. Legalább a környezet-specifikus konfiguráció ne az appban legyen!

Mint fejlesztő, nagyon szeretem azt, ha nem kell a fél életemet a fejlesztői környezet összebuherálásával töltenem. Értelmes alapértékek (akár pl egy beágyazott DB), könnyű felülcsűrhetőség.
Illetve ezt csak nagyon szeretném, baromi ritka az ilyen. Remélem nem úgy képzelitek el a halálcsillag építését, hogy kiszedik a dobozból, bekapcsolják és működik.

Plain Property file-ok

A property fileok ősi java feature és a legtöbb rendszer még mindig felhasználja a konfiguráció tárolására. Ezzel persze nem rossz dolog. Máig ez a legtöbb konfigurációs megoldás alapja, de persze a tiszta és legalapabb formája az, amikor pl a konstruktorban megkapod a Properties ojjektumot magát és bányásszad ke belőle azt, ami köll. Volt egy ennél kicsit szofisztikáltabb megoldás, ami csak a teljes konfig egy részét passzolta oda... lényegtelen. Ezek tipikusan az IoC-nélküli rendszerek.

Á igen, IoC

Az IoC egy olyan ötlet volt, amiért jópárszor leégettem magam azzal hogy próbáltam megmagyarázni a főnökeimnek valamikor régen, és néha még mostanában is. Ötlet: "Do not call me, I will call you!" Azaz az IoC konténer majd beállítja neked a konfigot, összekapcsolja az ojjektumaidat, elindítja az appod ha kész, illetve elhasal ha nem sikerült (ez esetben az jó, hogy hülyeséggel nem indult el). Ebből eleinte még két faj létezett, az intrusive (pl Avalon) és a non-intrusive, tipikusan POJO jellegű. Az elöbbit mára csak CVS-múzumokban találod. Az utóbbiból se a spring volt persze az első, csak a legnépszerűbb. Volt még elötte picocontainer, nanocontainer, és már a fene se emlékszik mik. Ma Spring, Guice, és az EJB is sok inspirációt kölcsönzött a téren ezektől a projectektől. Vitatkozhatnánk róla, hogy eleget-e vagy sem, de igazából nem érdekelne.

Még itt szeretném megemlíteni azokat a böszme nagy XML fileokat amiket írunk az IoC frameworknek és együt jönnek az appal szinte minden verzióban kicsit úthuzalozva és átkombinálva. Szerintem ne akarjátok, hogy az admin ebben matasson! Az merge-hell! Sírás-rívás, jajjveszék, rollback, cancel, és hasonló kulcsszavak jutnak róla eszembe. (Egy külsős fejlesztő szívatott ilyennel éveken át)

Spring, PropertyOverrideConfigurer és PropertyPlaceholderConfigurer

Ezt a két dolgot igazából nagyon szerettem a spring-ben. Ez megoldás arra, hogy az appcontext-ben összeállított konfigurációt felülcsűrd egy property file tartalmával. Tehát ide lehet tenni az X-et ennek én nagy rajongója vagyok még most is. A különbség a két dolog lehetőség között, hogy az override configurerrel mindent felül lehet csapni (söt, olyat is ami az appcontextben nem is volt benne), míg a placeholder configurer csak a placeholdereket helyettesíti be. Azért gyanús, hogy az előre kigondoltakon kívül jól jöhet, ha időnként más beállításokat is megváltoztathatsz. Természetesen az a placeholder configurerben viszont szimpatikus, hogy az éles rendszerektől megköveteli az előre definiált placeholderek értékének beállítását, különben nem indul el. Ugyanakkor még mindig jobban szeretem, ha a rendszer értelmes defaultokkal jön, és bármít felül lehet benne csapni.

Mindkettőnek van némi hiányossága. Pl listákat és map-eket nem kezelnek. Na erre mindenkitől láttam valami saját szintaxist és saját megoldást.

Jó, de hova?

Azt a kérdést, hogy hova tegye a rendszergizda a konfig fileokat, illetve az app hol keresse, az izlés és hitviták tárgya. Volt egy melóhelyem, ahol a unix filerendszerhez kellett igazítani a struktúrát. A konfig az etc-be, a program kód meg a usr-be (usr-be?!?!?!), felhasználókkal kapcsolatos dolgok talán a home-ba, adatok a var-ba. Igen, még mindig java szoftverfejlesztésről van szó. Vicces volt egész addig amíg rá nem jöttem hogy komolyan gondolják. Utánna már nem :-D

Mindenesetre a legtöbb program egyszerűen csak a classpath-on keresi a konfigját, többnyire {appnév}.properties alatt. Ez talán a legértelmesebb dolog, de minden appszerveren máshova kell dobni, hogy a classpath alatt legyen. Had sírjon aki migrálni merészel!

JMX!

A JMX még belerúg ebbe a témába kicsit. JMX-en keresztül beállíthatod az alkalmazásod konfigurációját, meghívhatsz rajta maintenance metódusokat, stb. A JMX király dolog, de arról nem gondoskodik, hogy a container újraindítása utánra is megmaradjanak ezek a beállítások. Az az app gondja. Valószinúleg ez lehet az oka annak, hogy hibakeresés közben láttam csak JMX-et, konfiguráció beállításhoz soha. Nevezhették volna inkább java debugging extensionnak.

JNDI?

Ha már a container szolgáltatásainál tartunk. Sokat tűnődtem rajta, hogy a JNDI miért csak annyi lett, amennyi lett. Semmi mást nem csinálsz vele, csak java.sql.Datasource és java.mail.Session objektumot halászol ki belőle, többnyire hardcode-olt címről. Az innen kihalászott objektumok előre fel vannak konfigolva a környezet beállításaival: hol az adatbázis, milyen adatbázis, hány kapcsolatot nyithatok rá, satöbbi, hasonlóan az smtp szerverrel. Na jó, még arra is használjuk néha, hogy a LDAP szervereken kurkásszunk valamit. Ennyi?
Tehát akkor az adatbázis és SMTP eléréssel kapcsolatos infókat akkor ott tartjuk. A többit miért nem? És ha a többit nem ott, akkor azt miért? Nem lenne jobb egybe tartani?
Kipróbáltam pár appszervert, a GUI/web-es felületeken keresztül egyik sem volt hajlandó a fenti kettőtől eltérő ojjektumot elhelyezni a JNDI fában. Kézzel be lehet haxolni.

Adatbázis

Remélem mindenki érzi, hogy egy komoly robosztus ACID-compliant replikált és backupolt nagy teljesítményű, 24/7 365 felügyelt RDBMS a legrojszrojszabb hely a világon, ahova a konfigját az ember berakhatja. Szóval legkevésbé sem ritka, hogy az appok az adatbázisban tartják a konfigjukat. Akkor már csak az a kérdés, hogyan éred el az adatbázist, de ezt többnyire a JNDI megválaszolja.

Én nem érzem a késztetést :-) Csupán technikai oldalról, nem értem mi haszna van az ACID viselkedésnek akkor, amikor olyan adatokról van szó, ami csak akkor változik, amikor éppen bütyküljük a rendszert. Sokkal hasznosabb ha gyorsan és egyszerűen hozzá lehet férni, mindig. Továbbá nagyon nagyon szép ha pl valami verziókövetőben tárolhatjuk, hogy tudjuk ki buherált rajta és mit, mikor hogy nézett ki. Egy text-file sokkal szimpatikusabb. Na ezt talán inkáb oda kellett volna írnom a propertyfile-hoz. Na mindegy, úgyis elcsesztem már pár helyen ezt a cikket.

2011. augusztus 17., szerda

Gyárlátogatás: verziószám

Tipikus igény a szoftverekkel szemben, hogy meg tudják mondani a saját verziószámukat. Ez főleg azért kell, hogyha a kedves felhasználó meglát egy bogarat benne, meg tudja mondani, hogy melyik verzióban látta. Legalábbis hogy esélye legyen rá. Erre szedtem össze az általam eddig látott és használt megoldásokat, azzal együt hogy mi a tipikus elba**** velük kapcsolatban. Nemcsak hogy egyik sem tökéletes megoldás, de mindegyik szerintem elég töketlen. Persze a sajátját mindenki szereti :-)

Build script

Ez volt a leggyakoribb. Az ötlet annyi, hogy amikor buildelsz, akkor generáljon neked egy számot bele egy file-ba, amit valószinűleg besúvaszt utánna a classpath-ra. Ezt persze csak inkrementálgatni kell. Láttam olyat, hogy ez a file csak úgy "floating around" azaz akik release-t csináltak azok tudták a számozást, aztán volt olyan hogy visszakommitolták legalább időnként a verziókövetőbe. Ja még ezen belül is két különböző műfaj van, van aki verzió számot tart számon, van aki build számot. Szóval a kombinációk száma igen magas.
A tipikus elba:

  • Amikor nincs meg a file a classpathon, akkor valami törik
  • Elfelejted inkrementálni a build számot
  • Elfelejted a verziószámot bepakolni a verziókövetőbe, mielött tegelsz



Database, config

Olyat is láttam, hogy az emberek a konfigurációba, vagy gyakrabban az adatbázisba írják bele, hogy mennyi a szoftver verziószáma. Az egyébként tetszik, hogy az adatbázisban valahol benne legyen az, hogy milyen patcheket hajtottak végre rajta és milyen verzió satöbbi a jelenlegi schema, de akkor most az operátorra bíztuk, hogy felülbuherálja a verziószámot.
Elba:

  • Azon felül hogy anyukádat emlegetik közben, még rizikó tényező hogy az operátor valamikor visszacsinálja vagy átírja, vagy éppen ellenkezőleg: elfelejti átírni.
  • Az fenti elfelejtések simán ide is passzolnak

SVN-way


Ezt én találtam ki és hát primitív mint a szerzője: Csinálj egy osztályt pl Version néven, tegyél bele egy final static String mezőt, aminek az értéke legyen ennyi: "$HeadURL: http://svn.blf.hu/fubar/trunk/src/main/hu/blf/Version.java $", plusz egy metódust, ami fubar és az src közül kibányássza neked ami ott van: pl ennyi: StringUtils.substringBefore(StringUtils.substringAfter(version, "/fubar/"), "/src/"), ne felejtsd el a végén az svn property-k között a keywords-be beleírni azt hogy "HeadURL".
A build numebert nyilván hanyagolja. Csak azt adjuk oda bárkinek is, amit szépen betegeltünk.
Jó, a nyilvánvaló hátrányok elött felsorolnám hogy miért szerettem ezt:

  • Soha nem sikerült elszúrnom :) A Version osztály mindig valami értelmeset ad vissza. Pl azt hogy "trunk". A legdurvább elcseszés esetén semmit, de nem NullpointerException-t.
  • A release során simán meg lehet róla feledkezni. A release nálam ennyi: mvn release:prepare release:perform (így "howto release" manuált se írtam soha)
  • Ja és ez az egész substringes dolog csak a cicoma rajta, sima statikus text/html fileokkal is működhet, ha érti a felhasználód a HeadURL-t hogy mi az.
Akkor jöjjön a hátrány:
  • Totálisan SVN függő - azért volt ilyen a CVS-ben is, de arra már kiemlékszik
  • Az SVN-re meg most úgy fintorgunk mint a CVS-re úgy 6-7 évvel ezelött. Valahogy akkor jött ki az SVN, nem?
Még annyit a megoldás portolhatóságáról, hogy a git pl nemcsak hogy nem csinálja, de elvben is ellenzi. Linus Torvalds szerint írjál scriptet. Szerintem meg ... :-) Na mindegy, nekem ez nem tetszik, túlságosan könnyen elcseszhető. Meg bújja a git elba manuálját az, akinek nincs jobb szórakozása.

Ennyi... részemről

De kiváncsi lennék a ti tapasztalataitokra, linkeljétek vagy írjátok ide nyugodtan! Köszi előre is!

2011. augusztus 3., szerda

ping brno

No, messzemenőbb tapasztalatokat nem tudok mesélni a Red Hat-ről, tekintve hogy pár napja vagyok csak itt. Szóval első impressziók:
  • Rövid eligazítás után egyből kezembe nyomták a gépemet, egy ThinkPad-ot, amit magamban csak TankPad-nak nevezek. Elég izmos gép, nagy ram, 4 core, nagy vincsi. Dokking sztésön, extra képernyő, egy angol billentyűzetet is sikerült kukáznom. Hardwer-ügyileg soha nem voltam ilyen jól elátva.
  • Az már az első látogatásomkor lejött, hogy a régi munkahelyeimhez képest baró csendes az iroda. Engem mondjuk a zaj nem nagyon zavart sehol sem, de jónéhány régi munkatársam mondott fel a zaj miatt. Itt inkáb ilyen könyvtár jellegű a hangulat.
  • Minden gépen linux van, én újabban az eddig gyűlölt Gnome 3-at hajtom, lassan megszokom.
  • Van Ingyen Ebéd! Hétfőn gyümölcsök, amúgy kb folyamatosan műzli. Az egészséges táplálkozáson túl pl tegnap esti release partin volt sülthús és sör is.
  • Na igen, a technikai témák jobban pörögnek mindenképpen. Örülök neki, mert ezért jöttem ide. Sajnos tegnap kicsit el voltam havazva (és ez folytatódni látszik) de volt egy JBoss AS 7 release party.
  • Ehhez kb hozzá lehetek szokva, de hiába költöztem ide, majdnem mindenki remote.
  • Vannak viszont magyarok, rajtam kívül hárman. Még nem volt időm megkeresni mindenkit :-( Eléggé el vagyok havazva.
Egyébként a város:
  • Egy része ugyanolyan koszos büdös, mint Budapest. Cejl bizonyos szempontból még Budapestet is alulmúlja, nyóckerszerű rohadó belváros. A város többi része tele van építkezésekkel, az egész nő mint a gomba.
  • Zseniális a villamoshálózat. Meg olcsó is. A legdrágább jegy forintba átszámolva 250-270 ft között lehet, ezért egy órán át utazhatsz a városon keresztül ha jól értettem akárhány átszállással. A legolcsóbb jegy 90 forint körül van (8 CZK), ez csak 10 perces utakra elég. Remélem nem értettem félre semmit, ellenőrrel még nem találkoztam.
  • Ez a része, ahol mi vagyunk (Královó Pole) egész csinos, parkos, tele van különféle egyetemekkel és van egy hatalmas infópark
  • A táj szerintem bejön azoknak, akik szeretnek túrázni (az IT szakmában tipikus)
  • 10 évnyi Budapest után totálisan megdöbbentő, hogy ha a zebrához érek, megállnak az autók az úton, hogy átengedjenek.
  • A sör a legkevésbé sem érdekel, de amúgy a kaja, főleg a tejtermékek (ami az alap üzemanyagom) lényegesen olcsóbbak a hazainál.
  • A lakások és albérletek viszont marha drágák.

2011. július 17., vasárnap

Gyárlátogatás: saját főztöm

11 évvel ezelött landoltam egy új munkahelyen -azóta rég beszünt- , ahol valami tetűnagy rendszert fejlesztettünk C++-ban. Volt a dologban egy kis CORBA (béke poraira) és Oracle RDBMS, mert azt már akkor sem lehetett kihagyni semmiből. Érkezés után az űberführer mondta el, hogy mi is ez az egész. Egy chat szerver volt végülis, sok klienshez. Nem IRC protokol kompatibilis, hanem custom webes chat. Szóval az első reakcióm az volt, hogy "Klassz! Próbáljuk ki!", mire az űberführer már az első napomon korán reggel jól lecseszett: "Figyelj, nem érünk rá játszani, nagyon sok dolgunk van!"
Ez nekem ilyen tréfás emlék arról a cégről, mert végig ilyen volt, a termékeket soha nem próbálgattuk. Tellt-múlt az idő. Úgy kb 8-10 helyen dolgoztam azóta, ebből 2 helyen volt olyan ember, hogy "tesztelő". Igazából csak az egyik esetében jelentette ez azt, hogy az az ember automatizált teszteket programoz. Most már biztosan változott a kép, a sok kis magyar cég helyére többnyire multik jöttek, többszáz embert alkalmaznak és náluk nem az a QA, hogy "aha, kipróbáltam..."

A tesztelő mellett kiválló input lehet egy ügyfél (illetve a felhasználó, mert az nem ugyanaz) is, bár az kicsit változatosabb tud lenni minőségben. Például az egyik külföldi munkatársnő egyetlen hibajelzést tud leadni: "nem működik". Ilyenkor 10 email váltás, telefonon felhívom, satöbbi, fél óra amíg kiderül hogy a loginig el sem jutott, a browsere nem jut át a proxyn. Más felhasználókból egész értelmes dolgokat lehet kihúzni, mint például hogy nem értették hogy mire való az a gomb és nem merték megnyomni, nem találták a dokumentációban, pár kör levelezés után megegyezünk abban hogy hogyan tudunk segíteni.
Ez SCRUM-ban talán a product owner feladata lenne, de a személyes kapcsolat a felhasználóval azon túl hogy baromi sok időt emészt fel és néha még éjszaka is a munkahelyi leveleimet válaszolgatom meg, egyébként szerintem egyrészt sokat lehet belőle tanulni, másrészt pedig tényleg elhozza az egész problémakört oda. Ebben a problémakörben nem csak dolgozol, hanem ebben élsz. Azok, akikkel naponta spanolsz kint a konyhában vagy felhívnak valami problémájukkal, azok lesznek a társadalmi kapcsolataid, a te saját kicsi világod. Így egy kicsit más érzés egy problémán dolgozni. Nem azért csinálod, mert a managered azt mondta, vagy mert van egy jira issue rá és bekerült az iterációba, hanem azért, mert valakinek a környezetedből gubanc. Például volt egy hely, ahol ketten dolgoztunk 150 callcenteres nő között. Nekik az üzleti logikától nagyban fügött, hogy mennyi pénzt vihetnek haza hó végén, ezért munka végén volt aki bejött és megköszönte hogy jó munkát osztottunk neki (illetve a kód amit írtunk), vagy ránköntötte minden haragját amiért nem.

Csodálatos visszajelzés az üzemeltető csapat, amennyiben van ilyen :). Ők nem fogják megmondani neked a hiba okát, van ezer más bajuk, viszont nagyon precíz információkat tudnak adni arról hogy milyen hibajelenséget láttak és ez mennyire fáj. (rendszer outage, crash, túlterhelés, lassulás, memory leak, restart, satöbbi) Aztán persze tesznek rá, hogy a kód helyesen működik-e vagy sem, az már valaki más baja. Például az tök jó, hogy a vasműben minden nap többször is összefutok az üzemeltetőkkel. Másként nem tudok bemenni és kijönni. Szóval ha bármi gubanc volt, ők biztosan nem felejtik el.

Persze direktben a felhasználótól kapni vissza az élménybeszámolókat egy bizonyos mennyiségű felhasználó felett már nem szórakoztató, ilyenkor bejön a support, management, satöbbi. Csak szerintem annyira gyakran van az, hogy a management beáll középre a kommunikációt bonyolítani és nagyon lényeges információk vesznek el ezen a ponton.

No, ennyi jutott eszembe erről az eating your own dogfood témáról. Ja meg hogy csütörtökön palacsinta, az is a saját főztöm lesz :-)

2011. július 12., kedd

Cassandra - eddig

Mostanában szabad pillanataimban a Cassandra adatbáziskezelőt próbálgatom. Ez amolyan szakmai kirándulásféle nálam, mindenféle konkrét cél nélkül kipróbálok dolgokat. Nem jutottam még messzire vele, tényleg a bemelegítő gyakorlatok: működtetés, programozás, őszintén szólva nekem a thrift is teljesen új volt - bár nem újszerű, engem a dolog valahogy nagyon emlékeztet a CORBA-ra, de nem jutottam ezzel se olyan messzire, hogy elkezdjem osztani az észt két kézzel.

Eddigi olyan igazi járatlan út szaga van a Cassandrának. A dokumentáció felületes és jobbára törött, az API minden release-ben változik, programozni kicsit hosszadalmas és fapados érzés, a hibaüzeneteihez tolmácsra van szükség. A legtragikusabbnak az üzemeltetés tűnik.

Viszont amire kitalálták, arra ailghanem jó: nagy mennyiségű adat analízis jellegű feldolgozása. Majd ha befejeztem a teszteket akkor valószinűleg én is azt mondom majd, hogy baró és tetszik. De  legtöbb embernek nincsen annyi adata, hogy ilyenekre legyen szüksége. Ez egy igencsak speciális eszköz. Kéremszépen legyenek szivesek megtekinteni a wikipédiát, ami kiválló példa arra, hogy a legtradícionálisabb LAMP architektúra is képes top 10 weboldalra jellemző terhelést elvinni. A lenézett és döglődő MySQL szolgálja ki.

Komolyan tartok tőle, hogy a NoSQL felhasználók jelentős része valójában csak a szép új technológia miatt nyomul az új generációs adatbáziskezelők körül.

2011. július 7., csütörtök

Indigo - eddig

Nagyjából átálltam az új eclipse release-re minden projectemmel, pár észrevétel eddig:

  • Mi a szösznek van még mindig benne a CVS kliens? Ki használ CVS-t 2011-ben?
  • Viszont defaultból benne volt az egit, az szép.
  • Szintén az alap csomagban benne volt a maven plugin is (m2eclipse) - na végre, csókolom, 2011 van!
  • Megintcsak az alapcsomag része google által bedobott GUI designer, amit a heliosba is belegyömöszöltem, de ebben alapból benne van. Öszintén szólva az egyetlen dolog amiért hajlandó voltam átbóklászni néha netbeans-re az a GUI designer volt, viszont ez jobban tetszik. Végre egy használható GUI designer swinghez, SWT-hez és azt hiszem GWT-hez is működik.
  • Egy csomó szép új plugint felfedeztem. Ilyenkor néha elszáll az agyam és próbálgatok, de az igazat megvallva nagyon kevés plugin éli túl nálam az első hónapot. Meglátjuk hogy lesz most.
  • Egyes pluginokat nagyon nehezen sikerült beszerezni. Pl a google web toolkit plugint égen földön kerestem a marketplace-ben, aztán a GWT UI létrehozásakor felajánlotta hogy letölti.
  • A legtöbben az eclispe marketplace-t használják (én is preferálom) pluginok beszerzéséhez. Hát ez az utóbbi időben a legváltozatosabb hibákat generálja a szerver oldalán.
Szóval 2011-ben is, eclipse az IDE.

2011. július 1., péntek

Ez nem egy magyar blog

Ma lépett életbe Magyarországon a sajtótörvény és aki valamennyire is ismer, az sejtheti rólam, hogy nem regisztráltam be ezt a blogot. Következő okokból:

  1. Egyszerűen lusta vagyok hozzá. Még a postára se járok el, nyilván majd ugrok minden alkalomra ha valami jó kis nyomtatványkitöltésre nyílik kilátás :-)
  2. A törvény szövegéből nem értek egy kukkot sem. Nem derül ki egyértelműen hogy rám és a blogomra vonatkozik-e vagy sem. A nagy általános érvényessége alapján a marslakókat is be lehetne perelni vele.
    Persze a törvény nem ismerete közismerten nem ment fel, de viszont nem kellene egy tesztelő csapat a törvényekhez is? Hogy érthető és használható-e? Nem ad lehetőséget hatalommal való visszaélésre, stb?
  3. A blogot nem Magyarországról szolgája ki a Google. Köszi Google!
    Amúgy sem magyaroknak írtam, hanem csak úgy magamnak és az internet járókelőinek.
  4. Pár héten belül befejezem a munkát Magyarországon és Csehországba költözök, Brno-ba. Az ismert médiacéget elcseréltem egy ismert technológiai cégre (Linux, Java, satöbbi, szóval nekem való helynek tűnik).
    Mondta is valamelyik űberführer, hogy ha nem tetszik el lehet menni. Na, szóval én már megyek is.
Szóval úgy gondoltam, hogy ezek alapján rám biztosan nem vonatkozik, meg ha igen, akkor pár héten belül már nem. Nemsokára külföldi leszek...

2011. május 27., péntek

A Halálcsillag Design Pattern

(not hungarian? read this post in english - translated by @kkovacs)

A munkahelyemen valamennyire sikerült meghonosítanom a Halálcsillag kifejezést. 4 év alatt többször elmondtam, mint Palik a kegyetlent. Akkor most megmagyarázom, hogy mi is ez :) A következő a lényeg:

  1. Évekig építik titokban akkora pénzekből, amennyi nincs is a földön.
  2. De csak nagyon kevés ember használja, a többi max nézheti
  3. Esetleg sikerül demonstrálni az erejét egy lényegtelen célponton, de egyből utánna jön gipszjakab meg kakukkjenő a kukacbombázóikkal és szétcsűrik. A kevésbé drámai végkimenet az, hogy egyszerűen csak elfogy a pénz és törlik a projectet.
  4. A "2.0" projectet az első tragikus kudarca után lényegében ugyanúgy hajtják végre, lényegében ugyanazzal a végeredménnyel.
  5. Az egész lényegesen több költséggel jár, mint haszonnal.
  6. Ja és baromi lassú is, a Milenium Falcon simán rávert jó egy nap előnyt alig pár fényévnyi távolságon :)
A Halálcsillagra az előző nagyfejes azt mondta volna hogy böszmeség. Totálisan túlméretezték. Azon gondolkodtatok már, hogy mi lett volna, ha csak fele akkora Halálcsillagot építenek, de kettőt? Mondjuk nem tudja totál szétrobbantani a bolygót, csak egy pillanat alatt eltörölni minden életet a felszínéről? Az nem lett volna elég jó?

Pár informatikai projekt azok közül, amiket biztosan ismertek:
  • magyarorszag.hu - ennek valahanyadik 2.0-ás verzióján dolgoztam én is és hát nem esett messze az alma a fájától, de ez hosszú történet... azért volt pár egészen jó dolog is benne mindenkitől jól elrejtve
  • kormanyszovivo.hu - az például igazi gerillamozgalmat indított olcsó drupálos egyestés klónokkal
Ennyi a lényeg, biztosan értitek, minek is szaporítsuk a szót... Boldog pénteket mindenkinek!

2011. április 29., péntek

Firewall vs JDBC

Ma egy egész érdekes dologot találtunk meló közben. Érdekes egybeesésként ez ugyanaz a gubanc, mint amiről az egyik előadó is beszélt a 33degree konferencián, csak ő valami légiközlekedéssel foglalkozik. (hmmm, biztonságban érzitek magatokat?) A probléma alapja az, hogy a firewall-ok eltépkedik időnként a TCP kapcsolatokat. Egészen vicces, a szerver nem kapja meg a kérést, a kliens meg azt hiszi hogy elküldte, köztük a firewall röhög a markába, te meg nem érted miért áll a kliens, miért nem csinál semmit a szerver, és egyáltalán mi a rák történik. Ne tőlem kérdezzétek, hogy miért annyira fontos firewall-t telepíteni például az adatbázisod és az appszerver közé, szerintem ha valaki felhakkolta az appszervered és megvan az adatbázis kapcsolat akkor már régen rossz, de...
Ennek a problémának általában áldozatul esik néhány protokol, a lényegesebbeket említve RMI és valószinűleg minden adatbázis kapcsolat, általában a hosszú JMS kapcsolatok is, LDAP. Amit nem üt, az a HTTP nyilván, mert az bontódik amint lement a kérés és a válasz. Más most nem jut eszembe, ami jól működik vele :-)

Minden protokolra nem tudok orvosságot, de a commons-dbcp képes csekkolni az adatbázis kapcsolatot mielött odaadná a alkalmazás kódnak. Az 1.2-es verzió csak annyit tud, hogy elküld egy dummy kérdést a szervernek (tipikusan egy "select 1") és ha sikeresen válaszolt az adatbázis, akkor adja csak oda a kapcsolatot. Nem láttam még olyat, hogy a validation query elhasaljon, tulajdonképpen kicsit haszontalannak tűnik. Viszont amikor a fenti firewall gubanc beüt, akkor fentakadsz már a validation query-nél is, a kódod meg se kapja a vezérlést. Na erre a problémára ad megoldást a DBCP 1.3-tól kezdve a validationQueryTimeout paraméter. A DBCP 1.4 is már jó egy éve kint van, de amennyire látom még a legfrissebb cuccokban is az 1.2 van. Szóval egyéb hijján, akinek ez probléma, az kénytelen felülbuherálni.

Hát csak ennyi, remélem átérzitek :)

2011. április 11., hétfő

33 degree konferencia, Krakkó - II

Folytatás tegnapról...

Jevgeni Kabanow: Do you really get memory?

Reggel máris kicsit meredeken kezdődött a nap, Jevgeni egy sajnát java-ban implementált virtuális gépről beszélt, szóval jó messziről futott neki a témának, mégis sikerült értelmes dolgot kihoznia. Például az Azul systems félelmetes garbage collectorát, ami a linux kernellel együtműködve egyszerűen kidobja azokat a page-eket, amiken már csak szemét van. Hoppá, erről ti is lemaradtatok? Én igen...

Házi feladat az egész, utánnanézni.

Brad Drysdale: HTML5 Websockets

Erről a témáról már írtam itt, túrkáltam a témát és... én sehogy se vagyok olyan optimista mint Brad a websocketekkel kapcsolatban. Egyetértek azzal, hogy hatalmas lépés a webapp architektúrában, de sehol se tartunk vele. Rövid helyzetjelentés: a chrome-on kívül minden böngészőből eltávolították a websocket támogatást, az IE-t leszámítva mert abban nem is volt soha. Semmilyen proxy-n nem megy át és azt hiszem a firewallok tevékenységét se fogja jól bírni a protokol. A servlet speckóban szó sincs róla, a mod_proxy nem engedi át... hát nem is tudom mennyi idő amíg ez a sok gubanc elmúlik. Azért megkérdeztem az előadót és kitérő választ adott, ami korrekt, én se mernék tippelni ennyi ember elött :-) Mindenesetre az ő munkaadójának, a Kaazing-nek van egy websocket gateway terméke. Szerencsére ezt csak említette, nem marketing-prezi volt, korrektül összefoglalta a technológiát.

A témában éppen most megint nyomulok és a elcsűrt prototipusomat írom újra, szorgalmi feladat ceruzás zöld kicsi egyesért.

Guy Korland: "Same data, any API", making sure your application scales

A szoftver architektúrák fejlődésének vicces bemutatása. Hát igen, ő pedig a Gigaspaces-től érkezett és az ő cuccuk tényleg elég jó trükköket tud. Annyi pénzért...

Nathaniel Schutta: HTML5 fact and fiction

Herr Schutta zseniálisan löki a rizsát a html5-ről is. Mint azt tavaly a w3c-s srácok kijelentették: a html5 nincs kész igazán. Hát most még mindig nem, de nem csak a IE miatt. Gyászosan áll a firefox is, még az Opera alakított a legszebben. És a kutya se használ operát. A video formátumokkal kapcsolatos háború meg csak nyúlik...
Viszont lassan tényleg változni látszik a web, lassan elveszti a jelentőségét a flash, stb...

Venkat Subranmiam: Programming Clojure

A Clojure veszedelmes. Igazi write-only nyelv, mint a perl, amit egy óra múlva már te se értessz. És hát volt is olyan, hogy Venkat kicsit elakadt, hogy vajon hol hiányzik rengeteg zárójel. Pedig a csóka elég rendesen pörög. De nem számít, egy pár dolog igazán zseniális volt a nyelvben és azt ki akarom próbálni. Komolyan, olyan rendszert, amit valakinek át kell adni, ami nem csak az én desktopomon fut, nem mernék írni benne, de ki fogom próbálni.

Házi feladat: prototípusok, nyelvtanulás, mérések.

33 degree konferencia, Krakkó

A héten TVik-kel ketten elugrottunk a 33 degree java konferenciára Krakkóba. Csak mi ketten voltunk magyarok és talán egyéb külföldiből sem volt túl sok, ha leszámítjuk az előadókat. Viszont egy percre sem bántuk, hogy elmentünk, mert az előadók tényleg nagyon jók voltak. Nagy szükségem volt már egy ilyen pár napos cuccra, ahol kicsit távol a mindennapi munkámtól foglalkozhatok végülis a munkámmal :)
Az egész teljes költsége ha jól számoltam a végére úgy 80ezer forint lett utazással, szállással és regisztrációval együtt. Magyar fizetéshez kitalált összeg.

Alapelvek az előadások kiválasztásához: nem érdekel az "enterprise" és a "standard", ezek lejártak és beégtek. Más irányokban keresek tudattágítót.

Vettem pár papíros könyvet is:

No nézzük, előadások...


Linda Rising: Deception and Estimation

Linda Rising arról beszélt nekünk bemelegítőként, hogy az ember totálisan nem alkalmas hardver matematikailag pontos becslésekre. Egyszerűen az evolúciós multunkból adódóan.

Házi feladat nekem: A groupthink probléma megelőzését lökdösni a melóban, amíg nem működik.

Matt Raible: Comparing JVM web frameworks

A legfrissebb web-framework helyzetértékelés és összehasonlítás. Igazából, én nem használok web frameworköt, csak MVC-t és bár utálom kézzel hímezni a html-t, rájöttem arra, hogy ezekkel nem lehet ugyanazokat a trükköket megoldani, amiket a kézzel hímzett html-ben. A kedves ügyfél meg addig nem boldog, amíg pontosan az meg nincs, amit megbeszéltünk. Szóval ebből a szempontból ez a sok framework csak akkor érték, ha az ügyfelet le tudod beszélni a sok ökörségről és jópár értelmes dologról is.

Nathaniel Shutta: Hacking your brain for fun and profit

Rövid howto az emberi agyhoz, hogyan kell használni ahhoz, hogy optimális teljesítményt adjon egész hosszú időn át. Például érdemes aludni, esetleg egyet szunyókálni délután (amennyiben nem lép fel a kirúgás kockázata, de egyébként a legtöbb meeting pont ilyenkor van), sport, satöbbi.
Az ürégnek nagyon érdekes előadóstílusa van, biztos sokat gyakorol :)

Nathaniel Shutta: Going Mobile with JQuery

Ismét ugyanaz az előadó, de ezúttal valami hasznosabb dologgal. Ötlet: miért akarnál külön IPhone-ra,  Windows7-re és Android-ra is külön klienst fejleszteni. Megtehetnéd ugyanezt szimpla HTML-lel is, és ebben segít a JQuery mobile. Úgy tűnik nagyon könnyen lehet vele összedobni kis webappokat és alighanem működni fog offline módban is...

Házi feladat: kipróbálni mit tud.

Shang Shin: Android Programming

Kemény 3 órás Android fejtágító, amin Tvik már majdnem elaludt (a vonaton alvás nem a legpihentetőbb dolog) de nekem nagyon jól jött, mert elég szegényes az android tudásom. Komolyan tetszett az egész. A csóka egyébként Sun-os volt, de az Orékülből nem kért, csinált inkáb egy saját kis java okosítócéget.

Ennyi volt az első napon, a többit megírom máskor mert holnap meló és addig még aludni is kellene, mint arra Schutta úr is rámutatott :-) Fogok is aludni, csak elöbb kipróbálok ezt-azt...

2011. március 31., csütörtök

Új java blogom

Gondoltam egyet és csináltam egy új blogot azokkal a dolgokkal kapcsolatban, amikre mostanában töredékidőmet rá tudtam szánni. A téma java teljesítmény mérések és ezúttal angolul írom. Rémes vagyok angolból, de majd belejövök. Had szokjam, had szokjátok :-)
Szóval itt van: http://dummywarhead.blogspot.com/

Persze ez a blog is megy tovább, de nem hiszem, hogy ezeket a tuningtémákat tényleg mindenki tudná értékelni.

2011. március 21., hétfő

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

2011. február 27., vasárnap

mod_cband, mod_bw

A bandwidth throttling kiválló eszköz arra, hogy már a fejlesztőkörnzezetedben átélhesd a felhasználóid fájdalmát az alkalmazás nyomorult válaszidejével kapcsolatban. Hébe-hóba még egy-két bugot is segíthet megérteni. Amikor a localhostról jön a válasz, akkor irreálisan gyors válaszidőket kapsz, éles üzemben ilyen soha nem lesz és amikor párhuzamosan egymással több AJAX interakció is történik, akkor lehet, hogy valamit ráépítessz a válaszok sorrendjére. Pedig tök összevissza az egész. Szóval ajánlom figyelmetekbe a  mod_bw és a mod_cband apache modulokat, ők segítenek olyan tré minőséget produkálni, mint amilyet az éles szerverek :-) Az egyik konfigurációban még két vmware-s virtualális szerverre épített clustert is bedobtam mögé, hogy az is igazán ótvar legyen.

2011. február 16., szerda

process != progress

A fejlesztők arra koncentrálnak, hogy minnél több és minnél frankóbb dolgot belepakoljanak a programjukba és sajnos néha ez buktatókkal jár. Úgy hívják a dolgot, hogy bug, defekt. Üzemzavarok, leállások, biztonsági hibák, kiskapuk, átgondolatlan UI, hiányos manuál, tákombákom, satöbbi. Ez ebből a fajta melóból kicsit adódik, de persze lehet koncentrálni a stabilításra, bugok persze akkor is lesznek amíg ember írja a kódot (meg szerintem utánna is, csak azt már senki se fogja átlátni)

Néhány súlyosabb probléma után aktiválódik a management és mindenféle metodikákat kezd bevezetni a probléma kezelésére. Kezdetben bár kisebb-nagyobb áldozatok árán de úgy tűnik sikerül megoldani a problémát (legalábbis lehet róla statisztikát hamisítani), de mivel egy-két csapat talál kiskaput, ezek a metodikák tovább nőnek és lassan kiterjednek a munka minden területére. Azon kapod magad, hogy a reggel vagy az egész délelött rámegy a standupra, esténként hosszú unalmas telefonkonferenciákon veszel részt, esetenként pedig beugrik egy-egy rendkívüli esemény is, "all hands meeting", satöbbi. Az iterációkat szinte lehetetlen összefogni, mert bár megvan a release, a deployment eltart hónapokig, ami szerintem ijesztő, de hát tényleg ez van. Mire valami kijut élesbe, már rég kész lennél a következő verzióval.

A folyamatnak ezen a végén megintcsak elkezdenek problémák jelentkezni, amik a process-ből adódnak. Páran (néha a többség) félreértették a processzt, nem igazodtak ki az eszközökön. Vannak tipikus problémák, például számítógépektől jogosan várjuk el, hogy nagyon sokáig emlékezzenek egy dologra és ha a feladat végrehajtásának két lépése között eltellik 2-3 hét, akkor is mintha az elöbb történt volna, tudják folytatni. Embereknél ez egészen viccesen nem működik, 2-3 hét alatt teljesen elfelejtik, hogy hol tartottak és amire ennyit kell várni, az egyszerűen ennél a lépésnél megakad és az emberünk totál elveszti a fonalat. Ez a dolog kellene a munkájához, szóval mit csináljon két hétig? Minden alkalommal menjen el nyaralni, amikor belefut egy ilyenbe? Egész életét havajon töltené.
Programozók ilyenkor szoktak jönni azzal, hogy "az én gépemen futott", a managerek pedig azzal védekeznek, hogy "nekem sikerült". Például a munkaadómnál a legrövidebb általam ismert SLA 10 munkanap, azaz két hét.

2011. január 10., hétfő

backend fail

Mintha nálam tipushiba lenne a gubancos backend, amit integrálni kell a rendszerhez. Az egyik SOAP-os backend pl NPE-t vág az arcomba kiszámíthatóan minden alkalommal, amikor egy bizonyos metódust meghívok rajta teljesen tökmindegy milyen paraméterekkel. Állítja a szakember, hogy rosszul van telepítve és én hiszek is neki, csak akkor kérném hogy telepítsék fel jól, mert én akármit csinálok, mindig NPE lesz belőle.
A másik backend egy sima XML+http és a szerver oldalon mysql+php, de valami trükköt mégis csinálhattak rajta, a continuous integration szerver ugyanis egymás után kétszer is hibát jelzett a tesztben. Egyből éreztem kis motivációt utánnanézni és ez derült ki: két rekordot küldök át neki, a másodikban benne van az első ID-je, amit nyilván csak akkor kapok meg, ha az első sikeres volt. Általában működik is, de néha nem, néha azt van képe állítani, hogy az előző rekord nem létezik. Tipikus cluster hibának tünt elsőre, hátha aszinkron replikáció van adatbázisok közt, hogy az is "elég jó" és akkor kicsit várni kell, hogy szétreplikálódjon az első rekord, mielött becsapódik a második. Savanyú arccal a kettő közé tettem egy obj.wait(fubar)-t és lefuttattam újra a tesztet és ocsmány pofáraesés... megint elhalt. Úgyhogy kijött szépen az obj.wait és a helyére bement egy catch és retry. Most gondolj egy szóra... nekem is csúnya szó jutott eszembe.
Régebben meg volt a paypal történet, amit ha nem velem történik, nem hinném el senkinek és volt egy egész csinos rakás kis buhera a többi gubancos backendek kezelésére, azt gebaszos backendek egész hada idézte elő, az akkori projectem 9 backenddel tartott kapcsolatot. Mára azok szerencsére elmúltak de a helyükre újak jöttek.

A gubancos backendek megfigyelésére a múlt héten összeütöttem egy kis webappot és ez életem egyik leggyorsabban megtérülő befektetése lett :-) másnap reggel máris hibát jelzett és még a helyszinen elkaptam a merénylőt, aki buherálta az adott backendet.

Szóval a backendek az eddigi tapasztalatok szerint kulcsfontosságúak a szoftverhibák megvalósíŧásában. Ha csak egy mód van rá, használj inkáb beágyazható megoldást, legyen pár failover opciód, hogy ne menjen dőljön be az egész project, ha egy szolgáltató kifekszik.
A felhasználóidat ugyanis nem fogja érdekelni, hogy hol és miért volt gubanc, nekik áldozat kell majd és te vagy a legközelebb.