szantog.com - Web

Egy alternatív mobilos megoldás

Mon, 10 May 2010 02:00:00 +0200

Vége a szép időknek, amikor egy weboldalt elég volt 1024x768-ra tervezni, ma már érzékelhető forgalom érkezik mobil eszközökről. Erre az első válasz a mobil változatok megjelenése volt, de ez szerintem nem elég, nem így kellene. A Media2Radio-val már két hónapja kísérletezünk egy másik megközelítéssel.

A következő problémáim vannak a "klasszikus" mobil változatokkal:

A fenntartása drágább, hiszen minden front-end dologból új kell neki (HTML, CSS, interfész-tervezés), duplán dolgozunk.
A duplán dolgozást sokszor elfelejtik, a mobilos változat "mostohagyerek", nem követi a desktop változat változásait. Előfordul, hogy rosszul működik, régen jó volt, de valami kimenet megváltozott a desktop miatt, így hibával száll el.
Eszközspecifikus mobil változatok, például iPhone skin: a többi mobilon nem biztos, hogy jó ez, csak egyfajta mobilra készülünk? Ne már! (Pedig iPhone-buzi vagyok.)
Macerás többféle eszközre tervezni, márpedig ezekből egyre többféle van. Egy oldalnak ma már egészen hihetetlen felbontásokban is kell menni, a mindenféle kézi-kütyük pedig összevissza méretekben érkeznek, ráadásul forgathatók. Ez egyre "rosszabb" lesz.
A mobilos (handheld) stylesheet nem igazán működik, egyre több mobil böngészője hazudja magát desktop-nak. Olvasd el az A List Apart vonatkozó cikkét, tragikusan kaotikus a dolog, a cikkben lévő megoldási javaslat bonyolult, nehezen tartható karban.

A Media2Radio-nál kísérletezett megoldásról

A Media2Radio egy "klasszikus" elrendezésű weboldal, ezekből a részekből áll: fő tartalom, kiegészítő tartalom, navigáció, fejléc és lábléc. A fő és kiegészítő tartalom alkotja az oldal "törzsét", két oszlopban. A kiegészítő tartalomban vannak a keresztbeajánlások és egyéb kevésbé fontos "bizbaszok", a fejléc szerepe leginkább az, hogy szép legyen, a lábléc pedig azért van, hogy "ne lógjon az oldal a levegőben", és oda tettünk néhány kevésbe fontos navigációs elemet is.

Első lépésként érdemes a fentiek szerint felosztani a tartalmat, mert egyből nyilvánvalóvá válik, hogy mit kell a mobilos részből kidobni: a kiegészítő részt és a fejlécet. A mobilos megjelenés a navigációval kezd, ami lehetőleg csak néhány pontból álljon, senki nem fog 6-7 elemnél több lehetőségben böngészgetni, nem kényelmes. A tartalmi részben minden rugalmas szélességű legyen, így jól fog megjelenni a desktop változat kb. 500 pixel szélességű dobozában és egy mobil képernyőjén is. A mobilos megjelenés végén ismét a lábléc érkezik, a kevésbé fontos linkekkel.

Csak egyféle CSS-t készítettünk, nincs handheld és @media, meg egyebek. A lehető legtöbb elem mérete em-ekkel lett megvalósítva, hogy mindenhol rugalmasan jó legyen. És most a legfontosabb:

Mindenhol a mobilos változat az első, a CSS és a HTML kimenet is így lett megírva, csak akkor érkeznek a desktop elemek, ha a képernyő szélessége elég nagy.

Minden munkamenet elején megnézzük JavaScript-tel a screen.width tulajdonságot, ez szerencsére minden böngészőben elérhető és jól működik. Ha nagyobb 800-nál, akkor jelenítjük meg (szintén JavaScript-tel) a többi tartalmat. Ezeket nem húzzuk be mondjuk egy AJAX kéréssel, hanem ott van már a JavaScript kódban sima változóban tárolt HTML kódként, hogy gyors legyen. Amúgy is csak néhány kByte.

Mi van, ha nincs JavaScript? No problem, akkor csak a mobilos változat látszik, attól még használhatók maradunk.

A CSS kód nem változik, mindössze a body tag kap egy 'bigscreen' class-t. A CSS úgy van megírva, hogy a végén található néhány sornyi body.bigscreen kivétel, így lesz a mobilos CSS-ből desktop. Bumm.

Egyéb apróságok, in no particular order

A margók mindenhol meg lettek növelve, szép nagy white-space-ek vannak mindenhol azért, hogy tapiképernyőn is könnyen lehessen a bumfordi ujjakkal nyomkodni.

Az űrlapokat lerövidítettük, csak a legszükségesebb mezőket tartalmazzák, mert mobilon nehézkes a kitöltés, és desktop-on is lusta mindenki. 2010-ben már pláne nem szabad olyan modellekben gondolkodni, ami sok mezőn alapul.

Csak egeres dolgoknál van mouse over, mindennek működnie kell anélkül is, maximum nem lesz olyan szép.

Ha embed-delünk valami objektumot (hogy legyen zoxigén), akkor tegyük alá/mellé a tartalomra mutató direkt linket is, mert ahány mobil eszköz, annyiféle képpen eszi az ilyesmit. Példa: egy YouTube videónál az embed kód alá kerüljön a videó saját oldalára mutató link, hogy azok az eszközök, amik nem jelenítenek meg ilyesmit, el tudják indítani a saját YouTube appjukat, ha van nekik olyan.

Másik példa: az mp3-akat Flash lejátszókban mutatjuk, de adunk direkt mp3 linket is, ha nincs a gépen Flash (és nem, a HTML5 audio player-ek sem működnek minden mobilos eszközön!). A noembed és egyéb alternatív tartalom csacsiságok sajnos nem működnek minden mobilos böngészővel, ezért kell ez a fapados megoldás.

Képek

Érthető, hogy minél kisebb letöltési méret kell, de sokan nem gondolnak a memóriaigényre.

A mobilos böngészők általában nagyon kevés RAM-ot használhatnak (a desktop-hoz képest), és hiába a kis letöltési méret (mondjuk 3 kB), a képek általában a felbontásuknak megfelelő szeletet hasítják ki a memóriából, pl. egy 100x100-as 4 csatornás PNG rögtön 40 kB-ot. Ha ezekből több van, akkor pillanatok alatt el lehet érni a több mB méretet, a böngésző pedig elszáll. Hányszor dobott ki a mobilos böngésződ emiatt, ugyeugye?

Miért jó ez nekünk?

Biztos van még valami, amit kifelejtettem, de a lényeget olvashattátok. A végére itt a slusszpoén, hogy miért érte meg ezt az egészet csinálni azon kívül, hogy többféle eszközön is kábé használhatók maradunk: állandó, tartós növekedést eredményezett a látogatásokban (17%), az oldalon eltöltött idő pedig 23%-kal nőtt.

Videós apró

Wed, 09 Dec 2009 01:00:00 +0100

Pre-roll reklámok, embed nézettség, csillagozás.

A pre-roll reklámok végignézése 70%, azaz elvileg 30% nézőt veszít egy oldal a pre-roll-okkal. Ez azért fontos, mert jelenleg a pre-roll a leginkább eladható videós reklámozási forma. Ebben persze a véletlen odakattintások is benne vannak, tippem szerint a tényleges veszteség úgy 20%.

A YouTube éppen ezért (is) átugorható pre-roll videókkal kísérletezik, nemcsak azért, hogy jobb legyen a nézettség, hanem a reklámozók felé is visszajelzést tud küldeni: a minél jobb egy reklám, annál kevésbé ugranak át rajta logika mentén.

Fontos az embed

A YouTube globális videónézettségi részesedése 60%, de az embed piacon 82. Vimeo 8.8%-kal, DailyMotion 4%, MySpace 1.1%, Google Video 1%, a többiek pedig mind-mind alattuk vannak. Ebből szerintem az következik, hogy a tartalom átlagos minősége/eredetisége a YouTube-on és a Vimeo-n a legjobb.

Nem jó a csillagozás

Szintén YouTube hír, hogy fontolgatják az ötcsillagos felhasználói minősítések megszüntetését, mert nagyon torz:

Legjobb minősítést hatszor többször adnak, mint a többit összesen.
Csillagozni általában egy jól körülírható "véleményvezér" felhasználói csoport szokott és ez nagyon nem reprezentatív (kevesen vannak).

Úgy tűnik, hogy inkább a végignézést fogják mérvadónak tekinteni ("hányan meddig nézték a melyik részét a videónak").

Amazon MySQL

Sat, 31 Oct 2009 01:00:00 +0100

Pontosabban Relational Database Service (RDS), ami egy speciális EC2 példány, ami csak MySQL-t futtat. Érdekes, de nem tudom még hova tenni.

Az Amazon dolgok bonyolultabbak, mint egy hagyományosabb szolgáltatónál hostolni, ezért nem értem ennek a helyét. Persze könnyebb vele egy MySQL-t megvalósítani, de úgyis kell egy ügyes rendszergazda az Amazon-os cuccokhoz, akinek egy ilyen MySQL összeállítása biztosan nem ügy.

Ráadásul a saját megvalósításban totális kontrol van, az RDS-nél nincs saját patch, parancssori és SSH elérés, replikáció. Akkor lesz majd valóban használható, ha megoldják a replikációt is (ígérik), akkor már tényleg sok terhet vesz le a rendszergazda válláról (aki így kénytelen lesz olcsóbb lenni). Viszont drágább, mint a már jelenleg is elérhető third-party, teljes körű Amazon-os MySQL megoldások, például a RightScale-féle.

A futtatása kb. 30%-kal kerül többe, mint a vele egyenlő teljesítményű EC2 példányé. Az ár teljesítményfüggő és a fix díjon felül az I/O kérésekért és a sávszélért kell fizetni. Nem kell megijedni, a régión belüli sávszél ingyenes, a webszerver meg úgyis ott van. Már a legkisebbbet is 1.7 GB RAM-mal adják, ez jó, mert tudjuk, hogy a MySQL akkor gyors, ha az adatbázis befér a memóriába.

A jelenleg elérhető MySQL verzió 5.1.38 és folyamatosan frissítik/patchelik. Nagyon jó, hogy az árban már benne van az automatikus backup (teljes méretű), lehet nightly és snapshot is. Az adatbázis egy EBS (hálózati) lemezen van, így ha onnan kell olvasni, akkor nyilván lassú: be kell férni a RAM-ba, nincs mese. Csak InnoDB és MyISAM van, de az szerintem bőven elég.

Különleges lehetőség, hogy valamennyi díjért (nincs fent, call us!) szinkronban tartanak egy másik farmon lévő replikát is biztonsági célból. Egyébként kaptunk még 15%-os EC2 árcsökkentést is, de így lassan 2010 táján már kevésnek/drágának érzem a benne foglalt CPU erőket.

Az RDS egyelőre csak az USA-ban érhető el, EU majd később. That's all folks. Használjatok Slicehost-ot, az a legtöbb magyar projektre bőven elég.

Ott lesz a Flash minden okostelefonon

Tue, 06 Oct 2009 02:00:00 +0200

Épp zajlik a MAX, az Adobe fejlesztői konferenciája, ami olyan, mint az Apple WWDC, csak kevésbé hájpolt. A tegnap folyamán izgalmas bejelentéseket hallhattunk, mert 2010 első félévében kijön a Flash 10.1, ami ott lesz a legfontosabb okosteló platformokon és egy ügyes húzással úgy-ahogy az iPhone-on is.

A Flash 10.1-gyel vége a Flash Lite-nak, a mobilok teljesértékű Flash-t kapnak a böngészőjükbe, úgy, mint az asztalon. Állítólag rengeteg optimalizációt tartalmaz azért, hogy a mobilokon is jó legyen a teljesítmény és ne egye az akksit, ráadásul ezek (állítólag) az asztalon is vissza fognak köszönni, így (állítólag, talán) a Flash még jobban fog futni. Persze eddig is jobbára a fejlesztőkön múlt, hogy a Flash mennyi erőforrást zabált, alapjában véve a Flash ma is gyorsabb, mint bármelyik böngészős JavaScript megvalósítás. Tehát kevesebb CPU, kisebb memóriaigény, és a Flash 10.1 már nem asztali player, hanem cross-platform.

Végre rendesen használni fogja a futtató eszköz hardveres gyorsítási képességeit, nem fog egy H.264-es videót szoftveresen kikódolni például és a GPU-t is kapásból igénybe veszi (asszem OpenGL-lel).

Kapunk HTTP Streaming támogatást, az FMS egyre kevésbé vonzó. Nem kell majd pseudo-streaming-gel szórakozni (bár ez végülis az...) és adaptív bitrátával adhatunk sima HTTP szerverrel. Az FMS-t persze nem hagyta el az Adobe, az RTMFP protokollal P2P területen erősíti a terméket, úgy tűnik jön a P2P live adás lehetősége (a jelenlegi P2P szinte csak chat-hez jó néhány résztvevővel).

A Flash 10.1 a mobilos dolgok miatt alapból támogatja a többujjazást (multitouch), a giroszkópot (accelerometer) és a képernyőforgatást. A Flash 10.1 simán a böngészőben fog futni a következő platformokon: Windows Mobile, Palm webOS, Android, Nokia Symbian. Itt van például ez a videó, ahol egy Palm Pré-n megy a Flash egész jól, beszarás:

Az iPhone bizony szenvedni fog a böngészőben lévő Flash hiányától.

Lesz még PCM (ha nem tudod mi az: wav) audió adathozzáférés, automatikus mp3 kikódolással, és ugyanez a mikrofonra is, pl. Flash-sel elemezheted a mikrofonból jövő jelet vagy egy mp3 fájl tartalmát.

iPhone

