2010. november 19., péntek

lworm (egy pehelysúlyú PHP ORM megoldás)

Amikor elkezdett foglalkoztatni a gondolat, hogy PHP-ban fejlesszek Google App Engine-re, az egyik legnagyobb problémának az adatbázis elérése tűnt, hiszen PHP-ból általában SQL használunk erre, ami ugye App Engine alatt nem megoldható, hiszen a datastore egy nem relációs adatbázis. Utánanéztem kicsit, hogy mások hogy oldják meg ezt, és igazából két megoldást találtam. Az egyik az App Engine által szolgáltatott JPA vagy JDO réteg használata. Itt ugye az a gond, hogy ezzel elveszítjük a rendszer hordozhatóságát, hiszen egy standard LAMP környezetben már nem állnak rendelkezésre ezek a programkönyvtárak. A másik lehetséges megoldás, hogy valamilyen SQL wrappert használunk, amin keresztül a datastore szabvány SQL adatbázisnak tűnik. Ezzel az volt a gondom, hogy feleslegesnek tűnt, hiszen az SQL réteg felett úgyis valamilyen ORM réteget használnék, és ha már így van, miért ne építsük az ORM réteget közvetlenül a datastore fölé. Így született tehát az elhatározás, hogy saját ORM réteget fejlesszek PHP-hoz, és ha már belefogtam, megpróbáltam belegyúrni az eddigi tapasztalataimat.

Az első szempont az egyszerűség volt. Minimalista megoldást akartam, ami egyszerű, de mégis hatékony. E mellett legyen transzparens, tehát az elkészült PHP alkalmazás egyaránt képes legyen futni egy általános LAMP környezetben, és az AppEngine datastore-ja felett is. Mivel annak idején a Hibernate-el volt némi nézeteltérésem, mindenképp olyan megoldást akartam, ahol az entitások memória objektumok, tehát nincsenek az adatbázishoz kötve (csúnyán mondva nem attach-oltak). Itt most nem térnék ki a részletekre, de a lényeg, hogy ennek köszönhetően az adatbázis objektumokat büntetlenül tárolhatjuk a session-ben, vagy mondjuk JSON formában mozgathatjuk őket két rendszer között. Kb. ezek voltak az előfeltételek, lássuk hát a megvalósítást.

A rendszer használatához elsőként egy YAML állományban le kell írnunk az adatbázis sémát és az entitások kapcsolatrendszerét. Ez a YAML formátum felépítésének köszönhetően nem túl bonyolult, mégis szép és átlátható. A YAML alapján a ModelGenerator osztály használatával legenerálhatjuk az entitás osztályokat. Az entitás objektumok csak egyszerű adattároló szerepet töltenek be, így felépítésük az adatbázis megvalósítástól független. Ha ezzel megvagyunk, a megfelelő Datastore factory hívásával kérhetünk a rendszertől egy datastore példányt, aminek segítségével az adatokkal kitöltött entitás az adatbázisra menthető, illetve onnan felolvasható. Ugyancsak a datastore segítségével generálhatunk lekérdezéseket, aminek segítségével egyenlőre csak szűrni és rendezni lehet az eredményeket. Ennek az az oka, hogy az alacsony szintű datastore API csak ezeket teszi lehetővé. Bár lehet, hogy ez az eszközkészlet kicsit szegényesnek tűnik, de az esetek nagy részében általában elég, vagy némi kódolással kiegészíthető. Az entitás példányok kapcsolatainak kezelésére azt találtam ki, hogy az entitás objektum minden kapcsolatához egy metódust rendeltem, ami paraméterként kapja meg az aktuális datastore-t. A metódus egy kezelő objektumot ad vissza, ami a kapcsolatnak megfelelően karbantartja a kapcsolódó objektumokat. Tehát vegyük például a User (felhasználó) és Role (szerepkör) entitásokat, melyek közt many-to-many (több-több) kapcsolat van. Ebben az esetben a User osztálynak lesz egy getRolesRelation metódusa, ami egy kezelő objektumot ad vissza. Ezen az objektumon keresztül adhatunk hozzá Role-okat az adott felhasználóhoz, ezen keresztül listázhatjuk ki a hozzárendelt szerepköröket, vagy törölhetjük azokat. Mivel ezek a Relation objektumok mindig létrehozáskor kapják meg a szükséges adatbázis kapcsolatot, az entitásnak magának nem kell az adatbázishoz kötődnie, amiről az előzőekben már írtam. Röviden tehát körülbelül ennyi.

Az eredmény tehát egy nagyon kompakt kis ORM rendszer. Jelenleg a MySQL-t és a Google App Engine Datastore-ját támogatja, de nagyon egyszerűen kiterjeszthető. Maga a kód nagyon egyszerű, áttekinthető és könnyen használható. Bár ennek a lehetőségét nem vizsgáltam meg mélyebben, de a csökkentett eszközkészletnek köszönhetően valószínűleg a datastore-on kívül más nem relációs adatbázisokra is alkalmazható lenne a rendszer, pl. MongoDB-re. A későbbiekben talán érdemes ezt az irányt is megvizsgálni. A programkönyvtár másik nagy előnye, hogy nagyon pici, így akár kódméret kritikus rendszerekben is használható lenne. A későbbiekben lehet, hogy készül Java, Python, esetleg C++ változatot, amit például mobiltelefonok programozásához lehetne használni.

A kód és néhány példa elérhető a Google Code-on a http://code.google.com/p/lworm/ címen.

2010. november 16., kedd

gae-filestore (Írható/olvasható virtuális fájlrendszer Google AppEngine-re)

A Google AppEngine egyik elég erős megszorítása, hogy a telepített alkalmazás csak olvasni tudja a fájlrendszert. Új fájlokat nem hozhatunk létre, illetve nem módosíthatjuk a fájlokat. Bármilyen adattárolásra az AppEngine által biztosított adatbázist, a Datastore-t kell használnunk. Igazából ha jobban meggondoljuk, egy webalkalmazás többnyire valóban csak az adatbázist használja, így sokszor tényleg nincs szükség fájlrendszerre, de azért néha jól jön. Egy projektem kapcsán épp ilyesmire volt szükségem, ezért készítettem egy igazán egyszerű virtuális fájlrendszer implementációt Google AppEngine-hez. A rendszer működésének megértéséhez először írnék kicsit a Datastore-ról, annak is az alacsony szintű megvalósításáról.

Az AppEngine Datastore-ja egy BigTable alapú nem relációs adatbázis rendszer. Bár pontosan nem tudom, hogy a Google alkalmazások (GMail, Google Maps, a kereső, stb.) is ezt a megvalósítást használják-e, erről nem találtam konkrét leírást, de mindenesetre ez valami nagyon hasonló dolog kell hogy legyen. A rendszer használatára két lehetőségünk van. Egyfelől kapunk egy szabványos JPA/JDO réteget, így J2EE alkalmazásainkat változtatás nélkül, vagy kisebb változtatásokat követően futtathatjuk AppEngine-en. A másik lehetőség a low-level API használata, ami közvetlen hozzáférést biztosít a DataStore-hoz, így sokkal hatékonyabb, ugyanakkor kicsivel kényelmetlenebb is, mint a szabványos réteg. Én ez utóbbiról írnék kicsit bővebben. A Datastore adattárolásának alapja az Entity. A relációs adatbázis kezelőkhöz hasonlítva az Entity az adatbázis rekordnak felel meg, azzal a különbséggel, hogy az Entity-nek nincs fix szerkezete. Ebből a szempontból az Entity inkább olyan mint egy asszociatív tömb, vagy Java terminológiával élve Map. Egy ilyen Entity-be szabadon helyezhetünk el név-érték párokat. A másik nagyon fontos komponens a Key. A Key az entitás elsődleges azonosítója. A Key 3 féle módon épülhet fel. Generálhatjuk egy string-ből vagy long-ból, ezen felül definiálhatunk egy kulcs típust (kind), ami kb. a tábla megfelelője, és végül definiálhatjuk úgy a kulcsot, hogy ezeken felül egy szülő kulcsot is megadunk. Ez utóbbi megoldással a kulcsok és ezzel az Entity-k hierarchiába szervezhetőek. Ha összeállítottunk egy Entity-t, azt egyetlen metódussal lerakhatjuk a datastore-ra, és onnan a Key segítségével vissza is olvashatjuk. Amennyiben nem a Key alapján szeretnénk visszanyerni az entitást, úgy létre kell hoznunk egy Query-t. A Query segítségével az Entitás bármely értékére szűrhetünk az alapműveletek (kisebb, nagyobb, egyenlő, stb.) használatával. Az ilyen keresések segítésére definiálhatunk indexeket, de erre sincs feltétlenül szükség, hiszen a rendszer a lekérdezések alapján automatikusan legenerálja a szükséges indexeket. Az eredményként kapott entitás listát bármely eleme alapján rendezhetjük is, és nagyjából ennyi. Ha több entitást szeretnénk összekapcsolni (JOIN), VAGY kapcsolatot kialakítani a szűrési feltételekben, vagy bármi hasonlót tenni, amire egy relációs adatbázis amúgy önmagában képes, azt kódból kell megvalósítanunk. Cserébe viszont az egész rendszer masszívan elosztott, sémamentes, flexibilis és gyors. Most hogy megismertük a Datastore-t, lássuk a virtuális fájlrendszer működését.

A virtuális fájlrendszer legfelső szintű eleme a DataStoreFile entitás. Ezek az entitások testesítik meg az állományokat és a könyvtárakat egyaránt. Egy ilyen entitásnak 4 attribútuma van. A fájl típusa (könyvtár v. fájl), az utolsó módosítás ideje, a fájl mérete, és a fájlt tartalmazó útvonal. A fájl entitás egyedi azonosítója annak elérési útja, így ez alapján nagyon könnyen elérhetőek a fájl metaadatai. Mivel a metaadatokra sokszor szükség lehet, ezért a fájl entitás mentésekor és betöltésekor a memcache-ben is tároljuk, így annak további elérése már nagyon gyorsan megy a cache-ből. A fájl tényleges tartalmának tárolása Blob-okban történik. A Blob tulajdonképpen egy byte tömb, aminek mérete maximálisan 1 Mb lehet AppEngine esetén. Én 512 Kb méretű blokkokat használtam, amiket sorszámmal azonosít a rendszer. Az egyes blokkok a fájl entitás alatt helyezkednek el (a blokk kulcsa a fájl entitás kulcsának leszármazottja). Amikor adatokat írunk vagy olvasunk a fájlból, a rendszer a fájlmutató alapján meghatározza a blokk sorszámát ahol az adat van, majd ebben módosítja a megfelelő adatot. Egyszerű kialakítás, mégis kényelmes és hatékony.

A kód szokásos módon a Google Code-on megtalálható a http://code.google.com/p/gae-filestore/ címen.

2010. november 8., hétfő

PHP futtatása Googel App Engine-en

A GAE vagy Google App Engine a Google alkalmazás hoszting szolgáltatása. Nagy előnye, hogy segítségével alkalmazásunka a Google infrastruktúráján futtathatjuk. Nem kell olyan apróságokkal foglalkoznunk, mint a load balanceing, erőforrás allokáció, elosztott session kezelés, stb. hiszen a Google a terheléstől és a kérések helyétől függően optimálisan fogja "szétkenni" az alkalmazásunkat. Adatbázisként egy Google BigTable alapú nem relációs adatbázist kapunk, aminek klaszterezését ugyancsak a rendszer végzi automatikusan. E mellett kapunk még néhány "nyalánkságot", mint amilyen az elosztott memcache, e-mail, vagy xmpp lehetőség. Amiért azonban igazán vonzó lehet induló startup-ok számára, az az, hogy a rendszer körülbelül havi 1 000 000 lapletöltésig és 500 Gb tárhelyigényig teljesen ingyenes. Ha pedig az embernek sikerült ekkora forgalmat generálnia, akkor már jó eséllyel ki tudja termelni a plusz sávszélesség és tárhely árát is, ami néhány cent gigabájtonként, tehát igen baráti. Persze ezért a nagy kényelemért némi kompromisszumot is kénytelenek vagyunk meghozni. Az egyik ilyen korlát, ami véleményem szerint nagyban gátolja a technológia elterjedését, hogy egyenlőre csak Java és Python nyelven programozható. Az egyik talán leggyakoribb kérés szokott lenni a felhasználók felől, hogy más hoszting szolgáltatókhoz hasonlóan támogassák a PHP nyelvet is. Így megnyílna az út sok népszerű web framework, és PHP fejlesztő előtt. Ezt a dolgot viszont valamiért a Google nem annyira erőlteti. Bár a PHP hivatalosan nem támogatott, mégis viszonylag egyszerű módon futtathatunk PHP scripteket AppEngine felett.

