Archívum

A(z) ‘Nincs kategorizálva’ kategória archívuma

Startup inkubátor

november 27th, 2011 2 hozzászólás

Az előző postban azt próbáltam fejtegetni, hogy mennyire nehéz itthonról elindítani egy projektet. Azóta kicsit gondolkodtam a dolgokon, és rájöttem, hogy a helyzet még ennél is sokkal rosszabb, hiszen vannak dolgok, amik sokunknak triviálisak, viszont egy geek-nek nem feltétlenül. A költségek elszámolásához például élből kell egy cég, de szükség lehet technikai háttérre, jogi segítségre, mások tapasztalatára, stb. ahhoz, hogy egy ötletből valódi termék vagy szolgáltatás legyen. Huszonéves korában az ember még talán úgy gondolja, hogy magányos ninjaként, pusztán egy notebookkal felvértezve megválthatja a világot. De azért lássuk be, ehhez baromi nagy mázli kell. Éppen ezért szerintem a jó ötletek nagy része még az elején elhal. Egy huszonéves geek-től persze nem is várhatjuk el, hogy értsen a dolgok jogi hátteréhez, menedzselje magát, stb. Így aztán kicsiny hazán Mark Zuckerberg-jei valószínűleg rövid úton eltűnnek a süllyesztőben …

A megoldás talán olyan inkubátor cégek (vagy inkább alapítványok) létrehozása lehetne, akik ezeket a gondokat leveszik a geek-ek válláról, és lehetőséget biztosítanak nekik a kibontakozásra. A dolog valahogy úgy működhetne, hogy az ötletgazda valamilyen formába önti az ötletét (mondjuk PHP-ban összetákol egy közösségi portált), majd felkeresi az inkubátor céget, a cég pedig segít neki az infrastrukturális, jogi, pénzügyi háttér megteremtésében. Ennek a jogi formája valahogy úgy nézhetne ki, hogy az ötletgazda felhasználásra “bérbe adja” az ötletét a cégnek. A bevételeket az inkubátor cég fogadja be és a költségeket is az inkubátor cég állja ezekből a bevételekből. Ha valamilyen nyereség áll elő, azt szerzői jogdíj formájában lehetne kifizetni az ötletgazdának. A szerzői jogdíj talán az egyetlen út arra, hogy magánszemélynek pénzt adjon a cég úgy, hogy annak ne kelljen munkaviszonyban állnia a céggel. A konstrukció előnye, hogy így a startup cég gyakorlatilag nulla befektetéssel elindítható. Nem kell céget alapítani, könyvelőt, jogászt, stb. fizetni. E mellett, mivel az inkubátor cégnek (vagy alapítványnak) ez a profilja, valószínűleg gyakorlata lenne olyan dolgokban, hogy miképp kell adsense, paypal, stb. bevételek után adózni, külföldi számlákat elszámolni, stb. Ezek cseppet sem triviális dolgok, fórum bejegyzések százai szólnak arról, hogy miképp kéne legálisan elszámolni a Google-től kapott reklám bevételt. E mellett egy ilyen cég lehetőséget biztosíthatna arra, hogy a geek-ek társakat kereshetnek ötleteik megvalósításához, vagy később a befektetők rátalálhassanak az ígéretes startupokra. Mivel a cég csak használná az ötletet, maga a szellemi termék végig az ötletgazda kezében maradna, a szolgáltatás az ő általa választott infrastruktúrán futna, így nem kellene tartania attól, hogy bárki is “lenyúlja” az ötletét. A cég (bár egyre inkább az alapítvány tűnik szimpatikusnak) csak a pénzügyi és jogi hátteret adná. Ha később az ötlet kinövi magát, az ötlet gazdája bármelyik pillanatban kiviheti azt egy különálló cégbe, hisz onnantól kezdve már nincs szükség az inkubátorra. Maga az inkubátor cég a bevétel bizonyos százalékát tartaná meg magának, ebből fedezné saját működési költségeit. Ez némi plusz terhet ró az ötletgazdára, de mivel többen vennék igénybe az inkubátor cég szolgáltatását, ezért a költségek szétoszlanának. Talán még szimpatikusabb megoldás az alapítványi forma, ahol a működési költség egy nagy részét piaci szereplők adományai adnák. Hát, valami ilyesmi körvonalazódott az agyamban …

Ez persze még nem oldaná meg a barátságtalan gazdasági környezet problémáját, de talán segíthetne abban, hogy a jó ötletek ne halljanak el még azelőtt, hogy igazán megszületnének …

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)
Categories: Nincs kategorizálva Tags:

Jó dolog-e megölni az innovációt?

november 26th, 2011 2 hozzászólás

Bizonyára sokan ismerik a Diaspora projektet. Ez egy Facbook-hoz hasonló közösségi háló, viszont teljesen nyílt és ingyenes. Bárki csinálhat vele magának egy saját kis Facebook-ot (bár inkább Google+-ra hajaz). A nagy jóság, hogy az egyes saját kis Facebook-ok (itt pod-nak hívják ezeket) felhasználói felvehetik egymást. Így egy hatalmas, világméretű közösséget alkotnak. Kb. erről van szó. De ebben a bejegyzésben nem is ez a lényeg …

A rendszer története mesébe illő. 4 egyetemista diák kitalálta ezt a kis okosságot, és meghirdette egy Kickstarter
nevű adomány gyűjtő oldalon. Kezdetben 10.000$-t kértek a megvalósításra. Ennyi kellett ahhoz, hogy létrehozzák ezt a teljesen ingyenes rendszert. A dolognak valahogy híre ment. A NewYork Times is írt az “ingyenes Facebook”-ról. Az embereknek tetszett az ötlet, és tolták is az adományokat. Annyira nagy sikere volt, hogy végül a 10.000$ helyett összejött több mint 200.000$. Azóta a srácok előálltak az alpha verzióval és remélhetőleg a projekt egyenes úton menetel a siker felé. Igazi amerikai sikertörténet, ugye?

Ez annyira jól hangzott, hogy gondoltam magam is belevágok valami hasonlóba. Szabadúszó fejlesztő vagyok, amúgy is projekt munkákból élek. Miért ne lehetne az egyik projektem egy Diasporához hasonló ingyenes rendszer, amit nem valamilyen konkrét megrendelő fizet, hanem a közösség dobja össze rá a pénzt? Szívesen dolgoznék rajta, örömmel töltene el a fejlesztés. Megcsinálnám ingyen is, de valamiből ugye élni kell. Ezért kellenek az adományok …

Utána olvastam hát kicsit a Kickstarteren ennek a Diaspora projektnek és véletlenül találtam egy projekt elszámolást. Itt tételesen látszik, hogy miként költötték el a srácok a pénzt. Jártak konferenciákra, nyomtak pólókat, de ugye a legnagyobb rész a fejlesztők fizetése. 4 ember fizetése 1 évre 103 202$, erre az adó 10 549$ és volt valami Disability Isurance (talán a TB lehet), ami 1 083$. Összesen tehát olyan 11% ment el mindenféle adókra meg hasonlókra a fizetések után. Na, kb. itt ment el a kedvem az egésztől. Mi van, ha összegyűjtök valamennyi pénzt az én kis projektemre és valaki kér egy ilyen elszámolást tőlem? SZJA, TB, stb., és rögtön 40-50%-a el is ment a pénznek adóba. Csinálhatom EVA-s cégként (mondjuk feltételezem, hogy máshol kapom a jövedelmem), így 30% (jövőre 37%). Ez eggyel barátibb, de még így is égne a pofám, hogy az adományként kapott pénz egy jó részét nem a projektre fordítom. Nem érdekes, hogy közhasznú a dolog és teljesen nonprofit. Csinálhatok rá alapítványt, stb. akkor is így kell adóznom utána. Ha adományozó lennék, én nem szívesen adnék így pénzt egy projektre, hogy tudom, a pénzem egy igen jelentős része nem a projekt megvalósítására fordítódik. Mit lehet hát tenni?

Az egyik lehetőség, hogy az ember vagy megcsinálja a szabadidejében (ami így akár a végtelenségig húzódhat), vagy egész egyszerűen hagyja az egészet a francba. A bátrabbja megpróbálhatja összegyűjteni a pénzt és ha szerencséje van, sikerül eltitkolnia az adóhatóság elöl, ami viszont elég rizikós.  Végső megoldás, hogy az ember külföldön alapít egy offshore céget. Ez utóbbi azért elég bonyodalmas, és az egyszeri geek, akinek volt egy jó ötlete, biztosan nem jut el ideáig. Ráadásul ez is csak fél legális megoldás, mert ha haza akarom hozni a pénzt, megint kezdődik a susmus.  Ezekben a megoldásokban egyetlen közös motívum van. Az államnak egyikből sincs bevétele. Jó ez vajon? Nem hiszem …