Az Adobe ügyesen kerülte meg az Apple-t és megoldotta, hogy Flash CS5-tel natív App Store-os alkalmazásokat készíthessenek a Flash-es fejlesztők. Tehát semmi köze a böngészőhöz, ezek natív appok kéremszépen.

Csak néhány iPhone API lesz elérhető: multitouch, képernyőforgatás, photo library-be mentés, giroszkóp (accelerometer), geolocation, kopipészt. Nem lehet majd HTML tartalmat embeddelni, az RTMP kódolt változatával streamelni (RTMPE), a H.264-et pedig a beépített QuickTime játsza le - külön indít egyet, az alkalmazásodban nem lehet. ActionScript-et sem lehet embeddelni, mert nem fut majd semmilyen ActionScript értelmező, minden natív iPhone: SWF-et behúzhatsz skinezéshez, de benne kódot már nem.

Csak tisztán Flash-ben ajánlják a fejlesztést, mert a Flex által gyártott kód túl terjengős és lassú ahhoz, hogy iPhone-on fusson, bár lehetséges. A CS5 olyan kódot készít, amit be lehet tolni az XCode-ba, az szépen összerakja és a továbbiak a már ismert iPhone SDK-s módon mennek majd. Tesztelni csak készüléken lehet, az iPhone szimulátorban nem: feltételezhetően a CS5 ARM-os bájtkódot gyárt, amit statikusan linkel be az app. Az egyik Flash-es azt nyilatkozta, hogy könnyű volt jó teljesítményű kódot gyártani, mert sok tapasztalatuk van az ARM-os dolgokról (lásd Flash Lite).

Az a legérdekesebb, hogy néhány szerencsés fejlesztő az alfaváltozattal készített már olyan iPhone-os alkalmazásokat, amik bent vannak az App Store-ban. Szerintem az App Review Team nem is vette észre, hogy mivel készültek. A publikus CS5 béta december környékére várható.

Konklúzió

A HTML5-tel a Flash videóplatform-os jövője inogni látszik, de ezzel a mobilos húzással ismét megkerülhetetlennek tűnik a Flash. Nincs még egy olyan mobilos fejlesztőeszköz, ami egyszerre ennyi platformot fed le jó teljesítménnyel (a Java ehhez képest vicc). Bizonyára sok Flash fejlesztő kezd el most kisebb képernyőkben gondolkodni.

Habár nyilván eltér majd a megvalósítás itt-ott és foglakozni kell az egyes platformok sajátosságaival is, de mégiscsak olcsóbb lesz fejleszteni mobilra: a mobilos alkalmazások többségét Flash-ben is létre lehet hozni majd, a platformokra készített eredeti fejlesztőeszközöket pedig csak speciálisabb esetekben lesz érdemes használni.

Hiába volt eddig is rengeteg mobilos app, úgy tűnik jövőre jön a lavina.

(Web)videós történések a nyáron

Thu, 24 Sep 2009 02:00:00 +0200

Az év első felében úgy tűnt, hogy a H.264 lesz a befutó kvázi-szabvány a weben: kiforrt a Flash/Silverlight támogatás, ez lett az iPhone egyetlen használható formátuma, egyre-másra jelentették be a nagy médiaszerver fejlesztők a H.264 képességeket (pl. Microsoft, Adobe FMS, Wowza), élőzésre is. De jön a HTML5 és a Google megvette az On2-t.

Ma az egyetlen épkézláb (széleskörben elérhető és támogatott) webes videólejátszó platform a Flash. A Silverlight műszakilag már elég jó, de nem terjedt el, jogi okok miatt nem tolhatja be a Microsoft automatikus frissítésként (biztos sóhajtoznak miatta épp eleget).

Flash Access 2.0

A Flash mostanában látszik behozni a Silverlight egyetlen jelentősebb előnyét, a DRM képességet (igen, fúj, de sok tartalomszolgáltatónak kell, neked meg a pénzük, nem?). Eddig volt a Flash Media Rights Management Server, amivel csak AIR-hez lehetett DRM-es videókat tolni, most viszont sokkal barátságosabb nevet kapott (Flash Access 2.0) és működik a sima player-rel is. Sőt, a DRM megy a sima progresszív download-ra, nem kell hozzá feltétlen FMS. Persze ez még csak a jövő, 2010 első félév.

HTTP video streaming...

... azaz sima progresszív download. Ez a menő, nem a médiaszerver, hiszen nem kell hozzá "semmi". Az Apple a 3.0-s iPhone szoftverrel egyidőben mutatta meg, hogy lehet rajta mit fejleszteni: az új Quicktime (desktopon, iPhone-on és az iPhone Safari böngészőjében is!) tudja az adaptív bitrátát http letöltéssel, azaz dinamikusan állítja a képminőséget a felhasználó sávszélességéhez. Live stream is lehetséges.

Az adaptív bitráta egyébként úgy működik, hogy egyszerre több változatba kódolják a videót, aztán bizonyos időközönként megnézi a szerver vagy a player, hogy épp mennyi sávszéle van a felhasználónak és aszerint szolgálja/kéri a megfelelőt/legközelebbit. Az Apple megoldásában ezt tisztán a player tudja, de amíg a többiek a médiaszerverükkel kb. 2 másodperces időközönként vizsgálnak, addig a http-vel azért nem érdemes ilyen gyakran.

On2

A VP6 volt sokáig a Flash platform egyetlen jó minőségű videokodekje, az On2-tól licencelte az Adobe. A VP6-ba kódolás költséges volt, az On2 drágán adta hozzá az eszközöket, ezért tűnt jó ötletnek a H.264, hiszen az halvánnyal jobb minőséget adott és ingyenes eszközökkel (FFMPEG) is előállítható. Igenám, csak sokan megnézték az apróbetűt: a H.264 felhasználása sok esetben pénzes dolog.

A Google-nak érthető módon fontos a webes videó, így nem csoda, hogy vettek maguknak egy "formátumot", amivel jó minőségben lehet tolni a tartalmakat és nincsenek járulékos költségek - kérdés, hogy hogyan arányul ez a 106.5 millió USD vételárhoz (állítólag igen rosszul).

Az On2-val jön még a VP7 és VP8 kodek is: állítólag a VP8 jobb minden jelenlegi vetélytárs kodeknél, de igazából senki sem látta, hiába jelentették be 2008 végén. Ezzel a fegyvertárral a Google jó eséllyel indul a webes videószabványért folytatott harcban, mely a HTML5-tel kap új erőre.

HTML5

Az új HTML szabvány egyik újítása a beépített video és audio tag, így nem kell mondjuk Flash-be bújtatni a videót, hanem ugyanúgy kezelhető, mint egy sima kép, illetve JavaScript-ből közvetlenül buzerálható. Az Adobe Flash platform lényege, fejőstehene pedig a videó lenne, pont ennek megy neki.

Jópár videós oldalnak van már kísérleti HTML5 verziója, a YouTube-nak is. A "natív" videókezelés jót tesz a fejlesztőknek, egyszerűbb és átláthatóbb lesz a kód (nem kell külön platformon fejleszteni) és nem kell ki-be ugrálni a Flash meg a JavaScript között. A reklámozóknak is jó, mert:

Jó minőségű bannert (pl. ami nem tekeri a CPU-t) gyártani/megfizetni továbbra sem hajlandók.
Flashben nincs széleskörűen elfogadott/használt/egységes reklámbeépítési lehetőség, a rossz minőségű bannerek pedig az egész Flash-es videólejátszót belassítják, tönkreteszik a felhasználói élményt.
Nincs széleskörűen elfogadott/használt/egységes Flash videólejátszó.
A fentiekre tett erőfeszítések rendre elbuknak (pl. Open Video Player Initiative).

HTML5 kodek?

Ez eddig szép is lenne, csakhogy a HTML5 nem szabja meg, hogy a böngészőknek a video tag "alatt" milyen videóformátumokat kellene elfogadniuk, nem mondja meg, hogy akkor mostantól minden legyen H.264 vagy akármi.

Eredetileg az Ogg/Theora volt a célpont, de az ellenérdekelt felek a saját favoritjukat tolják: a Mozilla az Ogg/Theora-t, az Apple Quicktime-ozik (azon belül inkább H.264), a Google most talán VP-zni fog, a Microsoft pedig nyilván WMV. Ezek közül egyelőre csak az Ogg/Theora open source, de a többihez képest sajnos gyengébb a képminősége és természetesen mindenki a sajátját szeretné a HTML5-ben alapértelmezettként látni. Az álláspontok:

Az Apple nem szeretné az Ogg/Theorát szerzői jogi problémák és a hardweres támogatás hiánya miatt (tehát kamuznak, mint mindig).
A Google betette az Ogg/Theora és a H.264 támogatást is a Chrome-ba, de egyrészt valószínűleg VP-zni fog, másrészt szerintük az Ogg/Theora "minőség per bit mutatója nem elég jó a YouTube forgalmához". Ez igaz, több sávszél kellene ugyanolyan minőséghez, ami YouTube méretekben túl drága.
Az Opera és a Mozilla nem építi be a H.264-et, mert sokba kerül a licenc és ők kicsik - érthető álláspont.
A Microsoft csak most augusztustól szállt be publikusan a buliba (5 év után...), még nincs véleményük. Egyelőre csak annyit mondtak, hogy támogatják a video tag-et.

Talán a Google-nál a labda

A webes videóipar több, mint fele maga a YouTube, tök mindegy, hogy a videók számát vagy a nézett perceket vizsgáljuk. A Google döntése a YouTube jövőbeli formátumának irányában valószínűleg meghatározó lesz. A VP6 végülis jó választás:

Jó minőségű.
Ha a böngésző nem támogatja HTML5/natív módban, akkor Flash-sel még mindig lejátszható.
Ingyér van a Google-nek most már.

Ehhez viszont az is kellene és suttogják (remélik?), hogy szabaddá teszik a formátumot, hadd kódoljon mindenki VP6-ba ingyen, az FFMPEG például tudná már most is. Szerintem akkor jönne el a paradicsom, ha bilibe lóg a kezem:

Legyen a VPV8 teljesen ingyenes és open.
Legyen a VP8 a HTML5 default.
Lehessen FFMPEG-gel VP8-at készíteni.
Ha mégsem, akkor H.264, de csak akkor, ha az is ingyenes lesz.
Tudja minden böngésző az adaptív bitrátájú http streaming-et (és a kodek is legyen jó hozzá).

Konklúzió

Jövőre még biztos Flash-ezni fogunk, távolabbra pedig nem merészkednék, hiszen egy év óriási idő ezen a területen. Remélem el fog dőlni a formátumháború és nem lesz patthelyzet, mert az a legrosszabb: minden böngészőhöz külön kódolni? Neeee, akkor marad a Flash.

AWS Import/Export for Physical Data Transfer

Thu, 18 Jun 2009 02:00:00 +0200

Ez egy nagyon aranyos Amazon-os szolgáltatás. Lehet, hogy máshol is van hasonló, de ilyen nagyban még nem láttam. Arról van szó, hogyha rettentő sok adatot kell feltenni a szerverre, akkor lehetséges, hogy a leggyorsabb megoldás nem a neten keresztüli feltöltés, hanem vinyóról közvetlenül kéne.

Felteszed az adataid egy HDD-re vagy akár egy komplett rack-be szerelt storage megoldásra (max. 22 kiló lehet).
E-mailben elküldöd az utasításaidat és azonosítóidat egy YAML formátumú text fájlban. Mit hova tegyenek, hogyan, satöbbi.
Megcsinálod a szükséges autentikációt (digit aláírás és társai).
Elpostázod a cuccost az Amazon-nak.
Megcsinálják amit kérsz és visszapostázzák az eszközt. A belső Amazon-os hálózaton töltenek fel, ami sokkal gyorsabb az internetsnél.

80 USD egy ügy, plusz 2.49 USD egy "feltöltő-óra". Elsősorban terabájtok feltöltésére van, nem néhány giga backup megoldására. Jópofa, nemdeugyebár?

Automatikus skálázódás az Amazon EC2-n

Mon, 01 Jun 2009 02:00:00 +0200

Nagyon jelentős változás, hogy az EC2 már nem "buta", tud skálázódni, monitorozható és kapott terheléselosztást is. Bár ezek a képességek szép neveket kaptak (CloudWatch, Elastic Load Balancing, Auto Scaling), gyakorlatilag API kiegészítésekről van szó, nem grafikus felhasználói felülettel rendelkező szolgáltatásokról.

Ezek a kiegészítések a már ismert Amazon-os szokás szerint mennek (autentikáció, Query vagy SOAP API), jól illeszkednek az eddigiekbe.

CloudWatch

A legfontosabb elem a CloudWatch, azaz a monitoring, erre épül a többi, ez szolgáltatja a működéshez szükséges adatokat. A legkisebb monitorozási időegység 1 perc, ennél rövidebb izéket nem tud mérni, de általában nincs is rá szükség. Ezeket lehet mérni szerverenként:

CPU használat (százalék)
hálózati forgalom (összes interfész) kifelé, befelé (bájt)
háttértár használat (operation, bájt) írás/olvasás

A következők pedig csak a terheléselosztáshoz (Elastic Load Balancing) figyelhetők:

latency (kérések és válaszok közötti idő, ahogy a load balancer látja)
kérések száma per másodperc
"egészséges" és "beteg" szerverek száma (értsd: hány bírja és hány van leterhelve)

Mivel a CloudWatch időszakot mér (a legkisebb ugye 1 perc), a adatok többsége öt formában érhető el: minimum érték, maximum érték, szumma, átlag, minták (értékek) száma. Nemcsak szerverenként, hanem összesítve is kérhetőek az adatok (dimension), ezek lehetségesek:

adott szerverpéldány (instance)
szerverpéldány típus (pl. m1.small)
image (csak azok a szerverek, amik egy adott image-et futtatnak)
szerverfarm
autoscaling csoport név (lehet saját csoportokat csinálni, ezekbe szerverazonosítókat pakolni stb.)
terheléselosztó (load balancer) neve (tehát azok a szerverek, akik ugyanazon az elosztón lógnak)

Elastic Load Balancing

Terheléselosztáshoz eddig egy külön EC2 szerverpéldányt kellett létrehozni és futtatni, de most már van rá beépített szolgáltatás. Egy elosztónak saját DNS neve van, ahhoz kell intézni a kéréseket. Lehet a portokat egymáshoz rendelgetni (hányasra érkezzen a kérés, de a szerverpéldány melyiken dolgozza fel) és meg lehet határozni a protokollt is (TCP vagy HTTP). A bejövő port csak a 80-as, 443-as vagy 1024-től felfelé lehet. Ebből lehet látni, hogy inkább a HTTP és HTTPS a "célközönség".

A terheléselosztó figyeli a szerverpéldányokat, időnként megvizsgálja mindet. Ehhez be lehet állítani, hogy milyen URL-t kérjen le, mennyi legyen a timeout és azt is meg lehet mondani neki, hogy hány sikertelen kísérlet után minősítse "betegnek" az adott szerverpéldányt. Tehát nem a CPU, háttértár, stb. terhelést figyeli, hanem azt, hogy az adott szerver tud-e elfogadható időn belül válaszolni.

Auto Scaling

Ő az a komponens, aki beállítható CloudWatch mérési szabályok alapján szerverpéldányokat indít vagy állít le. Autoscaling csoportokat lehet létrehozni, ezekhez pedig szabályokat adni. Nem egyszerűen image-eket indít, hanem indítási konfigurációkat (launch configuration), amik egy csomó környezeti dolgot határoznak meg és adatok is átadhatók vele az induló szerver számára.

GUI-t neki!

Van már most is jónéhány startup, aki hasonlót kínál (pl. RightScale), az ő működésüket biztosan meg fogja változtatni az ügy, az árakat pedig remélem lefelé (eddig borsos volt). Már alig várom, hogy valami jó kis asztali klienst építsenek rá, amivel egyszerűen lehet konfigurálni a farmunkat.

Persze ez nem oldja meg a magasabb szinteken lévő skálázódást, pl. egy replikált MySQL farmhoz az Amazon API-nak semmi köze.

Árak

Egy terheléselosztó 1 havi futtatása 18 USD (smafu), viszont minden rajta átfolyt sávszél 0.008 USD/GB, azaz kb. 8 USD per terabájt. Ez kedvező, sokkal olcsóbb, mint egy dedikált EC2-s terheléselosztó szerver.

Az Auto Scaling ingyenes, viszont minden szerverhez CloudWatch mérést is indítania kell, a CloudWatch viszont pénzes megint. Minden vizsgált szervernél 0.015 USD per óra, azaz kb. 11 USD havonta szerverpéldányonként. Hát, hát. 10 szervernél mondjuk elég jó, csak oda még minek.

Szopat az Apple keményen

Thu, 07 May 2009 02:00:00 +0200

Már írtam róla, hogy mekkora szívás volt az iPhone Developer Program-hoz csatlakozni, de az igazi szopó csak ezután jött. Az egész lényege a DJ Player alkalmazás, miatta tanultam ki az iPhone fejlesztés csínját-bínját és miatta csinálom az egész cécót. Startupok figyelem: iPhone-ra fejleszteni nem biztos, hogy megéri!

Mielőtt elkezdtem volna fejleszteni, természetesen jól megnéztem, hogy nem tartalmaz-e olyan komponenst, amely sérti valamelyik idióta Apple szabályt. Mindegyik funkcionalitása megtalálható több App Store-os szoftverben is, ezért úgy gondoltam, hogy oké lesz.

Nem konzisztens

Ez volt az első hibám. Szabály: attól, hogy van már ugyanolyan funkcionalitás valamelyik App Store-os programban még nem biztos, hogy nálad is elfogadják. Az elfogadási eljárás nem konzisztens!

Ikon

Január 30-án küldtem be az alkalmazást, február 4-én megérkezett az első elutasítás: az alkalmazás ikonja hasonlít az iPod-ra. (Az ikon egy iPod-ra ültetett fejhallgató volt.) Nem lehet semmilyen Apple-s termékre hasonlító ikonod vagy képed az alkalmazásodon belül!

Olvastam olyan történetet, hogy egy alkalmazás súgójában a magyarázó képen egy iPhone volt látható "rázás" (shake) közben (rázni kellett valami funkcióhoz). Elutasították, mert az iPhone ugye Apple védett ügy... Úgyhogy rajzolniuk kellett egy iPhone-ra nem hasonlító eszközt, jó vicc. Persze mivel nem konzisztens az ügy más appokban simán vannak védett képek.

Béta

Február 4. után jött a nagy semmi, ezért beküldtem az alkalmazást más néven is. Erre jött 21-én a következő elutasítás, hogy távolítsam el a "béta" szót a leírásból, mert nem lehet benne semmilyen utalás arra, hogy béta állapotú lenne. Igenám, de én azt írtam, hogy "...a béta tesztet profi DJ-k végezték...", ami nem azt jelenti, hogy a szoftver még mindig béta lenne ugyebár.

Erica Sadun-nak volt egy hasonló története, ő egy olyan ingyenes alkalmazást készített, ami a béta teszt folyamán segítette a fejlesztőt. Az övét is eldobták... de úgy már elfogadták, ha azt írta, hogy "ez az alkalmazás a KISZERKESZTVE folyamatban segít". Gigalol, utána pár nappal írt neki az Apple, hogy ez mégiscsak hülyén néz ki, használhatja a béta szót... De csak ő, Te nem!

Egy körben?

Utána jött a következő semmi, beküldtem egy harmadik néven a DJ Player-t, azt február 27-én utasították el, mert az "organize" ikont használtam a tracklist-hez való visszatéréshez (a képe pont passzolt hozzá).

Persze gondolhatnád, hogy a fenti problémákat egyetlen körben is leírhatták volna, de nem: ahogy beleakadnak valami ügybe dobják vissza az alkalmazásodat. Sőt, ekkor nem veszik figyelembe az esetleges korábbi elutasításokat, szóval visszatérnetnek bármilyen hülyeségre.

Ez igaz egy esetleges frissítés beküldésekor is! Simán találhatnak valamit, amit még az elfogadáskor nem vettek észre és egyébként hónapok óta benne van az alkalmazásodban. Szóval frissíteni is rizikós...

Fekete lyuk

Február 27. után jött a nagy fekete lyuk, jegelték a DJ Player-t. Ez azt jelenti, hogy nem utasítják el, de nem is engedélyezik. Ilyenkor gyakorlatilag senkit nem tudsz elérni, a hivatalos e-mail címek, bugreporter és telefonszámok semmit sem érnek, nem érkezik válasz, az App Review Team még belsős Apple munkatársak által sem elérhető!

Az App Review Team e-mail címéről "robot" válaszok érkeznek (bármit kérdezel ugyanaz a válasz, egy kivonat bizonyos fejlesztői szabályokról), a telefonos Apple Developer Connection pedig nem tud segíteni, csak egy belsős várakozási sorba teszik a kérésedet. Ezt a kérést kétszer lehet "nyomatékosítani" (escalation), ekkor magasabb prioritásba teszik, de nálam 6 hét alatt sem érkezett válasz. Az ADC arra jó, hogy beszélj egy kedves ügyintézővel, aki az ég egy adta világon semmit sem tud tenni semmilyen ügyben.

Olvastam olyan fejlesztőről, akinek az alkalmazását végül 6 hónap után fogadták el, de több az olyan, akinél örökre jegelnek. Ez akkor is lehetséges, ha valamelyik Apple haver cég hasonlót fejleszt és ilyenkor megváratják a tiedét addig, amíg az el nem készül és sikeres nem lesz. Utána pedig hiába kiabálsz, hogy dehát a tiéd előbb kész volt.

iTunes Library Access

Május 7-én zárult le a fekete lyuk, elutasították az alkalmazásom, mert zenefeltöltés van benne (az iTunes library-t nem érhetik el az appok). Persze beküldtem ismét azzal a megjegyzéssel, hogy nem egy DJ app van már a Store-ban ilyen funkcionalitással, de nincsenek illúzióim.

Elárulok valamit, pedig az NDA miatt nem tehetném, de konkrétan leszarom: a 3.0-s verzióban bejelentett iTunes Library Access egy nagy kamu, ezt a problémát (sem) fogja megoldani. Az iTunes Library Access lehetővé teszi a listázást, trackválasztást, de az alkalmazás nem férhet hozzá magához az audiofájlhoz.

Annyit tehet mindössze, hogy "megkéri" a beépített lejátszót a zene lejátszására, de saját feldolgozás nem lehetséges. Pedig milyen sok zeneapp készítő szeme csillant fel... Már a bejelentés másnapján tele volt a belsős fejlesztői fórum azzal, hogy ez így használhatatlan lesz.

Nem fizet

A napokban pattant ki a TechCrunch-on egy másik sztori, miszerint a már bent lévő alkalmazásoknak sem fizet úgy az Apple (45 napon belül), ahogy kéne. Érdemes elolvasni a hozzászólásokat: nem egy-két dollárral tartoznak, hanem több ezerrel.

Van olyan fejlesztő, aki január óta egy buznyákot sem kapott és jóval 10e dollár fölött tartoznak neki. Természetesen itt sincs igazi kontakt lehetőség, hiába írnak és telefonálnak a megadott helyekre, az Apple szokás szerint baszik válaszolni.

Nagyok

Megkerestem a problémámmal a magyar Apple vezetőjét, Majoros Miklóst is, aki szinte azonnal válaszolt. Sajnos előre látható volt, hogy nem tud segíteni, de egy próbát megért a dolog.

Nagy vagy ismert cégeknek, fejlesztőknek persze nincsenek ilyen problémáik, ők belsős Apple kontakttal pár órán belül mindent meg tudnak oldani, rájuk nem vonatkoznak a szabályok.

Példának ott a Skype alkalmazás megjelenése, ami a felhasználók nagy része számára egyszerűen nem működött és tele volt bug-gal, át sem mehetett volna az elfogadási folyamaton. Volt is belőle forró thread a belsős fejlesztői fórumon. Nálunk a Ustream csapata rendelkezik ilyen értékes kapcsolattal, meg is próbáltam "venni", de nem adják ki, féltik a saját pozíciót, teljes joggal.

Startup?

Ezek alapján a StartUP konferencián azt tanácsoltam, hogy iPhone-os fejlesztésben bízni nagyon rizikós. Összefoglalva:

Bekerülni a Developer Programba Magyarországról macerás, de kivitelezhető.
Egy alkalmazás nem biztos, hogy bejut az App Store-ba még akkor sem, ha más alkalmazások ugyanolyan funkcionalitást tartalmaznak.
Ha mégis bekerül és vannak eladások, akkor sem biztos, hogy kifizetnek.
Az Apple nem válaszol szinte semmire, elérhetetlen.
Az App Review Team a legjobban őrzött részleg, a döntései szubjektívek és nem konzisztensek.
A nagy és/vagy haverka cégek előnyben vannak, velük sosem fogsz tudni versenyezni, mert lejegelnek.

Ne higyjetek a fejlesztői sikersztoriknak (például Steve Demeter, Smule), azok csak a marketing miatt léteznek. A saját sikerhez sok türelem, kemény munka és óriási szerencse kell.

Nincs versenytárs

A velem történt eset a jéghegy csúcsa, olyan hülyeségekről lehet olvasni mindenfelé, hogy csak na. Nem véletlen, hogy még a belsős fórum is Google Android sóhajtásokkal van tele. Sajnos azonban még a legújabb 1.5 béta változat is harmatgyenge az iPhone SDK-hoz képest. Bártházi kollégával már megállapítottuk, hogy API-k terén a Google válságban van, az Android még mindig béna, az OpenSocial meg pláne.

Az Apple termékek nagyon jók, az iPhone SDK remek, de a fejlesztőkkel nagyon-nagyon kibasznak és ennek az eredménye a sok rossz minőségű iPhone szoftver. A Pinch Media felmérése szerint a feltelepített iPhone alkalmazások mindössze 1%-át használják egynél többször. Nem véletlen.

Update: a szifon.com bekopizta a cikket, vannak hozzászólások ott is.

Egy kis gyorsítás az iWiW appokhoz

Thu, 23 Apr 2009 02:00:00 +0200

A tegnapi indulásnál számítani lehetett a nagy reccsre, be is következett, remélem senki sem csodálkozott. Az alkalmazások szinte kivétel nélkül az iWiW rendszere miatt nem működtek, ahol a kapcsolati háló adatok még csak-csak megérkeztek, de az adattárolási és a külső szerverhez fordulási kérések teljesen behaltak.

Ha külső szerverhez fordul egy alkalmazás, akkor a kérés általában keresztülmegy az iWiW rendszerén, még akkor is, ha mondjuk egy külső SWF fájlt tölt be. Ez főleg az adatforgalomnál gázos, mert a böngésző által bezárt "biztonsági doboz" miatt nem lehet direkt AJAX-os kéréseket intézni kifelé (nem megy az XMLHttpRequest, a MooTools-os se), hanem a gadgets API-n keresztül a gadgets.io.makeRequest metódust kell használni.

Ő pedig szépen keresztülmászik az iWiW-en, megkérdezi a külső szervert, aztán visszajön az eredménnyel. Az a baj vele, hogy:

Függ az iWiW rendszerétől, pedig külső kérésnél nem szeretném terhelni a nagy tesót.
Lassú még akkor is, ha gyors: felesleges http kéréseket eredményez.
Nem tud előre beállítható timeout-ot: olyan későn is visszatérhet, amikor már nincs szükség rá. Nekem "igazi" timeout kell, ahol az idő letelte után teljesen elfelejti a kérést és már nem is fordul a külső forráshoz, nem terheli azt.
Nem lehet leállítani, eldobni a kéréseket, ha azok még nem tértek vissza.

A fentieket nagyon trükkös és így böngészőnként bizonytalan sikerű JavaScript-tel (pl. dinamikus script tag) meg lehet oldani, de az igazi robusztus megoldás egy icipici Flash objektum használata.

FlashIO

FlashIO-nak neveztem el a megoldást, így működik: van egy globális FlashIO JavaScript objektum, amelynek mindössze három metódusa van: init, makeRequest és cancelRequest. Mindent megcsinál helyetted, még a szükséges (láthatatlan) Flash objektum beillesztését is, meg JSON parse-ol, satöbbi.

Az egész pakk letölthető innen, benne van a Flash objektum forrása is (pl. Bártházi doktornak tanulási célzattal, kevés kód van benne). Az én alkalmazásom (Videotelefon) gyorsabb lett tőle, 2-400 ms (és néha 2-20 másodperc...) helyett 50-150 ms még az átlagfelhasználó számára is észrevehető.

Adobe Strobe

Tue, 21 Apr 2009 02:00:00 +0200

Már írtam róla, hogy egy egységes "ipari szabvány" videólejátszó keretrendszer milyen jó lenne, pláne egy reklámbeillesztést is támogató. Aztán lett Open Video Player Initiative, ami egy Akamai-os lufi/reklám volt, most pedig itt az Adobe Strobe Framework ígérete.

A Strobe valami médialejátszó keretrendszer lesz a Flash platformra (tehát mehet Flexbe is), egy halom API/osztály, ilyesmi. Állítólag az Adobe és az Akamai továbbra is együttműködik az Open Video Player Initiative-on (OVPI) és a Strobe ezt kiegészítené majd... zavaros. Egyébként az OVPI most már egészen használható osztályokat ad, a forráskód tanulmányozása tanulási célból nem hülyeség, de egy komplett playert építeni rá egyelőre az.

Tök jó lenne, ha nem több ezer sorból állna egy használható videólejátszó, lásd iMectPlayer, ezért szurkolok a Strobe-nak, csak ne lenne ennyire reklámszagú az egész. Része az Open Screen Project-nek is, ami egy nagy cégek által támogatott (pl. LG, Samsung, Nokia), interfész-forradalomnak álcázott 10 millió dolláros Flash reklám/alapítvány.

Megjelenés: 2009 ősze. Pénz: ingyen. Ha lesz doksi, akkor majd írok róla: egyelőre szép piros lufi, nem több. Még logója sincs.

Amazon CloudFront tapasztalatok

Thu, 09 Apr 2009 02:00:00 +0200

A Media2Radio fontos eleme, hogy a DJ-k nagy méretű (320-as) mp3-akat hallgatnak és tölthetnek le. Ezen sikerült a CloudFront-tal dobni egy nagyot, user experience.

Eddig a MediaTemple GridService-ről ment a zenék kiszolgálása, mert nem állt rendelkezésre olcsó és kis forgalomra is használható CDN. A GridService nagyon jó fájlkiszolgálásra, óriási terhelést bír. Mivel amerikában, viszonylag központi helyen van, ezért a világ minden tájáról elég jól el is érhető.

De azért panaszkodtak a DJ-k, hogyha úton vannak mondjuk ázsiában, akkor elég karcsú a letöltés, csináljunk valamit. Kapva kaptunk a CloudFront-on, pont a hozzánk hasonló kicsikre találták ki.

Készítettem egy démont, ami figyeli a zenék feltöltését/módosítását és szinkronizál az Amazon S3-mal (törli a régit, frissít, stb.). Kb. 2 óra alatt fel is kúszott a jelenleg elérhető 19 GB zene úgy, hogy csak tízpercenként futtatom: gondolom a MediaTemple és az S3 között bitang sávszél van (olyan 40 mbps körül).

Aztán beállítottam, hogy a media2radio S3 bucket-et szolgálja ki a CloudFront, rátoltam egy domain aliast (cdn.media2radio.com) és kész. A démon beírja az adatbázisba, hogy melyik zene van már a felhőben, így a kiszolgálásnál a megfelelő url-re irányít a rendszer.

Minden startupnak CloudFront-ot, Magyarországra is!

Kettő órán belül megkaptuk az első visszajelzést, hogy mi történt, hűdegyors lett a letöltés. Ezt még amerikai felhasználók is megírták, pedig ők közel voltak a MediaTemple-höz.

Én itt Budapesten valószínűleg a frankfurti központhoz vagyok közel, a letöltések a 20 mbps kapcsolatom teljes szélességén jönnek le, így nem tudom mennyi lehet a max. Ez azt jelenti, hogy egy fájl (átlagosan 20 MB, mi csak jó mp3-akkal foglalkozunk) néhány másodperc alatt lejön. Ráadásul mivel a letöltés eleje mindig gyorsabb, ez idő alatt átjön a zöm, így a jellemző letöltési időm 3 másodperc.

A CloudFront-ot minden startupnak ajánlom, csak a forgalom után kell fizetni. Nekünk az első 10 napban eddig 5 dollárba került az egész... Ha nagy fájlokkal foglalkozunk (nagy = nagyobb, mint 1 mega), akkor sokat dobhat a felhasználói élményen (a hazain is!) egy ilyen kiszolgálás, ráadásul plusz backup-ot is ad.

iWiW videotelefon

Thu, 26 Mar 2009 01:00:00 +0100

Az iMect Bt. új Videotelefon alkalmazást indított el az iWiW felületén. Így szól az ajánlott szöveg, ezzel lehet bejelenteni az újdonságokat. Arról szól ez a bejegyzés, hogy mit, miért, kinek és hogyan.

Mit?

A leírása így szól: ingyen beszélgethetsz a többi iWiW taggal, csak egy webkamera kell hozzá. Beállítható a foglaltság, a minőség, kikapcsolható a videó (csak hang).

Azaz távolról nézve olyan, mint mondjuk a Skype, csak épp bent az iWiW-en fut. Így néz ki az ajánlója:

Miért?

1. Tanulási és kipróbálási céllal

Meg szerettem volna tanulni az OpenSocial fejlesztés csínját-bínját és ki szerettem volna próbálni az új Adobe Flash P2P technológiát, mindezt a hello world szintnél jóval mélyebben. Aztán jött bele még egy kis Google AppEngine is.

2. Verseny

Inspirált az iWiW fejlesztői verseny, ezzel az alkalmazással nevezek rá. Igyekeztem a támpontoknak megfelelni.

Kinek?

A célközönségre jó példa a szüleim korosztálya. A többségüknek hiába mondanám, hogy telepítse fel a Skype-ot, nem fogja megtenni. Én pedig lusta vagyok átmenni és megcsinálni nekik. Viszont az iWiW-et remekül és gyakran használják, így kapnak hozzá egy videochat eszközt.

Hogyan?

A fejlesztői ÁSZF 8.3-as pontja elvileg tiltja, hogy know-how-t tegyek közzé, tiszta Apple iPhone NDA. De azért közzéteszem. :-) A jelenlegi megoldással "óriások vállán" nyugszik az alkalmazás, a terhelés megoszlik az iWiW, a Google és az Adobe szerverei között, az én költségem pedig egészen pontosan 0 Ft. Az alkalmazás három fő részből áll:

1. JavaScript

Az OpenSocial ugye JavaScript-es ügy, itt az API-ja mellett még MooTools 1.2-t is használok. Ez a rész jeleníti meg az alkalmazást, foglalkozik a néző és az adatlap tulajdonos adataival, kezeli az elérhetőséget/foglaltságot, a hívásindítást, fogadást, elutasítást.

Az elérhetőség/foglaltság az iWiW saját rendszerén történik felhasználónkénti adattárolással. 6 másodpercenként frissül ezt az adat, így lehet tudni, hogy ki éppen online és nem foglalt-e. Megkérdeztem a Virgo-s srácokat, hogy bírni fogja-e a rendszer ezt a terhelést, egyelőre az az álláspont, hogy mehet.

Nyilván csak akkor lesz gond, ha nagyon sokan használják, akkor viszont át tudok menni Google AppEngine-re és annak fizetős változatával le tudom kezelni a nagy tömegű lekérdezést. Ha sokan használják, akkor ez a költség nem lesz gond.

2. Google AppEngine

Mivel az owner számára nem lehet adatot írni, ezért egy külső szerverrel kell lebonyolítanom a híváskezdeményezést, illetve a Flash objektumok összekapcsolásához is szükséges. Az AppEngine-re esett a választásom, mert ingyen kapok óriási terhelhetőséget, így ez a teljesítmény sokáig elég lesz, kb. 20 000 egyidejűleg bejelentkezett felhasználóig.

Az egész csak néhány sor Python kód és még adatbázis-kezelés sem kell hozzá. Az adatokat maximum 120 másodpercig tárolom, erre pedig kíváló a Memcache, gyors, egyszerű. Ráadásul jogilag is védve vagyok, hiszen innen minden adat két percen belül elpárolog, a többi pedig az iWiW rendszerén belül marad.

3. Flash

Maga a beszélgetés már Flash-ben történik, ActionScript 3-ban írtam meg. A Flash objektumok közvetlenül, média szerver beiktatása nélkül peer-to-peer kommunikálnak UDP protokollon keresztül. Az UDP sokkal hatékonyabb audio/video továbbítására, mert megengedi, hogy elvesszen néhány adatcsomag, ami észrevehetetlen, viszont az átvitel "gördülékenyebb" lesz tőle. Ez a 10-es player nagy újdonsága és elég jól működik.

Ez nem olyan P2P, mint a BitTorrent, a kliensek már nem adják tovább a kapott streamet, ezért csak néhány fős beszélgetésekhez használható, pont az alkalmazásomhoz találták ki. Mindössze egyetlen dologhoz szükséges médiaszerver, azon regisztrálják a Flash objektumok az adás azonosítóját, tehát csak néhány bájtról van szó.

Az Adobe Stratus szolgáltatása viszont ezt az "összekapcsoló" médiaszervert is megoldja helyettem, teljesen ingyen lehet használni. Tehát mégegyszer: a Flash objektumok a Stratus és az AppEngine segítségével kapcsolódnak egymáshoz, utána viszont minden adat elpárolog és egymással kommunikálnak peer-to-peer. Nincs belehallgatás, nem tudom kideríteni, hogy ki mennyit és kivel kommunikál.

Tapasztalatok

A fejlesztés kb. egy hónapig tartott tanulással együtt. Az OpenSocial API úgy működött, ahogy azt a doksi írta és sokat segített a dev.iwiw blog. Jól lehetett érezni, hogy ezerrel dolgoznak az iWiW vonatkozó alrendszerein, mert sokszor futottam leállásokba és lassulásokba. Ez nem rossz, jó látni, hogy melóznak vele.

Az AppEngine egy sajátos valami, teljesen egyedi mindene. Jópofa a lokális szervere, kényelmes használni és telepíteni az új verziókat. A Python programozási nyelv viszont nagyon furcsa nekem. Az Adobe Flash P2P is jól működik, a Stratus pedig villámgyors.

Összességében véve kevesebb kiforratlan dologba ütköztem, mint szoktam, ami váratlan. Persze azért volt egy-két megszokott "crazy hour", amikor nem jöttem rá miért nem működik és csapkodtam a billentyűzetet. A fejlesztő élete már csak ilyen.

Meglepő, hogy a sok érintett technológia ellenére igen kicsi lett az alkalmazás letöltendő mérete: az összes fájl összesen 61 kbyte, és ebben két csengőhang is benne van. A forráskód mindenestül, kommentekkel együtt kábé 800 sor.

Szerintem elegendő funkció van az alkalmazásban az induláshoz, csak annyit sajnálok, hogy nem tudtam egy harmadik státuszt beletenni: "elérhető csak az ismerőseim számára". Ehhez az kellene, hogy tudja az alkalmazás a viewer-ről, hogy az owner ismerőse-e (barátja).

Ez az alapvető funkció egyelőre hiányzik az OpenSocial-ból, és csak egy csúnya workaround-al lehetne megoldani: le kell kérdezni az összes ismerőst és megnézni, hogy az owner benne van-e. Ez viszont túl sok http lekérést eredményezne, hiszen lehet, hogy az owner csak a 300-adik a sorban (ha legalább 300 ismerős felvette már az app-ot...).

Majd meglátjuk mi lesz belőle, remélem sokan fogják használni.

Ne blokkolj!

Wed, 04 Mar 2009 01:00:00 +0100

A minap olvastam Tsabeeka tollából, hogy "Akad és akaszt a TurulMeme". A bejegyzés szerint a TurulMeme leállása megakasztotta a plugint használó blogokat, amik csak a timeout letelte után szolgálták ki a kért tartalmat. Nadekéremszépen, itt nem a TurulMeme a hibás, hanem a plugin készítője.

A megoldás nem a JavaScript és nem is a timeout átállítása. Egyszerűen arról van szó, hogy egy tartalom kiszolgálása alatt blokkoló módon nem szabad külső forrásokra támaszkodni, sohasem, nemnem, még timeout-tal sem.

Jelen bloghoz írtam TurulMeme plugint, ami úgy működik, hogy bizonyos időközönként (crontab) ránéz a TurulMeme API-ra és beírja az adatbázisomba, amit kell (hozzáadja hozzászólásként). Ez a megoldás kíméli az erőforrásokat, csak egyszer fut óránként és csak egyszer terheli a TurulMeme rendszerét is.