A megoldás kulcsa a Caucho Quercus nevű Java Servlet alapú PHP implementáció, amely az App Engine-en való futtatást is támogatja. A gyakorlati megoldás sem olyan bonyolult. Töltsük le a legújabb resin verziót, és a resin.jar-t másoljuk a WEB-INF/lib könyvtárba. A web.xml-t bővítsük ki a következő bejegyzéssel:
  <servlet>
<servlet-name>Quercus Servlet</servlet-name>
<servlet-class>com.caucho.quercus.servlet.GoogleQuercusServlet</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>Quercus Servlet</servlet-name>
<url-pattern>*.php</url-pattern>
</servlet-mapping>

Így a .php állományokat a Quercus automatikusan a QuercusServlet-nek továbbítja. Magukat a PHP állományokat a root könyvtárba helyezzük. Ezt követően az appengine-web.xml-hez adjuk hozzá a következő sorokat:
<static-files>
<exclude path="/**.php"/>
</static-files>
<resource-files>
<include path="/**.php"/>
</resource-files>

E nélkül a rendszer a php állományokat statikus fájloknak tekintené, és nem adná át a szervlet motornak. Körülbelül ennyi. Innentől kezdve már PHP-t is futtathatunk a Google App Engine-en. Ezzel a technikával elvileg sikeresen futtattak már Drupal-t, Wordpress-t, és néhány hasonló PHP keretrendszert. Persze azért a PHP alkalmazások szállítása nem olyan egyszerű, hiszen ezek többnyire MySQL-t használnak, AppEngine-en viszont ugye nincs relációs adatbázis. Tehát valamilyen szintű módosításra mindenképp szükség van, de ez talán megéri mindazokért az előnyökért cserébe, amit az AppEngine, és eleve maga a Quercus adhat (pl. egyszerű PHP-Java integráció, Java libek használata, stb.).

2010. október 28., csütörtök

SimpleRSA

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/

2010. október 19., kedd

jin-plugin

Egy projektem kapcsán próbáltam valamilyen általános megoldást keresni beépülő modulok (plugin-ek) kezelésére. Ugye a lényeg röviden annyi, hogy a kész alkalmazáshoz bárki könnyen írhasson kiegészíthetőket, amiket egyszerű módon lehet telepíteni. Rövid keresgélés után rá is találtam az OSGi-re, ami tulajdonképpen minderre a szabványos megoldás. Ezt használja például az Eclipse is. Át is néztem a doksit, de úgy találtam, hogy az én igényeimhez képest ez amolyan ágyúval verébre megoldás. Valami olyan egyszerű megoldást kerestem, amit a leendő plugin fejlesztők néhány perc alatt el tudnak sajátítani. Olyat, amilyet például a PHP CMS-ek is használnak (pl. Wordpress, Joomla), ahol a plugin csak néhány függvényből áll. Találtam is egy annotation alapú jspf nevű keretrendszert, ami már nagyon megközelítette azt amire én gondoltam, de ekkor már úgy voltam vele, hogy csak és kizárólag a minimalista megoldás érdekel. Ahogyan a jin-template esetén, itt is arra gondoltam, hogy ha már készítek egy egyszerű megoldást, rögtön elkészítem a PHP implementációt is, amit később más programnyelvekre történő adaptáció követhet, így kvázi megteremtve a "minimális plugin architektúra szabványát". Ezt valószínűleg már sokan sokféle módon megtették előttem is, de sehol nem láttam publikálva ilyen jellegű különálló programkönyvtárat. Ennek valószínűleg az az oka, hogy a fejlesztők értelmetlennek találták leválasztani a plugin rendszert a kész alkalmazásról (éppen annak egyszerűsége miatt). Erre tipikus példa a PHP CMS-ekben használt plugin rendszer, ahol bár a megoldások nagyon hasonlóak, mégis minden rendszernek saját megoldása van. Így fogant meg hát a jin-plugin rendszer gondolata.

A rendszer felépítése a célnak megfelelően nagyon egyszerű. A plugin manager végignézi a paraméterként megadott könyvtárat, ahol minden pluginhez külön könyvtár tartozik. Minden könyvtárban egy yaml fájl található, ami definiálja a plugin osztályt, valamint az esetleges függőségeket. A plugin manager a függőségeket betartva tölti be a plugineket, és hívja meg a plugin osztály init metódusát. Maga a plugin kód a plugin könyvtárában található. PHP esetén a kódok helye közvetlenül a könyvtár, Java esetén pedig a classes könyvtár. Ez utóbbi esetben lehetőségünk van a program számára szükséges programkönyvtárak csomagolására is, amik a lib könyvtárban kapnak helyet. A pluginnek lehetősége van névvel ellátott szolgáltatások installálására, amiket más pluginek felhasználhatnak. Tulajdonképpen ez minden. Ennyi az a feltétlenül szükséges minimális működés, amire szükségem volt. A plugin installálása egyszerűen a plugin könyvtárba történő könyvtármásolással történik, a pluginek készítésének elsajátítása pedig a rendszer egyszerűségének köszönhetően néhány perc. Ez utóbbi szerintem bíztatólag hat a fejlesztőkre, ami igen fontos, ha azt szeretnénk, hogy minél több kiterjesztés szülessen az alkalmazásunkhoz. Már csak abban kell reménykednem, hogy a megoldásom elterjed, és így talán másokat is sikerül egy kicsit hozzásegítenem sikeres kiterjeszthető alkalmazások fejlesztéséhez.

A rendszer rövid dokumentációja, és a teljes forráskód LGPL licenc alatt megtalálható a Google Code-on:
http://code.google.com/p/jin-plugin/

2010. október 12., kedd

jin-template

Már több webes projekt van a hátam mögött, de igazából még nem sikerült olyan template rendszert találnom, ami maradéktalanul kielégítené az igényeimet. Az egyik legnagyobb problémát az szokta jelenteni, hogy a HTML designt öcsém készíti el rendszerint Dreamweaver-el, és a későbbi karbantartás miatt meg is kell őriznünk a HTML tisztaságát. A legtöbb template rendszer speciális tag-eket, vagy más extra blokkokat használ, ami rendszerint teljesen tönkreteszi a HTML forrást. Az ilyen tag-ekkel teletűzdelt HTML már nem úgy jelenik meg a böngészőben vagy a szerkesztőben, ahogyan az eredmény, így a vizuális szerkesztés a standard HTML-es eszközökkel (pl. az általunk is használta Dreamwaver) nagyon nehézkes. A problémát általában úgy hidaltam át, hogy a template motornak szóló parancsokat HTML kommentekben helyeztem el, és egy előfeldolgozó után eresztettem rá a template motort. Ez a megoldás egész hatékonynak bizonyult, de még így sem voltam maradéktalanul elégedett. Az a gond ezekkel a template motorokkal, hogy szűkös a tudásuk. Ez a szűkös tudás persze az esetek nagy részében elegendő is, de ha esetleg olyan igényünk van, amit a template rendszer alapból nem támogat, sokszor igen nehézkes kiterjeszteni azt. Smarty plugineket kell gyártanunk, saját taglib-eket, stb. De miért kell ennek ilyen macerásnak lennie? Valójában arról van szó, hogy a template rendszer egy primitív programozási nyelvet definiál, és ezt kell kiterjesztenünk. Innen jött az ötlet, hogy a template rendszer speciális nyelve helyett használjuk a jól megszokott programozási nyelvet, és ezzel tulajdonképpen bontsuk ketté a template-et egy tiszta HTML forrásra, és egy felület generáló kódra (view building logic). Ez volt a jin-template alapötlete.

A rendszer maga nagyon egyszerű, néhány osztályból áll az egész.  A forrás HTML-ben kommentekkel jelölhetünk ki blokkokat, majd a kódból ezen blokkok tartalmát használhatjuk fel, és cserélhetjük ki. Ez alapján tehát egy fórum motor bejegyzéseinek listája úgy áll elő, hogy definiálunk egy bejegyzés konténert, és egy bejegyzés elemet. Ezt követően kódból előszedjük a bejegyzés elemet, feltöltjük a megfelelő adatokkal, majd a bejegyzéseket behelyezzük a bejegyzés konténerbe. Ezzel a módszerrel a HTML forrásokat megtarthatjuk eredeti formájukban (csak néhány komment hozzáadása szükséges), a tartalom generálásához pedig felhasználhatjuk az implemetáló programozási nyelv teljes eszközkészletét.

Az elkészült rendszert feltöltöttem a Google Code-ra, ahol a működést egy egyszerű példán szemléltettem is:
http://code.google.com/p/jin-template/

2010. szeptember 21., kedd

Programfejlesztés Android-ra

Néhány hónapja beszereztem egy Samsung Galaxy Spica-t, azzal a határozott szándékkal, hogy végre megtanulok Android-ot programozni. A jelenlegi tendenciákat figyelve az Android valószínűleg hamarosan a legelterjedtebb mobil platformmá válhat, és az sem elhanyagolandó tény, hogy Java nyelven fejleszthetünk rá, ami (legalábbis szerintem) sokkal barátságosabb, mint a C++ (Symbian), vagy az Objective-C (iPhone). Úgy tervezem, hogy több bejegyzést is írok majd a témában. Ebben a mostaniban azt írom le, hogyan állíthatjuk be a fejlesztőkörnyezetet, és kezdhetjük meg a fejlesztést.

Ha Android fejlesztésre adjuk a fejünket, legjobb választás az Eclipse fejlesztőrendszer használata. Elvileg létezik NetBeans plugin is, de mivel én eddig is Eclipse-et használtam fejlesztésre (még a PHP projektekhez is), ezért soha nem próbáltam. Szóval maradjunk az Eclipse-nél. Én a 3.5-ös Galileo-t telepítettem (a cikk írásakor ez volt a legfrissebb Android plugin által támogatott változat). Az Eclipse telepítése után telepítsük az ADT plugint. Ha ez megvan, még szükségünk van az Android SDK-ra, amit innen tölthetünk le. Ha fent van az SDK, futtassuk az SDK Manager.exe-t (Windows esetén), amivel letölthetjük és telepíthetjük a legfrissebb fejlesztői csomagokat. Ha a fejlesztéshez emulátort használunk, akkor a Virtual Devices fül alatt adjunk hozzá egy virtuális eszközt. Ha ezzel megvagyunk, lépjünk vissza eclipse-be, és Window/Preferences fül alatt keressük ki az Android részt, és állítsuk be az SDK location-t. Ha mindez megvan, rendszerünk készen áll a fejlesztésre.

