Monthly Archives: november 2007

Játék a Miner API-val

Tegnap kicsit játszottam a Miner.hu API-jával – kiváncsi voltam hogy miket lehet kihozni a blogkereső találati adataiból. Egész jó lett a végeredmény, talán egyszer majd beépül pár dolog belőle a Miner.hu-ba is.

Miner.hu

A programocska megtekinthető élőben is a http://barthazi.hu/jaccoter/miner/ címen. Gyakorlatilag az adott keresőkifejezéshez kapcsolódó releváns kifejezéseket hivatott megjeleníteni. Rákeres a beírt kifejezésre, a talált blogbejegyzésekből eltávolítja a HTML részleteket, majd megszámolja, hogy egy adott két vagy három szavas kifejezés hányszor fordul elő. Amelyek többször is előfordulnak, megjeleníti.

Pár trükk van még a programban, egy több ezres tulajdonnév listát is használ, továbbá egy nagyon buta kis algoritmussal ezeket szótövezni is képes, így ragozott neveket is megtalál. A csak “stopword”-öket (gyakori magyar kötőszavak) tartalmazó kifejezéseket pedig kiszűri. Alapvetően kisbetűsít minden kifejezést, hogy az eltérő módon írt, de ugyanolyan szavakat is megtalálja, de a folyamat végén megnézi, hogy melyik a leggyakoribb írásmód, és ezt jeleníti meg.

Hogy mire volt jó ez a kis játék, még nem tudom, de érdekes dolgokat lehet kihozni segítségével, és egy kis ujjgyakorlatnak is jó volt. A Miner.hu címlapon megtalálható Trends kifejezésekkel, vagy egyebekkel érdemes kísérletezni, az általános szavakra nem ad eredményt.

Google marketing

Tegnap egy Wired Science videocastot nézegettem biciklizés közben, mely egy úgynevezett “restless leg” (kb. álmatlan láb) szindrómáról szólt. Pontosabban arról, hogy milyen aggresszív marketinggel teremtette meg a gyógyszeripar ezt a betegséget, hogy aztán gyógyszert tudjon rá adni (hozzáteszem, van aki szerint igenis létezik ez a betegség). Ma reggel meg ezt a cikket olvastam a Google keresési lehetőségeiről.

I will use Google…

Nem tudom, hogy csak én látom-e így a dolgot, de a Google nagyon ügyesen marketingel, és számomra ez látszik ebből a cikkből. Értem ez alatt, hogy piacvezetőként nem csak a szolgáltatásának fejlesztésével van elfoglalva, hanem azzal is, hogy az emberek továbbra is azt gondolják, hogy a keresője egyedi, és a versenytársaknál okossabb. És itt kapcsolódik be az a gondolat amivel felvezettem a bejegyzést, miszerint olyan problémákat teremtenek, melyek valójában nem is léteznek. Ez persze így nem igaz, inkább pontosabban fogalmazok: olyan extrákat vezetnek be és/vagy kommunikálnak a nagyközönség felé, amire az ember azt mondja, hogy “cool”, meg hogy milyen érdekes, függetlenül attól, hogy van-e haszna. Ha a geek (és talán az átlag) közönség felé folyamatosan tudnak ilyen lehetőségeket, érdekességeket kommunikálni a keresőjükről, míg a konkurencia ezt nem teszi meg, továbbra is elég nagy az esélyük rá, hogy piacvezetők maradjanak.

Ezek a lehetőségek, trükkök talán sehol sincsenek dokumentálva, így szájról-szájra terjedhetnek, illetve egy-egy marginális kérdés esetén szinte mindegy, hogy meg vannak-e valósítva, az emberek többsége ugyanis alig fogja ezeket használni, maximum egyszer kipróbálja – ez is egy érdekesség az ilyen jellegű újdonságok esetén (más kérdés, hogy az “emberek nagyon kis része” is elég nagy a Google keresője esetén). Jó trükk az is, hogy olyan szolgáltatásról beszélnek, amely még nem működik, és nem kommunikálják, hogy mikor fog megjelenni, vagy például az arab weblap fordítás esetén nehéz ellenőrizni, hogy mennyire működik jól, ellenben látványos, hogy jobbra van igazítva az oldal.

A korábban írt OpenSocial és Android Google fejlesztések esetén ráadásul a marketing – nálam legalábbis – túlzásokba esett, a marketing gépezet úgy indult be elsöprő erővel, hogy konkrétumokról egyáltalán nem esett szó. Nekem nem tetszik ez a Google viselkedés, mert a Microsoftra emlékeztet. Ne a marketinggel adják el nekem a fejlesztéseiket, pontosabban ne csak és kizárólag marketing legyen egy bejelentésnél, mert nem fogom őket szeretni.

SVN: telepítés

Korábbi SVN bevezető bejegyzésem igen pozitív visszajelzéseket kapott, több reakció is érkezett rá. Az egyikben azt a kérdést szegezték nekem, hogy akkor hogyan is van ez a dolog, kell-e valami szerverszerűt telepíteni az SVN használatához, vagy másképp működik a rendszer? Röviden: nem feltétlenül, de a legegyszerűbb, ha van.

SVN - Subversion

Én eddig egyszer telepítettem SVN szervert, egy ősrégi Debian masinára, a tapasztalat az volt, hogy bár megdolgoztam vele, nem igazán tért el egy szerver telepítéstől Linux alá. A helyzet azóta sokat változott, a Linux szerverek és maga a Subversion is fejlődött.

