2011. október 14., péntek

Samsung Galaxy Spica frissítése Android 2.2-re (Froyo-ra)

Mindenek előtt köszönet Maczák Balázsnak, aki felhívta a figyelmem az új firmware verzióra. Nélküle nem készült volna el ez a bejegyzés.

No de miért is érdemes firmware-t frissíteni? A Galaxy Spica egy jó ár/érték arányú Androidos belépő telefon. Annak idején, mikor még én vettem az enyémet, olyan 60 000 Ft körül lehetett megkapni (jelenleg olyan 30 000-40 000 Ft körül lehet) 1.5-ös Android firmware-el. Időközben aztán az ember kinövi. Jó lenne magasabb verziós Android, lehetne kicsit gyorsabb, hiányzik a multitouch támogatás, vagy a programok sd kártyára helyezésének lehetősége (nekem ez utóbbi kettő hiányzott leginkább). Ilyenkor az ember első gondolata, hogy cseréljük le a jó öreg Spica-t valami újabb modellre. Pedig sokan nem tudják, milyen tartalékok vannak ebben a kis eszközben. Kis bátorsággal körülbelül fél óra alatt a fenti feature-ök közül mind elérhetővé tehető a telefonon. Igen, a multitouch is! Régebben úgy gondoltam, hogy a Spica-n hardver okokból nem elérhető ez a lehetőség, de egy sima szoftver frissítés után ez is remekül működik. Nézzük hát, mi a frissítés folyamata.