A Package Explorer-ben adjunk hozzá gy Android projektet, állítsuk be az alkalmazás nevét, a package-t és a célrendszert, és kész is az első Android projektünk. A default Android projekt egy önmagában is futtatható Hello World alkalmazás, így nincs más dolgunk, mint elindítani azt a Debug As Android Application opcióval. Ha nincs csatlakoztatva telefon, a rendszer automatikusan az emulátort indítja el. Ha rögtön telefonon szeretnénk tesztelni (én így szoktam), akkor kapcsoljuk be a telefonon a fejlesztői módot. Nálam ez a Beállítások/Alkalmazások/Fejlesztés alatt kapcsolható be az USB-hibakeresés opcióval. Ha bekapcsoltuk, az adatkábellel kössük össze a telefont a PC-vel. Ilyenkor a PC vagy felismeri a telefont (nálam már valahonnan fent volt egy Samsung ADT driver, ami valószínűleg a gyári szoftverrel települt). Ha nincs fent driver, próbálkozhatunk az SDK-ban lévő usb driverrel, ami az usb_driver könyvtárban található. Ha sikerült csatlakoztatni a telefont, újra indítsuk el az alkalmazást a Debug opcióval, és ha minden jól megy, most már az a telefonon fog elindulni. Ez a módszer szerintem sokkal jobb, mint az emulátor használata, hiszen élő környezetben tesztelhetjük a programot, mégis ugyanúgy tudunk debugolni, mint emulátor esetén. Ráadásul a natív környezetnek köszönhetően sokkal gyorsabban is fut az alkalmazás. Egy dolog van még, amit érdemes megtenni. Az Eclipse Window / Show view menüpontjában található a LogCat view, ahová a programból logolhatunk, és ahová a rendszer a hibaüzeneteket küldi. Ha valami nem megy, érdemes egy pillantást vetni ide.

Ha további infóra lenne szükség a környezet telepítését illetően, az SDK honlapja-án mindent meg lehet találni.

Sok szerencsét minden leendő Android fejlesztőnek!

2010. szeptember 1., szerda

A tudat létjogosultsága a természettudományokban

Nemrégiben olvastam Wigner Jenő válogatott írásait. Ami az írások közül leginkább megragadott, az az utolsó fejezetek egyike, ahol Wigner az anyagól független tudat lehetőségét boncolgatja a kvantummechanika nézetei alapján. Több ilyen írást olvastam már, de egy Nobel-díjas fizikustól mindez azért másképp hangzik.

A tudat - mint különállóan létező dolog - érdekes ívet futott be a természettudományokban. A kezdetekben magától értetődően feltételezték, hogy létezik. Később a fizikai, kémiai, biológiai törvények feltárásának köszönhetően a tudat szerepét egyre inkább átvette az agy, majd a fizika mélyebb összefüggéseinek feltárásával és a kvantumelmélet megjelenésével a fogalom érdekes módon megint csak kezdett visszaszivárogni a fizikába. A következőkben megpróbálom röviden megmutatni azt az ívet amelynek mentén a tudat előbb eltűnt, majd végül újra megjelent a fizikában, majd kicsit elmélkedünk arról, hogy mindez hogyan férhet bele a természettudományos világképbe.

A tudat eltűnése a fizikából (a materializmus és determinizmus)

A tudományos fellendülés, és a világ folyamatos jobb megértése folytán egyre inkább úgy láttuk, hogy az élőlények anyagtól független tudatának létezésére semmi szükség a természettudományokban. Az emberi gondolkodásért teljes egészében az emberi agy felelős, és az öntudat, vagy általános értelemben vett tudat mint olyan csak ennek a megnyilvánulása. Ennek a kijelentésnek pedig igen nagy súlya van. A tét nem kevesebb, mint a szabad akarat. Ha ugyanis az ember tudata nem több mint agyának működése, úgy elveszíti a szabad választások lehetőségét. Az agy működését ugyanis biológiai törvények írják le, a biológiai törvények alapját kémiai folyamatok képezik, amiket végül fizikai folyamatokkal írhatunk le. Ennek alapján tehát az agy, és ezen keresztül a tudat tisztán fizikai működés. A fizikai történések egyértelműen kiszámíthatóak. Tulajdonképpen pontosan ez a fizika célja, hogy a jelenlegi állapot ismeretében a fizikai törvények alapján kiszámolja a jövőbeni állapotot. Ha mindez igaz, akkor ha egy adott időpillanatban ismerem a világ összes részecskéjének állapotát, a fizika törvényei szerint kiszámíthatom azok jövőbeni helyzetét, így betekintést nyerhetek a jövőbe. Ha ezt a gondolatot kicsit tovább visszük, azt mondhatjuk, hogy ha ismerem az összes részecske állapotát az ősrobbanás utáni első pillanatban, onnan az ismert fizikai törvényszerűségeknek hála kiszámolhatom az egész rendszer állapotát a jövő bármely pillanatában. Ez pedig röviden azt jelenti, hogy az ősrobbanás pillanatában már minden eldőlt. Az hogy megszületek, hogy most megírom ezt a blog bejegyzést, hogy hátralévő életemben még mit csinálok, és hogy mikor, és miképpen fogok meghalni. Ha mindez igaz, akkor nincs túl sok esélyem, hogy "döntéseket" hozzak, hiszen már minden előre eldőlt a világ végéig. Ez sok erkölcsi és filozófiai kérdést felvet, amivel most itt nem foglalkoznék, mert könyveket lehetne megtölteni a témával. Ehelyett megmutatom hogyan szivárgott vissza a tudat, és ezzel a szabad akarat eszméje a tudományba.

A tudat visszatérése a fizikába (a kvantummechanika)

A 20. századi modern fizika talán legnagyobb tudományos vívmánya a kvantummechanika megjelenése volt. Ez az elmélet olyan mértékben kezdte el feszegetni a fizikai gondolkodás határait, ahogyan azelőtt még semmi. Itt most nem fogok kitérni a kvantumelmélet ismertetésére, csak néhány szóban megemlítem néhány következtetését, ami a tudat szempontjából érdekes. A kvantumelmélet megjelenésével arra sikerült rámutatni, hogy egy részecske helyzetét (és minden egyéb tulajdonságát) csak bizonyos pontatlansággal tudjuk meghatározni, a történések lefolyását pedig csak bizonyos valószínűségekkel tudjuk kezelni. Tehát amit eddig írtunk, hogy "ha ismerjük a részecskék helyzetét, abból a törvények segítségével kiszámíthatjuk a jövőt", itt már nem lesz igaz, hiszen teljes bizonyossággal nem ismerhetjük a részecskék helyzetét, és a törvények is csak valószínűségi jellegűek. Ez még önmagában nem indokolja a tudat létezését, mindössze valamiféle bizonytalanságot visz a rendszerbe, ami ettől már nem lesz számítható. Ezzel annyit értünk el, hogy a világ kiszámíthatóból kiszámíthatatlanná vált. A kvantumelmélet azonban tovább megy, és azt állítja, hogy a részecskéknek nem hogy nem határozható meg pontosan az állapota, hanem egyszerűen nincs is nekik, amíg nem figyeljük meg őket. Így tulajdonképpen a részecskék mindaddig nem, vagy csak virtuálisan léteznek, amíg valaki nem figyeli meg őket. Maga a megfigyelő pedig nem lehet anyagi objektum, mert akkor rá is a kvantummechanika szabályai vonatkoznának, következésképp a megfigyelőt ki kell emelni az egész rendszerből, ami elvezet a különálló tudat fogalmához. Ezt a fizikai szempontból zavaró elemet, a tudatot sokan sokféleképpen próbálták kiiktatni az elméletből, de ezidáig sikertelenül.  Sokan - köztük Einstein is - úgy próbálta magyarázni a kvantumelméletet, hogy un. rejtett paramétereket feltételezett. Tehát azt mondta, hogy a részecskéknek attól még létezik valamiféle állapota, hogy mi nem figyeljük meg őket, csak ezt az állapotot képtelenek vagyunk meghatározni. Ennek bizonyítására fel is állítottak több gondolatkísérletet, amiket végül Einstein halála után tudtak ténylegesen elvégezni. Ezek a kísérletek Einstein ellenében a kvantummechanikát igazolták vissza, így továbbra is úgy tűnik, hogy a részecskéknek nincs valós állapota mindaddig, míg valaki (egy fizikai világ felett létező tudat) meg nem figyeli azt. A kísérletről íródott egy nagyon jó cikk Hraskó Péter fizikus tollából. A fentieken felbuzdulva születtek is elméletek, melyek a fizikai agy és a kvantummechanikai tudat fogalmát próbálták összeházasítani. Az egyik ilyen elmélet, amit Roger Penrose fizikus írt le, hogy az agy neuronjai valójában kvantummechanikai effektusoknak köszönhetik működésüket, így az agy mint olyan valójában a kvantummechanika szabályainak engedelmeskedik. Az elmélet bővebb ismertetését a Nagy a kicsi és az emberi elme c. könyvben olvastam.  A könyv azért is kiváló, mert több nézőpontot ütköztet benne, így az érvek mellett ellenérveket is olvashatunk a szabad akarattal szemben. Nagy kérdés például, hogy a tudat megfigyelése csak valamiképp véletlenszerűen összeomlasztja a részecske hullámfüggvényét, vagy valami módon hatással is van a részecske állapotára. Erről például a kvantummechanika nem mond semmit, pedig ugye ha az agyat valamiféle interfészként képzeljük el a tudathoz, akkor alapkövetelmény, hogy a tudat "irányítsa" az agyat. A másik nyugtalanító kérdés, hogy a kvantummechanika effektusai csak nagyon kis méretek, az elemi részecskék szintjén mutatkoznak meg. Ha makroszkópikus rendszereket, például sejteket, neuronokat vizsgálunk, ott már nem sok mindent befolyásolnak a kvantummechanika effektusai. Tehát ha Penrose-nak nincs igaza, és az elemi részecskék világa nem képes közvetlen hatást gyakorolni az agy működésére, akkor jelenlegi fizikai ismereteink szerint az agy megint a kiszámolhatóság világába kerül, és oda a szabad akarat. További fejtegetésekbe nem bocsátkoznék a szabad akaratot illetően, ezt megteszi helyettem a fenti könyv. E helyett leírnám a saját értelmezésem, amihez az eddigiekhez képest egyfajta kerülőúton jutottam el. Talán ez is lesz annyira érdekes, mint az előbbiek ...

A kvantummechanika MATRIX féle értelmezése, avagy hogyan segíthet a virtuális valóság a kvantummechanika megértésében

Ahogy sokakat, engem is elgondolkodtatott a MATRIX. Sikerét szerintem nem is annyira a különleges effekteknek, képi hatásoknak, vagy úgy általában véve a sztorinak köszönhette, hanem annak, hogy a film alapgondolata, és a szereplők által megfogalmazott néhány kijelentés gondolkodásra késztette a nézőt. Nekem a világ egyfajta értelmezését adta a film utáni elmélkedés. Engem személy szerint az érdekelt, hogy pusztán elméleti szempontból vajon létrehozható lenne-e egy ilyen virtuális világ. Ha igen, miképp működne, és vajon megvalósítható lenne-e oly módon, hogy mi kielégítően kiismerhessük, tehát képesek legyünk bármely általunk kitalált fizikai kísérlet elvégzésére, ugyanakkor képtelenek legyünk megállapítani, hogy az nem a valóság. Ha jól meggondoljuk, a virtuális világban ez a kérdés így hangzana: "létezik-e a mi valóságunknál igazabb külső valóság", vagy nevezzük nevén a gyereket: "létezik-e túlvilág".  No de lássuk magát a gondolatmenetet ...

Az első kérdés, ami foglalkoztatott, hogy vajon mekkora lenne egy ilyen gép, ami számunkra tökéletesen hűen leképzi a valóságot. Ugye minden egyes elemi részecske minden egyes tulajdonságát le kellene tárolnunk, eztán pedig gigantikus számítási kapacitással a törvények alapján ki kell számolnunk a részecskék mozgását. Ez olyan feladat, amitől jelenlegi szintünkön iszonyatosan messze vagyunk. Valójában még ha rendelkeznénk kvantum processzorokkal, vagy bármilyen jelenleg elképzelhető modern technológiával, akkor is nagy teljesítmény lenne, ha csak néhány részecske pontos mozgását modellezni tudnánk, nem hogy az egész világét. Ilyen úton tehát jelenlegi ismereteink szerint vajmi kevés esély van rá, hogy valaha a MATRIX-hoz hasonló virtuális valóságot építsünk magunknak. A következő gondolatom az volt, hogy talán a világban van akkora redundancia, hogy ennek köszönhetően valamilyen nagyon elmés tömörítő algoritmussal letömöríthető lenne a világ, ezzel tárolási és számítási kapacitást spórolva. Egy ideig olyan dolgok izgattak, mint hogy "vajon mekkora lehet a világ összes entrópiája", meg hasonlók, de ez sem igazán vezetett sehová. Végül elkezdtem gondolkodni azon, hogy egyáltalán léteznek-e azok a dolgok, amikről nincs tudomásunk, vagy finomabban megfogalmazva "ha valamiről nincs tudomásunk, arról bizonyítható-e bármi módon, hogy létezik".