Hát, ezért nem Magyarok fogják fejleszteni a következő Diasporát …

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)
Categories: Nincs kategorizálva Tags:

Banki hitel vs. közösségi kölcsön

november 19th, 2011 Nincsenek hozzászólások

Távol áll tőlem a közgazdaságtan, a politika meg még inkább. De az informatikai vonatkozás miatt úgy gondoltam, megér a dolog egy bejegyzést. Mostanában a csapból is az folyik, hogy milyen nagy gondba kerültek azok az emberek, akik annak idején hitelt vettek fel devizában, most pedig dupláját kellene kifizetniük. Egy barátom is ebbe a helyzetbe került, aztán kitalálták ezt a végtörlesztés dolgot, és gyorsan élt is a lehetőséggel. Ahhoz viszont, hogy visszafizesse a kölcsönt, egy másik hitelt kellett volna felvennie, és hát az sem volt azért annyira csábító. Az volt a szerencséje, hogy egy másik barátomnak volt némi elfekvő pénze, amit eddig a bankban tartott. Megegyeztek hát, hogy az egyik barátom kölcsön adja a pénzét a másik barátomnak, és a banki hitelnél sokkal kedvezőbb kamatot kér érte. A hitelt visszafizető barátomnak ez nagyon jó, mert kevesebb kamatot kell fizetnie, és a hitelező barátom is jól jár, mert magasabb kamatot kap a pénzére, mint amit a bank adna. Nem egy hatalmas trükk, a bank is ezt csinálja, beszedi az egyik oldalon a pénzt, ígér rá X % kamatot, a túloldalon meg kölcsönadja Y%-ért. A kettő közötti különbséget meg zsebre teszi. Ebből vannak a szép márvány épületek, a csodaszép autók, meg a tengerparti nyaralók. A barátomék kihagyták a dologból a bankot, így aztán mindenki jól járt (természetesen a bankot kivéve). Amikor meghallottam ezt a rövid kis történetet, akkor fészkelte a fejembe magát az a gondolat, hogy miért nem tud ez nagyban is működni? Hányan lennének a mostaninál sokkal kisebb slamasztikában, ha lenne egy ilyen barátjuk, akinek van egy kis elfekvő pénze …

Aztán rájöttem, hogy ezt a dolgot igazából már kitalálták, erre való a közösségi kölcsön. Ezzel próbálkozik pl. a noba.hu. Itt ugye az történik, hogy vannak emberek akik hitelt szeretnének felvenni, és vannak emberek, akik pénzt adnának némi kamatért cserébe. Mivel az egész folyamatból hiányzik a bank, ezért a hitelezők kérhetnének kicsit magasabb kamatot mint amit a bank adna, a hitelt felvevők pedig még így is jobb feltételekkel kapnák meg a pénzt mint a banktól. Amit amúgy a bank tesz zsebre, az szétoszlana a két fél között. Egy gond van csak, hogy Magyarországon ilyet nem lehet. Nem adhatok kölcsön pénzt a haveromnak kamatra. Ennek ellenére azért adok neki, csak mivel ennek nincs szabályos formája, ezért nem lehet pl. megadóztatni. Ami ennél is rosszabb, hogy ha valakinek nincs kitől kölcsönkérni, akkor megy az uzsoráshoz, aki irreális kamatot kér a pénzre, és ha nem fizet a delikvens, még jól meg is veri. Lehet, hogy lenne kellő kereslet és kínálat is, de ezek az emberek nem fognak egymásra találni, mert ez az egész jelenleg illegális. Így nem készíthetek olyan weblapot, ahol kamatra adhatnak kölcsönt egymásnak emberek. Nem azt mondom, hogy ez megoldaná minden eladósodott ember problémáját, de ha csak néhány embernek segítene a dolog, akkor már volt értelme …

A közösségi hitelezéssel kapcsolatban sokaknak lehet ellenérzése. Például hogy mi a biztosíték arra, hogy a kölcsönt adó visszakapja a pénzét. Erre például az lehet a megoldás, hogy sokan adnak kölcsön sokaknak. Mindenki mondjuk csak néhány ezer Ft-ot dob be egy-egy kölcsönbe. Így ha van mondjuk 100 000 Ft-om, akkor azt nem egy embernek adom oda, hanem 20-nak. Így megoszlik a kockázat. Persze még így is megeshet, hogy elözönlik a szolgáltatást azok, akik ilyen kölcsönök vissza nem fizetéséből próbálnak meggazdagodni. Ezt talán a mostanában már eléggé elterjedtnek mondható közösségi hálózatok segíthetnének megoldani. Az emberek minősíthetnék egymást, a hitelezők “lenyomozhatnák” kinek adnak kölcsön. Például ha a barátom barátja szeretne kölcsönt kérni, akkor megkérdezhetem a barátomat, hogy a kölcsönt kérő mennyire megbízható. Végső soron pedig ott a törvényi megoldás, a kölcsönt kérő valamilyen írásbeli biztosítékot ad a hitel visszafizetésére. Talán ez utóbbi rendezésére és betartatására érdemes lehet fenntartani valamilyen köztes szervet, de semmiképp nem egy márványépületeket, telefonos kisasszonyokat, és gazdag bankárokat fenntartó bankot.

Talán egy lehetséges megoldás, ha a közösségi hitelezést szervező weboldal papíron bank lenne. Olyan bank, ami teljesen online működik, minimális haszonnal, és ahol az egyes ügyfelek teljesen direkt módon megmondhatnák, hogy a bank hova fektesse a pénzét (kinek adjon kölcsön). A bank tehát bankként adna hitelt, és adna kamatot az emberek pénzére, de mindezt minimális haszonnal, és személyre szabottan. Hiszen mindenki azon emberek után kapná meg a kamatot, akiknek a bank az ő jóvoltából kölcsönt adott. Nem ismerem a vonatkozó törvényeket, de ez így talán kivitelezhető lenne. A pénz az országban maradna (nem egy külföldi tulajdonú bank keresne rajta), meg lehetne adóztatni, és mindenki jól járna, a kölcsönt szervező weboldal fenntartója, a kölcsönt adó, és a kölcsönt felvevő is …

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)
Categories: Nincs kategorizálva Tags:

Az élet szabadúszó fejlesztőként

február 18th, 2011 2 hozzászólás

Már jó pár éve dolgozom fejlesztőként. Abban a szerencsés helyzetben vagyok, hogy a munkám egyben a hobbim is. Igazából a programozást inkább érzem valamiféle művészetnek, ahol ugyanúgy jelen van az intuíció, az ihlet, a kód, az algoritmusok, és a komplett megoldások szépsége, mint más művészeti ágak esetén. Persze mivel ebből kell megélnem, ez sokszor amolyan megélhetési művészet, de akkor is művészet. Mikor kikerültem a főiskoláról a fejlesztők szokásos útját kezdtem járni. Egy fejlesztő cégnél helyezkedtem el viszonylag jó kezdőfizetésért. Bizonyos magánéleti okok miatt, és mivel nem találtam elég kreatívnak a munkát, 1 év után az MTA Számítástechnikai Kutatóintézetére váltottam. Itt kisebb nagyobb külföldi és magyar projekteken dolgoztam, konferenciákon vettem részt, rendszerek tervezését és fejlesztésének vezetését végezhettem, így ez a munkakör már jobban kielégítette az igényeimet. Néhány év után viszont a SZTAKI-t is magam mögött hagytam. Alapvetően jó fejlesztőnek tartom magam, és továbbléphettem volna a “jó fejlesztők” szokásos útján. Elhelyezkedhettem volna egy külföldi multinál (elvileg a Google-hez is lett volna egy kis hátszelem) valami zsíros fizetésért, mégis egy sokkal bizonytalanabb, bár annál több lehetőséget magában rejtő utat választottam. Otthagytam a biztos állásomat, és vidékre költöztem a barátnőmmel (aki azóta már a feleségem), hogy otthonról szabadúszó fejlesztőként távmunkában dolgozzak változatos projekteken. Gondoltam, hogy nem lesz olyan egyszerű a dolog, és hát tényleg nem is az …