A kalandozást érdemes a Subversion projekt honlapján kezdeni, először is azzal, hogy pontosan hogyan is kommunikál az SVN kliens az SVN szerverrel. A – remélhetőleg – ismerős HTTP protokolt kiegészítő WebDAV/DeltaV kommunikációt használ (kicsit részletesebben), melyekről nem állítanám, hogy egyszerűek, mindazonáltal jól működnek. Ebből többminden következik. Az egyik, hogy a webproxy-kon keresztül elvileg jól működtethető az SVN kommunikáció, másrészt, hogy az Apache szerver a rendszer barátja. De ha nem akarjuk, nem kell bemutatnunk őket egymásnak, Apache nélkül is megoldható a dolog.

Kicsit előreugrok, hogy aztán érthetőbb legyen a következő bekezdés. Szóval miután felraktuk a szervert, az első dolgunk az lesz majd, hogy létrehozunk egy repository-t. A repository-k tárolására több módszer van, de alapvetően mindegyiknél létrehozunk egy könyvtárat a szerveren egy “svnadmin create könyvtárnév” parancs kiadásával, egy “mkdir könyvtárnév” mintájára. Windows alatt lehet, hogy van rá grafikus eszköz, nem tudom. Ebben a könyvtárban fogja nekünk letárolni a szerver a különböző információkat, és ezekben lehet matatni is, ha le akarunk kezelni olyan eseményeket, mint egy “commit” művelet. Jellemzően több könyvtár és fájl kerül ebbe a könyvtárba alapból bele.

Bár a dokumentációk mindenhol három lehetőséget emlegetnek mint rendszer összeállítási lehetőséget, valójában van egy negyedik is: a szerver nélküli használat. Ezt csak Linuxon parancssorban próbáltam, de vállalkozó kedvűek kipróbáhatják Windows alatt is, kiváncsi lennék. A lényeg, hogy az SVN kliensek jellemzően ismerik a fájlrendszer alapú címzést is a repository-t illetően, tehát ha az SVN repository-nk a szerveren a /usr/local/svnroot/webakademia könyvtárban van, akkor a file:///usr/local/svnroot/webakademia címen is hozzáférhetünk. Linux alatt ennek fényében az “svn co file:///usr/local/svnroot/webakademia” paranccsal “kicheckoutolhatjuk”.

További egyik lehetőség egy saját “svnserve” nevű szerverke, ez a legegyszerűbb feladat, s ha nincsenek különösebb igényeink, használjuk bátran ezt. Ezen kívül van még az SSH-n keresztüli működtetés “svnserve”-vel, és végül a legbonyolultabb konfigurációt az Apache 2 alá telepítés igényli, ahol egy modulként fog tudni működni a szerverünk. Fontos, hogy mind a három szerveres esetben magát a repository-t nekünk kell létrehoznunk, és hogy az SVN funkciókat illetően egyik szerver sem tér el a másiktól, csak és kizárólag abban, hogy hogyan authentikál a rendszerünk, s hogy milyen portokat használ. A konkrét szerver telepítéseket nem írom le, jó dokumentáció áll rendelkezésre hozzá a projekt honlapján. Alapvetően semmi hatalmas tortúrától nem kell tartanunk. Windows, Linux, Mac OS X és egyebek alá is elérhetőek a szerverek bináris terjesztésben, és ugye ott van a forráskód is, ha valaki a forrásban szeretne turkálni.

TortoiseSVN

Ami a klienseket illeti, én eddig négy megoldást próbáltam. Különböző Linuxok, Mac OS X alatt bár nem mindig a legkényelmesebb, de biztos pont volt a parancssori “svn” nevezetű SVN kliens. Windows alá bátran ajánlom a Windows Explorerbe épülő TortoiseSVN-t, folyamatosan fejlődik, kényelmesen használható, és a teknős (lásd mellékelt ábra) is jó fej (ha lányokat kell meggyőzni a használatáról). Eclipse alatt a Subclipse nevű plugint használtam, mely elég kényelmesen beépül az Eclipse-be, és kényelmesen használhatóvá teszi az SVN-t. Jó tudni, hogy a TortoiseSVN és az Eclipse modul ugyanúgy adminisztrálja kliens oldalon a fájlokat, így párhuzamosan tudunk együtt dolgozni a kettővel ugyanazokon a fájlokon. Végül mostanában az svnX nevű Mac OS X-es klienst használom, s bár ezzel nem vagyok annyira elégedett, mint a TortoiseSVN-nel vagy az Eclipse modullal, de ez is jól működik. Van még a TextMate-nek is SVN kliense, de az vagy csak részben használható, vagy még nem jöttem rá hogyan kell – nem tudom. Persze ez korántsem a teljes lista, egy jóval bővebb itt olvasható.

Jó SVN-ezést! Előbb-utóbb folytatom további részletekkel. :)

Itt a Safari 3.0

A mai Mac OS X Tiger frissítésben benne van a Safari 3.0 is, a Mac OS X Leopardban pedig alapból szerepel. Ez azt jelenti a webfejlesztők számára, hogy a Safari 2.0 részesedése a mai naptól drasztikusan fog csökkenni. Egy friss Windows verzió is kijött. A következőkben azt próbálom meg összefoglalni, hogy mit kínál a Safari 3.0.

Safari 3.0