Először talán egy repülő út kapcsán gondolkodtam el a dolgon, hogy vajon mi történik odalent, amíg mi a felhők felett repülünk? Mi van, ha az történik, mint Jim Carry-vel a Truman Show-ban. A repülő csak felszáll, jár néhány kört, addig pedig statiszták hada rendezi át alattunk a várost, hogy mikor leszállunk, azt higgyük, egy másik országban vagyunk. Vagy egy még egyszerűbb példával élve, vajon Amerika létezik-e? Én még soha nem jártam ott. Persze a tévében láttam már, olvasok róla az Interneten, stb. de mi van, ha ez csak egy baromi nagy globális összeesküvés része. Ezek persze butaságok. Esti sörözések témájának ideálisak ugyan, de mindannyiunk meggyőződése, hogy ezek a dolgok nem így vannak. Ami ezekből a gondolatokból mégis lényeges, az a megfigyelés szerepe, és fontossága. A repülőgépes példához visszatérve, ha valaki a felhők felett kedvenc mirelit sandwichünket (iszonyat rossz tud lenni a repülőn a kaja) majszolva megkérdezi tőlünk, hogy "Szerinted van alattunk valami?", mit válaszolhatunk neki? Mondhatjuk, hogy igen, éppen Európa felett repülünk. "Biztos vagy benne? Lehet, az egészet elnyelte a víz, mint Atlantiszt a legendák szerint." Erre valószínűleg azt mondanánk, hogy ez badarság, mire ő: "Be tudod bizonyítani, hogy bármi is van alattunk?". Ha jól meggondoljuk a választ, azt kell mondanunk neki, hogy ott, abban a helyzetben, sandwichet majszolva erre aligha vagyunk képesek. Az, hogy repülés közben van alattunk valami, legjobb szándékkal is csak hitnek mondható, de semmiképp sem bizonyosságnak. Bizonyosságnak akkor mondhatjuk, ha leszálltunk, látjuk a házakat, meg tudjuk érinteni a földet, stb. Amiről nem rendelkezünk információval, az egyszerűen nem létezik számunkra. Ez a kijelentés pedig egy iszonyatosan jó tömörítési eljárást ad a kezünkbe virtuális világunk építgetéséhez. Innentől ugyanis elég azokat a részecskéket szimulálni, amiket éppen megfigyelünk. Amelyik részecskét nem figyeljük meg, az nem érdekes, annak állapotát kipakolhatjuk a hátértárra, hogy majd ha elővesszük, ugyanolyan állapotban találjuk, ahogyan otthagytuk. Itt rögtön meg is jegyezhetjük, hogy a megfigyelés szerepe igen hasonló a kvantummechanikában. Ott is azt mondhatjuk, hogy amíg egy objektumot nem figyelünk meg, addig az nem is létezik, vagy legalábbis egyfajta virtuális állapotban van. Mikor megfigyeljük, akkor kap valamilyen konkrét állapotot, amit a továbbiakban meg is tart.

A gondolatmenet itt még nem ér véget. Miután a megfigyelés szerepén keresztül újra megcsillant a remény, hogy valamiképp létrehozható lenne egy ilyen MATRIX szerű virtuális világ, a következő problémán kezdtem el gondolkodni. A számítási kapacitást nagy mértékben le tudtuk redukálni azzal, hogy csak a megfigyelt objektumokat emuláljuk, de még mindig iszonyatos mennyiségű tárhelyre van szükségünk ahhoz, hogy eltároljuk azoknak a részecskéknek az állapotát, amiket valaha is megfigyeltünk. Ha ezt nem tennénk, akkor inkonzisztens lenne a világ. Bemennék például egy szobába, amiben két asztal van. A jobb oldalin van egy alma, amit átrakok a bal oldalira. Aztán elfordulok, ezzel megszüntetve a megfigyelést, aminek köszönhetően a szoba elveszítené valós állapotát. Ha visszafordulok, azt várnám, hogy az alma a bal oldali asztalon lesz, ami csak úgy lehetséges, ha a virtuális világot fenntartó gép megjegyezte annak állapotát. Ez pedig felveti a tárhely problémáját. Nos, akkor mi mindent is kell eltárolni, hogy a világ konzisztens maradjon?

A választ a megfigyelés szerepének analógiájára az emlékezés szerepe adta. Nevezetesen amit nem figyelünk meg, azt nem kell emulálni, amire nem emlékezünk, azt pedig nem kell tárolni. Ily módon a világ nem lesz inkonzisztens a tudatunkban lévő képpel. A repülőgépes minta analógiájára könnyen átgondolhatjuk, hogy ha egy objektumra nem emlékszik senki, akkor az olyan mint ha nem is lenne. Erre persze rögtön mondhatjuk, hogy mi van akkor, ha fogok egy dobozt, elásom a földbe úgy, hogy csak én tudok róla. Eztán eltelik néhány év, én meghalok, ezzel eltüntetve a föld színéről minden a doboz létére vonatkozó emléket. Később mondjuk egy építkezés alkalmával valaki megtalálja a dobozt, így a doboz objektív, rajtam kívül is létező dolog. Nos, vajon tényleg megtalálja? Biztos, hogy a doboz nem fog onnan eltűnni? Kísérletileg csak úgy ellenőrizhetnénk a dolgot, hogy én, aki emlékszem a doboz helyére, kiásom, és visszaigazolom magam felé, hogy a doboz ottmaradt, ahol hagytam. Okoskodhatunk úgy is, hogy miután elástam a dobozt, írok egy kis cetlit, és elküldöm valakinek levélben. Ha én meghalok, és eltűnik az emlékkép, attól a cetli még őrzi a doboz helyéről az információt. Ha ennek ellenére a doboz nem lesz ott, inkonzisztens lesz a világ. Erről az esetről viszont könnyen belátható, hogy a problémát a doboz létéről áttereltük a cetli létére. Ezek alapján tehát az objektív valóság létezése nem bizonyítható. Csak azon történések léte bizonyítható, amiket éppen megfigyelünk, és csak azon objektumok létezése bizonyítható, amelyekre emlékszünk. Aki mindezek alapján még nem látja át az emlékezés szerepét, annak álljon itt egy gondolatkísérlet, ami igen markánsan, saját létünk tényének bizonytalanságával magyarázza a dolgokat. Biztosak lehetünk benne, hogy eddigi életünk valóságos? Nem lehet, hogy tegnap klónozott bennünket valaki, és belénk táplálta eddigi életünk emlékeit? Van bármilyen mód, hogy ennek ellenkezőjét meggyőző módon bizonyítsuk? Ennek fényében újra tegyük fel a kérdést magunknak, hogy ha egy tárgyról minden emléket törlünk mindenhonnan, akkor a tárgy vajon valaha is létezett? Aki az előzőek alapján ráérzett a megfigyelés szerepére, az ennek fényében az emlékezés szerepét is beláthatja.

Virtuális valóságunkat odáig egyszerűsítettük, hogy csak a megfigyelt dolgokat szimuláljuk, és csak azokat a dolgokat tároljuk, amelyekre emlékezünk. Ezzel iszonyatos mértékű számítási és tárolási kapacitást spóroltunk, és megcsillant a remény, hogy elméletben létezhessen egy olyan gép, ami egy ilyen virtuális valóságot képes fenntartani. Egy kérdés maradt még. Mi van azokkal a helyekkel, amiket még nem látott senki? Mi van akkor, ha az őserdő mélyén találok egy olyan helyet, amiről senkinek a tudatában nincsenek emlékek? Ebben a helyzetben több lehetőség is van. Az adott helyet valamilyen szabályok alapján real-time létrehozza a rendszer oly módon, hogy attól még a teljes világ konzisztens maradjon. Ha nagyon sarkosan akarnék fogalmazni, azt mondhatnám, hogy ez az "Isteni teremtés" szinonimája. A második lehetőség, hogy a gép a tudatra, pontosabban a tudatalattira bízza, hogy az adott helyen mit érzékeljen. Ebben a modellben a virtuális világot lakó emberek "megálmodják" a még nem létező helyeket, így ők teremtik maguknak a világot egy központi "algoritmikus gép Isten" helyett.

Ezen a ponton már elég szilárdnak tűnt az ideális virtuális világ képe a fejemben, amiben már gondolatkísérletek végezhetőek. Tegyük fel, hogy az ide bezárt emberek kísérleteket végeznek, és ugyanazokat a tényeket találják, mint mi. Felépítenek egy fizikai rendszert, és felírták a történések közötti összefüggéseket úgy, ahogyan mi is tettük.  Itt érdekes kérdés, hogy a fizikai törvények adottak voltak-e, vagy ők alkották-e meg őket, miközben azt hitték, csak vizsgálgatják a már kész világot, de ezen most lendüljünk túl. Azt találták, hogy a fizikai törvények teljesen determinisztikusak, így ha ismerik egy embertársuk agyának minden részecskéjét, és az őt ért hatásokat, ezzel 100%-os pontossággal megjósolhatják annak reakcióit, így elvéve tőle a szabad akarat szabadságát. Be is raknak egy kísérleti személyt egy kamrába, rákötik az eszközöket, képeket villantanak fel, és megpróbálják megjósolni a reakciókat, amiket a kísérleti személy cselekszik. Mit tehet ebben az esetben a gép, aminek az a feladata, hogy a világot konzisztensen tartsa, biztosítsa, hogy a fizikai törvények minden körülmények között működjenek, e mellett viszont teljes mértékben rejtse el az emberek virtuális teste mögötti tudatot, hiszen ha az emberek felfedeznék, hogy virtuális testükön túl valamiféle külső tudat is létezik, úgy rájöhetnének, hogy egy virtuális világ foglyai. A gép erre egy módon reagálhat, mégpedig hogy egy kis egérutat ad magának. Nem engedi, hogy a fizikai törvények teljesen determinisztikusak legyenek, e helyett a folyamatoknak lesz egy kis bizonytalansága, ami pont elég arra, hogy az agy működése ne legyen kiszámítható, és hely maradjon a tudatnak. Ily módon az agyat olyan folyamatok fogják vezérelni, ami kívül esik az emberi mérés határain. Ezzel a lépéssel pedig eljutottunk a teljes kvantummechanikai állásponthoz. Mivel ez az egész csak egy gondolatkísérlet arra vonatkozóan, hogy létre lehet-e hozni virtuális világokat, eszem ágában sincs azt mondani, hogy a világ így működik. Mindazonáltal nem lennék meglepve, ha a jövőben az agykutatók ilyen kvantumfolyamatokat találnának az agy működésében, amilyeneket már Penrose is megjósolt.

Ez jó végszó lehetne, de azért leírnék még két gondolatot, ami a virtuális világokon való elmélkedés közben az eszembe jutott.

Az egyik, hogy ennek a virtuális világot fenntartó hipotetikus gépnek vajon rendelkeznie kell-e szimulátorral? Álmainkból jól tudjuk, hogy erre agyunk is egész jó hatásfokkal képes. Álmainkat úgy éljük meg mint ha valóságosak lennének, és felteszem, ha valaki részecskefizikusnak képzelné magát álmában, képes lenne kísérleteket elvégezni, így talán szimulátorra nincs is szükség, azt megoldja a tudat. Ugyanezen okokból valószínűleg tárolóra sem lenne szükség, hiszen amúgy is csak azt kellene tárolnunk, amit a tudatok tárolnak. Elég lenne, ha bármely tudatban tárolt emlékhez hozzáférést biztosítanánk másoknak. Innentől kezdve a gépnek egyetlen feladata van, hogy az emberek tudatát összekösse, és biztosítsa a közös "álom" konzisztenciáját. Itt persze megint kérdéses, hogy a konzisztencia fenntartását "erőltetni" kell-e? A konzisztencia igénye (ha leteszem az almát az asztalra, elfordulok, majd vissza, szeretném még mindig ott találni) az agyból származik. Ha egyszerűen csak valami módon összekötnénk a tudatokat, az így létrejött hálózat vajon nem gondoskodna a "közös álom" konzisztenciájáról? Mindenesetre egész jó haladás, hogy egy világméretű részecskeszimulátorból néhány "drótra" (amivel "összedrótozzuk az embereket") redukáltuk a hipotetikus virtuális valóság gépünket. És ha már itt tartunk, vajon egyáltalán szükség van drótokra?