Általában az a baj, hogy a cégek fix fejlesztőket keresnek napi 8 órás munkaviszonyba. Az ember azt gondolná, hogy a szoftverfejlesztés tipikusan az a munkakör, amit ideálisan lehetne végezni otthonról távmunkában (ami különben tényleg igaz), érdekes módon mégis csak több-kevesebb nehézség árán talál magának az ember ilyen otthonról végezhető projektmunkát. Sokáig próbáltam megérteni, hogy mi ennek az oka, és végül tapasztalatból mondhatom, hogy ez egyszerűen nem más, mint rossz beidegződés, hiszen szabadúszó fejlesztők alkalmazásának rengeteg előnye van az alkalmazottakkal szemben …

Az első és talán legegyértelműbb előny, hogy ha a fejlesztő otthonról dolgozik, úgy nincs szükség semmilyen infrastruktúra fenntartására. Nem kell irodát bérelni, nem kell számítógépeket, irodabútorokat biztosítani, nem kell áramért, fűtésért, vízért, stb. fizetni, így egy ilyen fejlesztő összességében sokkal kevesebbe kerül, mint egy alkalmazott. Amennyire tudom, a SZTAKI-ban a bevétel felét vitte el a rezsiköltség, amit egy szabadúszó fejlesztő esetén megspórolhat az őt alkalmazó cég. Negatívumnak igazából csak a személyes kontaktus hiányát lehetne felhozni, de erre viszont ott a Skype, a videokonferencia rendszerek, stb. A SZTAKI-ban több nemzetközi projektben is részt vettünk, ahol értelemszerűen nem lehetett biztosítani a személyes kontaktust. Tapasztalatból mondhatom, hogy a videokonferencia rendszerek alkalmazása vagy a Skype meetingek teljes mértékben kiváltották a személyes találkozókat.

A másik nagy előny, hogy ha az ember szabadúszó fejlesztőkkel dolgozik, a megbízónak nincs semmi kötöttsége. Egy alkalmazott esetén annak folyamatosan fizetést kell adni, aminek egyfelől adminisztrációs vonzata van (bérszámfejtés, járulékok fizetése, ha elégedetlenek a munkájával, és ki kell rúgni, akkor végkielégítés, stb.), másfelől a fix alkalmazottnak havonta kell fizetést adni, amit folyamatosan ki kell termelni. Ez egyfelől plusz terhet ró a megbízóra (könyvelés, fejlesztő eltartása), másfelől mivel a szabadúszó fejlesztők cégekként számlára dolgoznak, általában sokkal optimálisabban tudják elszámolni a költségeket, így végső soron olcsóbbak, mint egy fix fejlesztő. E mellett mivel projekt alapon történik az alkalmazás, ha az alkalmazó elégedetlen a fejlesztő munkájával, akkor a következő alkalommal nem veszi igénybe azt, nem kell neki végkielégítést fizetni, stb.

Mivel az alkalmazó cégek maguk általában projekt alapon dolgoznak, a fix alkalmazottakat viszont folyamatosan fizetni kell, ezért sokszor olyan helyzet alakul ki, hogy vagy nincs munka, és az alkalmazottak erőforrásai nincsenek lekötve, vagy (és általában ez a gyakoribb) túl sok a munka 1 emberre, és az alkalmazottak túl vannak terhelve. Én is több ilyen esetre emlékszem, mikor egyik hónapban csak tébláboltunk, mert nem nagyon volt mit csinálni, a másik hónapban viszont többször is hajnalig bent kellett maradni, hogy tartani tudjuk a határidőket. Ez sem az alkalmazónak,sem az alkalmazottnak nem jó. Van aki nem is bírja az ilyen egyenetlen terhelést, és előbb-utóbb otthagyja a munkahelyet emiatt, pedig ezt a problémát dinamikusan allokálható fejlesztőkkel nagyon könnyen át lehetne hidalni. Valójában erre építenek a mostanában egyre divatosabb outsourcing cégek is, viszont ezek a cégek meglehetősen nagy jutalékokkal dolgoznak, és mivel ők már alkalmazottakat foglalkoztatnak, sokkal drágább ez a megoldás, mint közvetlenül a fejlesztővel dolgoztatni. Az outsourcing cégeknél persze megvan az az előny, hogy biztosan megbízható fejlesztőket kap a megbízó, viszont megfelelő ütemezéssel egy szabadúszó fejlesztőről is hamar eldönthető, hogy megbízható-e, vagy nem.

Az eddigiek alapján tehát szerintem egyértelműen látszik, hogy ez a modell több szempontból is sokkal hatékonyabb mind az alkalmazó cég, mind a fejlesztő számára. Mindennek ellenére azt tapasztalom, hogy az emberek még nagyon bizalmatlanok ezzel szemben, és szabadúszó fejlesztőként nem olyan egyszerű projektet találni. Bár külföldi tapasztalatom nincs a dologgal kapcsolatban, de Magyarországon bizonyosan ez a helyzet, az ok pedig szerintem nem más, mint egy egyszerű beidegződés, egy minta, aminek megtartása a jelenlegi technikai környezetben már nem indokolt, és nem is optimális. Mára már egy cég teljes infrastruktúrája kiszervezhető, Internet kapcsolattal már mindenki rendelkezik, és egy alkalmazó cég semmivel sem tud jobb infrastruktúrát biztosítani, mint az otthoni környezet. A VPN-nek, videókonferenciának, feladat kezelő rendszereknek köszönhetően igazából teljesen mellékes, hogy a fejlesztők egymás melletti irodákban, vagy éppen külön kontinensen dolgoznak. A jelenlegi helyzet engem arra emlékeztet, ami mostanában a cloud computing (felhő infrastruktúra) körül történik. A cloud computing napjaink egyik divatszava, és tulajdonképpen az infrastruktúra bérlését jelenti egy elosztott rendszerben saját szerverek helyett. Sokáig az volt a szokványos módszer, hogy minden feladatra külön szervert állított be a cég. Így rengeteg gép dolgozik még ma is kis terheltséggel teljesen feleslegesen. A cloud computing segítségével sok funkció, vagy akár az egész géppark a cloud-ra költöztethető, így a fenntartása nagyságrendekkel olcsóbb, és biztonságosabb is, a cégek mégis bizalmatlanok a technológiával szemben. Ez a trend napjainkban kezd megfordulni, kezdik elfogadni a cégek a cloud computingot, kezdenek megbízni benne, és kezdik felismerni az ebben rejlő lehetőségeket. Úgy gondolom, hogy néhány év múlva már a cloud computing lesz a vezető irányzat, ha más nem, azért, mert a cég másképp nem lesz versenyképes, képtelen lesz a piacon versenyben maradni úgy, hogy közben ki kell termelnie saját infrastruktúrájának fenntartási költségeit. Valami hasonlót látok a munkaerő vonatkozásában is. A saját szerverek fenntartása az alkalmazottak foglalkoztatásával hozható párhuzamba, míg a cloud computingnak köszönhető erőforrás kihelyezés a szabadúszó fejlesztők foglalkoztatásának felel meg. Látszanak az erre való törekvések, az outsourcing már egészen elfogadott megoldás, és tulajdonképpen ennek a közvetlenebb, “p2p” változata a szabadúszó fejlesztők alkalmazása. A különbség annyi, hogy a cloud computing már a küszöbön van, a szabadúszó fejlesztők elfogadásához, és a jelenlegi “beidegződések” elhagyásához pedig még kell némi idő. Mint oly sokszor már, a környezet már most is adott, egyszerűen fejben kellene csak utolérni a technológiát, és élni a lehetőségekkel, aki pedig időben lép, az egyértelmű piaci előnyökké konvertálhatja a lehetőségeket.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)
Categories: Nincs kategorizálva Tags:

SimpleRSA

október 28th, 2010 Nincsenek hozzászólások

