/ András webkettőt fejleszt /
Szombaton “Turbó fokozat” címmel előadtam a Web Konferencián – az előadás keretében beszéltem az nginx, Redis és node.JS szoftverekről, melyek hasznos építőkövei lehetne egy gyors webszolgáltatásnak. Ha lesz egy kis időm, átírom blogbejegyzésbe is az elhangzottakat, de addig is az előadásom fóliái:
A prezentáció letölthető PDF formátumban is: Turbó fokozat (kb. 10MB)
A Google csavart egyet a böngészőháborún, rúgva egy hatalmasat a Microsoftba, kiadta a Chrome plugint, ami egy Internet Explorer-be beépülő böngésző kiegészítő, s lecseréli a böngésző motorját a Chrome kínálta WebKitre. Sem a kiadás indoka/célja, sem pedig a kezdeményezés nem igazán szimpatikus számomra, össze is szedtem, hogy miért.
Lehet hogy néhány indok nagyon szubjektív, illetve nem áll szilárd lábakon, de összességében a lépés számomra azt jelenti, hogy a Google erőszakos, s képtelen volt megcsinálni azt, amit egy hétköznapi webfejlesztő is meg tud csinálni: az Internet Explorer támogatását saját termékében.
Augusztus 9-én három éves lesz a Miner. Erre a dátumra jelentős szolgáltatásbeli bővülést, és technikai megújulást tűztünk ki célul. Három év alatt immáron 40 GB-osra nőtt a rendszer adatbázisa, 15 millió blogbejegyzéssel, hasonló nagyságrendű videó mennyiséggel őrizzük az elmúlt három év történéseit. Ez az adatmennyiség számos üzemeltetési, fejlesztési problémát is felvetett, ezeket szeretnénk most orvosolni a tudomány és technika újdonságait segítségül hívva. Ebben a bejegyzésben most pár problémáról írok, legközelebb pedig remélhetőleg már arról, hogy hogyan sikerült megoldani ezeket.
Egyik gond a MySQL adatbázis backupja, melyet megoldottunk ugyan egy slave adatbázis beállításával, a napi backup alatt a replikáció leállításával, rsync-kel történő backupolásával, de rengeteg erőforrást emészt fel így is a történet. A régi blogbejegyzéseket persze törölhetnénk, rengeteg helyet felszabadítva, hiszen ki kiváncsi vajon egy két évvel ezelőtt született blogbejegyzésre, de szeretnénk a Miner ezen lehetőségét megtartani. Másik lehetőség az lenne, hogy szétdaraboljuk az adatbázist, és a régebbi tartalmakat csak olvasható formában tároljuk, ezzel az a gond, hogy akár igen régi bejegyzésekhez is hozzá kell nyúlnunk néha, mert a szerző kéri, hogy blogját töröljük adatbázisunkból (ilyen igen ritkán van, de nem mondhatjuk hogy nem tudjuk megoldani). Az irány valószínűleg valamilyen elosztott adatbázisba mentés lesz, mely nem csak a tárolást, hanem egyben a backupot is biztosítani tudja.
Másik gond a lekérdezések sebessége. Itt például a mellékletek friss bejegyzéseiről van szó, itt a gyors megjelenítés a követelmény. A probléma itt abból adódik, hogy egyes mellékleteknél (mint például a film) vannak olyan blogok (pl. sorozatjunkie, comment.com), melyekben nagyon-nagyon sok bejegyzés van. Ilyenkor egy olyan SQL lekérdezés, mely dátum szerint rendez, és több tucat kategóriára szűr, elég sokáig tarthat. Ugyanitt probléma a megfelelő képek, videók kiszűrése is a tartalomból. Már korábban továbbléptünk egy külön indexelésre, illetve keresőszerverünk bevetésére (mely meglepő módon gyorsabb tud lenni, mint a MySQL), további lépés várhatóan az lesz, hogy az egészet felturbózzuk az egy-az-egyben a memóriába pakolással.
Végül, de nem utolsó sorban a robotok működését sem mondanám a legkiforrottabbnak, bár az utóbbi években bizonyított ez a felállás, a további skálázhatóság, és a jobb áttekinthetőség érdekében tovább kell lépnünk. Jelenleg pár PHP-ben írt robot fut párhuzamosan, lekérdezve a MySQL adatbázisból hogy mely blogok RSS-ének letöltése következik, s párhuzamosan elindítanak 100 kérést, az eredményt pedig memóriába pakolják. További robotok a memóriából felolvassák az RSS tartalmát, megnézik van-e új blogbejegyzés, módosult-e már régi, s ha igen, akkor letárolják azokat, s gondoskodnak a mellékletekbe történő “címkézésről” is. Ezt a felállást a MySQL lehetőség szerinti teljes kiiktatásával, s erre kitalált jobszerverek, queue-k összerakásával szeretnénk kiváltani, mely azt is kényelmesen lehetővé teszi, hogy a hamarosan beállítandó új szerverekre osszuk szét a jelenlegi terhelést (az indexelés jelenleg a legerőforrásigényesebb feladatunk).
Persze ez csak az előttünk álló technikai változtatások egy (a jelentősebb) része, s az új szolgáltatásokról még nem is ejtettem szót. A megoldásokról igyekszem majd részletes blogbejegyzésben, blogbejegyzésekben, továbbá ha lehetőségem adódik rá, akkor egy newtech meetup keretében is beszámolni.
Korábban már szóltak róla pletykák, most be is jelentette a Google: az eddigi Python kód futtatás mellett Java kódokat is lehet használni az App Engine “hoszting szolgáltatásukban”. Ez nagy lökést adhat a projektnek, Java programozóból ugyanis jóval több van, mint Python programozóból.
A Google bejelentése alapján “early look” minőségben érhetőek el jelenleg az új funkciók. Ami az adatbázis kezelést illeti standard Java interfészeket biztosít a Google, avagy az App Engine datastore API helyett a Java Data Objects és Java Persistence API használható. Új verzió jelenik meg a Google Web Toolkitből és a Google Plugin for Eclipse-ből is. Bár arról nem szól a bejelentés, valószínűleg az Androidban is elérhető Java motorra, a Dalvikra építették fel a szolgáltatásukat.
További eddig hiányolt funkciók is megjelennek: lehetőség lesz időzített kódfuttatásra, data importálásra, az adatok biztonságos csatornán történő elérhetőségére is.
Az újdonságokkal egy a hoszting szolgáltatásokkal kifejezetten versenyképes megoldást tesz le a Google az asztalra, a skálázhatóság ígéretével, ezzel sokkal népszerűbbé téve a megoldásukat. Kiváncsi leszek, hogy mekkora sikere lesz a Java fejlesztők körében a nyitásnak – az elkövetkező napokban meglátjuk.
Korábbi – bár viszonylag régi – ide kapcsolódó blogbejegyzésem a témában érdekes lehet: Google App Engine – mennyibe kerül?
Az imént egy érdekes MySQL Storage Engine megjelenésével találkoztam, segítségével PHP nyelven valósíthatunk meg adatbázis tároló motort. A PHP alapú MySQL Storage Engine ötlete egy kicsit őrült (hiszen a PHP meglehetősen lassú erre a feladatra), ellenben vannak olyan lehetőségek, melyek kapcsán érdekes megoldás lehet. Például egy távoli API MySQL-es reprezentációját lehet így megvalósítani.
Nem mondom hogy a kódot valaki próbálja meg élesben használni, ahhoz egy kicsit még kezdeti állapotban van – az irány az érdekes, amit meg lehet majd esetleg csinálni a motorral ha felnő.
Kérdés lehet persze, hogy mi a fenének hozzuk be a MySQL-t a képbe, miért ne direktben PHP-ben valósítsunk meg inkább egy feladatot, ha már. Számos oka lehet egy ilyen iránynak mely miatt hasznos lehet egy ilyen motor számos hátránya ellenére:
Több pontot is “persze”-vel fejeztem be, így látszik, hogy ez a motor azért eléggé öszvér megoldás. Az ilyen ötletek mozdítják viszont előre az innovációt, hiszen ki tudja kinek mi jut eszébe vagy mire tudja hasznosítani majd ezt a lehetőséget.
Dolgoztam egy kicsit az oldalon jelen levő, “Google Reader szerű”-nek bemutatott navigációval, így van pár kisebb újdonság: most már a teljes archívumon végig lehet menni, illetve kis üzenetablak jelenik meg, mert különben felfedezhetetlen lenne a lehetőség. Az üzenőablak a feed feliratkozást is reklámozza a blogbejegyzések oldalán.
A korábbi állapothoz képest azzal egészült ki a navigáció, hogy immár a lapozást is támogatja. Amennyiben (a címlapon) fel-le vándorlunk, és az első vagy utolsó bejegyzés után nyomunk egy J, illetve K billentyűt, a következő archívum oldal fog betöltődni. Korábban azt néztem, hogy hol áll éppen az oldal scrollja, és ha az oldal látható teteje alatt valahol volt egy bejegyezés még, akkor engedtem a lejjebb, ha pedig feljebb volt egy bejegyzés, akkor a feljebb görgetést. A probléma a lefele görgetésnél van, amennyiben az oldalon levő utolsó bejegyzés rövidebb az oldal magasságánál, akkor az oldal tetejéhez képest mindig lesz lejjebb bejegyzés, nem fog tudni továbbgördülni a böngészőablak, avagy sohasem észleli a kód, hogy most már a következő oldalt kellene betölteni.
A problémát úgy oldottam fel, hogy van egy változó is, hogy éppen melyik bekezdésnél jár az oldal scrollozása, és ezt használom, amennyiben az utolsó scrollozás után nem mozdította meg a felhasználó az oldalt. Ez utóbbi azért fontos, mert lehet, hogy a felhasználó továbbment, vagy visszament scrollozással, s nem a J-K billentyűket használva. Ez azért megoldás, mert így tudom, hogy a felhasználó már az utolsó bejegyzésnél jár, amikor megnyomja a J billentyűt. Lapozáshoz a K2 megfelelő kódját használtam, mely így egész jól is működik.
A kis üzenetek a jGrowl nevű jQuery kiegészítő segítségével jelennek meg. Ez elég sokféleképpen paraméterezhető, a lehetőségek igencsak kis részét használtam ki (viszont így meg lehet majd valósítani további üzeneteket). Üzenet jelenik meg, ha a címlapra érkezik a látogató (lásd kép), és üzenet jelenik meg, ha egy bejegyzés oldalon több, mint 5 másodpercig tartózkodik az olvasó.
Nem vagyok egy nagy Microsoft szimpatizáns, de erősen figyelem, hogy mit csinál a cég, és mostanában volt pár jó húzása. A hazai MS közösség is egész jól alakul, a devPortal blog részlege nemrégiben történt megújulása óta a feedolvasómba is bekerült. Talán náluk olvastam először egy új, a fejlesztőket érintő Microsoft akcióról is, melynek keretében 3 évre ingyen fejlesztőeszközöket (az ingyen ebben az esetben $100-t jelent), szerver szoftvereket biztosít induló vállalkozásoknak.
Az akció lényege, hogy a 3 évnél nem régebben indult cégek számára 3 évre teljes licencű csomagot kap a következőkből:
A hír szerint a fejlesztőkörnyezet a harmadik év után is használható, a többit viszont meg kell venni, ha a vállalkozás úgy dönt, hogy továbbra is ezekkel üzemelteti a szoftverét. Bátorfi Zsolt (hazai MS guru) a fent belinkelt blogbejegyzéshez történő hozzászólása alapján pár héten belül a hivatalos hazai részletek is várhatóak arról, hogy hogyan lehet Magyarországról élni az ajánlattal (bár a jelek szerint nincs akadálya már most sem jelentkezni, de nyilván egyszerűbb lesz, ha magyarul is lehet majd).
Személy szerint úgy gondolom, hogy nem éri meg a Microsoft szerverplatform használata, de ez nem egy általános igazság. Ami biztos viszont, hogy mindenképpen érdemes legalább rátekintés szinten megismerkedni a Microsoft által kínált környezettel is, akár mellette döntünk, akár nem. Az ajánlat elég csábító lehet a startupok számára, s bár azt nem hiszem hogy emiatt a lépés miatt döntő többség átállna, de mindenképpen egy elég fair ajánlat, mely biztosan sokakat motiválni fog a kipróbálásra.
Az OpenSociallal foglalkoztam már (Mi is az az OpenSocial?) annak még egy korai állapotában. Azóta többet tudunk arról, hogy mire jó az OpenSocial, s arról is, hogy mi az amit nem támogat, nem tesz lehetővé. Egyre több platform támogatja (az Orkuttól a LinkedInig), s azért a címben az aktuális szó, mert rövidesen az iWiW, és előbb-utóbb talán a születése után tetszhalottá váló IndaNet is fogja, ideje tehát megismerkedni vele. Megnézted már közelebbről?
Az OpenSociallal az a problémám, hogy a Google saját widget specifikációját is nyomja vele – bár úgy tűnik ez legalább részben változik azzal, hogy ebből a szempontból platformfüggetlen megoldások is előbb-utóbb érkeznek az OpenSocial REST API-val, és például a Netvibes UWA felől. Létrejött egy alapítvány is, melyben több cég is képviselteti magát a MySpace-től kezdve a Yahoo!-ig.
A megoldásról azt mindenképpen tudni kell, hogy nem célja a különböző közösségi oldalak közötti információcsere, azaz nem egy átfogó adatáramlást elősegítő szabványról beszélhetünk, hanem egy a közösségi hálók felett futó, és elvileg azok között hordozható alkalmazások írását lehetővé tevő környezetről. Az egyszer elkészített alkalmazás várhatóan bármelyik OpenSocialt támogató platformon futni fog majd, esetlegesen kisebb módosítással. A Facebooknak saját platformja van, a két megoldás azonban eléggé eltérő megközelítést ad az alkalmazásfejlesztésre.
Az OpenSocial alkalmazások a Google gadget technológiájára épülnek, tehát JavaScript alapúak. Egy jól definiált API-n (gyakorlatilag tízes nagyságrendű, könnyen tanulható függvényhalmazról beszélünk) keresztül érik el az adott platform (konténer, container) lehetőségeit, mely a szociális háló, ismerősök/barátok lekérdezhetőségét, ajánlásokat, aktivitásfolyam közzétételét, beállítások/adatok mentését és visszatöltését és hasonlókat jelent. A lehetőségek száma gyakorlatilag végtelen, hiszen egy alkalmazás az adott platform határain túlról is be tud hozni információkat a rendszerbe.
Az iWiW részéről észszerű lépés az OpenSocial támogatása, s ez a hazai fejlesztők, kisvállalkozások számára nagy lehetőségeket rejthet. Meg merem kockáztatni hogy egy sikeres bevezetés olyan mérföldkő lehet az iWiW életében, mint amilyen a WiW->iWiW váltás volt. Te átnézted már hogy hogyan működik az OpenSocial?
Az authentikáció kérdése elég érdekes manapság, mivel már nem csak a “bekérem a felhasználónevet, jelszót” változatot kell jellemzően megvalósítani, mikor hitelesíteni akarjuk a felhasználó személyét. Az OpenID és oAuth protokollok úgy biztosítanak hitelesítést, hogy az oldal nem tudja meg a felhasználó jelszavát, az egy harmadik félnél van. A dolog nálam egyéb okokból is aktuális, de az OpenID azért is jöhet a képbe, mert most már mind a három nagy támogatja: a Yahoo!, a Microsoft és a Google is.
Kimazsolázni a különbséget a két megoldás között nem feltétlenül könnyű, én is csak most ismerkedem ezekkel a protokollokkal (ha van tipp, jöhet!), de a lényeg, hogy az OpenID segítségével alapvetően annyit lehet kiszedni a szerverből, hogy sikeres volt-e az authentikáció, vagy nem, míg az oAuth további adatok biztonságos forgalmazását is lehetővé teszi (gondoljunk itt egy API-ra). Mind a két megoldás alapja egy authentikációs szerver, ahol nyilván van tartva a felhasználói azonosítónk és jelszavunk (vagy más formában kínál azonosítási lehetőséget), s ezt a szervert használva léphetünk be különböző oldalakon úgy, hogy közben a céloldal nem fogja megtudni sem az azonosítónkat, sem a jelszavunkat. Hozzáteszem, az OpenID-nak van egy kiegészítése, mely segítségével lehetőség van személyes információkhoz (pl. az azonosító) történő hozzáférésre (akár azok megváltoztatására is), az oAuth keretében pedig magának a protokoll használatának keretében dönthet úgy a szolgáltató, hogy biztosít olyan interfészt, ahogyan ez megtehető. Nyílt protokollokról van szó: ingyenesen használhatóak, és nyílt szabványokra, algoritmusokra épülnek.
Egyik protokollra sem mondanám, hogy egyszerű, mindkettő ide-oda üzengetést tartalmaz, jellemzően a biztonságot szem előtt tartva aláírva valamilyen algoritmussal az üzeneteket. Az OpenID authentikáció kiegészítője az OpenID tulajdonságcsere, ezekkel a doksikkal érdemes kezdeni egy átfogó kép kialakításához, majd mondjuk megnézni egy gyakorlati dokumentációt. Kész kódok is rendelkezésre állnak különböző nyelvekhez, de ehhez már jellemzően érteni kell magát a protokollt, vagy legalábbis a főbb elemeit. Az oAuth-tal történő ismerkedést is az oAuth specifikáció segítségével lehet érdemes kezdeni. Ezután szintén egy gyakorlatibb útmutatót, majd kész kódok nézegetségét tudom ajánlani.
Amit eddig még nem mondtam el, hogy miért is jó nekünk, ha ezekkel megismerkedünk (persze mindenki döntse el maga). Az OpenID kapcsán ha lehetővé tesszük annak használatát oldalunkon, akkor megkönnyíthetjük a felhasználók regisztrációs folyamatát mind fizikailag (pár kattintással túl tudnak lenni rajta – nincsen emailes megerősítés), mind lelkileg (nincs jelszó megadás, és gyors a folyamat). Ez sokat jelenthet, hiszen a felhasználónak megspórolhatunk pár percet – ami nagyon sok, ha azt nézzük, hogy 5 másodpercet sem szoktunk kivárni egy oldal letöltésekor.
Az oAuth akkor jó, hogy olyan webszolgáltatást írunk, mely együtt szeretne működni más szolgáltatásokkal a neten. A régimódi megoldás erre hogy bekérjük a másik szolgáltatás felhasználónevét, jelszavát ha szeretnénk a felhasználó más szolgáltatásnál tárolt adataihoz hozzáférni, ez azonban nem igazán bizalomgerjesztő, hiszen azt le kell tárolnunk: ha hozzánk betörnek, a másik szolgáltatáshoz is nyitott az út, illetve az sem nyugtatja meg a felhasználót, hogy látjuk ezeket az adatait.
A WebKit böngészőmotor (aki nem ismeri a történetét, a Wikipédián elolvashatja), mely többek között a Safari és a Chrome megjelenítőmotorját biztosítja elég jó ütemben, és jó irányba fejlődik. És ami a webfejlesztők számára kiemelten érdekes lehet, a Web Inspectort erőteljesen feltupírozták, s így egy elég jól használható hibakereső eszközt hoztak ki belőle, mely részben meghaladja a Firebug képességeit is (részben viszont hiányolok párat).
A WebKit blogjában el lehet olvasni a hogy mi változott: Web Inspector Redesign, én pedig inkább arról írok hogy mi tetszik, és hogy mi az, ami még hiányzik. A WebKit legfrissebb napi buildjei a tapasztalataim szerint stabilak, jól használhatóak (legalábbis Mac-en), érdemes kipróbálni hogy mit tud a böngésző (nagyon gyors is). A Safari és a Chrome következő változatával pedig hivatalos kiadásban is kipróbálhatjuk azokat, amikről most írni fogok.
A Web Inspector segítségével a Firebug-tól megszokott szolgáltatásokat kapjuk: van az adott weblap HTML-jének böngészését lehetővé tevő Elements fül, egy a letöltött oldalelemeket felsoroló, azok letöltési idejét, méretét jól áttekinthetően megmutató Resources fül, JavaScript debuggolást lehetővé tevő Scripts fül, egy teljesítménymérést (melyik függvény hányszor lett hívva, mennyi ideig tartott a ftása, stb.) nyújtó Profiles fül, továbbá egy az adott oldal helyi (lásd HTML újdonságok) adatbázisait elérhetővé tevő Databases fül. És az egészet kiegészíti egy konzol, ahol JS parancsokat adhatunk ki, hasonlóan a Firebug “parancssorához”.
A fejlesztések (amikről azt kell tudni, hogy nagy részük önkéntes munkából, különböző fejlesztők felől érkezett) igen sokat javítottak az Web Inspector használhatóságán, gyakorlatilag egyetlen egy gondom van: az összetett objektumok konzolban történő megjelenítése. A Firebuggal szemben ugyanis nem kapok betekintést az adott objektum tulajdonságaiba sem DOM objektumnál, sem pedig egy általános objektumnál. DOM objektumnál a helyzet ennél egy kicsit jobb, mert ha a kurzorral a konzolban felé megyek, akkor az Elements fül segítségével összeszedhetem azokat a tulajdonságokat, amiket keresek.
Jó dolgok viszont vannak dögivel (ezek egy része persze a Firebugban is megvan, de nem feltétlenül így), az eszköz kialakítása ami az interfészét illeti szerintem nagyon jól sikerült, lehet az adott oldalba “dokkolva” és külön ablakban is használni. A konzolban működik egy egész jónak tűnő kódkiegészítés, az oldal HTML-je élőben szerkeszthető, az idő/méret szerinti nézet a Resources fülön üt. A helyi adatbázis elérése is egy nagyon fontos lépés, előbb-utóbb a fejlesztők elkezdik használni ezt a lehetőséget, így egy nagyon hasznos eszköz lehet majd.
A WebKit letöltését és kipróbálását már ajánlottam a múltkor is, és most is csak ajánlani tudom.
Utolsó megjegyzések