A másik dolog, amin gondolkodtam, hogy ha az emberiség úgy döntene, hogy egy ilyen virtuális világba költözik (pl. azért, mert már felélte a föld erőforrásait, és más módon képtelen lenne fennmaradni), akkor hogyan nézne ki egy ilyen világ. Elsőre biztos paradicsomi állapotok uralkodnának, mindenki örök életű lenne, és élvezné a jólétet. Néhány száz év után azonban ez a nagy jóság biztos unalmassá válna, kihívások kellenének, amik szórakoztatnak bennünket. Valószínűleg kitalálnánk valami olyasmit, ami egy számítógépes játékhoz hasonló. Feladatokat tűznénk ki magunknak, amiket végig kell csinálni és hogy még izgalmasabb legyen, mindezt időre. A játékban megszületnénk, élnénk, az élet mindenféle akadályok elé állítana, amiknek a megoldása sikerélményt okoz, majd a végén meghalnánk, hogy újra kezdhessük egy másik pályán. Lehet, hogy tökéletlen világunk úgy tökéletes, ahogy van ... Jó elmélkedést ...

2010. július 23., péntek

Zeitgeist Addendum

Néhány napja láttam a Zeitgeist Addendum c. dokumentumfilmet (torrent site-okról magyar szinkronnal, vagy felirattal beszerezhető, de Google Video-n 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.

2010. július 13., kedd

Relativitáselmélet

Az első találkozásom a modern fizikával olyan 12 éves koromban a Relativitáselmélet megismerése volt. Emlékszem mennyire lenyűgöztek azok a következmények amiket az elmélet hozott és végre azt is megértettem, hogy a nyugati kultúrában miért jelent egyet Einstein neve a zsenialitással. Ez a borzas hajú bajszos kis öreg olyan dolgokkal jött elő, hogy nem létezik abszolút távolság vagy tömeg, vagy hogy épp lelassulhat az idő. Ezek a dolgok nem olyan könnyen emészthetőek, ráadásul egy rakás paradoxont szülnek. Erről írnék most egy kicsit, illetve arról, hogy ez az egész talán nem is olyan felfoghatatlan ha megfelelő nézőpontból szemléljük. Előre bocsátom, hogy a Relativitáselméletnek létezik egy speciális és egy általános változata. Időrendben először a Speciális Relativitáselmélet készült el, majd ennek kiterjesztéseként állt elő az Általános Relativitáselmélet amely már a gyorsuló rendszereket és a gravitációt is magában foglalja. Úgy érzem túl nagy falat lenne mindkét elmélet ismertetését egyetlen blogbejegyzésbe sűríteni, ezért ebben a bejegyzésben csak a speciális változattal foglalkozom. Elképzelhető, hogy a közeljövőben készül egy új bejegyzés is az általános változatról. No de lássuk, mit is mond nekünk a világról a Speciális Relativitáselmélet.

A 19. század nagy fizikai kihívása volt, hogy az elektromágneses kölcsönhatásokat leíró Maxwell egyenleteket hogy lehet összhangba hozni a klasszikus fizikával. Egész egyszerűen arról volt szó, hogy volt két jelenségcsoport amire volt két modellünk. A két modell külön külön nagyon pontosan leírta a dolgok működését az adott témakörben, de egymásnak ellentmondtak. A dolog valahol ott kezdődik, hogy már Newton kimondta, hogy nem tehetünk különbséget egy álló, vagy egy egyenes vonalú egyenletes mozgást végző rendszer között. Igazából mi választjuk meg, hogy mit tekintünk állónak, és mit mozgónak. Ha valaki a vonatsínek mellett áll, annak számára a vonat mozog, míg a vonaton ülő ember számára a vonat mozdulatlan, és a táj mozog. De ha valaki az űrből nézi a vonatsínek mellett álló embert, az azt látja, hogy ez az ember mozog, hiszen a föld vele együtt forog. Tehát a mozgás relatív, attól függ, mit tekintünk állandónak. Kicsit szalonképesebben megfogalmazva ezt úgy mondhatjuk, hogy nincs olyan fizikai kísérlet, amivel különbséget tudnánk tenni egy álló vagy egy egyenes vonalú egyenletes mozgást végző rendszer között. Tehát ha besötétítjük a vonat ablakait és eltekintünk attól, hogy döcög a sínen, képtelenek leszünk megmondani, hogy mozog-e vagy sem, sőt a mozgás sebessége is csak attól függ, hogy honnan nézzük. Ez eddig teljesen tiszta. A gond ott kezdődött, mikor bejött a képbe a fény. A fényt vizsgálva hamar rájöttek, hogy úgy lehet leírni, mint a víz felszínén keletkező hullámokat. A fényhullámok tudnak egymással interferálni, erősítik/gyengítik egymást, tehát ez a valami teljesen úgy viselkedik, mint a víz hullámai, amiket mondjuk egy kavics kelt ha a vízbe dobjuk. Mivel fény mindenhol van, be is vezettek egy amolyan hipotetikus folyadékot amit éternek neveztek, ami mindenhol jelen van, valahogy átfolyik a részecskék között, nem lehet sehonnan kizárni. A fény pedig ennek a varázslatos éternek a hullámzása. Igen ám, de ha létezik ez az éter, akkor össze tudunk állítani olyan kísérletet, amivel megmérhetnénk az abszolút sebességünket az éterhez képest. Tehát ha összeállítunk egy olyan egyszerű berendezést, ami előre és hátra is kibocsát egy fénysugarat, majd a két fénysugarat interferenciába hozzuk, akkor kimutatható lenne, hogy a föld milyen sebességgel mozog az éterben, hiszen ha az éter mozdulatlan, akkor a mozgás irányába eső fénysugár hamarabb érne vissza, mint az azzal ellentétes. Ez volt a híres Michelson–Morley-kísérlet. A kísérlet kudarccal végződött, nem sikerült kimutatni a mozgást és ezzel magának az éternek a jelenlétét sem. Bár Einsteint nem ez a kísérlet késztette a speciális relativitáselmélet megalkotására, ő egyszerűen csak a Maxwell egyenletek és a klasszikus fizika közötti ellentmondást próbálta feloldani, mégis ez a kísérlet jól mutatta, hogy itt valami nincs rendben. A klasszikus példával élve az történik, hogy ha egy autó 50 km/h sebességgel mozog, és vele szemben elhúz egy másik ugyancsak 50 km/h sebességgel, akkor az egyik autóban ülő utas számára a másik autó 100 km/h sebességgel száguld (hiszen magát tekinti nyugvó megfigyelőnek). Ezzel szemben a fény valami fura módon úgy működik, hogy akár szembe megyünk vele, akár távolodunk tőle, és mindezt akármekkora sebességgel is tesszük, mindig fénysebességgel fog haladni. Az ő sebessége valahogy nem relatív. Ha egy fénysebességgel mozgó űrhajóban ülök, és szembe jön velem egy másik fénysebességgel mozgó űrhajó, nem azt látom, hogy a másik űrhajó kétszeres fénysebességgel közelít, hanem azt, hogy az ő sebessége ugyancsak fénysebesség. Ez pedig már több mint furcsa.

Einstein végül egy matematikai trükkel élve azt mondta, hogy ha elfogadjuk, hogy a mozgó rendszerekben lerövidülnek a távolságok, az ellentmondás feloldható. Vagyis valójába nem is Einstein jött elő ezzel, hanem Lorentz. Ő azt mondta, hogy az éterrel való kölcsönhatás hatására a tárgyak fizikailag megrövidülnek a mozgás irányában és emiatt mérjük a fény sebességét konstansnak, valamint ezért nem sikerült a Michelson-Morley kísérletben kimutatni az éterhez mért sebességet. Einstein inkább csak annyival egészítette ki az egészet, hogy a távolságot eleve úgy definiálta, hogy az a sebességtől függ és e mellett bevezette, hogy az idő is lassul, valamint a testek tehetetlen tömege is megnő. Nem kereste a dolgok okát az éterben, egyszerűen feltételezte, hogy a világ így működik, és ha ez igaz, akkor megszűnik az ellentmondás. A fény sebessége fix marad, az egyenes vonalú egyenletes  mozgást végző rendszerek ugyanúgy megkülönböztethetetlenek az állóktól és minden a helyére kerül. Csakhogy ha ezeket az elveket elfogadjuk, azzal sok érdekes paradoxont hívunk életre. Az egyik ilyen az Iker-paradoxon. Ennek annyi a lényege, hogy ha egy ikerpár egyik tagja hosszú utazásra indul egy űrhajón a fényhez közeli sebességgel, a másik pedig a földön marad, akkor ha mondjuk 50 év múlva találkoznak, az űrhajós csak néhány évet öregszik - hiszen számára lassabban telik az idő -, míg a másik az eltelt időt rendesen 50 évnek érzékeli. Kicsit furcsa elképzelni, hogy az ikrek 25 évesen elköszönnek egymástól, majd 50 év elteltével egyikük mindössze 30 éves, míg a másik már 75. Meseszerűen hangzik az egész, főleg ahhoz képest, hogy az idő lelassulása csak egy matematikai trükk eredménye, hogy újra rendesen működjenek a képletek. Tulajdonképpen semmi alapja. Az egészben az a legcsodálatosabb, hogy mikor fizikai kísérletet végeztek az elmélet bizonyítására, az valóban azt mutatta, hogy a Relativitáselmélet működik. Persze nem ikrek utaztatásával, hanem elemi részecskék felgyorsításával végezték a kísérleteket, de az eredmény ugyanaz volt. Az idő lelassul, a tömegek megnövekednek, a távolságok pedig lecsökkennek. Talán ez volt a matematika és fizika egyik legnagyobb diadala, hiszen egy matematikai tákolmányt végül a természet visszaigazolt, ezzel jelezve, hogy a matematika és fizika igenis működik, és alkalmas a valóság leírására. Valami ilyesmi futhatott végig Einstein agyán is, mikor azt mondta: "a természet legcsodálatosabb tulajdonsága, hogy megérthető".

Persze azért ez az egész hozott magával néhány nyugtalanító dolgot. Például ha a földön van egy 1m-es etalon rúd, azt minden megfigyelő a saját sebességétől függően fogja valamekkorának mérni. Ha elrepül felette két űrhajó különböző sebességekkel, az egyik úgy találja majd, hogy ez a rúd csak fél méter, a másik számára viszont csak 1/4. A földön álló megfigyelő pedig szentül meg van győződve róla, hogy az márpedig 1m. És ez nem optikai csalódás, nem csak ekkorának "látják" azt a rudat, hanem az ő rendszerükből nézve az a rúd valóban ekkora. Tehát az egyetlen etalon rúdnak 3 mérete is van egyszerre, és mindhárom fizikailag valóságos, egyik sem igazibb a másiknál. Ez pedig ugye azt jelenti, hogy nincs sem abszolút távolság, sem abszolút tömeg, sem abszolút idő. Ezek pedig a fizika alapmennyiségei, mindent ezekből származtatunk, innentől kezdve tehát az egész valóság csak attól függ honnan nézzük, minden relatív. Ha az ember lába alól egyszeriben így kirántják a talajt, azt nehezen veszi be az elméje. Számunkra értelmezhetetlen dolog az, hogy az idő lassabban telik, vagy hogy több szemlélő számára többféleképpen telik az idő, vagy hogy épp egy 1m-es rúd valójában nem is 1m-es, sőt eleve a hossza csak attól függ, hogy honnan nézzük. Pedig a Relativitáselmélet is felfogható szerintem, ez is csak attól függ, honnan nézzük. :)