Nem tudom hányan próbáltak már Java-ban RSA-val titkosított dokumentumokat PHP-ból olvasni, vagy fordítva, esetleg Java-ban aláírt dokumentumok hitelességét PHP-ból ellenőrizni, de mindenesetre nekem most ilyenre volt szükségem. Naív módon azt hittem, hogy a nyílt kulcsú titkosítás valami egyszerű dolog (mármint programozás szintjén a megfelelő library-k használatával), fogok valami RSA library-t, egyik oldalon elkódolom valami függvénnyel, a másik oldalon kikódolom, és ennyi. Néhány napi Google használat után, elveszve a különböző kulcsformátumok, és certificate-ek között, rá kellett döbbennem, hogy ez az egész mégsem annyira triviális. A gond forrása, hogy a PHP (és amúgy más szkript nyelvek is) az OpenSSL-t használja a titkosításhoz, míg Java esetén ott a Crypto API, aminek viszont nem sok köze van az OpenSSL-hez. Gondoltam keresek valami Java OpenSSL wrappert, de ilyet sem találtam. A gond tulajdonképpeni forrása az volt, hogy a PHP-s titkosításhoz és aláíráshoz PEM fájlból kellett volna olvasni a kulcsokat, ilyen formában viszont sehogyan sem tudtam menteni a Java-ban generált kulcsokat. Az alkalmazás jellege miatt mindenképp Java-ból akartam generálni a kulcspárt, tehát az a megoldás nem jöhetett szóba, hogy openssl-el készítem el a kulcspárt, és majd azt használom PHP és Java esetén is.  Végül a megoldást a BouncyCastle Java library hozta el számomra, hiszen végül itt sikerült PEM fájl kezelő objektumokat találnom. Össze is raktam egy teszt kódot, és csodák csodájára a PHP kód képes volt olvasni a Java-ban generált kulcsokat, visszafejteni a Java-ban titkosított doksikat, és ellenőrizni az aláírások hitelességét.

Mivel nekem is sok segítséget nyújtottak mások leírásai, szinte kötelességemnek éreztem, hogy valamiképp megosszam frissen szerzett tudásomat. Ennek az egyik formája, hogy kódrészleteket közöl az ember (én is sok ilyenekből szedtem össze az RSA-val kapcsolatos tudásomat), én azonban azt tettem, amit eddig is, összeraktam egy kis library-t, amivel nagyon egyszerűen tudunk be/ki kódolni, illetve digitálisan aláírni adatokat. Egyre inkább az a meggyőződésem, hogy az ilyen kis minimál library-k sokkal hasznosabbak, mint a kóddarabok, vagy akárhány részletes leírás, hogy ezt meg azt hogy kell csinálni. Az elkészült library Java és PHP nyelven elérhető, és metódusok szintjén azonos, így elég egyetlen programkönyvtár használatát elsajátítani.

A kódot, ahogyan eddig is mindig, feltöltöttem a Google Code-ra, itt elérhető:
http://code.google.com/p/simplersalibrary/

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)
Categories: Nincs kategorizálva Tags:

Zeitgeist Addendum

július 23rd, 2010 5 hozzászólás

Néhány napja láttam a Zeitgeist Addendum c. dokumentumfilmet (torrent site-okról magyar szinkronnal, vagy felirattal beszerezhető, de YouTube-on is fent van). A film a Zeitgeist Movement projekt ismertető filmje, és bár néhol kicsit összeesküvés szagú, mégis nagyon elgondolkodtató. Rám olyan nagy hatással volt, hogy mindenképp úgy éreztem megér a dolog egy blogbejegyzést.

A film első fele a pénzügyi rendszer működését taglalja, és hogy a rendszer milyen alapvető hibákkal rendelkezik, és hogy hosszú távon miért nem működőképes.  A film “kistestvére” a Pénz mint adósság (torrent siteokról ugyancsak beszerezhető felirattal, de talán szinkronnal is, és darabokban ugyancsak fent van YouTube-on), ami rajzfilmes formában közérthetően magyarázza a rendszer alapvető hibáit. Mivel nem vagyok közgazdász, nem is vállalkoznék rá, hogy elemezgessem az elmondottakat, de mindenesetre elég logikusnak tűnik az egész. E mellett azért van néhány tény, ami elég erőteljesen alátámasztja a történetet. A rajzfilm lényege röviden annyi, hogy mindegy kik az aktuális politikai vezetők, a világot a tőke mozgatja, és ez által azok irányítják, akik a tőke felett rendelkeznek. Az persze kérdéses, hogy ezt az egész rendszert valóban valamiféle világuralmi szándékkal hozta-e létre valamiféle titkos társaság, de mindenesetre tény, hogy a világ vagyonának nagy részét néhány mocskosul gazdag ember birtokolja, és az előbbiek fényében az is elég egyértelmű, hogy nekik meg van a kellő hatalmuk ahhoz, hogy “irányítsák” a világot. Hogy az egész folyamatot lássuk, nem kell messze menni, itt a nemrég átvészelt (?) világválság. Amerikában bedől (bedöntenek?) néhány bank, és itt Magyarországon egy rakás ember elveszíti a házát, munkáját, stb. Szinte érezni lehetett a hullámokat, amik az USA felől cunamiként zúdultak sokakra. És mindebben azért van valami nagyon félelmetes. Ott, egy másik kontinensen tőlünk iszonyat távolságban valami megmozdul, és annak itt isszuk meg a levét. Ilyenkor azért valahol meg tudom érteni a globalizációt ellenzők félelmeit. Az megint kérdés, hogy ez a válság csak úgy bekövetkezett (állítólag lehetett rá számítani, és a lehetősége benne volt a rendszerben), vagy mesterségesen gerjesztették, de tény, hogy akár esés, akár emelkedés van a tőzsdén, ha valaki azt előre tudja, azzal iszonyat pénzt szakíthat. Ha előre tudjuk, hogy a részvényeink árfolyama esni fog, még időben eladhatjuk őket, ha pedig az emelkedésről tudunk, jó időben bevásárolhatunk belőlük. Ennek fényében tehát tényleg busásan megéri ilyen gazdasági folyamatokat gerjeszteni, tehát logikus lenne, ha az egész egy mesterséges folyamat eredménye lenne. Ami viszont a leges legdurvább az az, hogy vagyon (szándékosan nem pénzt írok) nem lesz a semmiből, egy ilyen esetleges manipuláció hatására pedig nagy mennyiségű vagyon cserél gazdát. Elég ha azokat az embereket hozzuk fel példának, akik a válság hatására elveszítették a házukat. És itt azért figyeljünk fel a helyzet groteszk mivoltára. Valaki élete munkájával felépít egy házat, éli az életét. Egyszer csak valami történik, megremeg a világpiac, a házat meg elviszi a bank. Szegény ember még csak fel sem ocsúdott, és már az utcán van kisemmizve. Ő nem tett semmi rosszat. Ugyanolyan becsületesen dolgozik ugyanannyit mint eddig, erre valaki kirántja alóla a munkája gyümölcsét. Persze gazdasági folyamatok vannak a történések hátterében, drágább lett a svájci frank, amiben a hitelt felvette, stb. stb. de ezeket egy pillanatra felejtsük el, és nézzük csak a történéseket. Ő becsületesen dolgozik, és egyszer csak volt ház, nincs ház. Ha kicsit átérezzük a helyzetét, valószínűleg mi is úgy gondoljuk, hogy ez az ember jogosan érzi meglopva magát. És ez a szörnyű az egészben, hogy valaki valóban elvette a házát, valahol valóban meglopták őt, de nem mehet a rendőrségre, nem jelenthet fel senkit, hisz az egész teljesen legálisan történt. De ki az aki meglopta őt? A bank, akitől a kölcsönt felvette? Részben talán igen, ő is keresett az ügyleten, de a folyamat végén valószínűleg azok a nagy tőkések vannak, akik az egész dologból profitáltak (és talán gerjesztették is). Nincs kellő közgazdasági alapom hozzá, hogy végigkövessem a folyamatot, de ha azt látjuk, hogy a világ egyik felén valaki elveszíti a vagyonát, a másik felén meg valakinek nő a vagyona, akkor jogosan merül fel az emberben a gondolat, hogy ugyanaz a vagyon vándorolt át egyik helyről a másikra. Ez az egész pedig már kifejezetten rémisztő, hogy az USA-ban valaki a tengerparton sütteti a hasát, miközben a világ vagyona folyamatosan vándorol át hozzá. Ha úgy tetszik, úgy lopja meg az embereket, hogy közben a kis ujját  sem mozdítja. Eleve már az természetellenes, hogy valaki dolgozik a pénzért, valaki (akinek elég sok van) meg felteszi a lábát, és a pénze dolgozik helyette. Hogy tud egyáltalán a pénz dolgozni? Szóval azért látható, hogy a rendszerrel valami nincs rendben, de annyira megszoktuk, annyira elemi, hogy nem érezzük ellentmondásosnak ezeket a dolgokat. Persze ez csak az én értelmezésem a dolgokra, mindenképp érdemes megnézni a filmet. Térjünk is vissza rá.