Kezdjük a felhasználókat érintő változásokkal, hogy aztán gyorsan áttérhessünk a webfejlesztőket érintőkre. Egyrészt ugye a 3.0-s verzió immár Windowsra is elérhető. Az első Windows verziók valami iszonyat bénára sikerültek, de ez ne riasszon el senkit, ezeket a bugokat előbb-utóbb kijavítják, talán a legtöbb már ki is lett javítva a legfrissebb 3.0.4-es Windows-os verzióval. A Safari 3.0 újdonsága az átméretezhető szövegdoboz is, mely jól jöhet ha valamelyik webfejlesztő túl kicsire állított be egy hosszabb szöveg fogadását megcélzó textarea-t. Az átrendezhető fül sorrend szintén új – az egyik nekem legjobban tetsző fejlesztés is ezzel kapcsolatos: egy fült ki lehet ragadni a többi közül egy új ablakot létrehozva ezáltal. A Firefoxból jött át a “valós idejű keresés”, mely az oldal tartalmában gépelés közbeni találat megjelenést jelent.

Érdemes lehet megjegyezni, hogy Safari három nem csak MacOSX és Windows alatt érhető el, hanem a mobil MacOSX alatt is, vagyis iPhone-on és iPod Touch-on is. Ezt azért hangsúlyozom ki külön, mert lehet azt mondani, hogy az újdonságokat mivel más böngésző annyira nem támogatja még, ezért minek megismerni, de ezeken a mobil eszközökön ezeket nyugodtan lehet használni és kihasználni – sokan használják is.

CSS: a mai napon a Safari 3.0 a CSS szabvány(oka)t legjobban támogató kiadott böngésző. Egyrészt az aktuális CSS 2.1-t is kiválóan támogatja, másrészt pedig a CSS 3-ból is jópár dolgot megvalósít:

  1. Több oszlopos tördelés: Egy adott blokk elemben több oszloposra tördelhetjük a szöveget. Ez a lehetőséget ugyan nem tartom jó ötletnek weben, de ami a nyomtatott oldalakat illeti, ott hasznos lehet. (-webkit-box-shadow)
  2. Lekerekített sarkok: A Mozillából már ismert lehetőség a keretek lekerekítésére. (-webkit-border-radius)
  3. “Négy dimenziós” színek (vagyis áttetszőség): a színeket ha RGB vagy HSL paramétereikkel adjuk meg, immáron egy negyediket, az áttetszőséget is használhatjuk (HSLA, RGBA). Ez gyakorlatilag annak a lehetősége, hogy az “opacity”-t, melyet a legtöbb böngésző támogat, színként is megadhassuk. Ezt a lehetőséget a FF3 is támogatni fogja. (rgba(255, 0, 0, 0.6))
  4. Több háttérkép beállítása ugyanazon elemnek: Több háttérképet, különböző igazítást, ismétlési értéket is definiálhatunk. (a háttér képeket, pozícióikat vesszővel elválasztva kell felsorolni)
  5. Képek használata keretként: vagyis immáron nem kell szenvedni grafikus keretek definiálásával – Safari alatt. (-webkit-border-image)
  6. Árnyék a block elemeknek: A block megjelenésű elemeknek árnyékot is definiálhatunk. (-webkit-box-shadow)
  7. Nyújtható háttérképek: A háttérképeknél immár az arányok is beállíthatóak, azaz lehet nyújtani, összenyomni azokat. Az Opera 9.5 is támogatja. (-webkit-background-size)
  8. Szöveg kiemelések: Különböző paramétereken keresztül változatos módon állítható szöveg kiemelések (-webkit-text-stroke és egyebek)
  9. Átméretezhető oldalelemek: A “block” megjelenésű elemek átméretezhetőek lesznek JS bűvészkedés nélkül is. (resize)
  10. Háttér levágások: a háttérként beállított grafikát levághatjuk, meghatározhatjuk, hogy pontosan milyen eltolása legyen. FF is támogatja. (background-origin és background-clip)
  11. Szöveg levágások: a túl hosszú szöveget le lehet vágni három ponttal, szabályozható, hogy szóhatárnál, vagy szó közepén legyen a vágás. Részben IE6 is támogatja, illetve Opera. FF csak vágni tud, pontokat kitenni nem. (text-overflow)

A lista nem teljes, kiválasztók, és egyéb paraméterek is támogatva vannak. A Safari 3.§ lehetővé teszi egyes form elemek átdesignolását is.

JavaScript: Nagyon sokat gyorsítottak a JavaScript értelmezőn is, de megjelent a Mozillából már ismert “getter”/”setter” támogatás, DOM osztályok “prototype” elérése (HTMLElement.prototype), fejlődött a HTML szerkesztés módban használható execCommand támogatás. Részben ide tartozik az XPath és XSLTProcessor támogatás fejlődése, megjelenése is.

A JavaScript gyorsítást a motor általános gyorsításával is, de apró trükkök bevezetésével érték el. Egy érdekes példa: az “onload” esemény már akkor elkezd lefutni, amikor az oldal valójában még nem töltődött be, bár ha olyan oldalelemre hivatkozunk bármilyen módon, ami még nem áll rendelkezésre, akkor a futása addig szünetel. Ezekkel a trükkökkel egy nagyon gyors böngészőt sikerült összehozniuk.

Végül de utolsó sorban bár Safarit én nem használok webfejlesztésre, de mindenképpen ki kell térni a Drosera kiegészítőre, mely egy JavaScript debuggert valósít meg – erről egész jókat hallani.

Android, a Google mobil platformja II.

Egy hete már írtam a Google Android platformjáról, amikor a Google bejelentette azt. Tegnap végre közzétették a programozói felület fejlesztők számára érdekes részleteit is, ennek kapcsán most már többminden látható a múlt heti (semmitmondó) bejelentéshez képest.