A JavaScript-tel az a bajom, hogy egyrészt JS nélkül nem működik (pl. a Google nem fogja indexelni), másrészt plusz kéréseket eredményez, nem hatékony.

Egyébként szintén a minap fordult elő, hogy a Google Analytics hasonló problémát okozott. A nagy GMail leállás napján egy rövid ideig haldoklott a GA script kiszolgálása és a GA mérőkód a vonatkozó osztály nélkül elszállt.

Ez Internet Explorer alatt okozta a legtöbb problémát, ott betöltődni látszottak az oldalak, de a végén jött a már jól ismert "a kiszolgáló megszakította a kapcsolatot" és végül nem jelenített meg semmit, így IE alatt elérhetetlenné téve sok-sok weboldalt.

Itt a megoldás a mérőkód ondomready vagy onload utáni futtatása, ha akkor száll el nem fossa össze magát az IE, ami technológiai oldalról arcpirítóan béna.

Egy szó mint száz, vigyázzunk a külső cuccokkal.

Google AppEngine árak

Sun, 01 Mar 2009 01:00:00 +0100

Megérett az AppEngine, úgyhogy jöttek az árak. Első gondolatom az volt, hogy majd jól összehasonlítom az Amazonnal, de aztán rájöttem, hogy ez nagy hülyeség lenne.

Már írtam az AppEngine-ről, viszont a fizetős rész bevezetésével változtak az ingyenes változat korlátai. Most már érettnek tűnik a szolgáltatás, hiszen beárazták.

Korlátozások

A dokumentáció részletessége, és a transzparencia teljesen ismeretlen ebben a szegmensben (is). Nagyon jó és tervezhető, az összes hosting szolgáltató tanulhatna ebből.

Egy kérés vagy válasz maximális mérete 10 MB lehet. Azaz nem ide fogod a videókat feltölteni, nem fájlkiszolgálásra lett kitalálva.
Az API hívások maximális mérete 1 MB (ilyen például egy kérés az adatbázis vagy a memória cache felé). Ezzel együtt lehet élni, a jól felépített oldalaknál a jellemző kérések jóval ez alatt szoktak lenni.
Egy kérés feldolgozása maximum 30 másodperc lehet. Ez olyan, mint a PHP script time limit beállítása. Őszintén szólva ha ennyit kell feldolgozni, akkor az alkalmazásodban van a hiba.
Egyszerre maximum 30 aktív szkriptpéldány futhat, azaz egy időben csak 30 kérést dolgozhatsz fel.
A kódod max mérete 150 MB lehet (uhh, ki ír ekkorát?). Maximum 1000 kód és 1000 statikus fájlt tölthetsz fel (már mondtam, nem fájlkiszolgáló).

Rengeteg további paraméter van még, csak a legfontosabbakat ismertetem:

Ingyenes csomag

6.5 CPU óra naponta
1-1 GB sávszél naponta (be-ki), 56-56 MB percenként (mintha 0.5 gbps kapcsolatú szervered lenne)
1.3 millió kérés naponta, 7400 kérés percenként (a max. 30 egyidejű kérés miatt 4ms hosszú futásokkal tudnád elérni, de ilyen alacsony átlagos értéket szinte lehetetlen produkálni)
1 GB adatbázis
szolid e-mail forgalom (2000 címzett naponta, de csak 8 darab percenként)

Fizetős csomag

46 CPU óra fölött kell fizetni, egészen 1729 CPU óráig mehetsz fel (rettentő sok), percenként maximum 72 CPU-t használhatsz egyszerre (borzasztó sok)
43 millió kérés naponta, 30000 kérés percenként
az 1-1 GB sávszél fölött sávosan kell fizetni, maximum 740 MB percenként (mintha 6 gbps-en lógna a szerver, komoly)
1 GB adatbázis fölött fizetni kell, bármekkora lehet
komoly e-mail forgalom (7.4 millió címzett naponta, 5100 darab percenként)

Az adatbázis forgalma már az ingyenes csomagban is óriási lehet, csakúgy, mint a külső URL-ről töltött adatok (URL Fetch) mennyisége és gyakorisága. A képmanipuláló API terhelése szintén bődület.

Mire elég?

Egy normálisan (jó minőségben) megírt alkalmazással kb. napi 30-50e unique látogatóig mehetsz az ingyenes csomaggal. Ez a legtöbb hazai igényt simán kielégíti, egy felkapottabb amcsi startup viszont pillanatok alatt a fizetős változatban találja magát.

Összehasonlítás az Amazonnal?

Hülyeség. Az Amazon EC2-n kapsz egy alap oprendszert, aztán arra azt tolsz, amit akarsz. Az AppEngine inkább egy API környezet, így korlátoltabb, viszont egy-két speciális vonatkozásban sokkal erősebb (pl. képmanipulálás, BigTable adatbázis), mint akár húsz EC2 példány egyszerre. Teljesen másképp kell a kettőhöz hozzáállni, fejleszteni rá, satöbbi.

Maximum a buta menedzserek keverik össze a kettőt, a fejlesztők dolga pedig rávilágítani a különbségre.

Ha viszont a buta menedzser csak néhány fő paraméter árát nézi (CPU óra, sávszél, tárhely), akkor annyit azért elmondok, hogy szinte hajszálra megegyezik az Amazon EC2 áraival és a CPU óra számítási erejét is a legkisebb EC2 példányhoz lőtték be.

RackSpace

Tue, 17 Feb 2009 01:00:00 +0100

A hosting piac egyik patinás szereplője a RackSpace és az elmúlt hónapokban szép erőfeszítéseket láttunk tőlük cloud computing téren. Egyértelműen az Amazon és a Media Temple ellen pozícionálják magukat, megnéztem milyük van. Azt is elmondom, hogy most mit használok és hogyan látom a cloud computing jelenlegi helyzetét. Microsoft Azure? Nem lesz könnyű olvasni, én szóltam.

Mosso

Ez lenne a Media Temple Grid Service ellenfele, írtam róla már, egyértelműen gyengébb és drágább. A hasonló szolgáltatásokat amúgy sem tudom nyugodt szívvel ajánlani, ha adatbázist is használna az alkalmazásod.

Itt lett egy kis névzavar, a Mosso lett átnevezve Cloud Sites-ra, illetve a teljes cloud computing division-t (Cloud Sites, Cloud Files, Cloud Servers) most már Mosso-nak hívják. Tehát régi Mosso = Cloud Sites.

Cloud Files

Ez lenne az Amazon S3 ellenfele. API oldalon kb. ugyanazt tudja, a következő eltérésekkel:

a bucketeket containereknek hívják
nem lehet permission-öket állítani, a cuccokhoz csak a feltöltő fér hozzá
nincs torrent támogatás

Van CDN is, csakúgy, mint az Amazon CloudFront-nál, de itt a Limelight áll a dolog mögött, azaz ez a része elvileg jobb (gyorsabb, alacsonyabb ping időkkel, nagyobb földrajzi terítéssel). Public-read dolgokat csak ezen keresztül lehet futtatni.

A fő probléma viszont az, hogy egyértelműen drágább az S3-nál. A költségek oroszlánrészét a sávszél viszi el, ott a 5 centtel drágább minden GB. Egyébként megvették a Jungle Disk-et is, ami hamarosan Cloud Files-ra is tud majd menteni.

Cloud Servers

Ez lenne az EC2 ellen, de még csak készül. Megvették a Slicehost-ot és az ott lévő rendszert fogják "fel-API-sítani". A Slicehost egy igen jó szolgáltató, ez az oldal is ott fut már.

Slicehost

Sallangmentes szolgáltató, abszolút a szolgáltatás minőségére fókuszálnak. Garantált teljesítményeket kapsz nagyon jó rendelkezésre állással, viszonylag olcsón. Mindent kontrollálhatsz, nagyon basic installokat kapsz (mint az EC2-n), amit aztán úgy telepítesz, ahogyan csak akarsz. Nincs "kényelmes" felülete, amin hipp-hopp össze lehet dobni egy hostingot.

Nagyon meg vagyok elégedve vele és a ping idők is prímák innen, pedig az USA-ban van. Azért váltottam, mert a Media Temple Grid Service-ben hiába volt garantált teljesítményem (MySQL Grid Container), az olyan lassú volt, mint a tetü és nincs memória cache. Amikor egy Media Temple-s szolgáltatáshoz férsz hozzá (pl. fájlt kérsz le vagy kapcsolódsz a MySQL konténerhez), akkor először "felpörög" a rendszer és utána már villámgyorsan kiszolgál, csak ez a "felpörgési" idő szokott akár fél másodpercig is elhúzódni. Olyan ez, mint a ping idő a hálózatoknál.

A Slicehost persze nem olyan, mint a Grid Service, a megvásárolt erőforrás limiten belül kell maradni, nem skálázódik. Ha tudod, hogy mekkora terhelés várható (minden weboldalnál illik tudni), akkor a Slicehost-tal nagyságrendekkel gyorsabb kiszolgálást tudsz ugyanolyan áron kialakítani.

A Grid Service-t már csak fájlok kiszolgálására használom, arra igazán olcsó és sokat bír.

Hol tart a cloud computing most?

Még mindig nincs "szent grál", nem tudok olyat, hogy a legkisebbtől a legnagyobbig skálázódik egy szolgáltatás. A hozzám befutó érdeklődések 99%-ánál nincs szükség ilyenre, mert a terhelés jól tervezhető és általában kevesebb, mint havi 50 USD-ból megoldható.

Ráadásul a cloud computing belépési költsége sokkal magasabb a hagyományos hostingnál. Egyrészt ha csak egyetlen legkisebb EC2 fut (gyengusz teljesítmény), az már 72 USD per hó, másrészt a fejlesztési költségek lesznek magasak.

Egy alkalmazás megírása, netán átalakítása cloud környezetre mindig ad-hoc dolog, nincs rá recept és sok munkaórába kerül. Nincs általánosan alkalmazható megoldás, bár minden hosting cég azt keresi ezerrel.

A Microsoft Azure persze változtathat ezen, a demó videóból elvileg az jön le, hogy írd meg a webalkalmazást .NET-ben, aztán majd mi futtatjuk és felskálázzuk neked. Tekintettel arra, hogy ez még mindig csak demó... majd meglátjuk. Mivel szinte mindig az adatbázis írásánál futunk bele a legnagyobb problémába kíváncsi leszek, hogy a cloud-os MS SQL hogyan fog megbírkózni egy izmos left join-nal másodpercenként mondjuk százszor. Ha ezt megoldják, akkor máris megyek MS webfejleszőnek. Ráadásul nem ismerjük az árát sem egyelőre.

Ökölszabály: szerintem Cloud computing-ba belefutni csak akkor érdemes, ha a havi hosting költség elérné a 250 USD-t és van pénz a fejlesztésre is. Hozzá kell még tennem, hogy sok "hagyományos" hosting-on futó alkalmazáson bőven lehet még optimalizálni, ilyenkor akár egy-két nagyságrendet is lehet rajta javítani, pl. 1000 helyett 50000 napi unique teljesítmény ugyanazon a vason.

Remélem nem romboltam le a cloud computing varázsát, mert az amúgy sincs neki. Viszont nagyon jól lehet megmarketingolni.

iWiW API, juhéj, de annyira azért nem

Sun, 15 Feb 2009 01:00:00 +0100

Nagyon örültem az iWiW bejelentésnek és anno én is rávetettem magam a témára, meglehetősen nagy lelkesedéssel. Végigjártam a homokozót, a tutorialokat, írtam egyszerű kis próbaszösszenetet. Egyszerű rá fejleszteni, sitty-sutty, ez a része príma. Csak az vele a bajom, hogy egyelőre az átlaguser nem fog vele találkozni.

Amikor az ember elkezd egy ilyen alkalmazáson gondolkozni, akkor előbb megnézi a feltételeket, pl. milyen adatokat érek el? Ez a kör meglehetősen szűk, kábé ennyi:

person objektum: név, thumbnail kép, profil url
ki vagyok én (person objektum)
kik a barátaim (egy halom person objektum)
az alkalmazás tulajdonosa (akinek az adatlapján nézem) vagy nézője vagyok-e
a tulajdonos barátai (egy halom person objektum)

Ezen kívül lehet még eseményeket (történéseket) küldeni, amik minden felhasználó kezdőlapján jelennek meg (saját és barátok történései). Jó, tehát megvan miből gazdálkodhatunk, de hol jelenik meg mindez? Egyáltalán hogyan használja az átlag iWiW felhasználó a rendszert?

Itt a bibi

Szinte minden ismerősöm a következő utat járja be:

Bejelentkezés.
Kezdőlap. Ezt nem olvassuk el, hanem scroll le a függő kapcsolatokhoz vagy egyből klikk az "ismerőseim"-re. Esetleg az "üzenetek"-re, de az "ismerőseim" az út vége így is, úgy is. A többi főmenü ikonra meglehetősen "vakok", nem tudják mi van ott, hiába kerül hát oda az "alkalmazásaim".
Ismerősök listája.
Klikk valakinek a képére, vagy inkább névre.
Adatlap. Nem nézzük meg, hanem egyből klikk a "képek"-re.

Merthogy az iWiW egy nagy képmegosztó alkalmazás a többség számára. Nándi találó megjegyzésével "meg tudom nézni, hogy mi van azzal a csajjal, akit de megdugtam volna a középiskolában".

Egy csomó felhasználó még mindig nem ismeri az "ismerőseim friss képei" funkciót sem. Amikor elmondom nekik, akkor mindig nagy csodálkozás és "ezt kerestem", meg "végre" a reakciók. Hol találkozhatnának hát az alkalmazásommal? Három helyen:

a kezdőlapon történés formájában (ha az alkalmazás küld ilyet),
az adatlapon,
külön az "alkalmazásaim" alatt.

A kezdőlapot jelenlegi formájában nem olvassák. Az adatlapot szintén nem, az csak egy közbenső állomás a "képek" felé vezető úton. Az "alkalmazásaim" pedig végképp érthetetlen lesz.

Persze nyilván lesz kirakatba tett iWiW fejlesztői sikersztori, de pontosan a fentiek azok az okok, amiért nehéz lesz népszerűt és jót (hozzon pénzt is) írni. iWiW alkalmazást programozni könnyű, üzleti modellt és jó felületet kitalálni, na az már sokkal nehezebb. A Facebook-on a pofádba tolják az alkalmazásokat, ott könnyebb. De a magyar átlag felhasználók meg itt vannak.

Összeesküvés-elmélet: lehet, hogy emiatt hosszabbították meg a fejlesztői versenyt? Nem érkezett elegendő jó minőségű alkalmazás?

YouTube prezentáció a Midem-en

Thu, 05 Feb 2009 01:00:00 +0100

Pirossal karikáztam be a naptárban, erre el kellett mennünk. Csak reménykedtünk benne, hogy általánosságok helyett inkább tanulhatunk valami jót. Korábban zártuk a standot (17 óra), amúgy is egybeesett az Obama beiktatási show idejével: sok lúzer inkább ott bulizott a Billboard standnál amerikai zászlókkal meg ingyen piával.

A legtöbb YouTube videó alatt van zene, így hát érintett a zeneipar is. Sok probléma volt a legalizálással, valahogyan meg kellett oldani, hogy a kiadók akkor is hozzájussanak a pénzükhöz, ha egy családi videó alatt szól a cucc. Azt is tudjuk, hogy igen jelentős forgalom megy el tisztán videóklipekkel.

Erre a problémára pedig a ContentId a válasz. A ContentId azonosítja egy feltöltés videó és audió részeit, azaz egy YouTube videónál pontosan tudja a rendszer, hogy milyen zene szól alatta vagy melyik másik videóból használtak fel egy bejátszást. Felismeri a részeket is, kb. 10 másodperces darabokban, tehát ha mondjuk csak a refrént játszod be már az is meglesz neki.

Minden egyes új feltöltéskor átnyálazza az egész adatbázist (bele sem merek gondolni, mekkora meló ez) és átlag 15 perc alatt kész az eredmény (mindkét irányban!), hihetetlen. A fejlesztés kezdetekor ez az idő még 70 óra volt, sokat dolgoztak rajta a fiúk, az biztos.

Ha tehát jogtulajdonos vagy (pl. zenekiadó saját zenékkel), akkor irány a YouTube Partner Program, töltsd fel a termékeidet, hogy azután felismerje a ContentId. Ez a feltöltés nem megosztás, csak a ContentId-nak mondod meg, hogy "itt a zene, ezentúl figyelj rá és szólj, ha használják".

Tehát ma már minden zenekiadó érdeke, hogy részt vegyen a YouTube Partner Programban, még akkor is, ha egyébként nem tölt fel semmit.

A ContentId-val érintett videóknál (is) a YouTube reklámokat mutat és ebből fizeti a százalékot feléd illetve a sápot a szerzői jogkezelő szervezeteknek a vonatkozó helyi szabályozás (törvények) szerint. A legtöbb szerzői jogkezelővel már megállapodtak, egyenként, külön-külön, nagyon sok jogász dolgozott ezen. A százalékok titkosak, nincs gyakorlat.

Ha felhasználták a zenét, akkor választhatsz, hogy:

Tiltod. Ekkor jön a már ismert audió nélküli lejátszás.
Engeded és megfigyeled (csak statisztikát kapsz).
Engeded és pénzt keresel.

Ez a szabályozás országokra és egyebekre lebontva állítható be. Tehát nem a YouTube az, aki leszedi a zenét az épp feltöltött családi videódról, hanem a jog tulajdonosa, rendszerint a kiadó. A ContentId beállítások 90%-a a harmadikon van, de pl. a Warner az első eset mellett döntött, ezért van a perpatvar.

Az is beállítható, hogy a zenéd lejátszása közben felpattanjon egy buy on iTunes/Amazon satöbbi link.

Egy szó mint száz nem hülyeség ez a rendszer, bár nyilván vannak gyerekbetegségei, pl. mi a helyzet a rossz felismerésekkel (remixek), erre nem tudtak nekem elfogadható választ adni. A többi videómegosztó fényévekkel a YouTube mögött kullog, igazából már csak egy pofás design kellene a YouTube-ra szerintem. Pláne, hogy már annotálni is lehet.

Az előadásról

Sajnos nincs fent a neten a prezentáció, még csak hasonlót sem találtam. Hiába kértem a srácokat, nem adták oda. Elvileg semmi új nem hangzott el, minden összeszedhető lenne a netről, de valahogy mégsem köztudott a zenei világban (se).

Az előadó nagyon profi volt, egy slide nem volt fent 20 másodpercig (!!). A legtöbb kérdésre "i don't have the answer" volt a válasz, vagy "titok". Elhozták viszont egy csomó munkatársukat, voltak marketingesek, jogászok és egy vezető fejlesztő, mindenféle, kábé huszan (!!), zömmel a zürichi központból. Nagyon komolyan vették a Midem-et.

Ez a felállás egyébként nagyon vicces és szteretíp volt, a jogászok öltönyös fehér jómódú srácok, a közgazdászok skandinávnak látszó csajok, a fejlesztő pedig mi más, mint egy apró ázsiai.

Tőlük lehetett a prezentáció után az előtérben kérdezni és mi ki is használtuk az alkalmat, nem hagytuk őket Obamát sasolni. :-) Mutattunk nekik érdekeseket, kérdeztünk érdekeseket és névjegyeket cseréltünk. Nem, semmit nem tudtam kihúzni egyikből se, nagyon be vannak idomítva.

Megkérdezték, hogy a DJ Player-t miért iPhone-ra hoztam ki (elmondtam nekik, hogy az Android-dal mik a problémáim), kitárgyaltuk a pseudo-streaminget, elemeztük a live streaming lehetőségeket (kenik-vágják a Jasmin és Ustream setupot!), és persze nem tudtam semmilyen YouTube live infót szerezni, de nagyon úgy éreztem, hogy kábé 2 éven belül lesz ilyen.

Felhő kolléga, kösd fel a gatyád, vagy vásároltassátok fel magatokat. :-)

Open Video Player Initiative

Thu, 15 Jan 2009 01:00:00 +0100

A napokban kaptam egy hírlevelet az Akamai-tól, hogy nézzem meg az Openvideoplayer.com-ot. A címlap csudás dolgokat ígér, például "easily create your own video players" (sitty-sutty készíts saját videólejátszót) meg egységes reklámplatform és egyebek. Hű, csatlakozzunk azonnal! Ez kell az iparágnak, tényleg! De aztán kiderült, hogy egyelőre csak egy átverés az egész.

Pedig olyan nagy támogatói logók vannak rajta: Adobe, Microsoft, Akamai... Megnéztem a dokumentációt és letöltöttem a mintaalkalmazást, rászántam egy jó órácskát.

Sajnos a fentiekről szó sincs, ráadásul a doksi osztályai mind így kezdődnek: com.akamai. A community oldalak pedig konganak az ürességtől. Leesett már?

Az egész egyelőre nem több, mint segítség Akamai-os lejátszók elkészítéséhez. Pedig milyen jó lenne, ha igazi lenne... Lesz tovább?

Amazon hírek

Tue, 13 Jan 2009 01:00:00 +0100

Összegyűlt néhány AWS hír az RSS olvasómban és már rég itt volt az ideje, hogy feldolgozzam őket. Ezeket találtam fontosnak: AWS Management Console, SLA, S3 requester pays model. Megnéztem mik ezek.

AWS Management Console

Nem volt az Amazonnak grafikus felülete az AWS szolgáltatásaihoz, ezért sok-sok szoftver született ennek áthidalására. Végülis ez egy API felület, majd megoldják a fejlesztők valahogy.

Most viszont kijött az AWS Management Console az Amazon oldalán, amivel az EC2-es műveletek többségét grafikus felületen végezhetjük. Ez a kezdőknek igazán nagy segítség. Nem kell szórakozni a publikus/privát kulcsokkal, az AWS account-tal megy minden.

Természetesen nincs benne automatikus terhelésfüggő indítás/leállítás és egyebek, így a Rightscale és társai továbbra is meg fognak élni valamiből. Ilyen sohasem lesz, ugyanis ez nem egy egzakt dolog, nem lehet "felülről" megmondani, hogy mikor kell beavatkozni. Ez image-enként és azon belül alkalmazásonként változik: valahol a CPU-t érdemes figyelni, máshol a network socket-ek számát, mégmásholabb pedig mondjuk egy rendszerszintű változót. A skálázódás nem általános dolog, azt az alkalmazásod határozza meg, neked kell megvalósítani.

SLA

Nem új hír, de nem írtam róla még itt és hátha nem hallottál róla: van olyan, hogy EC2 és S3 Service Level Agreement, magyarul SLA. Tehát nem béták ők már, hanem százalékokkal leírható rendelkezésreállások! EC2: 99.95% (kb. 6 óra leállás per év), S3: 99.9% (kb. 9 óra leállás per év). Ezek a számok igen kedvezőek a KKV-k számára, azaz a legtöbb netes vállalkozásnak pont jó.

S3 requester pays model

S3 bucket-enként beállítható, hogy a bucket tulajdonosa helyett az onnan letöltő fizesse a transzfer költségeket (sávszél + request-ek, tehát a tárolást nem). Természetesen a letöltőnek is Amazon tagnak kell lenni, anonim letöltés itt nem lehetséges és torrent sincs. Az ár ugyanaz, mintha a tulaj fizetne.

Az igazán érdekes ebben a másik fizetési modell, az Amazon DevPay feature: meg lehet mondani, hogy letöltésenként mennyit kell fizetni és az ügyfél az Amazon-os account-ján keresztül rendezi a dolgot (nem, PayPal nincs). Példa: feltöltesz egy doksit, azt mondod 10 dollár és bankkártyás fizetés után letölthető.

Mégsem olyan jó Amerikában a net? Románia dübörög?

Fri, 12 Dec 2008 01:00:00 +0100

A világ legnagyobb CDN-je, az Akamai rendszeresen közzéteszi, hogy milyen átlagos sebességeket lát az egyes országokban. Az Akamai hálózatán bonyolódik az internet forgalmának egy igen jelentős része, így a beszámoló adatainak tényleg sok köze van a valósághoz.

Dél-Korea és Japán elsősége nem csoda, ők hagyományosan évekkel előbbre járnak a világ többi részéhez képest. Az igazi meglepetés Románia és az Egyesült Államok.

Úgy tűnik, hogy keleti szomszédunk telkó vállalatai komolyabban veszik a központi infrastruktúrát. Nálunk ugye az a helyzet, hogy inkább a végpontok sebességére gyúrnak (jójó, sok helyen még arra sem, tudom), mert azt lehet reklámozni. Aztán hiába az elméleti sebesség a végfelhasználó felé, ha kicsit beljebb jól összetorlódunk.

Egyébként nagyon jól jön Románia szomszédsága, internet forgalmunk jelentős része Románián keresztül jut ki. Trace route közben csak úgy tobzódnak az ottani állomások.

USA

Csak a nyolcadik helyre csúszott be, pedig az átlagember előbbre gondolná. Érdekes, hogy ott is hasonló problémákon rágódnak, mint itt. Például azon, hogy mennyitől broadband a broadband, merthogy nemcsak nálunk hirdetik a 768kbps-t szélessávnak.

Gyanítom, hogy az USA átlagot a távoli vidék rontja le, mert azt azért nem hiszem, hogy San José-ban rossz lenne a vétel. Nem csoda, hogy Obama rá akar feküdni a dologra, ő jól jár a szélesebben elérhető internettel.

Amazon EC2 Europe

Thu, 11 Dec 2008 01:00:00 +0100

Most már van európai központ is és sokan örültek amiatt, hogy akkor most gyorsabb lesz az elérés vagy mi. Hát-hát.

A központ valójában Írországban található, ami felé nem biztos, hogy gyorsabb kapcsolattal rendelkezik az átlag hazai felhasználó. Ha Frankfurtban lenne a központ, akkor lehetne örömtüzeket gyújtani, így majd meglátjuk.

Az európai bővítés igazi haszna így nem is a gyorsabb kapcsolat/ping idő (az eddigi USA központok is hihetetlenül gyorsan érhetők el ping időileg, mintha csak a szomszédban lenne), hanem az, hogy az európai S3 bucket-ekben található tartalmak EC2-es feldolgozása olcsóbb lett.

Az európai árak pont 10%-kal magasabbak, amit a magasabb adókkal indokol az Amazon. Fogalmam sincs, hogy Írországban hogyan adóznak az Egyesült Államokhoz képest, ha valaki felvilágosít megköszönöm.

Ja és egyelőre nincs Windows instance, csak az óceán túloldalán.

Amazon CloudFront - CDN kicsiknek

Tue, 02 Dec 2008 01:00:00 +0100

A kicsik (=mi) az Amazon S3-at afféle CDN-ként használják, mert óriási terhelést bír, viszonylag olcsó és könnyű használni (nem kell szerződést kötni, tárgyalgatni, "majd visszahívnak", satöbbi). Az S3 a CloudFront-ig nem volt igazi CDN.

Elég nehéz pontosan definiálni a CDN fogalmát, de az S3 fő hiányossága az automatikus földrajzi terítés volt, amit a CloudFront-tal oldottak meg. A CloudFront tehát nem más, mint az S3 kiegészítése földrajzilag elosztott kiszolgálással és egy jó (óriási) adag marketing.