A filmnek kb. az első negyede szól a pénzalapú rendszerről. A második negyede azt boncolgatja, hogy az USA által vívott háborúk igazából gazdasági érdekeket szolgáltak. Hogy talán nem is létezik a “terrorizmus”, amivel az USA feljogosítja magát, hogy rendszereket romboljon le az olajért, sőt, hogy maguk az amerikai katonák azok, akiket a leginkább átvernek, és az egész háború csak pénzgenerálás. Ahhoz megint nem érzem magam feljogosítva, hogy ezt bármilyen irányban is véleményezzem. Sokan egyszerű összeesküvés elméletnek tartják ezeket, bár azért nem kerülheti el az emberek figyelmét, hogy ők vannak kevesebben. Az amerikaiak nagy része is ellenzi az általuk folytatott háborút, és ugyancsak amerikaiak azok az újságírók, akik tényfeltáró dokumentumfilmeket készítenek szeptember 11-ről, vagy az Iraki háborúról. Ezek mellett nem lehet csak úgy elmenni, és valóban elgondolkodtató, amit ezek a filmek mondanak. Ezek az emberek a rendszeren belülről jönnek, nem európaiak, akik kívülről kritizálják Amerika túlbuzgóságát, hanem azok, akik látják, és megélik ezeket a dolgokat. Ha viszont ezek az összeesküvés elméletek igaznak bizonyulnak, az félelmetes. Több ezren vesztették életüket ezekben a háborúkban, és mindez talán csak azért, mert valakinek kellett még egy színaranyból készült Ferrari a garázsába? A háború mint olyan eleve az emberhez méltatlan dolog. Az emberek akiknek tervei, családja volt, hirtelen kis erőforrás kockákká, számokká válnak. Itt előre tolunk néhány csapatot, ott lebombázunk néhány gyárat, a végén pedig átlagot számolunk, és megállapítjuk, hogy minimális emberáldozattal megúsztuk. Remek. Az, hogy ezeknek az embereknek családja volt, hazavárták őket, az az érintetteken kívül nem érdekel senkit. És ez egy háborúban mindig mindkét oldalra egyenlően igaz. Ha pedig mindennek tényleg az a célja, hogy valakinek még eggyel több Ferrari-ja legyen a garázsban, arra nincsenek szavak. Felháborító? Ördögi? Gyilkos? Ezek túl enyhe kifejezések. Persze ez mind fikció, nem lehet egyértelműen alátámasztani, de mindenesetre elgondolkodtató. Mindez önmagában elgondolkodtató, de ami engem igazán megfogott, az a film második fele.

A film második felében esik szó a Venus Project-ről, melynek honlapja itt található, de elérhető róla néhány magyar nyelvű leírás a Zeitgeist Movement magyar nyelvű lapján is. A Venus Project egy utópia, ami az előbb említett rendszer hibáit igyekszik orvosolni. A projekt egy olyan világot képzel el, ahol nincs pénz, az ember megújuló erőforrásokból tartja fent magát, nincsenek társadalmi különbségek, a rendszer alapja pedig a technológia. Ami engem igazán megfogott, hogy valójában már most rendelkezünk a szükséges technológiai alappal ahhoz, hogy a föld teljes energiafelhasználását megújuló energiákból lássuk el INGYEN!, és hogy ha az erőforrásainkat a technológia fejlesztésre fordítanánk a háborúk, piaci verseny, profitszerzés helyett, akkor már rég “paradicsomi állapotok” közt élhetnénk. Valójában a Venus Project által felvetett kérdések engem is régóta foglalkoztatnak, ezért is annyira szimpatikus az egész. A következőkben megpróbálkozom azzal, hogy a saját gondolataimon keresztül magyarázzam a rendszer működését, és jussak el a Venus Project-hez.

Az egyik alapvető kérdés, ami engem elkezdett foglalkoztatni, az az, hogy az általunk végzett munkának körülbelül mekkora része lehet “felesleges”. Óvatos becsléssel én arra tippelnék, hogy több mint a fele. Hivatalnokok, papír tologató emberek, ügyvédek, közgazdászok, politikusok, rengeteg olyan munka van, amire tulajdonképpen semmi szükség, egyszerűen a rendszer tökéletlenségéből adódnak. Ha nem lenne ilyen mértékű bürokrácia, akkor a hivatali dolgozók szinte 100%-át el lehetne bocsájtani, ha nem lennének ilyen nyakatekertek a törvények, az ügyvédek jó részére nem lenne szükség, ha nem lenne pénz, a bankok, banki alkalmazottak, és a köréjük szervezett informatikai, biztonságtechnikai, stb. cégek mindegyikét fel lehetne számolni. Ugyanígy gondoljunk csak bele, mennyi munkát ölünk a piaci versenybe. Ha eddig a piacon volt 4-5 konkurens cég, de egyszeriben megszűnne a verseny, úgy az elvégzendő munka rögtön 1/4-ére, 1/5-ére zuhanna vissza. A gondolatot tovább folytatva eljutunk odáig, hogy egy optimálisabb rendszerben az elvégzett munka legalább fele (óvatos becsléssel, a valódi szám lehet, hogy akár 80-90% is) teljesen felesleges. Reggel felkelünk, napi 8 órán keresztül dolgozunk, aztán hazaérünk, és félholtan puffanunk le a TV elé, megnézzük a napi agymosást, fogat mosunk, megfürdünk, elmegyünk aludni, és másnap kezdődik az egész elölről. De miért is hajtunk? Tulajdonképpen semmiért. A rendszer ennyire nem optimális, és pazarló az emberi erőforrással. Az általános vélekedés az, hogy azért van szükség a piaci versenyre, mert ez hozza a fejlődést. Ha az emberek nem hajtanának, hogy legyőzzék a konkurenciát, elkényelmesednének, a világ meg megállna a fejlődésben. Ezt úgy általában véve hajlamosak is vagyunk elfogadni, de én akár csak a saját példámon meg tudom cáfolni. Én személy szerint szívesen vennék részt kutatási projektekben (pl. rákkutatás, aminek valóban értelme is van) akár ingyen is csak a kihívás miatt, de nem tehetem, mert hülyeségeken kell dolgoznom, mivel abból lesz a pénz, és valamiből meg kell élni. És még így is a “pénzkereső időmből” elvéve próbálok foglalkozni ilyen dolgokkal, csak azért mert érdekes. Nem akarom magam felmagasztalni, lehet egész életemben az ég adta világon semmit nem tudnék hozzátenni a rákkutatáshoz, de nem nehéz elképzelni, hogy mi lenne, ha a hozzám hasonló emberek, akik kihívást látnak a feladatokban (és szerintem alapvetően mindenki ilyen, csak meg kell találnia a céljait) az értelmetlen piaci verseny fenntartása helyett az igazán fontos dolgokra koncentrálhatnának. A technológia valószínűleg fényévekkel előrébb járna a mostaninál, mondom mindezt annak ellenére, hogy a jelenlegi rendszer védői úgy vélik verseny nélkül nincs fejlődés. Ez szerintem egész egyszerűen butaság. De aki még mindig szkeptikus, nézze meg a Wikipedia-t, ami mára a világ legnagyobb lexikonává nőtte ki magát, vagy a Linuxot, ami (a M$ ellenérdekeltségének ellenére) egyre több számítógépen (főleg Netbookokra gondolok) jelenik meg, és az Androidon keresztül egyre több mobilon is megtalálható. A nyílt forrás, a szabad tartalom láthatóan idővel minden fajta piaci erőt felülmúl mindezt úgy, hogy nem fűződik hozzá piaci verseny. Olyan ez a versenyen alapuló társadalomnak, mint valami kis gyomnövény, ami ha elkezd burjánozni idővel túlnő mindenen. Tehát az emberekben szerintem igenis megvan ez a fajta alkotni vágyás, csak olyan mélyen beléjük égett a pénz és a verseny gondolata, hogy képtelenek magukat kiemelni a rendszerből. A közgazdaságtan próbál modelleket felállítani az ingyen dolgokra, azt mondja, hogy ez egyfajta marketing, de végső soron (pl. mikor a Wikipedia-t, ahol nincsenek reklámok, tisztán adományokból él, képtelen beilleszteni bármilyen modellbe) be kell látnunk, hogy az ingyenesség valahol alapvető és természetes. No de térjünk vissza az eredeti gondolatmenethez, és képzeljünk el egy világot, ahol az emberek nem végeznek felesleges munkát. Ha úgy gondolkodunk, hogy egy igazságos társadalomban mindenki egyenlően veszi ki a részét mindenből, akkor a meglévő munkát (ami a technológiát is figyelembe véve már szinte minimális) kb. egyenlően kell felosztanunk az emberek között. Így ha óvatos becsléssel fele annyi a munka, minden embernek fele annyit is kellene dolgoznia. Így több idő maradna a családra, a szórakozásra, elmélkedésre, mindenre, amire az ember alapvetően vágyik, a rendszer pedig a fenntartható fejlődés jegyében újrahasznosítható anyagokat és megújuló energiákat felhasználva olyan gazdagságot teremtene az embereknek, amiről eddig álmodni sem mertek. Hát valami ilyesmi a Venus Project lényege. Egy olyan világ megteremtése, ahol a technológia, a környezetbe való teljes integrálódás, és az optimális erőforrás kihasználtság révén mérhetetlen jólétben és gazdagságban élhetnének az emberek. Ahhoz, hogy mindez valósággá váljon persze sok mindennek meg kellene változnia, de elsősorban az emberek hozzáállásának. Ráadásul elég nehéz a jelenleg működő rendszerben valami ennyire gyökeresen újat bevezetni. Ez a projekt önmagában is megérne egy új bejegyzést, úgyhogy itt be is fejezem.