A Relativitáselmélet értelmezései

Hogy felfoghatóvá tegyük az egészet, kicsit a mélyére kell néznünk. Először is le kell szögeznünk, hogy Einstein nem mondott többet, mint azt, hogy a fizikában használt alapegységek (távolság, idő, tehetetlen tömeg) a mozgás hatására hogyan változnak. Nem filozofált azon, hogy vajon mit nevezünk időnek, tömegnek, vagy távolságnak. Ezek a fizika szempontjából nem is annyira érdekesek. A fizikusoknak az a lényeg, hogy a valóságot képletekbe foglalják, hogy számolni tudjanak vele. A könnyebb érthetőség kedvéért felállítanak modelleket, hogy valamiképp értelmezhető legyen az egész, de ez csak mankó, a végeredmény szempontjából nem érdekes. Annyi a lényeg, hogy az aktuális elmélet ellentmondásoktól mentesen megmagyarázza a valóságot, esetleg történhet fordítva - mint ahogy történt is a Relativitáselmélet esetén -, alkothatunk elméleteket, amik előrejelzéseket tesznek, amiket később igazolhatunk. Einstein tehát azzal, hogy bevezette a relatív tér/idő/tömeg fogalmát, közös nevezőre hozott két elméletet, és itt meg is állt. Ezzel együtt semmi nem tiltja, hogy modellek készüljenek, amik valamiképp magyarázzák a valóság működését, és összhangban vannak a Relativitáselmélettel. Ilyen modell például a Lorentz-elv. Valahol ezt konkurens elméletként említik, de szerintem ez inkább csak egy alternatív modell, ami összhangban van a Relativitáselmélettel. Lorentz a távolságok csökkenését fizikai folyamatként értelmezte. Azt mondta, hogy az anyag kölcsönhatásban van az abszolút éterrel, és mikor ebben mozog, a mozgás irányában az elektromágneses erőterek torzulnak, az elektron pályák közelebb kerülnek az atommaghoz, így a tárgyak fizikailag összemennek. Sokan támadják (válasz erre) ezt a modellt, hiszen nem ad választ az idő lassulására, vagy a tömeg növekedésére. Ez egyfelől valóban igaz, másfelől viszont jól mutatja, hogy lehetséges olyan modelleket alkotni, amelyek valamiképp magyarázni tudják a relativitást. Például a Lorentz-elv kiterjeszthető oly módon, hogy azt feltételezzük, az éter valami esszenciális módon van jelen minden erőhatásban, mindent az éter közvetít, így a Lorentz-elv kiterjeszthető a tömegre, vagy az időre is. Ez utóbbira oly módon, hogy az időt mint a kölcsönhatások lefolyásának idejét definiáljuk, így azzal, hogy az éterben való mozgás hatására ezek az éteren végbemenő kölcsönhatások lelassulnak, így minden fizikai folyamat (akár egy Ikertestvér öregedése is) lelassul. Hasonló magyarázatot alkothatunk a tömeg növekedésére is, hiszen a tömeget már annak idején Newton úgy definiálta, hogy azt mutatja meg, hogy egységnyi erő hatására mekkora gyorsulás jön létre. Ha elfogadjuk, hogy minden kölcsönhatás az éter közvetítésével működik, azt találhatjuk, hogy a mozgó rendszerre az éteren keresztül kisebb mértékben hat az erő, kisebb gyorsulást hozva létre, így ezt értelmezhetjük a tömeg növekedéseként. Persze az ilyen modelleket általában a fizikusok rögtön el is dobják, hiszen ha több ekvivalens elmélet/modell ír le egy folyamatot, azok közül a természettudomány azt választja, amely a legkevesebb előfeltételezést igényli. Ezt az elvet hívjuk Occam borotvájának. Emiatt az elv miatt a jelenleg elfogadott és használt elv a Relativitáselmélet a Lorentz elvvel, vagy általánosabban vizsgálva az éter alapú elméletekkel szemben, hiszen a Relativitáselméletnek nincs szüksége éterre. Itt jegyezném meg, hogy bár sokan úgy tartják, hogy a Relativitáselmélet száműzte a fizikából az éter fogalmát, valójában Einstein sohasem állított olyat, hogy az éter léte megcáfolható lenne. Einstein mindössze azt állította, hogy a világ természete miatt az éter mint olyan kimutathatatlan. Ettől még semmi nem tiltja, hogy létezzen, de mivel fizikai kísérletekkel kimutathatatlan, ezért a fizika nem tud vele mit kezdeni, tehát az a fizika számára nem létezik. Véleményem szerint nagyon fontos, hogy ezt a fajta természettudományos gondolkodást - nevezetesen, hogy ami nem mérhető, az nincs, illetve hogy azt a modellt fogadjuk el, amely a legkevesebb alapfeltevést igényli - megértsük, és ennek fényében vizsgáljuk a modern fizika állításait. Ha így teszünk, rögtön nem lesz olyan misztikus, és érthetetlen az egész, és mindjárt nem tiltakozik az agyunk az olyan kijelentések hallatán, mint hogy lelassul az idő. Fontos azt is leszögezni, hogy a fizikai idő/távolság/tömeg fogalmak adott esetben teljesen mást jelentenek, mint a fejünkben létező abszolút idő/tér/tömeg fogalmak. Erre is ugyanazt kell mondjuk, mint az éterre, hogy Einstein soha nem állított olyat, hogy az abszolút Newtoni tér és idő (ami az elménkben megtalálható idő/tér fogalmak) nem létezik, mindössze azt mondta, hogy ezek nem mérhetőek, nem kimutathatóak, így ezek helyére bevezette a fizikai tér/idő fogalmát. A fizikai távolság és idő az amit mérni tudunk. Tehát pl. 1m-t úgy tudunk definiálni, hogy ha 1/300 000 000 mp alatt a fény ekkora utat tesz meg. Ugyanígy az idő definícióját is csak elemi részecskék lebomlásához, fizikai kémiai folyamatok lefolyásához viszonyítva tudjuk meghatározni. Innentől pedig már rögtön kiveszik a misztikum az egészből, és úgy fogalmazhatjuk át a Speciális Relativitáselméletet, hogy a fizikai folyamatok lefolyásának ideje lassabb lesz, ha bármilyen mérést végzünk a távolságokra (amely ugye csak a 4 kölcsönhatás valamilyen közvetítésével lehetséges, más módon nem tudunk információt szerezni az anyagról), azt találjuk, hogy azok megrövidülnek, és bármilyen mérést végzünk a tömegre (erre a definícióból eredően sincs más választásunk, mint az erő által létrehozott gyorsulással visszaosztjuk az erőt), azt találjuk, hogy az megnő. Ebből a definícióból már jól látszik, hogy egy a Relativitáselmélettel teljesen ekvivalens elméletet kapunk akkor is, ha annyit mondunk, hogy a rendszer sebessége hatással van a rendszerben működő kölcsönhatásokra, például azért mert minden kölcsönhatást az éter közvetít. Innentől kezdve az egész érthetővé válik. A konstans méterrúd valóban 1m hosszú, csak a kölcsönhatások torzulása miatt mérik az űrhajósok különböző méretűnek, a gyorsan mozgó Ikertestvér a kölcsönhatások torzulása, és ez által a fizikai/kémiai folyamatok lelassulásának köszönhetően öregszik lassabban, és a tömegek is csak a kölcsönhatások "gyengülésének" hála tűnnek nagyobbnak. Bár ezt a modellt a fizika eldobja, hisz Einstein modelljével szemben nem állja ki az Occam borotváját és fizikai szempontból sem mond semmi újat (ekvivalens az einsteini modellel), mégis nagyon jó arra, hogy mi, halandó emberek jobban megértsük ezt az első látásra misztikusnak és érthetetlennek tűnő elméletet.

Bár tudom, hogy ha figyelembe vesszük az Általános Relativitáselméletet, a Lorentz elvből kiinduló éter alapú elméletek megint elkezdenek kicsit sántítani, azért remélem sikerült rávilágítanom arra, hogy a fizikusok kicsit máshogy gondolkodnak mint mi, és ha ezt nem tartjuk észben, sokszor értelmezhetetlennek tűnnek számunkra az ő állításaik, sőt kifejezetten misztikusnak. Remélem azt is sikerült megvilágítani, hogy egy jelenség, sőt az egész általunk észlelt valóság értelmezésére több ekvivalens modell adható, és ha az adott modellek ellentmondásoktól mentesek, és ugyanolyan teljességgel magyarázzák a világot, akkor tulajdonképpen szabad választásunk, hogy melyiket fogadjuk el. Ahogyan azt már Neils Bohr is mondta, a valóságot a maga teljességében amúgy is képtelenek vagyunk megérteni, csupán hasonló dolgokat kereshetünk az általunk érzékelt környezetből és ezekkel próbálhatjuk elírni a folyamatokat. Tulajdonképpen ez a modellalkotás. Jól tudjuk, hogy az atommag nem egy kis piros golyó (hogy is lenne színe?), az elektron nem egy kék golyó, sőt még csak nem is kering a mag körül, csak úgy ott van szétkenve hol itt-hol ott, csak az ilyesmin könnyen felülkerekedünk, mert ez egy számunkra kényelmes, jól kezelhető, érthető modell.

Így végezetül csak arra szeretnék kilyukadni, hogy ha már rendelkezünk a modellek szabad választásának lehetőségével, néha tegyük félre kicsit a fizikusokat (akiknek csak annyi a lényeg, hogy a dolgok számolhatóak legyenek, ők nem akarják a szó klasszikus értelmében "megérteni" a világot), hagyjuk figyelmen kívül Occam borotváját, és vizsgáljuk meg az adott jelenséget egy másik modell szemszögéből. Ha más értelme talán nincs is, annyi mindenképp, hogy meg bírjuk érteni és "épp ésszel" fel tudjuk fogni a dolgokat. Mindamellett én szentül hiszem, hogy az ilyen modellek vizsgálata nem csupán játék az elméletekkel, hanem adott esetben segíthet a tudománynak kimozdulni egy "lokális maximumból", és talán kicsit továbblökheti azt. Persze ez már csak az én véleményem.

Az egymással ekvivalens modellekről, a tudomány filozófiájáról, a relativitásról, a Lorentz-elvről, és még sok hasonlóról íródott egy nagyon jó könyv. Mindenkinek csak ajánlani tudom. Nagy része volt abban, hogy ez a bejegyzés így ebben a formában elkészülhetett.

2010. június 22., kedd

Samsung Galaxy Spica frssítése Android 2.1-re

Már régóta fontolgattam, hogy be kéne szereznem egy Android-os telefont. Kicsit körbenéztem az elérhető eszközök között, és a választásom a Samsung Galaxy Spica-jára esett. Ez a telefon ugyanis rendelkezik minden tudással, amivel a nagyok (WiFi, GPS, elviselhető teljesítményű processzor), az ára viszont kb. fele annyi (Extreme Digitálnál röpke 60 000 Ft). Mikor hozzájutottam, bekapcsolás után az első gondolatom az volt, hogy a telefonnal szállított 1.5-ös oprendszert 2.1-esre kellene cserélni. Kicsit utánaolvasgattam, és március környéki híreket találtam arról, hogy a Samsung hamarosan hivatalosan is elérhetővé teszi a 2.1-es firmware-t telefonjaira. Gyorsan fel is pakoltam a telefonhoz adott CD-ről a Samsung Kies nevű kezelőprogramját, és megpróbálkoztam a frissítéssel. Első körben a cucc fel sem ismerte a telefont, aztán valami modell adatbázist nem talált. Próbálkoztam a PC suite különböző változataival, a Kies-ből is töltöttem frisset, végül kb. fél napi tömény szenvedés után feladtam. Ezzel a telefon upgrade dologgal valahogy nincsenek a helyzet magaslatán. Végül úgy döntöttem, lesz ami lesz, felülvágom a firmware-t, mert nekem 2.1-es Android kell, ha a fene fenét eszik is.