Google Phone, vagyis az Android

A véleményemet már részben kifejtettem a Kispad idevágó bejegyzésében, de úgy érzem, tudom én ezt még részletesebben is. Mindenekelőtt két indító gondolat. Egyrészt akarva, akaratlanul, az Android operációs rendszer/programozói interfészt az iPhone+Mac OS X mobil verziója párossal hasonlítom össze, mivel nemrégiben beszereztem egy iPod Touch-ot, és eléggé beleszerettem a hackelhetőségébe. Másrészt az is megér pár mondatot, hogy miért is szerepel ez a bejegyzés a webről szóló blogomban. Ahogy elnézem, a jövő programozása a mobil platform, az asztali platform és a webes platform egyre közelibbé válásáról fog szólni. Az iPhone egy igen jó példa a webalkalmazások mobilizálására, mivel a modern webalkalmazásokat az iPhone Safarija támogatja a legjobban teljes értékű és kényelmesen használható böngészőjével. A web és az asztali szoftverek közeledéséről is írtam már, a lényeg tehát, hogy úgy látom, szűnnek meg a határok és a falak is.

Az Android platformot egyelőre kétkedve fogadom. Most már látszik, hogy a Google nem a levegőbe beszélt egy hete, de ezzel együtt tovább is mehettek volna ami az API-t illeti. A közzétett demókból, dokumentációból az szűrhető le, hogy az Android mobilok az iPhone-hoz hasonlítva sem szebbek, sem kényelmesebbek nem lesznek még egy ideig – egyedül arra van remény, hogy okosabbak lesznek. Eszpee gondolata ehhez jó kiegészítés, miszerint “viszont ez a dolog nem (csak) az iPhone szintű okostelefonokról szól“. Avagy az Android a “buta” és az iPhone szintű okostelefonok közötti kategóriában tényleg erőssé vállhat. De nézzük a kétkedés és az ujjongás részleteit is meg:

Az API-t átnézve (főként annak, aki ismeri a J2ME-t) feltűnhet, hogy nem okosabb és részletesebb az Android, mint a már most is használható lehetőségek (J2ME, Symbian). Az Android egyvalamiben látszik ügyesebbnek: lehetővé teszi rendszerközelibb alkalmazások készítését, ami a mobiltelefonnál azt jelenti, hogy például hívások, SMS érkezésének lekezelését is. Ezt leszámítva láttam már hasonló, többet tudó API-kat a Java és nem Java környékén asztali alkalmazások fejlesztésére is, és nem érzem úgy, hogy bármi forradalmi lenne ebben az API-ban. Az okosabb, hasonló jellegű API-k sem csábítottak el igazán.

Java. Ez nekem nagyon sokat mond. Egyrészt, hogy egyelőre még nem sikerült elsajátítanom ezt a nyelvet, így nem tudok hatékonyan fejleszteni benne. Ennek ellenére egyrészt az új Java nyelvi verziókban számos nagyon szimpatikus újdonság jelent meg az olyan script-kiddie (általános értelmezésétől eltekintve itt értsd: script nyelveket kedvelő) számára is, mint én vagyok, illetve lehet, hogy most már ideje lenne ezzel a nyelvvel is foglalkozni egy kicsit. Ezenkívül még nem láttam gyorsan induló Java alkalmazást. Java segítségével lehet gyors alkalmazást írni, de az Java gép beindítása, egy alkalmazás inicialiálása jellemzően még egy 1-2 GHz-es gépen sem mondható gyorsnak, nem tudom, hogy ezt egy kb. 400 MHz-es processzoron hogyan tudja, meg tudja-e valósítani a Google. Az Android ugyanis nem Java alapú operációs rendszerről szól, hanem egy “sima” Linux alapú. A gyors alkalmazásindítás megvalósítható, ahogyan a Java webkiszolgálók esetében is, előre be kell indítani a Java értelmezőből párat. Remélhetőleg ezt, vagy akár valami okosabbat is össze fog tudni hozni a Google. Egy másik lehetőség, hogy a jelenleg propagált Java mellett script, C és C++ fejlesztői eszközök is napvilágot látnak majd, Linux alap révén erre azért komoly esély van.

A jelenleg közzétett interfész elemek szegényesebbek az iPhone-on rendelkezésre állóknál kinézetükben és lehetőségeikben. Az iPhone platform jelenleg zárt, így nem tudok doksira linkelni, az eddig iPod Touch-on látott third-party fejlesztők által készített egységes interfész elemek (például egy nagyon szép progress bar) mondatják ezt velem. Az Apple-nek a fejlesztőket nagyon jól segítő interface guideline-jai (bocs, hirtelen nem találtam jó fordítást) is nagyon sokat jelentenek, látva a Mac-es alkalmazások kiváló használhatóságát a Windows-os és Linuxos társakhoz képest. Mondjuk ez az, ami a jövőben fejlődni fog és tud, egyrészt a Google által, másrészt pedig azért, mert ilyen interfész elemek szabadon készíthetőek lesznek.