Akit érdekel a téma, az mindenképp nézze meg a filmet. 2 óra, de szerintem abszolút megéri. Rám legalább is nagyon nagy hatással volt.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)
Categories: Nincs kategorizálva Tags:

JBoss POJO Cache mint adatbázis

február 16th, 2010 1 hozzászólás

Az memória alapú adatbázisok kapcsán kicsit utána néztem a postban felvetett megoldásnak, vagyis hogy a JBoss POJO Cache-re építve lehetne-e memória alapú adatbázist készíteni. A POJO Cache dokumentációja alapján elvileg minden adott ehhez. Ahogyan már írtam, clusteres kialakítás esetén a POJO cache önmagában képes a benne tárolt objektum fa transzparens replikálására, méghozzá úgy, hogy csak a változásokat szórja a rendszerben. A cache ezen kívül kezeli az objektum referenciákat, és még tranzakció támogatást is nyújt, tehát valóban minden rendelkezésre áll ahhoz, hogy adatbázis rétegként használjuk. Létezik egy mechanizmus, aminek segítségével a cache-ből kikerülő elemeket perzisztens tárba menthetjük, így a passziválás is megoldott. Ugyanígy létezik mechanizmus a változások mentésére, valamint a cache állapotának perzisztens tárolóból történő visszaállítására. A JBoss POJO Cache tehát elvileg könnyen alkalmassá tehető arra, hogy memória alapú adatbázisként működjön, sőt sokkal egyszerűbben, mint gondoltam. E ellett olyan feture-ök is eleve adottak, mint például a tranzakció kezelés. Egyedül az volt csak fura, hogy hiába kerestem a neten, nem találtam példát ilyen megvalósításra, pedig szinte adja magát a dolog. Már csak egy projekt kellene, ahol a gyakorlatban is ki lehet próbálni a fentieket …

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)

Memória alapú adatbázisok

február 15th, 2010 Nincsenek hozzászólások

A napokban ismertem meg egy új adatbázis szervezési filozófiát, az Object Prevalence -t, amit jobb híján memória alapú adatbázisnak fordítottam (tudom, hogy a szó szerinti fordításnak semmi köze ehhez, de ez adja vissza legjobban magyarul, hogy miről is van szó). A filozófia alapgondolata, hogy napjainkban a memória nem túl drága erőforrás, és megfelelő mennyiségben rendelkezésre is áll ahhoz, hogy egy rendszer teljes adatbázisát ott tároljuk. Gondoljunk csak bele, ha mondjuk egy felhasználó tárolása 5K memóriát igényel (és 5000 karakterbe aztán tényleg rengeteg adat belefér), akkor 1000 felhasználó mindössze 5Mb-ot, 10 000 pedig 50Mb-ot igényel. 10 000 felhasználó már egész jelentősnek mondható, ugyanakkor 50 Mb a jelenlegi RAM méretek mellett elenyésző. Ez alapján szinte adja magát a gondolat, hogy a teljes adatbázist tartsuk a memóriában, célszerűen az adott programozási nyelv jól megszokott eszközeivel (pl. Java esetén sima Map-ek és List-ek). Kicsit olyan érzésem van a dologgal kapcsolatban, mintha a relációs adatbázis kezelők csak mindössze a nyakunkon maradtak volna azokból az időkből, mikor még a memória és a tároló kapacitás drága volt.

Más szempontból vizsgálva azt is mondhatjuk, hogy a memóriába ágyazott adatbázisok a jelenlegi rendszerek optimalizálásának logikus következő lépései. Gondoljunk csak egy általános vállalati rendszerre, ahol az adatbázist valamilyen ORM rétegen keresztül (pl. Hibernate) érjük el. Egy entitás objektum módosítása esetén módosítjuk a memóriában lévő lokális változatot, amit az ORM engine SQL utasításokra alakít, átpaszírozza őket egy socketen, ott az adatbázis szerver értelmezi az SQL utasításokat, és módosítja a winchesteren található fájlokat. Ha adatot olvasunk, ugyanez megy visszafelé. Az az ironikus a dologban, hogy a winchesteren lévő adatbázis fájlokat a gyakori használat miatt az operációs rendszer jó eséllyel felcache-eli a memóriába, így végső soron ugyanúgy a memóriából dolgozunk, csak ehhez a szükséges erőforrások sokszorosát használjuk el. Memória tekintetében rossz esetben legalább 2x megvan az adat (az ORM által kezelt memória reprezentáció, valamint az SQL adatbázis felcache-elt része), és itt még nem beszéltünk a közbe iktatott mindenféle cache-ekről, amit az adattáblák és a Java alkalmazás közé pakolunk, hogy gyorsítsuk az elérést. Számítási erőforrást tekintve megint csak elég rossz a helyzet, hiszen az adatok módosítása egy rakás SQL-t eredményez, amit az adatbázis szervernek értelmeznie kell, majd végrehajtania a változásokat, újraindexelni a táblákat, stb. A memória alapú adatbázisok segítségével ezek a felesleges köztes lépések kiküszöbölhetőek.

Jelenleg két implementációt találtam Java nyelven a memóriába ágyazott adatbázisokra. Az egyik a Prevayler a másik pedig a valamivel okosabbnak tűnő Space4j.

Persze az első kérdés, ami felmerül, hogy ha minden adatot a memóriában tartunk, mi történik egy esetleges rendszer leállás/áramszünet, stb. esetén. A Prevlayer/Space4j megoldása a problémára, hogy minden adatmanipuláló műveletet un. Command-okba csomagolunk és a memória objektumok manipulálását csak és kizárólag ezeken keresztül végezhetjük. Minden Command végrehajtását log-oljuk, így ha leáll a rendszer, nincs gond, hiszen a Command-okat újra lefuttatva visszakapjuk az eredeti állapotot. A gondolat maga nem új keletű. Így működnek az adatbázis rendszerek tranzakciói, vagy éppen a HSQLDB, ami egy ugyancsak memóriában működő, de SQL alapú adatbázis. Hogy a log fájl ne nőjön túl nagyra, bizonyos időközönként a rendszer csinál egy memória snapshot-ot, amikor a teljes állapotot lemezre menti. Ez kicsit erőforrás igényesebb művelet, de általában ez is viszonylag gyorsan megtörténik, és csak ritkán kerül rá sor.  Egy ilyen adatbázisban tehát az olvasás extrém gyorsan történik, hiszen egyszerű memória műveletekről van szó, és a módosítás is nagyságrendekkel gyorsabb, mint egy relációs adatbázis esetén, hiszen mindössze csak a Command-ot kell serializálni, és letenni a log-ba, nem kell SQL-eket értelmezni, indexeket karbantartani, fájlokat átrendezni, stb.