Az S3 onnan szolgált ki, ahova feltöltötted a fájlt (USA vagy EU), a CloudFront viszont a letöltő helyéhez legközelebbi parkból. Jelenleg 8 USA, 4 EU (hozzánk Frankfurt van legközelebb) és 2 Ázsiai helyszín van.

Hogyan működik?

Feltöltöd a fájlokat egy kifejezetten a CloudFront-hoz létrehozott S3 bucket-ba.
Meghívsz egy API-t, hogy az ebben a bucket-ban található fájlokat a CloudFront is szolgálja ki.
Az API-tól visszakapott név alapján megtudod, hogy mi a fájljaid CloudFront URL-je, mehet a menet.

Az alap kiszolgálási limit 1000 letöltés per másodperc összesen 1gbit/s sávszéllel, de ez egyedi elbírálás alapján ingyenesen növelhető (magyarán indokold meg, hogy miért kell több és nyilván megnézik, hogy mondjuk nem warezra kell-e).

Árazás

Csak a letöltések száma és a felhasznált sávszél után kell fizetni és picit olcsóbb, mint az S3! Az árba beleszámít az S3 és a CloudFront közötti forgalom is, azaz fizetni kell azért, ha a CloudFront lehúz egy fájlt az S3-odról.

Ez nem csak egyszer történhet meg (egyrészt több farm van, másrészt pedig a régóta nem letöltött fájlokat törli a cache-ből, ezért ismételt lekérésre is szükség lehet), de még így is elhanyagolhatóan kicsi szám.

Videó

A CloudFront csak HTTP kiszolgálást tud, nincs HTTPS, pseudo-streaming vagy RTMP. Csak a progresszív download működik tehát.

Úgy tűnik, hogy az Amazon long-tail alapon fogja megszorongatni a nagyokat (Akamai és társai), hiszen a legtöbb webes oldal/szolgáltatás kicsi, nekik a nagy CDN-ek túl nagyok (drágák, vízfejűek, rugalmatlanok).

Végre! Google Analytics Flash-re

Fri, 21 Nov 2008 17:00:00 +0100

Egy csomó munkaórám ment rá, hogy elkészítsem a saját GA implementációmat Flashben, mert az iMectPlayer-nél szükség volt GA mérésekre és nem mindenhol áll rendelkezésre külső JavaScript-es GA.

Most megkaptuk készen és kábé ugyanazt tudja, mint a JS verzió, bár szerintem a JS mindig előbbre fog járni. Beállítható, hogy "bridge" vagy AS3 módban fusson: "bridge" módban a beágyazást végző oldalban lévő JS kódot használja, AS3 módban viszont nem nyúl ki, elintéz mindent Flash-en belül.

Ráadásul a kód open source! Mekkora királyság! (Egyébként érthető, a Google nem áll túl jól AS3-as fejlesztők terén, a legtöbb Flash-es termékük AS2, a YouTube is...)

ActionScript 2-es fejlesztők figyelem, ez AS3 komponens, ideje végre átállni!

Apró pofon a Silverlightnak

Fri, 21 Nov 2008 13:00:00 +0100

A Major League Baseball egy nagyon népszerű fizetős baseball videó oldal, ahol teljes meccseket is meg lehet nézni, esetenként élőben. Fontos, pénzes és nézett dolog, a Microsoft rá is feküdt és rengeteg pénzt öltek bele, hogy Silverlight-on fusson Flash helyett. Váltottak.

A szolgáltatás minőségével állítólag semmi gond nem volt, így szerintem csak az lehetett a probléma, hogy nagyon sok gépen nincs még Silverlight, illetve az egységsugarú felhasználók valamiért nem telepítik. Ez csökkenthette a bevételt, lépniük kellett.

Ráadásul a sokat emlegetett NBC a (sikeres? nem sikeres?) jól bereklámozott olimpiai Silverlight oldala ellenére továbbra is sok helyen használ Flasht, például az NFL (amerikai fociliga) élő közvetítésére.

Továbbra sem értem, hogy az MS miért ne tolja fel a Silverlight-ot minden (Windows-os) gépre automatikusan a Windows Update szolgáltatáson keresztül. Mi lehet a gát? Egy újabb antitröszt per? A böngészőset is szépen megoldották.

A Microsoft közleménye szerint a Silverlight 2 jelenleg 100 millió internetező gépén van fent (a Flash a milliárd fölött jár), de úgy gondolom, hogy a jövőre érkező 3-as verziót (H264 és egyéb nyalánkságok) sokkal jobban megnyomják majd.

A világon kiszolgált összes videó 81%-a jelenleg Flash-sel történik.

A Flash Media Server 3.5 újdonságai

Fri, 21 Nov 2008 01:00:00 +0100

Most jelent meg, megnéztem mi az újdonság, vagy legalábbis mit mondanak. Alapvetően olyan dolgok jelentek meg, amiket ügyes fejlesztők létrehoztak már, csak most out-of-the box áll rendelkezésre.

Mindenhol a dynamic streaming-gel kezdenek, ami azt jelenti, hogyha a nézőnek mondjuk kevesebb a sávszéle, akkor a szerver kevesebbel szolgál ki, hogy ne legyen akadás (természetesen ilyenkor esik a képminőség).

Ez nem úgy működik, hogy élőben csak neked csak most újrakódolja a streamet! Azt nem bírná el a szerver CPU. Előre le kell kódolnod néhány változatot és abból fog válogatni.

Egyébként ilyet lehet a playerben programozva is csinálni, de ha a keyframe-ek nem ugyanott voltak, akkor kis akadással járt. Az FMS most állítólag megpróbálja megtalálni a hasonló keyframe-eket, hogy minél röccenésmentesebb legyen a váltás.

Érdekes, hogy live stream-eknél is működik a dolog, ott az asztali Adobe Live Encoder 3.5 képes egyidejűleg több bitrátát is kódolni és a szerver ezeket megeszi. Ha bírja az asztali CPU-d (jelenleg valószínűleg nem).

HTTP szerver

Lett benne egy egyszerű fájlkiszolgáló, de őszintén szólva őrültség a drága médiaszerverrel kiszolgálni a weboldalunk CSS és képfájljait. Érdekesség, hogy az RTMPT-vel közös portot is tud használni.

DVR

Ez azt tudja, hogy a live stream-et egyben fel is veszi, tehát erre nem kell külön dolgokat írni. Eddig úgy volt, hogyha külön nem programoztad le, akkor a live stream tényleg élő volt, ha lemaradtál egyik-másik részéről, akkor nem tudtad visszanézni.

Apró kényelmetlenség, hogy a DVR bekapcsolása plusz 2-8 másodperc késést (lag) ad az eddigiekhez hozzá.

Konklúzió

Az FMS egy csodálatos termék lenne, ha ingyen kapnánk (open source! bilibe lóg a kezem) és olyan kényelmesen + biztosan tudná elosztani a terhelést, mint a Windows (Media) Serverek.

Flash player CPU zabálás és wmode-ok

Mon, 10 Nov 2008 01:00:00 +0100

A Flash player CPU-t eszik, mint minden más. Hogy mennyit, az a benne lévő dolgoktól függ. Engem elsősorban az érdekel, hogy az általam gyártott iMectPlayer H264-es videóval hogyan muzsikál. Az alapállás eddig az volt, hogy a Flash mindent szoftveresen oldott meg különösebb hardvertámogatás nélkül. Ez a H264 esetében igen komoly hátrány, egyetlen videó lejátszása egy öreg gépet képes teljesen leterhelni.

Kaptunk rá (marketing) ígéretet, hogy a 10-es player már képes lesz a fejlettebb grafikai képességeket kihasználni. Itt van a végleges verzió, leteszteltem.

Sajnos a H264-et továbbra is szoftveresen dekódolja, pedig a legtöbb operációs rendszerben van erre már fejlettebb megoldás, hardveres képességeket kihasználó kodek, akármi. Sőt, a 10-es player a 9-eshez képest 5%-kal több CPU-t eszik a H264 lejátszásakor az én gépemen.

Wmode

Az újdonság az, hogy az embed kód wmode paraméterével többféle stratégia közül lehet választani és bekapcsolni mindenféle hardverközeli trükköket. Azért van többféle mód, mert sajnos kompromisszumokat kell kötni.

Normal mód: az operációs rendszer által kínált sztenderd API-val rajzol.

Transparent mód: a Flash objektum alatt/fölött lévő HTML (és egyéb) tartalmakat is megjeleníti, úgy viselkedik (legalábbis megpróbál), mint egy sima HTML elem. Mivel az alpha (átlátszóság) csatornát keveri, ez a mód a normálnál CPU igényesebb.

Opaque mód: csak Windows alatt van, olyan, mint a transparent, csak az objektum alatti elemekkel nem foglalkozik. Más OS alatt egyenlő a normal móddal.

Direct mód: a lehető legdirektebb módon kezeli a videókártyát, a saját területét direktben kezeli.

GPU mód: használja a videókártya néhány funkcióját, kompromisszum a normal és a direct mód között. Csak akkor ajánlják, ha egyetlen Flash objektum használja a weboldalon.

A videókártyával való viszony eltérése miatt a webes videók kissé másképpen, más színezettel, élességgel mutatkozhatnak meg az egyes módokban.

A számok

A tesztelést a saját gépemen végeztem (alu iMac, 2 GHz Core 2 Duo, 3 GB RAM). A videólejátszóban (iMectPlayer, mi más) be van kapcsolva minden trükk a lehető legjobb képminőség érdekében (pl. smoothing). Az utolsó sor egy sokkoló összehasonlító adat, ott Flash helyett ugyanazt a videót Quicktime-mal játszottam le.

mód	CPU terhelés normál méretben	teljes képernyőn
normal	35	100
transparent, opaque	42	95
gpu	28	95
direct	25	95
Quicktime	18	30

A fenti számokból kitűnően látszik, hogy a Flash nem használja ki megfelelően hardverünk képességeit. Ha lesz H.264-et lejátszó Silverlight (lesz, jövőre), akkor azzal is megnézem majd.

Sajnos a Webcsatornán a transparent módot használjuk, pedig nem kéne. Azért tesszük ezt, mert a player alsó két sarka lekerekített és átlátszó. Azt hiszem, hogy a teljesítmény oltárán ezt a kis designt be kellene áldoznunk.

Ajánlások Flash banner készítők részére

Sun, 09 Nov 2008 01:00:00 +0100

A Webcsatornán elkezdtük a Flash overlay bannerek megjelenítését. Ehhez a minap kaptam egy bannert az egyik (díjnyertes!) ügynökségtől, de nem tudtam beilleszteni, mert felpörgette a CPU-t és elszállt tőle a videólejátszó. Flash bannereket ma már nemcsak HTML kódba ágyazunk, hanem egyre inkább elvárás a Flash-be illeszthetőség is, ez a videóreklámok (egyik) jövője. Összeírtam, hogy mire kellene figyelni.

Először is leszögezem, hogy lehetséges olyan kreatívot gyártani, ami egyszerre üzemelhet a hagyományos bannerhelyeken és videólejátszós ügyekben is. Mivel eddig csak sima HTML beillesztés volt, az jótékonyan elfedte az esetleges fejlesztési gyengeségeket és bezárta a problémákat a Flash dobozába.

Az eredménnyel már mindenki találkozott: a Flash reklámot betöltő oldal lelassult, elkezdte pörgetni a processzort és pillanatok alatt anyázás meg böngésző crash lett a vége. Pedig a Flash reklámokat el lehet úgy készíteni, hogy ne jelentsen különösebb terhelést, akármilyen hihetetlenül hangzik!

A Flashbe (pl. egy videólejátszóba) illesztett Flash reklámnál ez még nagyobb gond, mert a CPU-t pörgető kód "gátolja" a szülő objektum ActionScript-jét és a timeout érték elérésekor leáll minden, azaz elszáll a teljes videólejátszó.

1. Ne legyen blokkoló (állandóan futó) ActionScript kód

Kevesen tudják, hogy minden Flash objektumnál beállítható egy timeout érték (pedig az export ablakban van, script time limit a neve), 15 másodperc az alapértelmezett. Ha egy ActionScript kód több, mint 15 másodpercig fut, akkor kampec, lemerevedik minden. Jó esetben felpattan egy ablak, hogy leállítja-e a kód futását a tisztelt felhasználó, akinek fogalma sincs ezekről, miért is lenne.

Az ActionScript kódot is korszerűen, eseményvezérelten kell megírni. Reagáljunk eseményekre, hívassuk meg a metódusainkat az események által, közben ne csináljunk semmit. Blokkoló kódot nem szabad írni! A script time limit átállítása nem megoldás! A kódunk sose fusson 2-3 másodpercnél több ideig.

A már említett (díjnyertes! :-) ) ügynökség egy olyan ősrégi animációs függvénykönyvtárt használt, ami állandóan futott. Ma már azonban gyönyörűen megírható az animáció a Tween osztályokkal nem blokkoló módon.

2. ActionScript 3 (három!)

Felejtsük el az ActionScript 2-t. Sok kritika érte az ActionScript-et, teljes joggal, azonban a hármas verzióval óriásit ugrott az Adobe. Teljesen más felfogású lett a dolog, a 2-ről 3-ra átállni elég fájdalmas és sok tanulással jár, én is szívtam vele. De korszerű és ha rááll az agyad, egy csomó mindent gyorsabban, egyszerűbben, hatékonyabban és szebben lehet megoldani vele. Szép objektumorientált környezet.

3. Használj natív Flash funkciókat

Rajzold meg a grafikus felületen az animációt, az adja a leggyorsabb futást és programozni sem kell. Ahol csak lehet használd a beépített osztályokat, lehetőségeket, szinte mindenre van megoldás (ActionScript 3-as környezetben sokkal több van, mint a régiben).