És most jutottunk el oda, ami szintén egy aggodalmam a használhatóságot, egyszerű kezelhetőséget, kompatibilitást és egységességet illetően. Az, hogy ez a platform túl nyílt. Láthattuk, hogy ez mit jelent a Linux esetében: rengeteg irányt, több párhuzamos “szabványt” alkalmazásfejlesztésre (mondjuk KDE és Gnome, Gtk és Qt, stb.), “káoszt”. Ez jó, mert sokminden közül választhatsz, rossz, mert nem egységes semmi sem. A Linux hosszú évek után mostanra kezdi kinőni ezt a gyermekbetegségét különböző kezdeményezések által. Erre lehet a válasz, hogy de hisz itt csak egy platform van, de ez a platform nyílt, fiatal, egyelőre hiányoznak elemei, és a különböző fejlesztők ezeket a hiányosságokat különbözőképpen fogják az elején befoltozni, megkerülni. Ez ellen a Google egyféleképpen védekezhet, egy tettrekész, hiperaktív saját fejlesztői gárdával, a jó fejlesztői könyvtárak kiemelésével, a kevésbé jók elsorvasztásával, beolvasztásával, az egységesítéssel, a szigorú gyeplővel a fejlesztők, alkalmazás gyártók felé. Ehhez nagyon-nagyon oda kell tennie magát, ha ez sikerül neki, akkor szinte a lehetetlent fogja véghezvinni.

Szintén kérdéses a hardvergyártók minőségre törekvése is. Az eddigi telefon felhozatalt látva kevesek tudnak igazán minőségit alkotni interfészek terén, és az Andorid csapatban sem az ászok szerepelnek. Attól tartok, hogy az igényességet nem sajátították el a gyártók a csatlakozással. Nem lesznek jobb programozóik, interfész tervezőik, mert például a hiányzó láncszem Nokia ezeket már rég elszipkázta. Hogy a Google delegálni fog-e nekik fejlesztőket (vagy legalább minőségellenőrzést végez-e), egy erős platform tud-e ezen segíteni, nem tudom. De az erős platformot egyelőre még nem látom, és a Google segítsége pedig biztosan pénzbe kerül – erre pedig eddig sem költöttek túl sokat. Azért itt is van remény a fejlődésre, de félek, hogy gagyi saját szoftvereket, kis nüansznyi baromságokból, hardveres inkompatibilitásból adódó problémákból, szoftveres módosításokból összejön majd annyi, hogy kezdetben nem fog sokat érni a platform nyíltsága.

Az egységesség, nyíltság mégvalamit hozhat, a vírusokat. Ezen a téren azonban az Android felkészültnek látszik, bízzunk benne, hogy ez a gyakorlatban is így lesz, és kevés rés lesz a pajzson, a felhasználók pedig tudni fogják, hogy mit csinálnak. Mindazonáltal megvan az esélye, hogy 2008 a mobil vírusok éve lesz.

A vége felé kitérek arra is, hogy a webfejlesztés szempontjából az, hogy a hivatalos böngészőnek a Google a Webkitet választotta, számomra pozitívnak tűnik. Egy fejlett, s bár JavaScriptben még nem, de megjelenítésben nagyon erős, gyorsan fejlődő, nyílt és kellemesen gyors böngészőről van szó. Az Apple sem véletlenül választotta ezt a motort a Safarinak, és nem véletlenül ez fut az iPhone-on sem. Ha a mobil gyártók kijönnek egy az iPhone-hoz hasonlító felbontású kijelzős mobillal, a Google pedig szoftver szinten biztosítja a kompatibilitást (nem túl nehéz), akkor máris futni tudnak az iPhone alkalmazások az Android telefonokon is.

Az Android telefonok hackelhetősége, bővíthetősége még így is várhatóak elég magas lesz. Kérdés, hogy jobb lesz-e a megnyitott iPhone SDK-hoz képest is, az OpenMoko-hoz (Nokia közel van ehhez) hasonlítva? A Google állt oda, így a hype, az erős videós és dokumentációs gyakorlata miatt erre jó esélyt látok, bár pont ezekaz Apple+iPhone-nak is sajátjai. A Google mindazonáltal hatalmas tőkével rendelkezik, és ezt be is veti: 10 millió dollárt szán az induló fejlesztésekre.

Ígéretes, és egyelőre nem tudom hova tenni azt, hogy egészen magas támogatottságú a projekt a Google-n belül is. Mutataja ezt az, hogy Eric Schmidt prezentálta egy hete az Androidot, vagy hogy Sergei Brin (Google alapító atyaúristen) is szerepel a mostani bemutató videókon. Igazából tökmindegy, hogy ezeke az emberek valóban részt vesznek-e az Android marketingjében és fejlesztésében, vagy csak a mostani kezdeti lendületet kívánták-e megadni a projektnek, mert nagyon magas marketing/jelzés értékű ez a tény. Nem véletlen, hogy Steve Jobs prezentál minden újdonságot az Apple-nél, és ennek az Androidnál történő megjelenése sokat érhet a platformnak.

Az Android minden fenti kétkedésem ellenére egy ígéretes indulás, és sokat jelenthet a mobil számítástechnikának. Ahogy az iPhone feladta a leckét és igen magasra tette a lécet az interfész és design terén, addig az Android a nyíltságával határoz meg egy magas szintet. Ez erős versenyt indíthat be, ami a felhasználóknak jól használható telefonokat, a fejlesztőknek pedig egy új, elérhető, könnyen programozható platform megjelenését jelentheti. Még meglátjuk, mi lesz ebből. És megint Kispadot és eszpee-t idézek :) , amivel ő kezdte, én azzal fejezem be: “Ez nagyjából a legnagyobb dolog, ami a mobiliparral mostanában történik“.

Jön a Netvibes Ginger, készülj rá