A következő kérdés, ami felmerül egy ilyen rendszerrel kapcsolatban, hogy mi van, ha valahogy mégis olyan hatalmasra nőne az adatbázis, hogy nem fér el a memóriában, esetleg másnak is kell a memória. A Space4j-ben ennek megoldására létezik egy mechanizmus, ami a nem használt adatokat a lemezre “passziválja”. Egy adatbázis esetén valószínűleg sok ilyen objektum van, amire épp aktuálisan nincs szükség. A mechanizmus hasonló az operációs rendszerek virtuális memória kezeléséhez, oly annyira, hogy talán nem is érdemes ezzel alkalmazás szinten foglalkozni. Bár gyakorlati tapasztalatom nincs, valószínűleg egy linux rendszer esetén elég lenne annyi, hogy megfelelően nagy swap területet hozunk létre. Bár nem tudom, hogy a kernelnél hol a határ, de ha jól tudom, a mai modern processzorok  legalább 4 Tb memória megcímzésére képesek. Tehát elvileg nem tiltja semmi, hogy akár Tb-os méretű swap használatával gigantikus virtuális memóriát hozzunk létre, amiben már akármilyen adatbázis kényelmesen elfér. Ráadásul az operációs rendszer natív virtuális memória kezelő mechanizmusa biztosan nagyságrendekkel gyorsabban és hatékonyabban működik, mint egy Java-ban programozott megoldás.

A memória alapú adatbázisok működése tehát egyszerű, elegáns, gyors, és erőforrás takarékos, ugyanakkor szinte mindenre képesek, amire egy relációs adatbázis. Például nagy adathalmazok esetén ugyanúgy definiálhatunk indexeket, de itt a megoldás jellegéből adódóan nem kell bonyolult index struktúrákban gondolkodni, elég egy bináris fa, amit az egyetem első félévében minden programozó tanonc fejébe belevernek.

Bár még a gyakorlati tapasztalatom nincs ezekkel a rendszerekkel, az látszik, hogy legnagyobb hátrányuk a Command-ok viszonylagos bonyolultsága lehet, ezekben a rendszerekben ugyanis a Command-ok a módosítás atomi műveletei, amelyek működésébe a rendszer nem lát bele. Az egyetlen dolog, amire a rendszer képes, hogy végrehajtsa a Command-okat. Minden adatellenőrzést, ütközés figyelést, stb. a Command-on belül nekünk kell leprogramozni, ezekhez a rendszer nem nyújt semmilyen támpontot. A másik dolog, ami csak nagyon problematikusan oldható meg, az a konkurens tranzakciók használata. Ez csak oly módon kivitelezhető, hogy másolatot készítünk a tranzakcióban részt vevő objektumokról, majd a tranzakció végeztével a módosításokat végrehajtjuk a memóriában lévő globális objektumokon. A másolást nem tudja nekünk transzparens módon elvégezni a rendszer, hiszen nem lát bele az atomi Command-ok működésébe, így azt sem láthatja, hogy azok milyen adatokat módosítanak. Így az egyetlen lehetőségünk, hogy leprogramozzuk ezeket a másolásokat.

Ami még nagy előnye a rendszernek, hogy nagyon egyszerűen clusterezhető. Minden cluster elem rendelkezik egy saját objektum fával, és bármelyik rendszerben valamilyen módosítás történik az adatbázison, egyszerűen broadcast-olnia kell a módosítást végző command-ot. Persze ilyen elosztott rendszerben a command-okat érdemes timestamp-el ellátni, a hálózati lag-ból eredő elcsúszások kiküszöbölésére (a Command-ok megfelelő sorrendben történő végrehajtása nagyon fontos). Maga a megoldás (módosítások broadcastolása a rendszerben) megint csak nem új keletű. Tulajdonképpen az összes clusterezhető cache (memcached, ehcache, JBossCache, stb.) így működik. Ha valahol változik valami, azt jelszik a többi szerver felé, így tartva konzisztensen a globális állapotot.

Tulajdonképpen a clusterezés gondolatán elindulva jutott eszembe, hogy a Cluster Cache-ek filozófiáját és a memória alapú adatbázisok filozófiáját ötvözve létre lehetne hozni valami perzisztens cache szerű dolgot, ami mentes lenne a Command-ok bonyolultságából eredő hibáktól. A rendszer alapja a JBossCache, vagy valamilyen ahhoz hasonló megoldás lehetne. A JBoss POJO Cache ugyanis tud valami nagyon ügyeset. Komplett Java objektum fákat tárolhatunk benne, mégis gyorsan képes szinkronizálni a cluster egyes elemeit. Ezt úgy éri el, hogy mindenféle proxy-k (és talán AOP) segítségével figyeli, hogy a cache-ben tárolt adatok mikor változnak, és csak a fa változásait küldi szét a többi szervernek. Ez nagyon hasonlít egy cluster-be kötött memória alapú adatbázis működéséhez, ahol a command-ok a JBossCache-ben tárolt objektumok változásai. Nem kellene tehát más tenni, mint a cluster cache-t kiegészíteni egy olyan mechanizmussal, amely folyamatosan log-olja a műveleteket, és néha snapshot-ot készít az aktuális állapotról. Ezt neveztem el én perzisztens cache-nek. Egy ilyen megoldásban nem lenne szükség command-ok írására, így az adatbázis kezelés valóban mindössze memóriában tárolt Java objektumok használatából állna, a rendszer valóban teljesen transzparens lenne. Ami a command-ok egyéb funkcióját illeti (adat ellenőrzés, indexelés, stb.), azt AOP segítségével aggathatnánk rá az adott objektumokra, így megőrizve a rendszer transzparenciáját.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)

JBoss hibakeresés

február 15th, 2010 Nincsenek hozzászólások

Mostanában elég sokat szívtunk néhány hibával egy JBoss-on futó rendszerben. A legtöbb hiba persze fejlesztéskor rögtön szemet szúr, vagy ha mégsem, úgy a log alapján hamar megtalálható az oka, van azonban néhány elég nehezen felderíthető. A legutálatosabb, mikor a nem optimális kód, vagy egy rejtett (akár több metódus híváson keresztül ívelő) végtelen ciklus annyira leterheli a rendszert, hogy az képtelen válaszolni (kvázi DoS-olja azt). PHP esetén van erre egy nagyon egyszerű mechanizmus, ami figyeli, hogy mi mennyi ideig fut, és ha túl sok idő telt el, egyszerűen kilövi. Nem is csoda, hogy a hosting szolgáltatók körében a PHP a leggyakoribb, hiszen erre könnyen lehet biztonságos hosting szolgáltatást építeni (a jogosultságok, memória limitek, idő limitek jó beállításával kiküszöbölhető, hogy a felhasználó megölje a szervert). Ilyen mechanizmust nem találtam JBoss-hoz (Tomcat-hez, mert valójában az intézi a web-es dolgokat), így marad a szerver újraindítása, és a log fájlok bújása.

Az ilyen hibák felderítésére a legegyszerűbb módszer, hogy a JBoss PID-re kiadunk egy kill -3 -at, aminek hatására a Java VM a log-ba hányja az aktuális szálak állapotát stack trace-el. Ilyen kill -3 -ból érdemes többet is nyomni néhány másodperces eltéréssel, hogy később ne csak az utolsó állapotot lássuk a szálaknak, hanem az egyes szálak működését folyamatában (pl. egy több metódusos végtelen ciklust így lehet leginkább kiszűrni). A baj az ilyen thread dump-okkal az, hogy a processzor használatot nem látjuk belőlük, így nem látszik, hogy pontosan melyik szálak próbálják megenni a processzort. Hogy ezt megtudjuk, adjunk ki egy ps -L auxH parancsot, ami az egyes szálak processzorhasználatát mutatja. A log-ot, és a ps eredményét az LWP/nid köti össze. A ps-ben látható LWP a szál egyedi azonosítója, amit hexadecimális formában nid néven a thread dumpban is megtalálunk. Tehát nincs más dolgunk, mint megkeresni a kiugró, extrém magas processzor használatot mutató szálakat, az ezekhez tartozó LWP-ket hexadecimálisra váltani, majd belekeresni a logban, hogy a hozzá tartozó szál mit csinál. Ezzel a módszerrel viszonylag egyszerűen megtalálhatjuk a kód kritikus részeit.

Annak idején én külföldi blog-ok alapján szedtem össze ezt a módszert, így gondoltam megosztom magyar nyelven is, hátha mások is hasznát veszik.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)

Óvatosan a Hibernate-el

február 14th, 2010 2 hozzászólás

Nemrégiben egy projekt kapcsán felmerült egy elég csúnya hiba. Nagyobb megterhelés esetén a rendszer processzor használata extrém magasra pörgött fel, olyannyira, hogy képtelen volt a webes kérések kiszolgálására, így újra kellett indítani. A rendszer fejlesztésével egyre instabilabbá vált a rendszer, aztán egy ponton elérte a teljes használhatatlanság fokát. Sokáig kerestük a hiba okát, mire rájöttünk, hogy mi okozta.