Elsőként root-olni kell a telefont, amihez itt (http://www.addictivetips.com/mobile/root-samsung-galaxy-spica-i5700-with-leshaks-kernel/) megtalálhatunk minden szükséges kelléket.

  1. Mielőtt bármihez kezdenénk, az sd kártya root könyvtárába másoljuk fel az  LK2-02-1_update.zip állományt.

  2. Töltsük le az Odin-t innen (cloud.addictivetips.com/wp-content/uploads/android/samsung/galaxy-spica/Odin_v4_03.zip).

  3. Kapcsoljuk ki a telefont, majd a hangerő szabályzó gombot lefelé nyomva és a fényképező gombot nyomva tartva nyomjuk meg hosszan a hívás bontás gombot. Így bekapcsolva a telefont az download módba kerül.

  4. Az Odin-ban nyomjuk meg a Reset files gombot, majd az ops részbe tallózzuk be a spica_jc3.ops fájlt (ezt az Odin-hoz csomagolva megtaláljuk).

  5. Bontsuk ki a i5700_LK2-02_PDA.zip állományt, és a tartalmát tallózzuk be a PDA részhez.

  6. Nyomjuk meg a Start gombot. Ekkor az Odin feltölti a telefonra az új loadert.

  7. Ha az Odin végzett, a telefonon megjelenik egy menü, ahol az 'Apply any zip from SD' opcióval kiválaszthatjuk az előzőleg oda másolt zip-et.

  8. Újraindítás után van egy root-olt telefonunk, tehát félig megvagyunk.


Root-olást követően már könnyedén telepíthetünk új ROM-ot. A Samdroid ROM 2.2-es változatát innen (http://forum.samdroid.net/f53/samdroidmod-2-2-1-a9-froyo-aosp-i5700-3017/) tölthetjük le, de a Wikipedia-n találhatunk néhány hasznos linket más ROM-okra. A ROM telepítéséhez végezzük el a következő néhány lépést:

  1. Másoljuk fel a ROM állományt az sd kártyára.

  2. Indítsuk el a telefont recovery módban a hangerő szabályzót lefelé nyomva, valamint a hívás fogadás és bontás gombokat egyszerre nyomva tartva. Ilyenkor előjön a boot menü, amivel már találkoztunk.

  3. Ha akarunk, itt készíthetünk backupot a jelenlegi rendszerről, de mivel jó esetben a címlista, a naptár bejegyzések, és a többi hasznos dolog a Google szervereire is le van szinkronizálva, erre sokszor nincs is szükség.

  4. Van egy Wipe data & cache menüpont, ezzel tisztára törölhetjük a telefon memóriát.

  5. Válasszuk ki a ROM zip-et az sd kártyáról az Apply menüpont használatával.

  6. A frissítés utáni reboot, és néhány percnyi várakozás után (4-5x újra fog indulni a telefon, addig hagyjuk békén, ellesz magában) a szépséges új 2.2-es Android UI fogad minket.


Ennyi az egész. Az egész procedúra körülbelül 15 percig tart, és a végén egy megújult telefon fogad minket. Telepíthetünk alkalmazásokat SD kártyára, használhatjuk a 2 ujjas nagyítást, és a 2.2-es Android virtuális gépébe bekerült JIT-nek köszönhetően sok alkalmazásunk is gyorsabban fog futni (2-3x-os gyorsulás is tapasztalható bizonyos alkalmazások esetén). Szerintem mindenképp megéri ...

UPDATE: A fenti leírásnak megfelelően én sikerrel frissítettem a Spica-mat minden probléma nélkül. A hozzászólásokban azonban sokan arra panaszkodnak, hogy megállt a telepítés, vagy más ok miatt nem jártak sikerrel. Sajnos ezen problémák megoldására nincs ötletem, mivel én ilyen problémákba nem ütköztem, és sem a frimware-hez, sem a feltöltő eszközökhöz nincs semmi közöm. Én is idegen nyelvű fórumok alapján végeztem el a telepítést, és ebben a bejegyzésben csak a tapasztalataimat osztottam meg. A legjobb amit tanácsolni tudok, hogy akinek problémája van a telepítéssel, az a samdroid fórumban tegye fel a kérdéseit a fejlesztőknek.

2011. május 8., vasárnap

HgEclipse - Mercurial az Eclipse-ben

Nemrégiben írtam egy rövid bejegyzést a Mercurial elosztott verziókezelő rendszerről. Ott a TortoiseHg-n keresztül mutattam be a rendszer lehetőségeit dióhéjban. Mivel azonban elsősorban a fejlesztésekhez használok verziókezelő rendszereket, szükségem volt egy Eclipse pluginre. Nagyon rövid keresés után rá is találtam a HgEclipse kiegészítőre. A kiegészítő telepítése nagyon egyszerű: a szokásos módon a honlapon található update URL-t kell megadni az eclipse-nek, ahonnan a rendszer lehúzza a kiegészítőt, és folyamatosan követi is annak frissítéseit. A HgEclipse nagyon jól integrálódik az Eclipse általános verziókezelő moduljába. Tehát a funkciókat a Team menüpont alatt fogjuk megtalálni, itt hozhatunk létre tárolót, innen commit-olhatunk, stb. Az egész annyira kézre áll, hogy ha lehet ilyet mondani, még kényelmesebb is a használata, mint a TortoiseHg-nek (pedig ahhoz sem kell atomfizikus diploma).  Nézzük is meg dióhéjban, hogy működik.

Első körben hozzunk létre egy Java projektet, mondjuk MercurialTest néven. Eztán a szokásos jobb gomb -> Team/Share project .../Mercurial módszerrel hozzuk is létre a tárolót. Ahogyan az előző bejegyzésben már írtam, maga a tároló nem több, mint néhány speciális rejtett fájl a verziókezelt mappában, így nincs más dolgunk, mint nyomni egy finish-t, és kész is a tároló. Nem kell megadnunk szervert, stb. Ha megvagyunk, hozzunk is létre egy állományt, mondjuk egy szokásos HelloWorld.java programot. Ha ez is megvan, akkor az SVN-ből már megszokott Team/Commit módszerrel rögzíthetjük a változásokat. Ilyenkor kell adnunk valami rövid leírást az adott verzióhoz (igen, kell, nem lehet elhagyni, ami nem is feltétlen baj), kiválasztjuk a fájlokat, és már kész is a verzió. Tehát a dolog ugyanúgy megy, mint SVN esetén, csak nem kell hozzá szerver. E helyett minden a projekt könyvtárában lévő lokális tárolóba kerül. A Team/Show history-val láthatjuk az egyes verziókban történ változásokat, összehasonlíthatjuk, hogy hol mi változott, tehát mindent megtehetünk, amit SVN-ben. Ahogyan az előző bejegyzésben már írtam, az elosztott verziókezelőknél a fejlesztő a lokális tárolóba dolgozik mindaddig, amíg nem végez egy feladattal. Ha a feladat elkészült (letesztelte, jól működik a programrész, stb.), csak akkor tolja fel a változásokat a központi tárolóba. Ezt a Team/Push... menüpont segítségével tehetjük meg. Itt értelem szerűen megadhatjuk a távoli tároló címét, ahová betoljuk a változásokat. Ez felel meg kb. az SVN commit-nak. (Mivel a Mercurial lokális tárolója valójában néhány fájlból áll, ezért elvileg megtehető az is, hogy valaki Mercurial-t használ lokális verziókezelésre, majd ha elkészült, a változásokat a régi SVN tárolójába tolja be. Ilyesmivel nem próbálkoztam, és nem is tudom mennyire lehet hatékony, de ha valaki nagyon ragaszkodik az SVN-hez, az próbálkozhat ilyesmivel. Így esetleg fájdalommentesebb lehet az átállás egyik rendszerről a másikra.) Próbaképp készítsünk néhány lokális változatot, majd térjünk rá az elosztott verziókezelés egyik legnagyobb előnyére, és klónozzunk.

A klónozás kicsit trükkös Eclipse-ben, ugyanis nem a Team, hanem az Import menüpontban találjuk a Mercurial/Clone repository menüpont alatt (ami utólag végiggondolva végül is logikus). A klónozásra kiválaszthatunk távoli tárolót (ez felel meg kb. az SVN checkout-nak), vagy lokális tárolót. Próbaképp válasszuk ki a fájlrendszerből az eredeti (azóta Mercurial tárolóvá tett) eclipse projektet. Ha elkészült a klón, itt is csináljunk néhány változatot, és az eredeti projektben is commit-oljunk néhányat, lehetőleg úgy, hogy a kétféle változtatás üsse egymást (így tesztelhetjük majd a merge-öt). Ha készen vagyunk, próbáljuk visszafésülni az eredeti projektbe az újonnan létrehozott változatokat. Ehhez az eredeti tárolón használjuk a Team/Pull menüpontot. (Az előző bejegyzésben már írtam arról, hogy a változásokat vagy tolni [push], vagy húzni [pull] lehet egyik tárolóból a másikba.) Itt válasszuk ki a második lokális tárolót (természetesen használhatnánk távoli tárolót is), és húzzuk át a változásokat. Ekkor az eredeti tárolóban létrejön egy másik ág, és a HgEclipse rögtön rá is kérdez, hogy összefésülje-e a két ágat. Ezt ugye érdemes megtenni, úgyhogy válasszuk a merg-öt. Ha jól dolgoztunk, a rendszer nem fogja tudni simán összefésülni a két ágat, és néhány állomány conflict-es lesz. Ez ismerős lehet SVN-ből is, hiszen ott is előfordulhat, hogy a szerveren lévő változatot nem lehet automatikusan összefésülni a lokális változattal. Mondjuk az SVN ilyenkor televágja minden krix-krax-al a fájlt, és létrehoz egy állományt a lokális, egyet pedig a szerveren lévő változatnak. A Mercurial ennél szebben jár el, hiszen ott csak egy kis jelet látunk a fájl mellet, hogy conflict van, de nem rontja el az eredeti tartalmat, alul pedig megjelenik egy Mercurial Merge ablak, ahol látszik a conflict-es fájlok listája. Itt ha jobb gombbal rákattintunk egy állományra, a legelső menüpont az Open in Merge Editor. Itt szépen egymás mellett látjuk a két változatot, és kézzel kijavíthatjuk a hibákat. Elég kényelmes kis eszköz. Ha készen vagyunk a kézi merge-öléssel, újra nyomjunk jobb gombbal a fájlra, és az SVN-ből már megszokott "mark resolved" menüponttal fogadjuk el a változásokat. Ha megvagyunk a javításokkal, az eredményt kitolhatjuk a szerveren tárolt közös tárolóba, stb. Dióhéjban körülbelül ennyi lenne.

Véleményem szerint a HgEclipse egy nagyon jól sikerült kis eszköz, és önmagában a HgEclipse is, és a Mercurial mint verziókezelő is jóval többet ad nekünk, mint a hagyományos SVN tárolók. Az én jóslatom, hogy egyre többen fogják felismerni az ebben rejlő lehetőségeket, és néhány éven belül mindenhol át fognak térni valamilyen elosztott verziókezelő (Git, Mercurial, stb.) használatára.

2011. május 7., szombat

Mercurial - első tapasztalatok egy elosztott verziókezelővel

Már régóta szemezek az elosztott verzió kezelő rendszerekkel. Egyfelől azért, mert úgy látom ez a trend (néhány év múlva az elosztott verzió kezelők fogják átvenni az  SVN helyét, úgy ahogyan annak idején az SVN került az akkoriban elterjedt CVS helyére), másfelől magam is szembesültem már az SVN néhány hátrányával, amiken az elosztott verziókezelő rendszerek felülemelkednek. No de mi is az az elosztott verzió kezelő rendszer?

Feltételezem, hogy az olvasó találkozott már  központi (centralizált) verziókezelő rendszerrel. Ilyen például a hagyományos SVN, vagy a CVS. Központi verziókezelő esetén ugye van egy központi szerver (pl. SVN szerver), a felhasználók pedig innen húzzák le, illetve ide tolják fel a saját változtatásaikat. Minden feltöltést egy letöltésnek kell megelőznie, ami az adott felhasználó gépén összefésüli a szerveren lévő és a lokális változatot. Ha az összefésülés automatikusan megoldható (általában megoldható), akkor azt a rendszer el is végzi, ha nem, akkor kézzel kell összefésülnünk a változatokat, majd az eredményt feltöltjük, és onnantól az lesz az aktuális változat. Az egyes változatokat vissza lehet keresni, egy egy állományt vissza lehet állítani a régi állapotra, és változatonként pontosan nyomon követhetjük, hogy hol mi változott. Nagyon röviden valami ilyesmiről szól egy központi verziókezelő.

Elosztott (decentralizált) verziókezelő esetén más a helyzet. Ott egyetlen központi tároló (repository) helyett minden felhasználónak van egy saját külön tárolója a gépén. A külön tárolónak külön verziókezelése van, tehát nem kell minden egyes változást a központi szerverre tölteni. Itt rögtön látszik is az elosztott verziókezelők egyik nagy előnye az SVN-el szemben. SVN esetén ha valami nagy feladaton dolgozunk, és a feladat megoldása közben menteni szeretnénk egy egy mérföldkövet, azt csak az egyetlen központi tárolóba menthetjük. Így választhatunk, hogy vagy félkész dolgokat mentegetünk a központi tárolóba (ezzel esetleg működésképtelen vagy hibás verziókat hozva létre), vagy mindaddig nem készítünk verziót, amíg el nem készültünk a feladattal (így viszont a feladat ideje alatt elveszítjük a verziókezelésből eredő előnyöket). Mindkét megoldás rossz, de mindenki saját szája íze szerint választhat, hogy melyik a kisebbik. Elosztott verziókezelés esetén nincs ilyen gond, hiszen a saját lokális tárolójába mindenki olyan verziókat hoz létre, amilyet akar (lehetnek ezek között működésképtelen, félkész állapotok is), és csak akkor tölti fel az egészet a központi tárolóba, ha kész van a feladattal (esetleg le is tesztelte, stb.). Így a központi tárolóban mindig egy stabil, használható változat van. Ez már önmagában nagy előny, de mint látni fogjuk, ez csak egyetlen a sok közül. Tehát egy központi tároló helyett itt több tároló van, és mivel nincs is olyan fogalom, hogy "központi" tároló, ezekből a lokális tárolókból tetszőleges hierarchiák kialakíthatóak. Tehát pl. egy projekt 2 nagyobb feladatra osztható, és mindkét feladaton dolgozik 2-2 fejlesztő. Ebben az esetben a két fejlesztőnek van 1-1 saját tárolója, ezekből mindig az adott feladat tárolójába szinkronizálnak, és ha az adott feladat elkészül, akkor tolják ki az egészet a "központi", stabil tárolóba. De hasonló módon akár az is megoldható, hogy 2 "központi" tárolót tartunk fenn. Az első egy "testing", a második egy "stabil" változat. Ha elkészül egy feladat, akkor az a "testing" rendszerbe kerül. Itt valaki leteszteli, és ha megfelelőnek találja, kihelyezi a stabil tárolóba. Ez csak néhány példa a teljesség igénye nélkül, de sok más elrendezés is elképzelhető. Például ami nekem nagyon tetszett, hogy nyílt forrású projektek esetén ha a forráskód tárolására SVN-t használnak, akkor két módon lehet beszállni a fejlesztésbe. Az egyik, hogy elérési jogot kérünk a tárolóhoz. Itt ugye az a dolog veszélye, hogy akinek ilyen jogot adunk, abban nagyon meg kell bízni, hisz kontrollálatlanul telepakolhatja a kódot mindenfélével. A másik eset, hogy a felhasználó elvégzi a módosítást, majd generál egy patch-t, amit elküldhet a projekt vezetőjének, aki átnézi azt, és kézzel befésüli az SVN-be. Ez viszont elég kényelmetlen. Elosztott verziókezelő esetén a dolog igen gördülékenyen megy, mivel a felhasználó csinál egy másolatot (klónt) a központi kódbázisról, elvégzi a változtatásokat (itt használhatja a lokális változatának saját verziókezelését), majd ha elkészült, értesíti a projekt gazdáját, hogy húzza át a módosítást a fő kódbázisba. Ez tulajdonképpen olyan mint mikor az ember patch-et küld egy SVN-es projekthez, de sokkal egyszerűbb, és gördülékenyebb.

A legismertebb ilyen elosztott verziókezelő a Git. Ezt a linux kernel fejlesztéséhez hozták létre, de mostanra már sokan mások is használják. Git-ben tárolják pl. az Android forráskódját, a Diaspora-t, az Appcelerator forráskódját, a Facebook is ezt használja a nyílt forrású projektjeihez, és még több ezer projekt, amiket jellemzően a GitHub-on hosztolnak. (A GitHub egy Git alapú code hosting szolgáltatás, olyan mint a Google Code Hosting, vagy a Sourceforge, bár sok szempontból sokkal fejlettebb.) A Git után szorosan második helyen áll a Mercurial. Nem kell szégyenkeznia a Git mellett, hisz olyan projektek használják, mint a Mozilla böngésző, Python programozási nyelv, OpenJDK, Netbeans, stb. Ráadásul a Google Code Hosting-on is használhatjuk az SVN alternatívájaként. Valójában nekem is szimpatikusabb a Mercurial, mint a Git, mivel a Git egy scriptekből és programokból összelapátolt valami, míg a Mercurial tulajdonképpen egy Python program, így ha kell, ebbe jobban bele lehet nyúlni (pl. plugint fejleszteni hozzá), ráadásul az egész valahogy jobban egyben van. Van még néhány elosztott verziókezelő (pl. Bazaar, amit az Ubuntu Linux használ), de mind közül nekem a Mercurial tetszett legjobban, így erről fogok írni.

Akit mélyebben érdekel a Mercurial, a http://hginit.com/ címen találhat egy nagyon jó angol nyelvű összefoglalót, de én is írok róla néhány sort.  Ha ki szeretnénk próbálni ennek a verziókezelő rendszernek a képességeit, legegyszerűbb, ha letöltjük a TortoiseHg klienst. Ez beépül a Windows jobb gombos menüjébe, így a fájlkezelőben könnyen adminisztrálgathatjuk a tárolóinkat. A kísérletezéshez hozzunk létre egy tárolót. Ehhez a TortoiseHg-ban van egy "Create repository here" menüpont. Az első dolog, amit észrevehetünk, hogy maga a tároló egy egyszerű könyvtár néhány speciális fájlal, tehát alapvetően nincs szükség szerverre a működéshez. Ez már önmagában is hasznos lehet. Ha kész a tároló, hozzunk is létre benne néhány fájlt. Eztán ha a tároló könyvtárán jobb gombot nyomunk, feltűnik az ismerős commit parancs. Ezzel az SVN-hez hasonlóan rögzíthetjük a változásokat, és létrehozhatunk egy verziót, ami az SVN-el ellentétben nem egy szerveren, hanem a könyvtárban lévő egyik mappában jön létre. Készítsünk még 1-2 verziót. Van egy Hg Workbench menüpont is, amivel szépen fában látjuk a változatokat, megnézhetjük a különbségeket, stb. Eztán jöhet a trükk, ami az elosztott verziókezelők legnagyobb előnye.  A menüben találunk egy "Clone" parancsot. Ezzel a teljes tárolót lemásolhatjuk még egy példányban, verzió történettel, mindennel együtt. A clone után mér két tárolónk van (két sima könyvtár néhány speciális fájlal és mappával). Most csináljunk néhány verziót az egyik, majd néhány verziót a másik tárolóban. Ez jelképezi a több fejlesztési ágat. A gyakorlatban ez úgy néz ki, hogy minden egyes fejlesztő klónozza magának a tárolót, és abba dolgozik. Szóval csináljunk néhány verziót mindkét tárolóban. Ha ezzel megvagyunk, akkor jön az, hogy a másodlagos (pl. fejlesztési) tárolót fésüljük vissza az elsődleges tárolóba. Ezt két módon tehetjük meg. Vagy a cél tárolóba húzzuk (pull) a változásokat a forrás tárolóból, vagy a forrás tárolóból nyomjuk (push) a cél tárolóba a dolgokat. Mindkét módozatnak van értelme. A push-ra jó példa, amikor mondjuk egy fejlesztő befejezett egy feladatot a saját lokális tárolójában, és ezt betolja a központi fejlesztői tárolóba (kb. az SVN commitnak felel meg). A pull használata pedig például akkor lehet hasznos, ha a stabil szál felelőse áthúzza a változásokat a fejlesztői szálból. Például GitHubon (ez Git alapú, de a mechanizmus ugyanaz) úgy szállhatunk be egy nyílt forrású projekt fejlesztésébe, hogy klónozzuk a projekt tárolóját, megcsináljuk a változtatásokat (ehhez semmilyen interakció nem kell ugye a projekt gazdájával), majd ha megvagyunk, küldünk egy pull request-et (ez kb. egy üzenet, hogy "kérlek, húzd át a változásokat az én tárolómból") a projekt gazdájának, aki átnézi, hogy mit változtattunk, és ha mindent rendben talál, áthúzza a változásokat a projekt fő tárolójába. Ez nagyon gördülékeny módja a nyílt forrású projekthez való hozzájárulásnak, sokkal kényelmesebb, mint SVN hozzáférést kunyerálni, vagy patch-eket küldeni. A példa kedvéért tehát nyissuk meg az elsődleges tárolónkat a Hg Workbench-ben, és húzzuk át a változásokat a másodlagosból. Ha ez megvan, láthatjuk a Workbench-ben, hogy a másodlagos tároló történettel, mindennel együtt egy új ágként megjelent a mi tárolónk történetében (magyarul látszik, hogy ott ketté vált a fa). Ez már majdnem jó, már csak egyesíteni kell a két ágat. Ehhez van a workbench-ben egy merge művelet. Ez igazából ugyanúgy megy, mint SVN-ben a merge-ölés, ha lehet, automatikusan merge-öl a rendszer, ha nem, akkor kézzel kell ezt megtenni. (Elvileg a Mercurial mindenféle metaadatot gyűjt a merge segítésére, de ezt a részét annyira nem próbáltam.) Ha megvan a Merge, jöhet egy commit, és rögtön egy szálon megy tovább az egész. Tehát ha a fejlesztés végén ránézünk a fára, lépten-nyomon kis elágazásokat és visszacsatolásokat fogunk látni, amik az egyes fejlesztések.

Úgy nagyon dióhéjban ennyi lenne a Mercurial bemutatása. Feltűnhetett, hogy minden műveletet a fájlrendszerben végeztünk, de ahogyan SVN esetén, természetesen itt is megvan a lehetősége annak, hogy egy repository-t egy szerveren tároljunk, amit HTTP-n, HTTPS-en, vagy SSH-n keresztül lehet elérni. A dolgok mechanizmusán ez nem sokat változtat, egyszerűen az ilyen tároló nem a fájlrendszerben van, hanem egy távoli szerveren, de ugyanúgy lehet klónozni, lehúzni (pull) róla a változásokat (ami az SVN update-hez hasonló), vagy felnyomni (push) oda a változásokat (ami az SVN commit-hoz hasonló). Célszerűen csak a fejlesztő lokális tárolóját érdemes a fájlrendszerben tartani, minden olyan tárolót, amit többen használnak (közös fejlesztési ág, stabil ág, stb.), szerveren érdemes tartani.

Remélem ezzel a kis ismertetővel sikerült kicsit kedvet csinálni az elosztott verzió kezelő rendszerek, azon belül is a Mercurial használatához.

2011. március 6., vasárnap

Vizautók és hidrogén hajtás

Nemrégiben írtam már egy posztot a vízautókkal kapcsolatban. Ott azt próbáltam fejtegetni, hogy miért nem jogos a "jelenlegi ismereteink alapján ez nem lehetséges" típusú elutasítás ezekkel a találmányokkal kapcsolatban. Most kicsit más szempontból írnék ugyanarról. Nevezetesen, hogy mi az amit már tudunk, de mégsem élünk vele. Kezdjük is hát az elején.

A benzin (és vele minden más kőolaj származék üzemanyag is) fogy. Nem áll belőle rendelkezésre végtelen mennyiség. E mellett a benzin szennyezi a környezetet, és drága is. Mivel az áruszállítás miatt a benzin ára beépül mindenbe, ezért minden drágább lesz, így az olajsejkeken kívül mindenki rosszul jár. Mondjuk ők cserébe szigeteket építhetnek Dubaj-ban, de ez minket cseppet sem vigasztal. Az egyszerű halandó embernek marad a folyamatos fizetés, a szmog, meg a tüdőrák. Nem csoda hát, hogy mikor felreppen a hír, hogy ezen túl benzin helyett vizet tankolhatunk az autóba, sokak szeme felcsillan. A föld nagy része (ha jól emlékszem, azt tanították, hogy 70%-a) víz, így abból jutna mindenkinek. Attól sem kellene félni, hogy elfogy, mert a vízautó ugye vizet pufogna ki, ami idővel visszapotyog az óceánokba, így közel ingyen közlekedhetnénk. A kérdés már csak az, hogy kivitelezhető-e a dolog. A válasz pedig szerintem egyértelműen igen, csak nem úgy, nem annyira egyszerűen, mint gondolnánk. Le is írom miért.

Ha hihetünk az energiamegmaradás törvényének (van esély rá, hogy nem mindig működik, de eddig erre nem volt példa), akkor a semmiből nem lesz energia. Tehát csak úgy magától nem fog menni az autónk. A benzintől azért megy az autó, mert abban koncentrált energia van. Ha elégetjük, más anyagokká alakul. Ekkor szabadul ki belőle az energia, és ettől megy az autó. Szóval a benzin esetén egy anyag másik anyaggá alakul, innen van energiánk. Amikor tehát autózunk, akkor az évmilliók során a kőolajban tárolt energiát használjuk el. A vízautókkal szemben azért szkeptikusak az emberek (köztük én is), mivel itt nincs ilyen átalakulás. Víz megy be, víz jön ki, sem kémiai, sem fizikai változás nem jött létre, tehát honnan lenne energiánk? Erre aztán az a válasz, hogy bizonyos speciális körülmények között ez a folyamat energiát csatol ki az univerzum végtelen energiatengeréből, vagy még durvább esetben az, hogy maga az energiamegmaradás hibás, és lehet semmiből energiát termelni. Nos, érthető, ha az ilyesmitől viszolyognak a fizikusok, hiszen ilyenre még soha sehol nem láttunk példát, sőt, minden jel arra utal, hogy az energiamegmaradás igaz, és nagyon kemény alaptörvénye a fizikának. Ennek ellenére, ahogyan az előző postban már írtam, egy fizikusnak kutya kötelessége kivizsgálni minden ilyen esetet, még akkor is, ha az aktuális modellnek az ellent mond. Hiszen mindig csak a megfigyelésekből vonhatunk le következtetéseket, soha nem járhatunk el fordítva. Tehát egy megfigyelést nem cáfolhatunk az eddigi következtetéseink alapján. Azért az esetek döntő többségében (tulajdonképpen eddig mindig) a fizikusoknak volt igaza, tehát mikor felreppen egy ilyen újabb "vízautós hír", joggal feltételezhetjük, hogy végül az derül ki róla, hogy a dolog nem működik.

Szóval a "vizet tankolok a kocsiba" dolog működésére elég kis (persze soha nem 0) esély van, viszont a poszt elején azt írtam, hogy mégis megoldható a dolog. Lássuk hogyan. Ehhez viszont először térjünk vissza a benzinhez. Hogyan működik a benzin? Ahogy már írtam, a benzinben kémiai formában energia tárolódik. Mikor elégetjük, ez az energia kiszabadul, és ez hajtja az autót. Tulajdonképpen minden égésnek ez az alapja, ez történik például akkor is, ha fából tüzet rakunk. Itt a fa hamuvá alakul, és a felszabaduló energia jelenik meg hőként. No de hogy kerül a fába az energia? Erre való a fotoszintézis. A fa elnyeli a napfényt, aminek hatására bizonyos anyagok más anyagokká alakulnak. Ily módon a fa a nap energiáját saját anyagában konzerválja. Mikor elégetjük, akkor tulajdonképpen a nap évek alatt összegyűjtött energiája szabadul fel. Ez tulajdonképpen majdnem ugyanaz, mint mikor napelemmel feltöltjük mondjuk a zseblámpánk elemét, amivel aztán este világíthatunk. A fa is egyfajta "napelem", csak kicsit bonyodalmasabb a működése. Valójában itt a földön szinte minden dolog a napból nyeri az energiáját, "a föld mint gépezet energiaforrása a nap". Mi emberek például étkezéssel nyerjük az energiánkat, állatokat és növényeket eszünk. Az állatok is növényeket esznek, onnan nyerik az energiát, a növények pedig fotoszintetizálnak, tehát végső soron mi is napenergiával működünk. De a vízerőművet hajtó vizet is a nap mozgatja, vagy a szélerőművet hajtó szelet, és végső soron a kőolaj és a földgáz is rothadó állatok és növények maradványaiból keletkezik, ami egykor ugyancsak a naptól kapta az energiáját. No de hogy jön mindez a vízautókhoz?

Az előbbiek alapján már látható, hogy jelenlegi tudomásunk szerint energiát csak úgy lehet termelni valamiből, ha oda valahogy bekerült. A hajtóanyagnak energiát kell veszítenie, amivel aztán az autónkat hajthatjuk. Ezt szaknyelven úgy szokták mondani, hogy a zárt rendszer energiája nem változhat. A benzin esetén ez teljesül, hiszen a folyamat elején bemegy a benzin, majd kipufogó gázzá alakul. Ekkor veszít az energiájából, és ettől megy az autónk. Ha vizet öntünk az autóba, és víz jön ki, akkor semmi nem veszített az energiájából. Ha az autó mégis mozog, akkor valami misztikus helyről (pl. az univerzum kimeríthetetlen energiatengeréből, stb.) energiának kellett oda bekerülnie. Ahogy már írtam, ilyesminek a létezéséről nem tudnak a fizikában, tehát a jelenlegi tudásunk szerint ez így nem működhet. Mit lehet tehát tenni? A víz ahogyan kémia órán tanultuk, két rész hidrogénből és egy rész oxigénből áll (innen a H2O képlet). Megtehetjük, hogy energia befektetéssel a vizet alkotó részeire bontjuk. Ha így teszünk, az alkotó részekben konzerválódik a bontásra szánt energia. Amikor az alkotórészeket egyesítjük, tehát a hidrogént és az oxigént vízzé égetjük el, akkor visszakapjuk ezt a befektetett energiát. Pontosan ugyanaz történik, mikor a fa vagy éppen a benzin elégetésével visszanyerjük az abban tárolt napenergiát. Röviden tehát ahogyan a benzinben, vagy a fában tárolódik az energia, úgy a vízben (vagyis a víz kettébontott alkotóelemeiben) is tárolhatunk energiát. Tehát a benzin a fa, vagy éppen a víz is olyan mint egy akkumulátor. Ugyanúgy energiát tárol. Itt jutunk el ahhoz a kérdéshez, hogy akkor minek az egész folyamatba belekeverni a vizet? A víz bontásához is energia kell, miért nem használunk simán egy rakás akkumulátort, és hajtjuk az autókat elektromos motorokkal? A víz bizonyos szempontból  jobb erre a célra. Az elektromos hajtáshoz a kocsi motorját egy az egyben elektromos motorokra kellene cserélnünk, ezzel szemben amennyire én tudom, a hidrogénhajtáshoz csupán a kocsi átalakítására van szükség (ugyanúgy robbanások hajtják a motort, csak benzin helyett hidrogén és oxigén ég el vízzé), az alapanyag nem környezetszennyező, és az égéstermék is csak víz. Ennek fényében tehát ha nem is vizet, de hidrogént tankolhatnánk a kocsinkba benzin helyett. A hidrogént előállíthatnánk megújuló energiaforrások (pl.: víz, szél, nap, stb. energia), vagy éppen nukleáris energia felhasználásával (a tévhitekkel ellentétben ez sokkal kevésbé környezetszennyező, mint a benzin). És persze ott van az energiaforrások netovábbja, a fúziós energia, ami például a napot működteti. Ilyen fúziós erőművet még nem vagyunk képesek létrehozni, de egy nap talán ez is lehetséges lesz.

Hogy miért nem hidrogénnel hajtjuk már most az autókat? Amennyire én tudom, a hidrogén ellen felhozott legnagyobb ellenérv a tárolás/szállítás nehézsége. Míg a benzinhez elég egy sima benzines kanna, addig a hidrogén tárolásához rendkívül erős falú tartály szükséges. A benzint simán öntögethetjük, kicsit párolog ugyan, de könnyen kezelhető. Ezzel szemben a hidrogén gáz, nagy nyomáson, cseppfolyósítva tárolhatjuk, így mindenféle vastag csöveken tudjuk csak egyik helyről a másikra átnyomatni. Azt is szokták emlegetni, hogy veszélyesebb, mint a benzin, sokkal könnyebben, sokkal nagyobbat robban, mint a benzin. Erre a problémára már láttam megoldásokat, és úgy tudom, van már rá technológia, aminek használatával már viszonylag biztonságosan megoldható a tárolás. Ezek alapján úgy néz ki, hogy a hidrogénhajtás elterjedése inkább infrastrukturális, mint technikai jellegű probléma. Át kellene alakítani a kocsikat, hidrogén kutakat kellene építeni, hidrogén gyárakat, stb.

Persze a hidrogén mellett ott a tiszta elektromos hajtás is, sőt, sokak szerint ez sok szempontból jobb is. Nincs gond a tárolással (csak jó akkumulátorok kellenek hozzá), nincs gond a szállítással (csak néhány villanyvezeték kell, ami tulajdonképpen már meg is van), sőt, akár magunknak is előállíthatjuk a szükséges energiát a házunk tetején lévő napaelemmel, vagy a kertben elhelyezett szélerőművel. A dolog hátránya, hogy teljesen újra kell gondolni hozzá az autókat, a benzintartályt akkumulátorokra, a motort elektromos motorra kell cserélni. A másik gond, hogy a jelenlegi akkumulátorokkal hamar lemerül egy ilyen kocsi, így 50-100 km-enként töltőállomásokat kellene elhelyezni (bár ha jobban belegondolunk, a benzinkutak is vannak ennyire sűrűen). Alternatív megoldás, hogy a kocsiban vész esetére egy benzines generátort is beszerelünk, amivel elpöföghetünk a következő elektromos töltőállomásig. Szóval ez sem egy rossz alternatíva, de legalább olyan elszántság kellene a bevezetéséhez, mint a hidrogénhajtás esetén (elektromos töltőállomások, elektromos autók gyártása). Akit a dolog bővebben érdekel, nézze meg a "Ki ölte meg az elektromos autót?" című YouTube-on elérhető kis dokumentumfilmet, ami jó összefoglalása a témának.

Szóval van alternatívánk a benzinre, nem is egy. Hogy a váltáshoz szükséges lépéseket miért nem lépik meg, azt pontosan nem tudom. Lehet, hogy gazdasági okai vannak, lehet, hogy a fentieken kívül van még valami technikai probléma, ami megoldásra vár, de az is lehet, hogy valóban akkora üzlet a benzin, hogy sokak ellenérdekeltek abban, hogy mindez megvalósuljon. Mindenesetre nincs semmi hókusz-pókusz a dologban, jelenlegi ismereteink szerint működőképes, és megvalósítható.

De ebben a posztban nem is annyira ez a lényeg, hanem az, hogy az alapelvet megértsük. Nevezetesen, hogy a vízautókkal az a legnagyobb baj, hogy "klasszikus" (vizet töltök a tankba) formájukban sértenék az energiamegmaradás törvényét, amitől a fizikusokat kirázza a hideg. Jelenlegi ismereteink szerint energia nem lesz a semmiből. Energiát csak úgy nyerhetünk valamiből, ha egyszer valahogy oda energia került be. Ily módon mindenfajta üzemanyag csak egyfajta energiatároló közeg. A benzin a fa, a hidrogén, a rádióaktív anyagok, és végső soron egy sima akkumulátor is ugyanazt a feladatot látja el számunkra. Nevezetesen energiát tárol. Persze egymástól igen eltérő formákban. A nem megújuló energiaforrások esetén ez az energia valamikor nagyon régen került be oda, és ha ezt az energiát felhasználjuk, az "nem pótolódik vissza", tehát az ilyen anyagok folyamatosan fogynak. Ilyen ugye a kőolaj, amiben egyszer régen energia konzerválódott, és ha elégetjük az autó motorterében, kipufogógáz lesz belőle, soha nem áll össze újra benzinné. Ez persze igaz a hidrogénre is, hiszen a hidrogén vízzé ég el, és a víz később nem fog magától hidrogénre és oxigénre bomlani. Ugyanakkor a hidrogén könnyen előállítható elektrolízissel, amihez már használhatunk más, megújuló energiákat (pl. szél, víz, napenergia), és végső soron tisztán elektromos áramot is használhatunk üzemagyagként elektromos autókban. Amennyire én tudom, ilyen energiából van elég, a nap bőségesen ellátja a földet. Tulajdonképpen mikor mi emberek még nem voltunk, akkor is nagyon jól elműködött a bolygó a nap energiájával, és valószínűleg napjainkban is történhetne így a jelenlegi környezetszennyező megoldások helyett. Szóval energia van, csak meg kell tanulnunk hatékonyan kiaknázni, és tárolni/szállítani. Lehet, hogy nem a hidrogén lesz az üdvözítő megoldás. Lehet, hogy lesz valami más anyag, amiben energiát tárolhatunk. Valami, ami olyan könnyen kezelhető, mint a benzin (szobahőmérsékleten cseppfolyós, vagy szilárd), mégsem környezetszennyező. Azt is el tudom képzelni, hogy egyszer majd genetikailag módosított mesterséges növények fognak fotoszintézis útján valamilyen anyagot előállítani, amit majd üzemanyagként használhatunk (ez a lényege a biodízelnek). Lehet, hogy nem is kémiai formában (üzemanyagként) kell tárolnunk az energiát, hanem elektromos áramként (valójában az akkumulátor is kémiai formában tárolja az energiát). Talán találunk valamilyen az eddigieknél hatékonyabb energiatároló közeget, és ez hozza el a megoldást az üzemanyag problémára. Mindenesetre tény, hogy hamarosan valamilyen irányba lépni kell majd.

2011. március 5., szombat

Vízautók, meg a fizikai törvények jellege

A napokban reppent fel egy hír a Facebook-on, hogy egy Gróf Spanyol Zoltán nevű úriember megoldotta, amire sokan úgy várnak mint egy falat kenyérre, nevezetesen, hogy ezen túl benzin helyett színtiszta csapvizet tankolhatunk az autónkba. Mivel sokáig az egyik legkedvesebb hobbim az volt, hogy ilyenek után olvasgattam (pl. Egely könyvekből megvolt tán az összes), természetesen ez is felkeltette az érdeklődésemet. Miután ez a hír már néhányszor nagy csinnadrattával felreppent, és annak rendje és módja szerint hamar el is ült, most is szkeptikus voltam, és hát ha valaki csinál egy egyszerű Google keresést, talál is jó pár ellenvéleményt. Ennek apropóján gondoltam, írok egy postot a véleményemről ebben az egész témában. Bár magam is egészséges mértékben szkeptikus vagyok, mégis sok szempontból inkább ezeknek a feltalálóknak a pártját fogom, mert valahol úgy gondolom,igazságtalanul járnak el velük, el is mondom miért.

Úgy általánosságban az ilyen "Tiltott találmányok" ellen felhozott vádak nagy része úgy kezdődik, hogy "márpedig ez a fizika törvényei szerint nem működhet". Nos, ez az a mondat, amit egy magára valamit is adó fizikus nem mondhat ki. Ha megteszi, azzal elismeri, hogy nem érti a fizikát, és mint ilyen, méltatlan arra, hogy fizikusnak, vagy mérnöknek nevezze magát. Ha a fizikusaink annak idején ebben a szellemben gondolkodnak, vagyis nem vizsgálják ki azokat a jelenségeket, amik az akkor aktuális világnézet szerint nem működhetnek, akkor most jóval szegényebbek lennénk. Mondok is egy egyszerű példát. Ha azt mondom, hogy lehetséges az, hogy egy golyót elhajítva az egyszerre két lukon is átmenjen, akkor még csak fizikusnak sem kell lenni ahhoz, hogy valaki azt mondja, hogy hülyeségeket beszélek. Nos, az a helyzet, hogy ha elég pici a golyó, és elég közel van egymáshoz a két luk, akkor ez a jelenlegi fizikai törvények alapján igenis lehetséges. Nagyon leegyszerűsítve ez a kvantummechanika egyik alapjelensége. Egy olyan fizikus számára, aki csak a klasszikus mechanikát ismeri, ez nem csak hogy a fizika törvényeinek mond ellent, de még józan ésszel is értelmezhetetlen. Mégis, ha nincs kvantummechanika, akkor talán ma nem lennének processzorok, integrált áramkörök, számítógépek, mobiltelefonok, TV, semmi, ami a mai modern társadalom alapja. Megrekedtünk volna a sötét középkorban. Az ilyen, és ehhez hasonló jelenségek miatt a mai modern fizika már jócskán túlhaladt azon, hogy a szó klasszikus értelmében "megértsük" azt. Egyetlen egy dolgot tehetünk, megfigyeléseket végzünk, az eredményeket pedig matematikai formába öntjük. Ha elég sok mérést végeztünk, és mind azt mutatja, hogy a formulánk helyes, (akármilyen mérést is végzünk el, mindig azt találjuk, hogy a formula által megjósolt eredmény az amit valóban tapasztalunk) akkor tehetünk egy olyan kijelentést, hogy VALÓSZÍNŰLEG ez a formula minden esetben helyesen írja le a világ működését. Ugyanakkor a dolog jellegéből adódóan nem vonhatunk le abszolút következtetéseket, hiszen nem vizsgálhatjuk meg az összes peremfeltételt. Hogy még jobban megvilágítsam a problémát, mondok egy nagyon egyszerű példát. Egy nap belém hasít a felismerés, hogy a víz folyékony. Tudom, hogy hülye példa, de mégsem sokkal rosszabb, mint az a felismerés, hogy az alma leesik a fáról, pedig ha hinni lehet a legendának, Newton fejében valahogy így kezdődött az az elmélkedés, aminek eredménye a gravitáció törvényének felfedezése lett. Szóval ott tartottunk, hogy "a víz folyékony". Ezt szeretném is fizikai törvény szintjére emelni, úgyhogy elvégzek egy rakás kísérletet. Felmegyek a padlásra, lemegyek a pincébe, bejárom az egész várost, és mindenhol azt találom, hogy a víz márpedig folyik. Mivel a nap végére nagyon elfáradok, úgy érzem, elég kísérletet végeztem, és publikálom az eredményeimet. Megszületett az első fizikai eredményem, törvényként mondhatom ki, hogy a víz márpedig folyékony. Innentől kezdve, ha valaki azt mondja nekem, hogy ő látott már nem folyékony vizet, kiröhöghetem, és mondhatom neki, hogy ez nem lehet, hiszen a fizika jelenlegi törvényei szerint a víz folyékony. Aztán eljön a tél, és meglátom az első jégcsapot. Ekkor két dolgot tehetek. Vagy elfordítom a fejem, és azt mondom, hogy bizonyára csak odaképzeltem a "szilárd vizet", vagy odamegyek, és megvizsgálom, hogy most akkor ez hogy is van. Lehet, hogy tél közepén látom meg az első jégcsapot, pedig a szomszéd Józsi már egy hete mondja, hogy ő látott már "kemény" vizet, de mindig legyintettem rá, hogy "áh Józsi, te nem vagy fizikus, mindig csak a pincében bütykölsz, és szerintem sutyiban pálinkázgatsz is, meg különben is, a 'kemény' az nem egy halmazállapot, a 'kemény' szót mi fizikusok másra használjuk". Pedig ha odafigyeltem volna arra a "hülye" Józsira, már egy hete hógolyózhatnék kint a többiekkel, a helyett, hogy mindenféle hülye fizika könyveket olvasgatok. Valami hasonló a helyzet a "valódi" fizikában is. Vannak törvények, a dolgok többségére alkalmazhatóak is ezek, de ha találunk valamit, amire nem, mindig késznek kell lenni megváltoztatni az addigi vélekedésünket. Az is lehet, hogy az egész eddigi világnézetünket ki kell dobni a kukába, vagy legalábbis csak az új törvények speciális eseteként értelmezni. Ez adott esetben fájdalmas lehet, de meg kell tenni, másképp együtt kell élnünk a tudattal, hogy hazugságokban élünk, és lehet, hogy jó dolgokról maradunk le emiatt, mint amilyen a hógolyózás, vagy éppen a vízzel hajtott autó. Persze azt is megértem, hogy egy fizikusnak 1000 kamu eset után semmi kedve foglalkozni az 1001.-kel, mégis meg kell tennie, ha felelősségteljes állításokat akar tenni. Ha ezt kihagyva állít biztos dolgokat, azzal a saját hitelességét veszélyezteti, és ugyanolyan "kóklerré" vélik, mint azok az emberek, akiket ő maga tart "kóklereknek". Csak hogy érzékeljük, hogy ez mennyire igaz, gondoljunk bele, itt van az univerzum, emberi léptékkel felfoghatatlan nagyságú. Ebben a végtelen sötétségben a porszemnél is porszemebb kis piszok a mi föld bolygónk. Kis golyókat gurigatunk ide-oda, ütköztetjük őket, és felfirkantunk néhány egyszerű képletet egy papírfecniere (ez volna a Newtoni mechanika), aztán elővesszük a távcsövet, elnézünk olyan messzire, ahová a fénynek is évekig tart, míg odaér (az is lehet, hogy amit látunk, már rég nincs is ott), és a látottakra azokat a törvényeket alkalmazzuk, amiket itt papírfecniken összeszedtünk. Honnan vesszük a bátorságot mindehhez? Hogyan merjük azt állítani, hogy ami itt működik, az ott is fog? Honnan tudhatjuk, hogy a fizikai térvényeink nem csak mondjuk a naprendszer pereméig érvényesek? Mi van, ha a csillagokat csak úgy vetítik elénk Isten óriás planetáriumában, miközben az ufók reggelihez valami valóságshowként nézik az életünket, mint az emberek a Truman Show-ban? A fizika hit, olyan mint bármely vallás, az alaptétele pedig, hogy a világ egyszerűen leírható, és ha valamire sok kísérletet végzünk, ami alapján felírunk egy törvényt, az mindenre működni fog. De ez magában rejti azt is, hogy bizonyosságokat soha nem állíthatunk, mindig késznek kell lenni a megújulásra, a dolgok átértékelésére, és el kell fogadni, sőt kutatni kell azokat az eseteket, ahol az eddigi elméleteink nem működnek, mert csak így lehet fejlődni, és a fejlődéssel sok minden újat kaphatunk, mint ahogy eddig is kaptunk.

Szívesen írnék még a hidrogénről, mint energiaforrásról. Ez is egy érdekes téma, oly annyira, hogy szerintem majd egy új postot szentelek neki, egy postba elég ennyi okoskodás... ;)

2011. február 18., péntek

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

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

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

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

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

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

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

2011. január 9., vasárnap

JSONP és Cross-Site Scripting

Aki próbált már JavaScript-ből idegen szerverrel kommunikálni, az valószínűleg belefutott már a Cross-Site Scripting problémakörbe. Röviden arról van szó, hogy biztonsági okokból egy oldalon lévő JavaScript csak az oldalt tartalmazó domain-el képes kommunikálni (onnan bármit letölteni, vagy küldeni oda). Ez bizonyára sok gonoszságtól megvéd minket, mégis vannak helyzetek, mikor jól jönne, ha idegen domainről tudnánk adatokat letölteni. Például RSS feed-et szeretnénk olvasni JavaScript-ből, vagy valami távoli szolgáltatást szeretnénk valami API-n keresztül elérni. A napokban én is egy hasonló problémával találtam szemben magam. Nevezetesen volt két oldalam (mondjuk foo.com és bar.com). Az egyiken leraktam egy cookie-t, amit a másik oldalon szerettem volna kiolvasni, és mindezt JavaScript-ből. Mivel a bar.com oldal nem láthatja a foo.com oldal cookie-jait, ezért ezt csak úgy lehet megoldani, hogy a foo.com kiolvassa a saját cookie-ját, és valahogy átadja ezt a bar.com-nak. A baj csak az, hogy a bar.com-on lévő JavaScript nem tudja semmiképp elérni a foo.com oldalt. Több dologgal próbálkoztam, iframe-el, megpróbáltam a foo.com-ról betölteni a JavaScript-et, stb. de semmi nem vezetett eredményre. Ekkor találtam rá a JSONP-re.

A JSONP igazából egy igen egyszerű kis trükk a fenti probléma megkerülésére. Ha egy ideig szenved vele az ember, valószínűleg egy idő után magától is kitalálja. A JSONP-nek annyi a lényege, hogy úgy adunk át adatokat a foo.com-ról a bar.com-nak, hogy foo.com az átadandó adatokból generál egy JavaScript-et, és ezt a bar.com egy egyszerű script taggal behúzza. Mindebből úgy alakíthatunk ki kétirányú kommunikációt, hogy a kliens URL paramétereket használ az adatok továbbítására, amire a szerver a megfelelő javascript generálásával válaszol. Hogy mindez tisztább legyen, nézzünk egy példát. Tekintsük a fenti problémát, vagyis a foo.com domainről szeretnénk lekérni a cookie megadott nevű mezőjének értékét. Ehhez hozzunk létre egy cookie.php állományt a foo.com domainen, amit a következőképpen paraméterezhetünk: foo.com/cookie.php?cookie_name=<változó neve>&callback=<javascript fv.>. Itt a változó neve ugye egyértelmű, a callback paramétert meg nemsokára megértjük. A cookie.php valahogy így fog kinézni:
<?php
$cookie_name = $_GET['cookie_name'];
$data = array();
$data[$cookie_name] = $_COOKIE[$cookie_name];
echo $_GET['callback'] . '(' . json_encode($data) . ');';
?>

ha a fenti scriptet cookie_name=test és callback=jsonp_callback paraméterrel hívjuk, az eredmény valami ilyesmi lesz:
jsonp_callback({'test': 'Test cookie value.'});

Ez pedig egy teljesen szabványos javascript hívás. Nincs más dolgunk,mint a fenti url-t egy script tag-el behúzni a hívó oldalra:
<script type="text/javascript" src="http://foo.com/cookie.php?cookie_name=test&callback=jsonp_callback"></script>

A script tag tartalmát a böngésző azonnal végrehajtja, ami ugye így azt eredményezi, hogy meghívódik a jsonp_callback függvény a {'test': 'Test cookie value.'} paraméterrel. Nincs más dolgunk, mint definiálni a jsonp_callback fv.-t, és kész is vagyunk:
function jsonp_callback(data) {
alert(data.test);
}

Igazából ennyi az egész. Persze a gyakorlatban általában nem fix paraméterekkel akarunk hívni egy szerver szolgáltatást. A dinamikus paraméterezéshez dinamikusan kell előállítanunk a script tag-eket, ez DOM műveletekkel viszonylag egyszerűen megvalósítható, de van egy még kényelmesebb megoldás, ez pedig a jquery javascript library ajax hívása. Ezzel a megoldással egy egyszerű függvényhívásra van csak szükség, ami valahogy így néz ki:
$.ajax({
dataType: 'jsonp',
data: 'cookie_name=test'
url: 'http://foo.com/cookie.php',
success: function (data) {
alert(data.test);
},
});

Így tehát JQuery használatával, és némi PHP ismerettel már egész kényelmes Cross-Site Scripting megoldást készíthetünk. Akit a JSONP mélyebben érdekel, az utánanézhet a wikipediában.