A frissítést a http://forum.androidhungary.com/topic/samsung-galaxy-spica-android-21-flashing-utmutato alapján végeztem. Az Odin-t és a drivereket könnyen be tudtam szerezni, a firmware-hez kicsit szenvedni kellett, mert ilyen hülye fájlmegosztó oldalakról kellett lebányászni, amik mindenféle várakoztatásokkal próbálják rávenni az embert, hogy dobjon be némi pénzt. Mennyivel jobban örültem volna egy szimpla torrent linknek, de mindegy, leszenvedtem a firmware-t. Megnyomkodtam a gombokat, beállítottam a letöltést, betallóztam a fájlokat, aztán vártam, de nem történt semmi. Rájöttem, hogy a Kies még fut a háttérben. Lelőttem, újraindítottam az Odin-t, de a letöltő csík meg sem mozdult. Na, gondoltam, most vágtam tönkre a telefont, ugyanis kikapcsolni nem lehetett, a leírásban meg az ember lelkére kötik, hogy ne szakítsa meg a folyamatot. Végül aksi ki-be, bekapcsoltam a telefont, és hamar meg is könnyebbültem, mert simán bebootolt az eredeti 1.5-ös Android. Ezen kicsit fel is bátorodtam, hisz ebből látszott, hogy azért nem olyan könnyű tönkre vágni a telefont. Újra elindítottam a feltöltést az Odin-ből, de most valami cache fájl miatt nyavajgott. Végül rájöttem, hogy az Odin mellé csomagolt ops fájlban van a hiba, és a helyről, ahol a firmware-t is letöltöttem, letöltöttem az új ops-t. Felülvágtam a régit, elindítottam a frissítést, és minden smakkolt. Végigfutott a progress bar, telefon kikapcs-bekapcs, és az új 2.1-es Androidom fogadott. A beállításoknál visszaváltottam a nyelvet magyarra, és végre birtokba vehettem az újdonsült telefonomat.

Amúgy magával a telefonnal eddig nagyon meg vagyok elégedve, a Google szinkronizálás (címjegyzék, levelezés, gTalk, stb.) alap. A WiFi-t is rögtön belőttem, hogy ne is próbálkozzon 3G-n, mert nem szeretnék következő hónapban 10 000-es számlát kapni az adatforgalom miatt. Telepítettem még a market-ből egy eBuddy nevű üzenetküldő alkalmazást, ami kb. a Pidgin Androidos megfelelője (MSN, ICQ, stb. támogatás), és egy Skype Lite Beta-t. Talán még egy IGO hiányzik róla, hiszen a GMap-nak netkapcsolat kell, és utazás közben általában nem jut az ember WiFi-hez, a mobilnet pedig dárga.

UPDATE: A későbbiekben néhányszor próbáltam belőni a 3G-t, de nem jártam sikerrel. A megoldást végül egy kolléga segítségével sikerült megtalálni. Ahhoz, hogy a telefon csatlakozzon a 3G hálózatra, a Beállítások/Vezeték nélküli beállítások/Mobilhálózatok/Hozzáférési pontok neve menüpont alatt hozzá kell adnunk a szolgáltatóhoz tartozó APN-t, amiről itt találhattok egy listát. A beállítást követően remekül működik a 3G. A megoldás megtalálásáért külön köszönet Kercza Ádámnak.

2010. június 8., kedd

Üzenet alapú programozás - Entourage és ErraiBus

Az utóbbi időben az ActiveMQ kapcsán kicsit mélyebben utánaolvastam az üzenet alapú rendszereknek. Nem annyira az ESB megoldások érdekeltek, hanem inkább az, hogy léteznek-e üzenet alapú web-es keretrendszerek. A közelmúltban 2 nagyon jó projektet is találtam. Ezek a címben is szereplő Entourage és ErraiBus.

Az Entourage az Appcelerator egyik alprojektje. Maga az Appcelerator egy olyan keretrendszer, melynek segítségével mobil és desktop alkalmazásokat készíthetünk HTML és JavaScript segítségével. Maga a futtató környezet egy beágyazott böngésző, valamint egy általános API gyűjtemény, amin keresztül JavaScript-ből hívhatóak az adott platform natív funkciói. Így ha egyszer összeraktuk a HTML/Javascript alkalmazást, azt minden változtatás nélkül futtathatjuk Android telefonokon, IPhone-on, és készülhet belőle desktop alkalmazás is. Igazából a rendszer önnmagában is megérdemelne egy saját post-ot, így többet nem is mondok róla, inkább az Entourage-re koncentrálok. Az Entourage egy JavaScript library, amelynek alapja egy üzenet sor (message queue). Az üzenet sorba üzeneteket rakhatunk be JavaScript-ből, illetve funkciókat ültethetünk rá egy-egy üzenetre. Ez így önmagában nem nagy dolog, az izgalmas igazából az, hogy a keretrendszer mi mindent ki tud hozni ebből az egyszerű architektúrából.

Az Entourage üzenetsorra épül az Entourage Expressions, ami tulajdonképpen egy HTML-be ágyazható DSL, aminek segítségével JavaScript nélkül valósíthatunk meg AJAX-os működést. Egyszerűen az adott HTML tag-et kell ellátnunk egy
 on="[condition] then [action]"

attribútummal. A condition rész tulajdonképpen egy esemény/üzenet az üzenet sorból, amit vagy mi tehetünk oda JavaScript segítségével, vagy a felhasználótól jöhet pl. click, hover, stb. Az action pedig ugyanúgy lehet egy újabb esemény küldése, vagy pedig valamilyen előre definiált működés pl. class attribútum cseréje, stb. Ezzel az egyszerű rendszerrel már eleve nagyon sok mindent meg lehet valósítani, mindezt JavaScript programozás nélkül egyszerű attribútumok használatával.

A következő szint az Entourage UI, ami tulajdonképpen egy az alsóbb szintekre épülő widget gyűjtemény. Itt egy control attribútum hozzáadásával definiálhatjuk a widget típusát és paramétereit, és annak szerkezetét általában a tag-ben szereplő HTML kód határozza meg (pl. ul/li tagok egy lista esetén). Ezzel az eszközzel már tulajdonképpen teljes AJAX-os felhasználói felületek építhetőek némi HTML tudással JavaScript ismerete nélkül.

Az utolsó komponens a Service Brokers, ami nekem a leginkább tetszett. A Service Broker-ek segítségével tulajdonképpen teljesen transzparens módon hozzákapcsolhatjuk a szerver oldali kódot az Ertourage alkalmazáshoz. A megoldás mindössze annyi, hogy a message queue-t úgy konfiguráljuk, hogy bizonyos üzeneteket a szerver felé továbbítson. JavaScript oldalról ez teljesen transzparens módon történik, hiszen ugyanúgy tudunk üzenetet küldeni a szerver felé, mint egy másik helyi komponens felé, ráadásul az egyszerű protokollnak köszönhetően szinte akármilyen programozási nyelven (Java,.NET, PHP, Python, stb.) és környezetben (Spring, Google App Engine, Pylons, stb.) készülhet a szerver oldal. Összességében tehát egy olyan rendszert kapunk, ahol - ha megelégszünk az alap készlettel -, JavaScript nélkül fejleszthetünk webalkalmazásokat úgy, hogy a szerver oldali keretrendszer teljesen szabadon választható.

A másik rendszer, ami az Entourage-hez hasonlóan üzenetkezelésen alapul, a JBoss egyik alprojektje, az ErraiBus. Az ErraiBus egy teljesen Java alapú rendszer. A rendszer kliens oldalát GWT-vel készíthetjük el, a szerver oldal futtatásához pedig valamilyen Java Servlet Container szükséges. A két oldal között egy üzenetsor segítségével kommunikálhatunk, tulajdonképpen ezt hívjuk ErraiBus-nak. Ha az előző megoldással hasonlítjuk össze, úgy hátrányának az mondható, hogy szorosan kötődik a Java nyelvhez (a GWT és a szerver oldal miatt is), ugyanakkor az előző light weight megoldáshoz képest ez igazi hard core megvalósítás, ugyanis az üzenetsor comet kapcsolaton keresztül működik, így tiszta kétirányú kommunikáció lehetséges. Nincs szükség külön poll-ozásra, és hasonló trükkökre, ugyanazzal az egyszerűséggel küldhetünk a szerverről a kliens oldalra, mint fordítva. Ez az architektúra tehát valóban real-time alkalmazásokat tesz lehetővé. Ha ehhez hozzágondolom, hogy GWT-ben már Quake-et is írtak, akkor látható, hogy egy ilyen rendszerrel a lehetőségek száma szinte végtelen. A transzparens működést pedig itt is az üzenet sor alkalmazása hozta.

A fentiek alapján úgy látom, hogy az üzenet alapú rendszerek előtt még nagy jövő áll, és sok esetben jelenthetnek nagyon kényelmes megoldást heterogén környezetben. Szerver oldalon az ESB és az ActiveMQ, kliens szerver kapcsolat esetén pedig az Entourage és ErraiBus jellegű alkalmazások. Én személy szerint szívesen látnék valamilyen egységes service bus megoldást, ami ezen rendszerek előnyeit egyesíti, tehát a buszra ugyanúgy "aggathatnánk" kliens oldali GWT alkalmazásokat, Appletteket, Flex, JavaScript, stb. alkalmazásokat, mint szerver oldali Java, PHP, .NET, stb. feldolgozókat, mindig az adott igényeknek megfelelően, sőt egy ilyen rendszerben sokkal szabadabban mozgathatnánk az egyes komponenseket, így ugyanazt a rendszert használhatnánk desktop környezetben (minden komponens a gépre kerül), webes, vagy mobil környezetben (bizonyos komponensek a szerveren maradnak).

2010. június 5., szombat

ActiveMQ, MorbidQ - üzenet alapú aszinkron kommunikáció heterogén rendszerekben

Nem olyan régen egy projekt kapcsán a következő problémába ütköztem: kényelmi szempontból egy heterogén rendszert készítettem, aminek voltak web-es PHP-s részei, néhány időzített offline PHP script, meg néhány Java-s komponens. Alapvetően egy weblapról van szó, ahol az ügyfél termékeket rendelhet meg (web-es PHP rész), majd a megrendelések alapján egy időzített Java process előállítja a felhasználó számár elkészült csomagot (Java komponens), végül egy offline időzített PHP script e-mailben elküldi a csomagot a felhasználónak (offline PHP rész).

Mivel a lehetőségek elég szűkösek voltak, valami nagyon egyszerű megoldást kellett találnom a kommunikáció megvalósítására. A megoldás szinte adta magát, a megrendeléseket tároló adatbázis tábla szolgált az adatok átadására. A webes alkalmazás felvette a megrendelést a táblába, aztán cron-al néhány percenként elindítottam a Java process-t, ami ellenőrizte, hogy van-e új megrendelés. Ha volt, legenerálta a csomagot és átbillentette a rendelés állapotát. Végül az ugyancsak cron-ból futtatott PHP process ellenőrizte, hogy van-e postázni való. Ha volt, elküldte e-mailben, és átbillentette az állapotot. A rendszer egész jól működik is, de azért nem hagyott nyugodni a gondolat, hogy hogyan lehetne ezt még hatékonyabban megcsinálni. Az egyik ötlet, hogy a PHP engine és a Java VM betöltődési overheadjét elkerülendő mindkét process-t démonként kellene futtatni cron nélkül. Így sok erőforrást lehetne megspórolni, hisz nem kell minden esetben újra elindítani a JVM-et/PHP script engine-t, és betöltögetni az osztályokat/scripteket. Ez viszonylag egyszerűen kivitelezhető. A másik dolog, ami már inkább gondolkodóba ejtett, hogy amit csináltam, az tulajdonképpen egy primitív message queue. A web alkalmazás bedobja a megrendelés üzenetet, amit a Java alkalmazás feldolgoz, majd bedob egy postázás üzenetet, ami pedig az időzített PHP process-nek szól. Ezt biztos lehetne valahogy általánosítani. Egy olyan queue megoldás körvonalazódott a fejemben, aminek célja több alkalmazás aszinkron kommunikációja, ahol az egyes komponensek bármilyen környezetben készülhetnek, így a megoldás teljesen platform független. Adatbázisban gondolkodtam, schedulerekben, és valami cross-platform (mondjuk JSON) kommunikációban. Végül ahogy szokott, kiderült, hogy nem én vagyok az első, akinek megfordult a fejében egy ilyen rendszer gondolata.