4. Videó

Vannak olyan reklámok, ahová videót kell beilleszteni. Sajnos még mindig azt látom, hogy gagyi H.263-as Sorenson kódolással készített FLV-t töltenek. Használj VP6-os FLV kódolást, amivel fele akkora méretet vagy kétszer jobb minőséget érhetsz el (pl. konvertálj Flix Pro-val). A H.264-et még nem ajánlom, mert az elérése jelen pillanatban csak 86% és kétszer annyi CPU-t eszik.

Olyat se keveset látok, hogy a videó nem pont a banner méretére van kódolva, hanem nagyobb. Minek? Csak eszed a sávszélt a semmiért. Tehát még egyszer, összefoglalva: a videófájl pontosan akkora legyen pixelre, mint amekkora kell - legyen VP6 a videó és MP3 (mono) az audió - FLV fájlban.

A bitráta legyen bőven 512kbps alatt. Hiába reklámozzák a 8 megás ADSL-t, a realitás az, hogy 95%-os elérés csak maximum 600kbps-al érhető el. A Webcsatornán sem véletlenül erre terveztünk, pedig de szívesen adnánk már 2 megán HD-ban! Sőt, mivel nem a reklámod a böngészés célja, nem tervezhetsz a teljes sávszélre.

A Flashben lehet alfa csatornázott videót is használni, ami azt jelenti, hogy a videó egy része áttetsző. Ez nagyon sok processzort eszik, reklámoknál ne használj ilyet!

5. Csökkentsd a HTTP kérések számát

Amit csak lehet helyezz el a Flash bannerben, a lehető legkevesebb dolgot töltsd kívülről, utólag. Ez jótékonyan hat a beágyazó oldal betöltésére, kevésbé "akad" meg a böngésző. Ha pici a videód (VP6-tal az lesz!), akkor akár az is mehet a fájlba, nem kell kívülről húzni.

6. Optimalizáld a libraryt

Menj végig egyesével a libraryben lévő objektumokon. Be tudod kattintani a usage count-ot, ami megmondja, hogy mit használsz és mit nem. Töröld azokat az objektumokat, amik nem kellenek, ne maradjon szemét.

Menj végig a képeken is és egyenként a tulajdonságok alatt be tudod állítani a használt tömörítést (jpg vagy png, jpg százalék). Optimalizáld szénné, állítsd be a lehető legkisebb méretet elfogadható minőség mellett. Ezzel a lépéssel akár az összméret felét is meg tudod takarítani.

7. Allowdomain

Erősebb biztonsági intézkedéseket vezetnek be folyamatosan, a 9-es Flash playerek "közepe" táján is volt egy ugrás. A Flash reklámodnak "közölnie kell", hogy milyen Flash objektumok tölthetik be. Ezt a közlést praktikusan úgy kell beállítani, hogy bármi betölthesse, hiszen reklám. A leges-legelső frame-be tedd ezt a kódot: Security.allowDomain('*'). Ennyi, de ha ez nincs benne, nem fog működni.

Konklúzió

A fentiek használatával elkészítettem a (díjnyertes!) ügynökség részére a reklámot, afféle mintaként. A CPU használatot sikerült a felére, a letöltési méretet pedig 60%-ra csökkenteni, a böngésző meg sem röccen, ha jön a reklám. Hiába pici a mérete, sokszor szolgáljuk ki, ezért 40%-os letöltési megtakarítás több tízezer (ha nem százezer) pénznyi sávszél megtakarítást jelent.

Érdemes tehát a Flash bannerek kialakításába kicsit több energiát fektetni, megtérül.

A nagy Silverlight elemzés, DRM

Fri, 24 Oct 2008 02:00:00 +0200

Jaj, hogy utálom ezt a témát, de (sajnos) van rá piaci igény. A DRM lényege esetünkben az, hogy a videónkat csak az általunk engedélyezett eszközökön lehessen lejátszani. Tehát a DRM-mel nem letöltésvédelmet, hanem lejátszási korlátozást valósítunk meg! Sokan nem tudják, hogy mi a DRM, én szóltam.

Mindkét platform kvázi letöltésvédelemmel ellátott, ha azt nézzük, hogy az egyszeri felhasználónak nem áll rendelkezésre egy "mentés másként" gomb a videóhoz, azaz a felhasználók többsége nem fogja tudni lementeni. De az "igazi" lopósok ellen ez édeskevés.

Számtalan "videólopó", videóletöltő program áll rendelkezésre, amikkel a Flash vagy Windows (Silverlight) videókat el lehet csípni, le lehet menteni saját részre, még teljesen live sugárzás ("igazi" streaming) esetén is. Egyik videómegosztó oldalon sem tudtak hatékony védelmet építeni, nézd meg az általam készített Stubes.net-et.

Kinek kell?

Vannak még olyan öreg dinoszaurusz tartalomgazdák, jellemzően nagy médiavállalatok és lemezkiadók, ahol a túlzsírosodott fejű vezetők még mindig azt hiszik, hogy van eszköz a védelemre. Nem számít nekik, hogy az összes eddigi DRM-et feltörték vagy megkerülték már (értsd: majd lehúzom máshonnan). Tehát ez a "piac" még él és ha ilyen nagy cégeket célzol, akkor biztosítanod kell a DRM-et, edukálni úgysem tudod őket, hiszen barmok.

Hogyan működik?

Nagyon leegyszerűsítve: a bekódolt videódon lefut egy izé, ami "átcsomagolja" azt úgy, hogy csak egy kulcs birtokában lehet "visszacsomagolni". Hiába kaparintod meg a videót, nem tudja a lejátszód értelmezni, csak ha megvan neki a kulcs. A kulcsokat egy központi szerveren tárolod és a lejátszód onnan húzza a kulcsot, persze mindenféle biztonsági ellenőrzés (pl. megvetted a lejátszás jogát?) után.

Kinek van?

Az Adobe nem biztosít DRM-et a webes Flash lejátszó részére, az csak az asztali megoldásoknak (Adobe Media Player és AIR) jár. A termék neve Adobe Flash Media Rights Management Server és potom 40 000 USD szerver processzoronként az ára. De még egyszer mondom, ez nem megy a böngészőbe épülő Flash lejátszóban, így tehát Flash platformon nincs DRM.

A Microsoft-nak viszont komplett megoldása van, amit nem csak Silverlightra, hanem az egész Windows médiás világra kiterjedő PlayReady márkanevű dolog biztosít (nem egyenlő a régebbi Windows Media Rights Manager-rel és PlayForSure-ral, magyarán a régebbi MS DRM megbukott). Az ára 30 000 USD szerver processzoronként, vagy ha neked sok, akkor 1 USD ezer lejátszásonként (szorozd be, ez még drágább).

Min lehet lejátszani?

A DRM-mel tehát bezárod a vevődet bizonyos termékek, lejátszók körébe. A PlayReady-vel védett webes videódat nem fogják tudni lejátszani mondjuk Linux-os masinán vagy iPod-on. Apró probléma, hogy a Microsoft Zune lejátszón sem működik, annak külön inkompatibilis DRM-je van... Tehát vagy az oldaladon nézik böngészőben, vagy pedig Windows Media Player-rel, leginkább számítógépen. Még a híres-neves iTunes-ban is lehet felárért DRM-mentes zenét vásárolni, nem véletlenül.

Összefoglalás: ha vagy akkora ökör, hogy DRM-et használj webes videóra, akkor csak a Silverlight platformot választhatod és sokba fog kerülni, de neked úgyis sok pénzed van, ha meg tudod finanszírozni, hogy ökör legyél. Illetve, pontosabban az ügyfeled egy ökör, te viszont egy csomó pénzt keresel, ami jó. A felhasználók meg majd szívnak, de inkább a pénz, mint a jó minőségű termék, nemde? Vagy nem?

Új Silverlight! Új Flash!

Wed, 15 Oct 2008 02:00:00 +0200

A tegnapi és mai nap két hosszú távra (értsd: legalább 1 évre) mutató alapvető fontosságú termék megjelenését hozta, igen rossz időzítéssel.

A gazdasági válság miatt amúgy is minden hír egy kicsit a háttérbe szorul, de a tegnapi napot egyértelműen az új Apple bejelentések vitték, óriási hülyeség volt ezzel egy időben a Silverlight 2 hivatalos kiadása. Ugyan a sajtóhír hétfői, de letölteni csak tegnaptól lehetett, amikor már mindenki az Apple oldalán böngészi a technikai paramétereket...

A fejlesztőknek ez teljesen mindegy, de a Microsoft rettentően erőlködik azon, hogy a döntéshozók számára promózza a terméket. Akik pedig nagy valószínűséggel a tőzsdeindexek mellett az Apple hírekkel vannak elfoglalva inkább.

Ma pedig a Flash Player 10 jelent meg, új telepítésnél (get adobe flash player és társai) már ez jön, Windowson és OSX-en legalábbis. Ide viszont nem kellett különösebb hírverés, a 10-es player hype már a nyáron megvolt.

Be kell terveznem néhány munkaórát az iMectPlayerbe, hogy kihasználhassam a 10-es verzió oda érdekes funkcióit.

A nagy Silverlight elemzés, enkódolás

Fri, 10 Oct 2008 02:00:00 +0200

Először is be kell kódolni a videónkat a webes lejátszónk számára érthető formátumra. A következő táblázatban összefoglalom, hogy ki mit fog támogatni 2009-ben:

	Flash	Silverlight
videó	Sorenson h.263 FLV, On2 VP6 FLV, H.264	Windows Media Video (WMV) 7-9, SMPTE VC-1, H.264
audió	Nellymoser, MP3, AAC, Speex	Windows Media Audio (WMA), MP3, AAC
DRM	nincs	Microsoft PlayReady - Windows Media DRM 10
2008-ban még nincs	Speex	H.264, AAC

A legjobb minőséget/legkisebb méretet a H.264/AAC páros adja, a videókat ebbe érdemes konvertálni (a WMV, VC-1 és a VP6 épp csak közelíti vagy eléri). Ráadásul open eszközökkel állítható elő és szinten minden támogatja, a legtöbb videólejátszó lejátsza, a legtöbb videószerkesztő kezeli, minden operációs rendszeren. Nem vagy bezárva, mint pl. a Windows Media esetében, aminek a lejátszása pl. Mac-en nem out-of-the box. Mindkét platform kezeli, ez a kérdés kipipálva az jövőben kódolandó videók esetén.

Archívum

Nade mi a helyzet a már bekódolt videókkal, azaz az archívummal? Jelentős mennyiségű cucc van FLV-ben és WMV-ben tárolva. Hazánkban úgy tűnik, hogy WMV-ben minőségibb anyag érhető el (pl. Magyar Televízió), FLV-ben pedig inkább csak a videómegosztók hosszútávon kevésbé érdekes készlete van. Ez előny a Silverlight részére, ha nem akarunk konvertálni. Viszont miért ne akarnánk? Elemezzük ezt is:

Ha Flash platform-mal szeretnénk WMV archívumot lejátszani, akkor azt először át kell kódolni H264/AAC-be és az eredmény bitrátája legyen 1.2-szeres, hogy észlelhető minőségromlás ne következzen be. Ez a tárhelyigény 20%-os növekedését vonja maga után (a tárhely ma olcsó!), illetve a konvertálásra kell egy kis programocskát írni. A tömeges átalakítást az Amazon EC2 platformján érdemes szimultán módon végezni és így néhány tízezer Forintból megvan az egész néhány nap alatt. Ugyanezt visszafelé (FLV-ből H264-be) is így érdemes, ha esetleg FLV-ket szeretnénk Silverlight-tal.

Egy szó mint száz, ha nem akarunk konvertálni, akkor meg van kötve a kezünk. Ha akarunk, akkor pedig indítsunk erre egy projektet, aminek a költsége fejlesztői díjjal, fejlesztőidővel, Amazon pénzzel együtt kb. 3 hét és az archívum méretétől függően 100e Ft fölött, de 1 millió Ft alatt van. Kábé. Természetesen archívum alatt ne 20 videót tessék érteni, hanem legalább több százat.

Enkódoló programok

Mindkét platform ad eszközt a kódolásra. Az alap kiszolgáló szerverek is tudnak valamennyire kódolni (Flash Media Server, Windows Server), de az igazi minőséget ezekkel nem lehet elérni. Ahhoz vagy asztali enkóder kell, vagy pedig egy tömeges szerveroldali megoldás. A gyári asztali megoldások: Microsoft Expression Encoder és Adobe Flash Media Encoder, a gyári tömeges cucc: Windows Media Encoder és Flash Media Encoding Server (ez kényelmesebb).

Vannak third-party megoldások, pl. az On2 termékei a Flash-hez (Flix család), továbbá nagyon sok ingyenes asztali eszköz is tud konvertálni ezekbe a formátumokba, valamelyik jobban, valamelyik rosszabban (mármint minőségügyileg).

Engem továbbra is a H264/AAC-be konvertálás érdekel és erre van egy svájcibicskám, az FFMPEG. Ingyenes, szénné optimalizálható, olvassa a legtöbb formátumot (általában többet, mint bármi más), fut egy csomó operációs rendszeren (Win, Mac, Linux hegyek), felhőbe tehetem (pl. Amazon), használhatom az asztalon, szerverre telepíthetem, nyílt, testre szabható, parancssorból fut (scriptelés rulez), ingyér van és rengeteg a magyar vonatkozása. Minek foglalkozzak a többi konvertálóval? Azok az FFMPEG-hez képest bezárnak. Cserébe persze pilótavizsgás, ha a maximumig ki szeretnéd használni.

Egymondatos konklúzió

Kis előny a Silverlight részére az archívumok terén, a többiben pedig egál.