A Netvibes következő változata várhatóan a hónap végén fog kijönni, és Ginger névre fog hallgatni (a mostani verziót Coriandernek hívják). Számos kisebb-nagyobb újdonsággal készülünk, de az egyik legfontosabb, hogy szocializálódik a Netvibes, vagyis képes lesz az emberi kapcsolatok, ismerősök alkotta hálózat kezelésére, és ebből adódóan egy kicsit közösségi szintérré is válik.

Netvibes Ginger Release

Disclaimer: a Netvibes-nak dolgozom, de ennek ellenére és ezzel együtt, a bejegyzésben leírtak és a bejegyzés illusztrációja is kizárólag csak a személyes véleményemet tükrözi. Egyik információ sem tekinthető hivatalosnak.

Úgy gondolom, hogy a Gingerrel jövő szocializálódás egy természetes folyamat része a webkettes időkben. Hülyén hangozhat, de ahogy az ember is szocializálódott a történelem folyamán, úgy az egyes webszolgáltatásoktól is ezt várják el manapság a felhasználók. A Netvibes ecosystem, és az egyes fülek, widgetek megosztása már eddig is lehetővé tette, hogy egy kedvelt modult, kedvelt összeállítást megosszunk másokkal, az új Netvibes változat pedig az információ szintű megosztást is támogatni fogja.

Netvibes Ginger coming with social possibilities

A Netvibes célja a webes szolgáltatások összegyűjthetősége által egy vezérlőközpont kialakítása, hogy ne kelljen különböző oldalakat meglátogatni a különböző információk összeszedéséhez, a webre viteléhez. A Netvibest feedolvasóként is szokták kategorizálni, de ennél sokkal nagyobb célt tűzött ki: a kulcsszolgáltatások egy helyre gyűjtését widgetek formájában. Az UWA, Universal Widget API segítségével pedig ezek az információmorzsák bárhol (egyre több platformon), bárki számára elérhetőek lehetnek, nem csak konkrétan a Netvibes oldalán. A Netvibes ezen kezdeményezéséhez egyre több tartalomszolgáltató és szolgáltató csatlakozik hivatalosan is, érdemes felkeresni a Netvibes ecosystemet, és körbenézni.

A Netvibes widgetek elérhetőek mobilon (általánosan és iPhone-ra optimalizált verzióban is), az Apple Dashboardján, az iGoogle oldalain, Opera widgetként (Windows, Linux és Mac platformokra), Windows Vista oldalsávban, a Windows Live oldalain, Yahoo! widgetként, illetve szinte az összes böngészőben a Netvibes oldalán (Firefox, Internet Explorer, Opera, Safari), így különböző beágyazott böngészőkben is (mint például a Wii Operájában).

Ha bármilyen widgetet szeretnél fejleszteni, nem érdemes egy konkrét platformra fejleszteni, sokkal inkább érdemes Netvibes UWA segítségével egy halom platformra. És ezt nem azért mondom, mert a Netvibes-nál dolgozom, hanem mert tényleg úgy gondolom, hogy érdemes ezt a megoldást választani. Ha jut rá időm és van rá érdeklődés is, írok majd pár bejegyzést UWA fejlesztés témakörben.

A Netvibesnál egy ideje látjuk, hogy a felhasználóink szeretnék bevonni barátaikat is, megosztani információdarabokat másokkal, és erre a Netvibes szocializálásával (barátok felvételének a lehetősége, megosztások bevonása) is válaszolhattunk volna. Van azonban egy jobb megoldás: ernyőt kínálni a már felépített kapcsolati hálók fölé. Nem átcsábítjuk a felhasználókat, és nálunk építtetjük fel a kapcsolati hálót mégegyszer (bár ez is lehetséges), hanem a már meglévőket engedjük használni a Netvibes-on belül is. Egy ilyen kezdeti lépés volt a Twitter kliens, vagy a Facebook widget, melyek elég nagy sikernek is örvendenek.

A Ginger a “social API”-k, mint például az OpenSocial bevezetésével, és az ezeket közvetlenül nem feltétlenül támogató szolgáltatások integrálásával egy “Netvibes + UWA + social API” háromszöget kialakítva közösségi widgeteket fog bevezetni, melyek mindenhol elérhetőek lesznek. A Ginger a Netvibes közösségi újraértelmezése is lesz, bár nem lesz kötelező használni ezt a lehetőséget.

Tegnap két videót mutatott be (lásd itt és itt) a Netvibes a berlini Web 2.0 expo-n, az egyiken a “barátaim időjárása widget” látható, mely lehetővé teszi saját időjárásunk mellett a barátainknál aktuális időjárás megtekintését is. Amellett, hogy nem feltétlenül ez a legjövőbemutatóbb példa, talán mégis elég jól rámutat arra, hogy érdekes alkalmazásai is lehetnek a közösségivé alakulásnak. Szintén a videókon megtekinthető egy másik lehetőség is, a Netvibes Timeline-ja, azaz a widgetek, érdekességek megosztása barátaink számára egy kicsit FaceBook-os, kicsit twitteres információfolyam formájában.

A fejlesztők várhatóan a hivatalos átállás előtt is kipróbálhatják a Ginger lehetőségeit, érdemes lehet követni a Netvibes hivatalos blogját, illetve a Netvibes fejlesztői blogot.

Android, a Google mobil platformja

A Google sok hónapnyi (évi?) pletyka után bejelentette a várva-várt gPhone-t. Azaz azt nem, csak egy széleskörű mobil platformot. Google Phone várhatóan nem is lesz. A bejelentés szigorúan technikai jellegű, és szigorúan fejlesztőknek szólt. Vagyis egyelőre még nekik sem, majd egy hét múlva.