Olyannyira, hogy már nevet is adtak neki, Enterprise Service Bus-nak (ESB) hívják, és a célja pont az amit az előbbiekben felvázoltam. Egy közös üzenet soron alkalmazások lógnak, és minden típusú kommunikációhoz külön szál (topic) rendelhető. Ha az egyik komponens akar valamit a másiktól, egy üzenetet helyez az üzenetsorba, amit a másik feldolgoz, és persze a dolog működhet két irányban, tehát a feldolgozó komponens egy másik üzenet soron vissza üzenhet a feladónak. A megoldás nagy előnye, hogy ha az üzenetek valamilyen általános formában mozognak, a Service Bus-t kényelmesen használhatjuk valamilyen heterogén környezetben (mint pl. az általam vázolt rendelési rendszer). A másik nagy előny az aszinkron jelleg. Azt ugyanis nem említettem, hogy a megrendeléshez tartozó alkalmazás csomag generálása igen erőforrás igényes folyamat. Tehát nem csak azért kellett ezt a megoldást használnom, mert a PHP webalkalmazásból nehézkes Java-t hívni, hanem azért is, mert a generálás miatt könnyen timeout-olhatott volna a PHP script, vagy ha több megrendelés van egyszerre, azt nem biztos, hogy bírná a szerver. Így az üzenetsor nem csak a heterogén rendszerben történő kommunikációra, hanem az erőforrások elosztására is kiváló eszköz. A fentebb vázolt probléma általános megoldása tehát odáig egyszerűsödött,  hogy találjuk meg a megfelelő üzenetsor megoldást.

Olyan megoldás kell tehát, ami a legtöbb programozási nyelvben támogatott, nincs túl nagy erőforrás igénye, mégis megfelelően sokoldalú. Némi kutakodás után rátaláltam a STOMP protokollra. Ez a legtöbb programnyelvben támogatott üzenet protokoll, így ha heterogén rendszerekben (PHP, Java, Python, .NET, C++, stb.) működni képes megoldást keresünk, az nagyjából annyit tesz, hogy a megoldás legyen STOMP kompatibilis. Jelenleg két ilyen megoldást találtam, ezek között hezitálok.

Az ActiveMQ egy Java alapú megvalósítás, ami szinte mindent tud, amit egy ilyen üzenetsor megvalósítástól elvárhatunk. Klaszterezhető, JMS kompatibilis, támogatja a STOMP-ot (PHP, Python, stb. kompatibilis), ráadásul van hozzá egy Camel nevű valami, ahol DSL-ekkel leírt szabályok segítségével összekötögethetünk üzenet sorokat, újra rendezhetjük őket, broadcastolhatjuk az üzeneteket, stb., tehát konfigurálhatjuk az üzenet sort, és így különösebb programozás nélkül integrálhatjuk a komponenseket. A feature-öket tekintve nagyon szimpatikus megoldás, kérdés hogy mennyire erőforrás igényes.

A másik megoldás a MorbidQ ez Python-ban íródott, de STOMP kompatibilis, tehát ugyanúgy alkalmas heterogén komponensekből álló rendszer integrálására. Sokkal kevesebbet tud, mint az ActiveMQ, amire a honlapon is felhívják a figyelmet, hisz itt a lényeg az volt, hogy egy abszolút pehely súlyú megoldást nyújtsanak. Ez az erőforrás használat miatt lehet szimpatikus, de közelebbit nem tudok róla mondani, hisz nem próbáltam még ki, és nem hasonlítottam még össze az ActiveMQ-val.

Összefoglalva tehát ha a rendszerünk heterogén komponensekből épül fel, aszinkron üzenetkezelésre, erőforrás elosztásra van szükségünk (akár időben - soros végrehajtás, akár térben - klaszterezés), akkor ideális megoldás az üzenet sorok használata. Ilyen esetekben mindenképp érdemes számba venni ezek használatát, melyekből professzionális open source megoldások léteznek, mint pl. az ActiveMQ.

2010. május 17., hétfő

jQuery AJAX Form

Régóta keresek olyan egyszerű AJAX form megoldást, amit viszonylag fájdalom mentesen a szerver kód megváltoztatása nélkül integrálhatok a webes alkalmazásaimba. A neten többfajta megoldás fellelhető, de mindben közös, hogy az adatok szállítására valami speciális formátumot (pl. JSON) használnak, vagy valamilyen speciális szerver oldali függvénykönyvtárat (pl. XAJAX) igényelnek. Ezek jó megoldások, kímélik a sávszélességet, támogatják a szerver oldalról történő HTML manipulációt, stb., de igazából egyik sem tetszett igazán a szerver oldal "elcsúfítása" miatt. Nekem egyszerűen csak arra lett volna szükségem, hogy a submit gomb megnyomása után ne ugorjon a böngésző a lap elejére és ne kelljen adott esetben hosszú másodpercekig görgetni az egérrel, hogy visszamászunk a lap aljára, mindezt úgy, hogy ne kelljen a szerver oldali kódhoz nyúlni. Nem igazán érdekelt a sávszélesség kímélése, a kigenerálandó felületek számának csökkentése, egyszerűen csak az idegesítő oldalfrissítést akartam megkerülni. Az ember azt gondolná, hogy ez általános probléma és biztos van rá kész megoldás, mégis hosszú keresgélés után sem találtam ilyesmit, így hát úgy döntöttem lefejlesztem. Az eredmény egy néhány soros (jelen formájában 61 lazára formázott sor) JavaScript library lett, ami mostanra jócskán túlmutat eredeti célján.

Az alapötletet a JBoss Seam részét képző Ajax4jsf library adta. Itt szinte minden komponensnek van ajaxos változata, amely rendelkezik egy reRender attribútummal, ahol azt adhatjuk meg, hogy a komponens által végrehajtott metódust követően milyen id-jű mezőket kell frissíteni. Itt transzparens módon valósul meg az ajaxos működés, hisz nem JSON csomagok mászkálnak ide-oda, amikhez feldolgozó logika és nagy adag kliens oldali JavaScript kell, hanem HTML darabok, melyek generálását a keretrendszer oldja meg. Ez tehát egy olyasmi megoldás, amire nekem szükségem volt, a probléma csak az vele, hogy Java/JSF függő. Én egy sokkal általánosabb, keretrendszertől független megoldást szerettem volna (konkrétan PHP-ban akartam használni), lehetőleg minél kevesebb JavaScript-et felhasználva. Az igények, és az ötlet tehát már elég jól körvonalazódott, jöhetett a megvalósítás.

A JavaScript mentes megvalósításhoz a jQuery szinte adta magát. Ez egy un. "unobtrusive" JavaScript library, ami azt jelenti, hogy segítségével a JavaScript-et leválaszthatjuk a HTML kódról és CSS szelektorok segítségével "aggathatjuk" rá az eseménykezelőket az egyes elemekre, illetve módosíthatjuk azok attribútumait. Az egész ráadásul mindehhez egy böngészőfüggetlen programozói felületet ad. A lényeg tehát, hogy úgy szkriptelhetjük fel a lapot, hogy közben tiszta marad a HTML kód.

Így már majdnem minden adott volt, de kellett még egy kis ötlet amit a progress bar-os fájlfeltöltős JavaScript komponensektől kölcsönöztem. Itt az a trükk, hogy a form target-jét egy hidden iframe-be irányítják. Így a feltöltés elindul ugyan, de az oldal nem frissül. Ilyenkor a JavaScript egy másik szálon is kapcsolódik a szerverhez (a klasszikus XMLHttpRequest-el) és bizonyos időközönként lekérdezi a szervertől a képfeltöltés állapotát. Így képes feltöltés közben oldalfrissítés nélkül mozogni a progress bar.

Innen már csak össze kellett rakni a kódot. A jQuery alapú library létrehozza a rejtett iframe-et, kikeresi azokat a formokat ahol a form class attribútuma ajaxform, majd ezeknél beállítja a target-et és rárak egy kis submit scriptet is a formra. A formon belül egy rejtett input mezőben soroljuk fel azoknak az elemeknek az id-jét, amelyeket a submit gomb megnyomása után frissíteni kell. Mikor a felhasználó megnyomja a submit gombot, a kérés elmegy a szerver felé, az legenerálja az új oldalt, a submit script pedig visszamásolja a megadott id-vel rendelkező elemeket az eredeti HTML-be. Nem túl bonyolult dolog, a hozzá tartozó kód sem az, és tökéletesen megoldja a bejegyzés elején felvetett problémát, tehát a szerver oldali kód megváltoztatása nélkül valósul meg az oldal újratöltése nélküli AJAX-os működés. A megoldás ráadásul teljesen JavaScript mentes (csak a library-t kell betölteni). Mikor a kis programkönyvtár (a formázott kód kényelmesen elfér másfél képernyőn) elkészült, akkor döbbentem csak rá, hogy mennyire szép ez a megoldás, hiszen az eredeti célja mellett rengeteg lehetőség rejlik még benne.

Kezdjük ott, hogy az újratöltés nélküli frissítéssel egy csomó mágikusnak tűnő dolog nagyon egyszerűen, JavaScript nélkül megoldható. Gondoljunk például egy portál rendszerre, ahol adminisztrátorként belépve a cikkek alján egy módosítás gombot is látunk. A gombot megnyomva a szöveg "átváltozik" szerkesztővé, ahol módosíthatjuk a tartalmat, majd a változtatások elvégzését követően "visszaváltozik" tiszta szöveggé. Ilyesmihez általában komoly JavaScript-eket használnak kliens oldalon. De hasonló megoldás lehet egy popup, ami a gombot megnyomva ugrik fel, vagy egy nyitható zárható dinamikus (nem JavaScript-es) fa lista, dinamikus táblázatok, stb. Szinte az összes tipikus AJAX-os komponens megvalósítható kliens oldali JavaScript nélkül a szerver oldalon generálva.

A másik jópofa lehetőség, ami adja magát, hogy a szerver oldalon kiolvassuk a frissítendő id-ket (emlékezzünk, hogy ezeket egy hidden mezőben adtuk meg, ami természetesen a form elküldésekor átkerül a szerverhez), és egy olyan csonka html kódot generálunk, ami csak az id-kkel megadott részeket tartalmazza. A többi HTML kód generálása tulajdonképpen teljesen felesleges, hisz azok nem kerülnek vissza az eredeti kódba. Így tehát egy olyan megoldásunk van, ami képes ugyan a szerver kód megváltoztatása nélkül is működni, de lehetőséget ad arra is, hogy a szerver kód minimális módosításával sávszélesség és számítási kapacitás kímélő módon működjön, úgy mint más JSON alapú JavaScript igényes megoldások. Tulajdonképpen megfelelően kialakított HTML kód esetén (mindent CSS-ből formázunk, stb.) a mozgatott adattartalom mennyisége nem sokban tér el a JSON-ös változattól, ugyanakkor minimális változtatásra van szükség a szerver oldalon, a kliens oldalon pedig szinte semmire, ráadásul a működése teljesen JavaScript mentes. E mellett a megoldás keretrendszer független és alkalmazása valóban rendkívül egyszerű.

A Google Code-on létre is hoztam egy kis projektet a programkönyvtár számára, ami szerintem méltán kaphatja meg a "világ legkisebb AJAX library-je" címet.

A link: http://code.google.com/p/jqueryajaxform/