A Hibernate egy rendkívül kényelmes JPA alapú ORM rendszer. Az ember létrehoz néhány felcímkézett osztályt, és ide tárolja az adatokat. A Hibernate pedig szinte láthatatlanul elvégzi az adatbázis leképzést, és a kapcsolódó adatbázis műveleteket. A hibát ott követtük el, hogy kihasználva ezt a kényelmességet úgy használtuk ezeket a perzisztens objektumokat, mintha a memóriában lennének. Ciklusok futkároztak keresztül kasul a listákon, olvasgattuk/írogattuk az elemeket, mindeközben fittyet hányva arra, hogy milyen komoly adatbázis műveletek futnak a háttérben. Mint később kiderült, annyira komolyak, hogy néhány száz felhasználó taccsra tudott vágni egy 8 processzoros gépet. Mikor bekapcsoltuk az SQL-ek loggolását, elborzadva láttuk az eredményt, egy-egy webes kérés kiszolgálásakor százával pörögtek a 3-4x-es join-olt lekérdezések. Nem csoda, hogy az alkalmazás hamar felzabálta a gépet. Végül is az adatbázis használat optimalizálásával, és cache-ek használatával hamar úrrá lettünk a problémán. Ezt a kis affért tekinthetnénk akár egyszerű programozási hibának is, de engem gondolkodóba ejtett.

Egy régi kollégámmal annak idején sokat vitatkoztunk a Python és a Java nyelv kapcsán. Ő Python párti volt, én viszont nem nagyon tudtam megbarátkozni a nyelvvel. Ez azóta persze megváltozott. Script nyelvként nagyon megszerettem a Pythont, de komolyabb projektbe nem mernék belefogni vele. A vitánk alapja az volt, hogy szerintem a Python nagyon megengedő nyelv. Nem típusos, és szinte bármit felül lehet benne definiálni. Ez egyfelől nagyon kényelmes, ugyanakkor véleményem szerint egyben veszélyes is. Sokan egy programnyelv típusosságára vagy az operator overloading hiányára úgy tekintenek, mint koloncra, ami gúzsba köti a fejlesztőt, nem adja meg a kellő szabadságot, hogy kényelmes és elegáns kódot készítsünk. Én ugyanakkor ezeket a megkötéseket segítségnek tekintem, amelyek segítenek abban hogy hibátlan és optimális kódot készítsünk. A barátom érve ezzel szemben az volt, hogy ezeknek az eszközöknek a használata nem kötelező. Aki nem tud programozni, az ne használjon ilyesmit, aki jó fejlesztő, nem követ el szarvas hibákat. A probléma csak az, hogy az ember hamar elcsábul, vagy a felhasznált programkönyvtárak miatt belekényszerül abba, hogy éljen ezekkel a lehetőségekkel. A másik probléma, hogy ezek a nyelvek általában nem is adnak lehetőséget arra, hogy határok közé szorítsuk magunkat. Python esetén például ha akarnánk sem tudnánk típusos függvényeket írni, ami azért néha hasznos tud lenni, hiszen segít abban, hogy ne rontsuk el a paraméterezést (két paraméter véletlen felcserélése komoly galibát tud okozni). Van egy harmadik ok is, amiért a szigorú nyelvek mellett tettem le a voksomat. Egy komoly fejlesztés sokszor igen feszített tempóban történik. Kemények a határidők, sok a feature igény, kevés az ember. Ilyen körülmények között nem ér rá az ember gondolkodni, hogy vajon szép-e ez a kód, nem okoz-e majd később galibát, stb. Egyszerűen csak darálja a funkciókat, hogy elkészüljön a szoftver. Hasonló hibába estünk bele mi is a Hibernate kapcsán. Kihasználtuk az eszköz által nyújtott kényelmet, daráltuk a kódot, és nem gondoltuk végig, hogy ennek milyen következménye lehet. És ez a kis programozási nyelvekkel kapcsolatos kitérő itt kapcsolódik vissza az eredeti témához. Kényelem vs. biztonság.

A Hibernate-es probléma kapcsán tehát elgondolkodtam, hogy milyen elvek szerint kellene vajon felépíteni egy ORM rendszert úgy, hogy ne futhasson bele az ember ilyen hibákba, hasonlóan ahhoz, ahogyan a Java típusossága segít abban, hogy ne cserélhessük fel a paramétereket úgy, ahogy Pythonban. Az első gondolatom az volt, hogy talán vissza kellene térni a tiszta SQL-hez. Így rá vagyunk kényszerítve, hogy explicit módon adjuk meg a lekérdezéseket, és rá vagyunk szorítva arra, hogy ezek a lekérdezések optimálisak legyenek. (Legalábbis a nem optimális lekérdezések kibökik a szemünket.) Egy ilyen rendszerben SQL-el kérdeznénk le az adatokat, leképeznénk őket objektumokba, elvégeznénk a szükséges műveleteket, majd SQL-el pakolnánk őket vissza az adatbázisba. Ez tipikus DAO filozófia, és pont azért alakultak ki az ORM rendszerek, mert ez így azért elég kényelmetlen. E mellett azt se felejtsük el, hogy a manuális leképzés megint csak sok hibalehetőséget rejt magában. Az ORM rendszerek automatikus leképzése, és az objektum szintű típusosság sok gondot levesz a vállunkról, ráadásul az alkalmazás adatbázis rendszer független lesz, ami megint csak nagy előny. Tehát az ORM-től nem olyan könnyű megszabadulni, és valószínűleg nem is kell, de nagyon oda kell rá figyelni, ami nem jó, és mint látható, komoly hibákat szülhet.

Ami mostanában körvonalazódik a szemeim előtt, az valami olyan megoldás, ami ötvözi a JPA és a DAO-k előnyeit. A durva SQL-ek amiatt születtek, mert a rendszer felhúzott sok csatolt entitást is (ez okozta a sok join-t). Éppen ezért én a saját ORM rendszeremből kihagynám a kapcsolatokat, vagy legalábbis nem tenném annyira transzparenssé, ahogyan a Hibernate. Például egy entitáshoz kapcsolódó további entitásokat egy entitás osztályban definiált függvény szippantaná fel. Tehát az entitások tábla szintűek lennének, a kapcsolatok pedig explicit módon jelennének meg lekérdezések formájában. Bár nem okozott akkora galibát, de némi fejtörést igen, hogy bonyolultabb objektum manipulációk esetén az objektum struktúrát több request/response szakaszig a session-ben kell tartani, és csak ezután szabad visszarakni az adatbázisba. Mivel az entityManager csak 1-1 request alatt él, hamar problémát okozott, hogy egy session-ben lévő perzisztens objektumot (ami közben már elveszítette perzisztens jellegét) vissza akartunk rakni az adatbázisra (Lazy…Exception). Ennek kiküszöbölésére valamilyen long transaction mechanizmust tudnék elképzelni, ahol több request-en átívelő kérésekhez lehetne kérni egy long transaction-t. A long transaction session szintű objektum lenne, és ha felolvasunk/módosítunk valamit, ide kerülne. Végül egy commit-al a végén kerülne vissza az összes objektum az adatbázisra. Itt lehetne valamilyen ütközés figyelés (pl. verzionáljuk az objektumokat), ami konkurens írás esetén exception-el jelez. Végül pedig kellene valamilyen transzparens cache az adatbázis és az alkalmazás közé, hogy ha valamit felolvastunk, azt ne kelljen még egyszer felszedni. Valahogy így nézne ki egy ideális ORM rendszer.  Ami még kicsit zavaró, az a sok dinamikus proxy, ezek teljesen feleslegesen terhelik a processzort, ezek helyett hatékonyabb lenne statikus (fordítási idejű) kódgenerálást alkalmazni.

Találkoztam még egy érdekes Space4j nevű projekttel, ami az egész dolgot megfordította. Nem az adatbázist képezi memóriára, ehelyett az objektumokat a memóriában tartja, ami nem kell, azt perzisztensen kipakolja onnan, és e mellett mindent megold. Itt tehát nem a perzisztens objektumok cache-elése a feladat, hanem a cache (memória) perzisztens mentése. Talán pont egy ilyen megoldás lenne a leginkább ideális, persze kérdés, hogy mindezt hogy lehetne integrálni a már meglévő rendszerekkel, amennyiben hostolt rendszerben szeretnénk azt használni (pl. Google App Engine). Emellett még nem próbáltam a rendszert, tehát nem tudok nyilatkozni róla, hogy milyen rejtett hátrányai lehetnek egy ilyen megoldásnak.

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)