Google Phone, vagyis az Android

A standardnak szánt mobil fejlesztői platform neve Android lett a keresztségben, és egyelőre viszonylag keveset lehet róla tudni (szerintem ugyanazt a hibát követi el a Google, mint az OpenSocial esetén – nem mondott el semmit sem, csak egy szép ködünk van).  Amit sikerült összeszednem, az a következő:

  • Nagynak mondható nevek érdeklődnek, például T-Mobile, HTC,  Motorola (a sajtókonferenciát a cégek vezetői is megjelentek) – összesen 34 cég, köztük nem csak fejlesztőcégek, hanem mobilszolgáltatók is
  • Linux oprendszer képezi a platform alapját
  • Egy “nagyon robosztus” böngésző is helyet kap a csomagban
  • Megkerülték a választ, hogy okostelefon lesz-e a célhardver
  • Minimum hardverigénynek 200MHz-es ARM9 processzort jelöltek meg
  • Nagyon nyílt platformnak szánják
  • Elképesztő interfésze lesz neki

A célhardverek tekintetében változatosságot mondtak, alapvetően egy oprendszer + kódkönyvtár kombóról van szó, a fentiek szerint egy erős böngészővel, és egy szép felhasználói interfésszel megtámogatva. Ez így nem sok, az SDK-t magát jövő hét hétfőre ígérik. Én egy ügyes kódkönyvtárat várok, amiben a szinkronizálástól kezdve az interfész alapokig mindenre gondoltak.

Az Apple iPhone-ja sokmindenben közös ezzel a platformmal. Linux-szerű BSD nyújtja az alapot, egy nagyon szuper böngészőt faragtak a Safari-ból, 400 MHz-es processzora van. A platform maga nem szupernyílt, de jövő februártól lesz SDK, továbbá BSD lévén Perl-től, PHP-ig lehet rá fejleszteni, s ha valamiben nem lehetne, majd lehet. Mindenképpen verseny lesz a két platform között, ha máshol nem, hát a sajtóban.

A nyíltság nem tudom, hogy előny-e, vagy pedig hátrány? Az iPhone esetében én úgy érzem (a jövő februári, általam elképzelt helyzetről beszélek), hogy előny, hogy részben zárt a platformja, mivel így az Apple minőségbiztosíthatja az egész telefont az utolsó csavarig. Persze az, hogy sima USB háttértárként nem használható, és még pár egyéb dolog, az mindenképp azt mondatja, jobb lenne a nyíltság. Mindazonáltal mind a két platformra lehet majd fejleszteni, mind a kettőre fognak is, és valószínűleg a fejlesztőeszközök egyszerűsége, és a platformok elterjedtsége meggyőző lesz. Az iPhone egyszerűbb lesz fejleszteni az egységes kijelzőméret és egyéb ismert, kötött paraméterek miatt, az Androidra pedig a várhatóan olcsóbb telefonok és a nagyobb elterjedtség miat (bár az még odébb van, egyelőre sehol sincsenek az Androidos telefonok, és kétlem, hogy akkor hype-ot tudnak majd csapni, mint amit az Apple).

Az Apple (és az iPhone fejlesztők) helyében én portolnám szépen a gPhone könyvtárak előnyös részeit az iPhone-ra, és kihasználnám az egyébként elég nagy helyzetelőnyt. Egyébként a kikacsintás megvan, a fentebb belinkelt sajtótájékoztatón is felmerült, hogy a Google vezető Eric Schmidt lelkes iPhone felhasználó, és az Apple igazgatótanácsának is tagja.

A hiányos információk ellenére pár dolog majdnem biztos. A mobil piacon nagy verseny lesz, melyet az iPhone indított be, az Android pedig fokozni fogja. A hagyományos piaci szereplők (pl. Nokia), akik nem csatlakoznak az Androidhoz (ezt persze korai így kijelenteni), szintén kénytelenek lesznek okos, szép, könnyen a használható telefonokat a piacra dobni (a Nokia eddig nem volt rossz, de kőkorszak az iPhone-hoz képest, és nem csak annak csillogó felülete miatt). Nem beszélve arról, hogy várhatóan az Android olyan nyílt újdonságokat fog behozni, mint a “szabványos” szinkronizálás, felhasználói adattárolás és egyebek, melyekre asztali és szerver szoftverek ezrei építhetnek majd.  Ez jó lesz, de addig csóválom a fejem, hogy mi a fenéért nem tudott a Google közzétenni egy screenshot tervet, vagy bármit, amivel a hype-ot egy kicsit növelte volna? És bennem van a kisördög, bennem van a kétkedés, hogy mindez egy szép álom, túl szép ahhoz, hogy igaz legyen. Remélem, jövő héten nem jön ki valami gagyival a Google.

Mi is az az OpenSocial?

A Google a mai napon tette közzé OpenSocial platformjánal részleteit, mely a szociális hálózatok egységesítésére törekszik, s melyet valójában versenytársai – főként a FaceBook) – elleni lépésként értékel a média. Már most szép tömeg áll a kezdeményezés mögött, azonban csak lassan derül ki, hogy miről is van szó.

OpenSocial vs. UWA

Disclaimer: a Netvibes-nak dolgozom, mely valamilyen módon mindenképp érintett a történetben. Ennek ellenére és ezzel együtt, a következőkben leírtak és a bejegyzés illusztrációja is kizárólag csak a személyes véleményemet tükrözi.

Kezdjük azzal, hogy a Google a napokban bejelentette, hogy egy OpenSocial nevű platformot hoz létre jópár másik céggel karöltve. Ha megnézzük a listát, akkor láthatjuk hogy a piac szép nagy részét le is fedi a társaság. Az elemzők ezt egyből egy FaceBook elleni támadásnak értelmezték, ami azért is érdekes, mert nemrégiben versengett és vesztett a Google a Microsoft ellen a FaceBook egy kis részének megvásárlásáért. Az egész a Google reklámainak célbajuttatásáról is szól, szólhat, de a képlet nem biztos, hogy ilyen egyszerű.

A mai specifikációk közzétételével két dolog vált egyértelművé. Egyrészt a platform egy közös interfészt specifikál, melyen keresztül elérhető egy adott platform adott felhasználójának kapcsolati hálója, másrészt hogy mindezt a Google a saját iGoogle gadget platformjára építve képzeli el. A partnerek között ott a Netvibes is, az UWA lehetőségével, melynek egyik megcélzott platformja az iGoogle vagyis a Google widget – ezen platform alapja -, de ezen kívül még számos más felület, mint az Apple Dashboard, iPod Touch/iPhone, Opera widgetek, a Vista Sidebar widgetjei, a Windows Live és a Yahoo! Widgets is (nem beszélve azokról, melyek folyamatban vannak). A kettőt összekapcsolva igen érdekes lehetőségek merülhetnek fel bennünk – amennyiben az adott platformok lehetővé teszik, összeköthetőek lesz a különböző helyeken tárolt kapcsolati hálónk. Például – hogy egy vicceset mondjak – ha az iPhone-nal az Apple és az iWiW is csatlakozik az OpenSocial-hoz, akkor valóban telefonkönyvként is használható lesz az iWiW. Hozzáteszem, egyelőre azt látom, hogy az egyes platformok widgetjei maximum egy közös adatbázist használva tudnak kommunikálni egymással, azaz valószínűleg az iPhone-ról egy iWiW felhasználó adatai közvetlenül nem elérhetőek. Ez még mindenképpen további tisztázást igényel, ha valaki beleásta magát a dologba, szóljon hozzá bátran.

Sokkal konkrétabban, az egyes platformokon futó widgetek a következőkhöz férnek hozzá:

  • Felhasználói adatok, azaz az adott widget tulajának (aki ajánlotta a widgetet, akinél megnézzük azt), nézőjének (azaz az aktuális felhasználónak aki be van jelentkezve) és barátjaiknak listája
  • Adattárolási lehetőség, vagyis az adott alkalmazás adatainak tárolása konkrét felhasználóhoz, adott widget egyedhez, vagy globálisan a widgethez
  • Tevékenység napló, vagyis hogy ki mit csinált (hozzáadott, elvett, telepített, stb.) – mint a FaceBook, LinkedIn vagy hasonló oldalak naplója

Ez persze egy kicsit ijesztően is hathat, a kérdés abban rejlik, hogy melyik alkalmazás pontosan mihez és milyen körülmények között fog hozzáférni, bár ezek úgy tűnik, normálisan le vannak szabályozva. Nem igazán tiszta számomra, hogy mit jelent a “globálisan” adott widgethez történő letárolás, illetve az egy nagyon fontos kérdés – és egyáltalán nincsen tisztázva, hogy mi van akkor, ha az adott widgetet valaki mondjuk Orkutra és LinkedIn-re is telepíti. Egyrészt hogyan fogja a widget lekezelni a két platform ugyanazon felhasználójának azonosságát, másrészt pedig hogyan fog egyik platformról a másikra “terjedni” egy widget.

Az eddigi specifikációk, példák meglehetősen összecsapottnak tűntek számomra mikor átolvastam azokat, és nagyon sok kérdést hagynak nyitva. A specifikáció egyáltalán nem rögzíti a platformok közötti kapcsolati háló átjárhatóságát, csak azt teszi lehetővé, hogy ugyanazon widgetet több platformon is tudjunk használni, és az egyes platformokon ugyanúgy férjünk hozzá a kapcsolati adatokhoz.

A kapcsolati hálóhoz történő hozzáférés standardizálását jó ötletnek tartom, a Google Gadget platform nyomatását nem – vannak hülyeségei és elég limitált is összevetve az Netvibes UWA lehetőségeivel.

A Google egy általános felületet definiálásával ugyan saját szabványát nyomatja, de nem látom ennek veszélyességét a FaceBook-ra nézve. Ha a FaceBook csatlakozna az OpenSocialhoz, nem vesztené el semmi felett sem az irányítást, maximum – persze ez is igen fontos – a platform lehetőségeinek meghatározásába nem szólhatna annyira bele, mint most saját lehetőségeivel. Mivel az interfész nyílt, ezért a legjobb a FaceBook-nak talán az lehet, hogy vár egy kicsit a bejelentésével, miszerint támogatja-e a platformot vagy nem. Érdemes megnézni, hogy mit fog ebből konkrétan kihozni a Google, ha a jelenlegi változatnál nem akar többet, akkor az csalódás, viszont a FaceBook által minden további nélkül követhető. Ha többet szeretne, s motorja szeretne lenni az adatok áramlásának (és erre megvan a jel az adattárolás konkrét megvalósítását illetően), akkor veszélyes lehet. Tegyük hozzá: a felhasználói adatokra, és nem csak a FaceBook-ra nézve – mivel akinél az adatok vannak, az mindennek az ura és parancsolója a jövőbeni webhármas világban.