szantog.com - legfrissebbek

Hazai fejlesztésű DJ alkalmazás iPhone-ra profi DJ-knek

Wed, 13 Jan 2010 01:00:00 +0100

Azonnali közlésre: Az iMect Bt. a német Stereomusik-kal együttműködve adta ki a DJ PLAYER sorozat első darabját, mely a "Blue Edition" névre hallgat.

Több nemzetközileg ismert DJ is bekapcsolódott a fejlesztésbe, hogy "játék" helyett egy igazi, a DJ pultban is jól használható alkalmazás készülhessen el. Óriási harc folyt minden egyes pixelért, hogy a készülékek kis mérete ellenére se kelljen közelről vakoskodni a pultban. Kiemelt szempont volt a lehető legkisebb késleltetés, sikerült a legtöbb asztali "hardvernél" is gyorsabb eszközt készíteni.

A megszokott lejátszó funkciók mellett egy teljes értékű effekt szekciót is kapott a szoftver, a TouchPad mellett a készülék billentésével is vezérelhetők az effektek paraméterei.

A DJ PLAYER "ütötte ki" elsőként az Apple-nél a "DJ biztosítékot", ez volt az első professzionális DJ szoftver, ami miatt az Apple több, mint 10 hónapig gátolta a hasonló termékek megjelenését az App Store-ban. Az okok nem ismertek, de december hónap folyamán többször is telefonon kértek elnézést Szántó Gábortól (iMect ügyvezető) ezért, ami legalábbis furcsa az Apple-től.

A DJ PLAYER Blue Edition ára 24.99 USD, mellyel a prémium kategóriát célozza meg. Árcsökkenés hosszú távon sem várható, de hamarosan megjelenik majd egy ingyenes próbaverzió. A magas ár miatt az sem valószínű, hogy bármilyen App Store toplistában megjelenne a szoftver, de az eladások így is várakozáson felüliek.

Weboldal: http://djplayer.net Videó: http://www.youtube.com/watch?v=vpWRxPmFJ-4 Sajtófotók: http://djplayer.net/page/product_media

Web, mobil és buli, fejlesztés a legújabb technológiák irányában. Videós CMS-től a lasertag diszkóig, ez az iMect: internet, média és egyéb király dolgok.

A német Stereomusik több, mint 30 éves tapasztalattal rendelkezik professzionális audio berendézesek tervezésében és gyártásában, melyeket aztán főként ismert világmárkák számára licencel, így a vásárlók sokszor nem is tudják, hogy Stereomusik terméket használnak épp.

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").

DJ PLAYER Blue Edition

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

Január 30-a óta vártam rá, hogy bekerüljön az App Store-ba, hát végre. Minden, amit érdemes tudni róla, meg amit egyáltalán elárulok. :-)

A nyár folyamán több (nálam sokkal nagyobb és erősebb) cég is DJ alkalmazások fejlesztésébe fogott, amiket szeptember környékén szerettek volna kiadni az App Store-ban. Még augusztusban összeálltam egy német csapattal, akik több ismert cégnek fejlesztenek DJ termékeket (pl. Stanton, Vestax), velük pedig felcsillant a remény, mert vannak kapcsolataik.

Persze mindig is voltak bent komolytalan alkalmazások ilyen-olyan "DJ" névvel, de csak november közepén kezdődött el az igazi, tényleg használható szoftverek beengedése, hála az egészpályás letámadásnak (több belsős Apple kontakt, a többiek médiazaja, satöbbi). Ezzel persze elveszett az elsőség, az Apple meg kapja be.

Azt feltétlenül megjegyezném, hogy próbálkoztam én mindenféle szívélyes e-maileket írni a nagy amerikai blogoknak, hátha fel tudom kelteni az érdeklődést, hiszen minden szir-szar 6-7 hetes csúszásokat is megírnak, én meg már ezer hónapja várok. Á, semmi esély, pedig egész jól tudok külföldi kapcsolatokat szerezni. Sajnos nem vagyok benne a kis szilícium-völgyi mutyiban, nem foglalkoztak velem.

A szoftverről

A DJ PLAYER az asztali médialejátszók versenytársa (CDJ és klónjai), szinte mindent tud, amit kell, ráadásul egy komoly effektrész is került bele. Nem igazán arra való, hogy ezzel szaladgálj a városban, inkább a DJ pultra terveztük. Még sötétben is könnyen eltalálhatók a vezérlők, nem kell közelről matatni rajta. Minden egyes pixelért vérre menő csatákat folytattunk, sok-sok profi DJ eltérő igényét kellett kielégíteni.

Nagyon fontos volt az alacsony késleltetés (latency), ezért az alap UIKit-es kontrolkezelést szinte teljes mértékben ki kellett játszani. Meglepően kicsi lett a CPU étvágy, egy mp3 folyamatos kikódolása és lejátszása a teljes UI-val együtt mindössze 18-20%-ot eszik a legrégebbi 2G-s iPhone-on, ez a jellemző terhelési érték. Egy effektel megspékelve 30-40%, kivéve a reverb-et, úgy már 60-70%. Érdekes, hogy a korai fázisban a folyamatos időkijelzés (másodpercenként 15-20-szor) ette meg a legtöbb procit, képes volt akár 30%-is harapni, ezért saját rendert kellett írni hozzá.

A minőségre garancia a béta-tesztelők köre, a Media2Radio-nak köszönhetően könnyű volt nemzetközileg ismert arcokat szerezni, pl. a Numark fejlesztési vezetői, Victor Calderone, Misjah... A szoftver neve pedig azért "Blue Edition", mert lesz még több is, ez meg olyan... kék színű. Csak nem fogjuk "basic"-nek hívni.

Egy lejátszó?

Igen, egyelőre ez csak egy darab lejátszó keverő nélkül, hiszen az iPhone-nak csak 1 db sztereó kimenete van, amatőr megoldásokba (pl. szétválasztás két monóra) nem szeretnénk belemenni. Dolgozunk rajta.

A többi alkalmazáshoz képest drágán adjuk (5 rugó környékén) és a képernyőképekről talán nem is derül ki igazán, hogy mit tud, mert nem eléggé csillog-villog. Profiknak szánjuk, nem pedig a szélesebb tömegeknek, ráadásul az App Store-os eladások nem igazán fontosak az üzleti tervben.

Azt sem gondoltuk, hogy egyáltalán bekerül... úgyhogy most kapargatjuk össze a marketinget, ehhez dobtam össze gyorsan ezt az intró videót. Még rendes weboldala sincs, de majd lesz szebb, színesebb és szagosabb is.

iTunes link.

Harmonic mixing

Mon, 02 Nov 2009 01:00:00 +0100

A harmonic mixing egy olyan DJ technika, ahol nemcsak a számok tempóját veszik figyelembe, hanem odafigyelnek a hangzatra is ("milyen akkordokat használ"). Először cool DJ-zéssel kezdünk, aztán átmegyünk nerdbe, végül a geek tudással megvalósított iPhone-os alkalmazásommal térünk vissza a DJ pultba. Hosszú olvasnivaló.

Sok kezdő/béna/igénytelen DJ szinte kizárólag úgy kever, hogy megvárja a szám végén lévő "üres" (jóformán csak groove-ot tartalmazó) részt és ott úsztatja be a következőt. Ezt hívják "free beats" technikának, ami rendkívül unalmas tud lenni. Azt pedig pláne rühellem, ha egy számot 6-7 percig is hagynak menni, kevés olyan zene van, ahol tényleg szükséges a megfelelő hatás eléréséhez. Ha a teljes szett ilyen, akkor egyszerűen béna a DJ, bár a legnagyobbak is sokszor lusták.

A harmonic mixing-gel úgy lehet keverni, hogy a mix ne legyen disszonáns ("hamis"), hanem szépen egymásba ússzhasson a két zene, így nem kell megvárni a végét és érdekesebb az egész. A DJ szett hangulata folyamatosan kellemes lehet, de drasztikus pozitív hangulatváltó hatás is elérhető a megfelelő hangzat kiválasztásával.

A harmonic mixing alapja a zenére jellemző "alapakkord" megtalálása, azé az akkordé, amelyik a legtöbbször vagy legerősebben van jelen. Ez nem új technika, régen a DJ-k leültek a zongora mellé és addig nyomogatták a különböző akkordokat, amíg nem passzolt, aztán felírták jól. Természetesen megérkeztek már azóta a harmonic mixing szoftverek.

Mixed In Key

Ez a leghíresebb/legjobban marketingelt harmonic mixing szoftver, aminek a készítője birtokolja a Camelot jelzésrendszert. Ez semmi mást nem csinál, mint könnyen megjegyezhető és az óra számlapjára asszociáló jelzést ad az uncsi akkordneveknek.

Nagyon egyszerű a használata, az a szabály, hogy a következő szám csak 1 órával térhet el a jelenlegitől, tehát ha a 6-odikban vagyunk, akkor lehet 5 vagy 7. Hangulatváltást pedig úgy lehet elérni, hogy az azonos órában lévő ellenkező modalitású akkordra váltunk (pl. 6B-ről 6A).

Aki nem jártas a zenélésben: a harmonic mixing alapvetően kétféle modalitással foglalkozik, ezek a Major (magyarul dúr) és a Minor (magyarul moll) neveket kapták. Azért fontosak ezek, mert a Minor (A) szomorkásabb hangulatú, mint a Major (B).

Profi DJ mixeknél általában "körbejárnak az órában", a számok +1 órával következnek egymás után. Ha lanyhul a hangulat, akkor a következő szám +7 vagy +2 órás bedobása (hirtelen váltással vagy free beats-szel, különben disszonáns lesz) sokat segít, mintha "megnövekedett volna az energia" - ezt hívják "Energy Boost Mixing"-nek.

A Mixed In Key nem jó fej, licencdíjat kér a Camelot jelzésrendszer használata után. Állítólag patent pending a dolog, de néhányan rákérdeztek már, és a cégvezető állítása szerint a Camelot a Mixed In Key akkordfelismerő algoritmusában van védve (???). Ráadásul ez csak a "circle of fifths", azaz a kvintkör átnevezgetése, amit pedig nem biztos, hogy egyáltalán le lehet védeni.

Szóval a jogi helyzet kissé tisztázatlan, a cég pedig "keni" a dolgot, a rivális Beatunes épp ezért inkább kivette a Camelot jelzéseket és egy "arra utaló" izével helyettesítette. Én az iPhone-os alkalmazásomba épp ezért nem tettem be a Camelot kört, de a jelzést igen, hátha nem lesz belőle gond.

Algoritmus

Az akkordfelismerés nem egyszerű dolog és nincs rá kész vagy könnyen újrahasznosítható megoldás. A cégek védik a saját eljárásaikat, így az egyszerű halandó egyetemi és egyéb tudományos publikációk elmélkedéseiből indulhat csak ki. Én is ezt tettem, ilyeneket olvasgattam egy-egy kósza pillanatban és próbáltam kitalálni, hogy mit és hogyan kellene - szolid fél évig. Ebben sokat segített a Velence - Déli pályaudvar viszonylat lassúsága.

Aztán nekiültem és kb. 1 hét alatt kikísérleteztem a saját metódusomat, ami 80-90%-ban egyező eredményeket ad a többi szoftverhez képest. A különböző szoftverek sokszor különböző értékeket adnak, így ez a százalék bőven elegendő ahhoz, hogy jónak ítéljem meg az eredményeket. Dióhéjban és az igazi "titkok" felfedése nélkül a következő a módszer:

1. Kb. 0.37 másodperces hangmintákra kell felbontani az audiót, ezeket kell külön-külön megvizsgálni. Azért 0.37, mert így lesz a legkisebb a zengések és egyéb effektek által keltett felharmónikusok hatása, ez a legjobban közelítő statisztikai érték, ami minden zenére jó.

2. FFT analízissel kell felbontani a hangmintát, ezzel kapod meg, hogy egy megadott frekvencián mekkora volt a hangerő. Az FFT egy külön tudomány, ablakozni kell és egyebek. Mindenki látott már FFT eredményt, hiszen a leggyakoribb FFT kijelző az audió spektrométer:

3. A C1-B6 hangjegyek által határolt tartományt kell megvizsgálni (kb. 32-1975 Hz), az FFT-t érdemes minél részletesebbre venni és a hangjegyek között szépen elosztani (egy hangjegyre általában több FFT adat jut, de okosan kell szétosztani őket).

4. Normalizálni kell az adatokat, hogy a halkabb minták is érvényesülhessenek. Érdemes persze egy minimumot is megadni, például -70db-es átlaghangerőnél már biztosan nem fontos egy hangminta.

5. Az akkordok modalitásának van egy jellemző "profilja", ami az akkordban lévő egyes hangok hangerőinek egymáshoz való viszonyát mutatja (pl. az első hang mennyivel hangosabb az ötödiknél).

Ezt a profilt kell illeszteni a normalizált FFT értékekre, hogy megtaláljuk a leginkább közelítő akkordot. Nem olyan rettentő régi dolog, a 80-as évek végén fedezte fel Carol L. Krumhansl és csak 2000 körül tökéletesítette David Temperley.

6. Végül a közelítő akkordokat kell ügyesen súlyozva átlagolni, hogy megkapjuk a végeredményt.

Harmonic Mixing for iPhone

Szerencsére ebből a bonyolultságból a felhasználó már semmit sem vesz észre, így néz ki az alkalmazás, mindössze két gomb van rajta:

Sajnos a már említett licencgondok miatt nincs rajta Camelot jelzés. A design from-scratch készült a kis kezemmel Photoshopban. Sokat kellett dolgozni azon, hogy a bonyolult matekizé elfusson iPhone-on is, de végül jó eredmény született, mert az alkalmazás jellemzően csak 40% CPU-t eszik detektálás közben iPhone 2G-n.

iTunes link.

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.

A jailbrake lassítja az iPhone-t?

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

Jópár helyen olvastam már, pl. Handrástól egy Appleblog-os kommentben, hogyaszondja "Allandoan jossz azzal, hogy milyen lassu a telefonod, de ha vegre kiirtanad azt a jailbrakes szart ami allandoan fut, akkor mingyar gyors lenne :)". Nade az én telefonom jailbrake-s és nem lassabb, mint a gyári, ezért megnéztem, hogy mi okozhatja.

A jailbrake sokat segít az iPhone fejlesztőnek, beesesházni a telefonra jó dolog (megnézni mi hol van, mi lesz a fejlesztett app-pal, hova kerül, satöbbi). Így kaphatunk bash parancssort is és fel lehet tenni a top unix-os segédeszközt, amivel monitorozható, hogy mi eszi a mennyit.

A top szerintem jobban használható, mint az XCode-os Instruments CPU monitorja, de ez más téma. Itt van a telóm top-ja egy olyan pillanatban, amikor épp semmi nem fut:

Látható, hogy a rendszer terhelése szinte 0, a jailbrake-s cuccok nem esznek semmit.

Mik futnak?

SCHelper: System Configuration Helper: alapvető rendszerbeállítások kezelése, pl. IP cím, WiFi beállítások, stb. - nélküle nem megy szinte semmi.
bash: Ez a shell (Windows-osoknak: "parancssor"), ahonnan elindítottam a top-ot.
sshd: SSH démon: SSH-val jelentkeztem be a telefonba.
MobilePhone: A telefonkezelő (hívások bonyolítása, minden, amitől telefon az iPhone).
SpringBoard: Az ikonokat is tartalmazó indítóképernyő/asztal.
apsd: Apple Push Service Daemon: Push értesítések démona.
CommCenter: SMS és hasonlók kezelése, de szinte az összes kapcsolatra hatása van, nélküle nem lehet telefonálni, WiFi-zni, Bluetooth-olni.
accessoryd: A készülékhez kapcsolt kiegészítők kezelése (bármi, amit az alján lévő [dock] konnektorba dughatsz) + TV kimenet.
configd: Ez is valami rendszerbeállítás-kezelő izé, állítólag főleg hálózati bigyó. :-)
fairplayd: A DRM-mel védett számok lejátszásához kell, ezt az "iTunes DRM".
mediaserverd: Ez a keverő démon, ez keveri/hangerőszabályozza a különböző audio csatornák (pl. mikrofon, fejhallgató) és alkalmazások hangjait.
lockdownd: Egy csomó "biztonsági" és aktivációs dolgot csinál, védi az Apple-t attól, hogy neki nem tetsző dolgokat műveljenek a telefonnal. A jailbreak/unlock miatt ez már biztos nem az eredeti a telefonomon.
BTServer: Bluetooth-kezelő démon.
mDNSResponder: Multicast DNS Service Discovery: DNS, Bonjour és egyéb nevek feloldása.
notifyd: Rendszerüzenetek kezelése processzek között.
launchd: Alkalmazások/folyamatok/démonok indítása/leállítása és hasonlók.

Winterboard

Sok Jailbrake-es beállítással/alkalmazással együtt felkúszhat a Winterboard is, ami az Apple-féle indítóképernyő (Springboard) feltúrbózott/széthekkelt változata.

NA EZ AZ A "JAILBRAKES SZAR", AMI CPU-T ZABÁLJA.

Persze eheti még több más rosszul megírt "illegális" alkalmazás is, de a legtöbb laikusnak a szép háttérkép miatt feltett Winterboardja lassítja az iPhone-ját, nekem folyamatosan 20-30%-ot evett meg.

Ne tedd fel, ennyi az egész.

Egyébként a Winterboard-dal érkező Supreme Preferences nevű xar pedig még teleszemeteli a logot is, minden app indítása előtt lefut és ilyen hülyeségeket írkál be (még XCode-ból futtatott "legális" fejlesztési processznél is):

Supreme Preferences. This makes springboard ya bitch ;)

Update

Igen, direkt írtam, hogy jailBRAKE (fék) és nem jailbreak. Poénnak szántam, nem jött be? Nem.

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.

Előkészületek és alapozás

Mon, 31 Aug 2009 02:00:00 +0200

Az építkezés megkezdésének volt néhány feltétele, amit az alapozás megkezdéséig (kb. március eleje) biztosítani kellett. Egyedül áram volt a telken, de a többi közművet hiába rendeltem meg, tudtam, hogy nem lesznek meg időben.

Először a kútnak fogtunk neki még novemberben, hiszen víz nélkül nincs alap. Egy helybélit bíztam meg vele, ő ismeri legjobban a terepet, a talajviszonyokat. A talajvíz kb. 14 méteren van (enyhe dombon vagyunk), így egy talajvizes kút fúrása kb. 200e Ft-ra jött volna ki: ebben 30 méteres mélység van a jó vízhozamhoz és mellé gyöngykavicsos szűrőréteg kialakítása.

Inkább a karsztvizes megoldást választottuk, mert csak 50e Ft-tal drágább és ivóvíz-minőséget ad tuti vízhozammal. A karsztvíz fölött vízzáró réteg van, a talajvíz nem ér el oda, viszont 60 méterre kellett fúrni. A kútban így van 36 méter cső és alatta a vízgyűjtő.

Szerencsénkre volt a telken némi építési/hulladék fa, így gyorsan összedobtunk egy kocsibejárót a kutasnak (végig árok van mellettünk). Egy hétig dolgozott, az utolsó két napban már nem fúrt, "csak" a vízgyűjtőt alakította ki. Elég bonyolultnak tűnt a dolog, nem is hittem volna. Fúrás közben folyamatosan figyelte a feljövő szmötyit és szorgosan jegyzetelte, hogy milyen mélyen milyen föld van.

Egyik nap szívott is egy nagyot, mert a fúrással laza homokos rétegben nem lehet megállni, így sötétedés után is addig kellett dolgoznia, amíg meg tudott állni. Miután elkészült a kút, letesztelte és bemérte, hogy milyen teljesítményű szivattyút milyen mélyre kell elhelyezni adott vízhozamhoz.

Szerencsére sikerült az egyik barkácsáruházban ráakadni az általa ajánlott olasz (egyébként hiánycikk) szivattyúra, ami ráadásul a kínai tesók árában volt 40e Ft-ért (TM-10). 11-14 méteren kellett elhelyezni, amihez kellett jó erős műanyag kötél meg 1-es slag, hogy amíg felér a víz ne legyen szűkítés (ne erőlködjön). Ez az összeállítás mindössze 750W-tal 35 liter/perc vizet hoz fel, bármilyen hosszú ideig (azaz nem fogy ki). Ez a 35 liter/perc kábé olyan, mint a vezetékes víz maxigázon, bőven elég.

Bár még nem vizsgáltattam be az ÁNTSZ-nél, azért lehet sejteni, hogy ivóvíz minőségünk van. 2 hétig ezt itták az ácsok, utána mi is rákaptunk, mert nagyon finom, hideg és hihetetlenül átlátszó - fél év alatt még senkinek sem lett baja tőle.

WC

Minden építkezéshez kell egy budi (előírás és szerződési feltétel!), amit édesapám a szomszédja leselejtezett parkettájából ácsolt össze lapraszerelve, majd a helyszínen pikk-pakk telepítettük is (tiszta IKEA), épp az alapozás (március) előtt. Összköltség: 0 Ft. Barkácsáruházban készen 30-40e Ft, mobil WC pedig 3 hónapra horror. Mondjuk a pikk-pakk telepítés az első napon a nagy szél miatt nem sikerült, gyakorlatilag a szél egyedül pakolta le a táblákat a kocsi tetejéről, jó kis vitorlák voltak.

Még műanyag deszkát is raktunk bele, a melósok pedig szépen belakták (WC papír, stb.), csak a csöcsös képeket hiányoltuk. Már nincs az eredeti helyén, most a kert sarkában szolgál szerszámosként. :-)

Ideiglenes kocsibejáró

Szükségünk volt egy "melós" kocsibejáróra az árok miatt: jó szélesnek és erősnek kellett lennie, hogy elbírja a teherautókat és a mixert, tehát úgy 30-40 tonnát... A végleges (vasbeton) kocsibejáró ezeket nem bírta volna el, összetört volna, mint a ropi.

Ezt is sikerült 0 Ft-ból megoldani, volt a telken némi építési hulladék, onnan kikukáztunk két 30-as műanyag félcsövet, aztán jött rá némi föld, betonhulladék, megint föld, megint betonhulladék, megint föld...

Novemberben készítettük, így volt ideje télen "összeállni", majd pedig az alapozáskor tömörödött meg a betonmixer alatt, jó 10 centit süllyedt a teteje. Még most is bírja a strapát, pedig az oldala már többször bedőlt. Lassan el kell majd bontani, de annyira összetömörödött, hogy a csákány sem igazán viszi, a víz már nem árt neki, valami gépi trükk kell, nem is tudom.

Építési-szerelési biztosítás

Ilyet is kellett kötnöm, mert az építési vállalkozónak a még be nem épített anyagokra ugyan van biztosítása, de ha már be van építve, onnantól az én felelősségem. Ez 50e Ft volt és másfél óra ügyintézés. Nagyon fontos.

Alapozás

Kicsit hosszúra sikerült ez a tél, így csak márciusra lett olyan idő, hogy az előrejelzés szerint 1 hétig nem volt fagy és nappal legalább +5 a meleg. Mindössze 6 nap alatt végeztek vele, pedig teljesen hagyományos sávalap készült, semmi extra. Hétfőn kitűzték (kimérték és madzagokkal megjelölték) és ki is ásták, szombat délelőtt pedig már csak a készet láttam.

80-100cm-re ástak, itt van hazánkban a fagyhatár. Aztán ezt majdnem színig töltötték betonnal, arra pedig két sor zsalukő került (vasalva). A zsalukövekbe is beton jött, majd pedig kitöltötték az alap közeit földdel és sóderral, jól bevibrálva (tömörítve). Erre szigetelést tettek, majd pedig az egészre egy 10 centis vasbeton lap került (a szerelőbeton). Ja, és persze közben behelyezték a víz bemenő és lefolyócsöveket is.

Ezután már csak annyi dolgunk volt, hogy az első két hétben naponta locsoljuk az alapot, aztán pedig kétnaponta, háromnaponta: eltartott egy hónapig és jó sok benzin kellett hozzá (Kispestről). Ezt hívják a beton utókezelésének, nélküle "megég" és nem lesz olyan tartós, úgyhogy csak mi csináltuk vagy megbízható családtagok, mégiscsak az alapról van szó.

Végül az alapozás után egy napig takarítottuk a telket, összeszedtük a törmeléket, betont, kavicsokat, hogy ne legyen dzsuva. Ezt a jó szokásunkat megtartottuk az építkezés végéig, így egy későbbi gyepesítéshez nem kell majd földet hozatnunk marha drágán.

Papírmunka

Mon, 13 Jul 2009 02:00:00 +0200

Az építkezés időigénye 3, a papírmunkáé pedig 7-8 hónap, undorító, ezért egy bejegyzésben le is tudom. Fúj. Először szerződést kell kötni az építési vállalkozóval, utána megterveztetni a házat, aztán jön az építési engedély. Hitelt a bankok csak akkor adnak, ha már beépítetted az önrészt (pl. áll az alap), szóval az a legutolsó, hiába lenne a költségvetés a legfontosabb.

Gyakorlatilag 1 hét alatt megállapodtunk a részletekben: úgy haladtunk, hogy a kulcsrakész kivitelezésből kivettük azokat a részeket, amiket mi is meg tudunk csinálni, így olcsóbb. A vállalkozó adott egy részletes listát az építési fázisokról (ez lett a műszaki melléklet), beárazta azokat, mi pedig alkudoztunk. A végösszeg ekkor még egy becsült dolog volt a körülbelüli négyzetméter alapján.

Itt hagytuk ki például a garázst: kicsit luxus 3-5 millió Ft-ért a házba terveztetni, ennyibe kerül egy komplett autó. Elfér majd az udvaron, saját kivitelezéssel, sokkal olcsóbban.

Ezután aláírtuk az (elő)szerződést és indult a tervezés. Itt rengeteg mindent figyelembe kell venni. Érdemes végigmenni a mindennapi folyamatokon, például a mosásnál: honnan hozom a ruhát, hova teszem, hol legyen a mosógép, aztán hol szárítok, merre fordulok. És még bele is kell férni 90 négyzetméterbe, de jó legyen a bevilágítás (honnan süt a nap, mikor) és a terasz se az utca vagy a szomszéd felé nézzen, satöbbi. Meg kell felelni a szocpol feltételeinek (helyiségek száma, mérete, költséghatárok), valamint épp ekkor változott az OTÉK is ("építési törvény"). Egy hónap kellett hozzá és az eredmény a "Lakóépület építése - építési engedélyezési tervdokumentáció".

The quest for építési engedély

Közben elkezdtem járni a közműszolgáltatókat, hogy beszerezzem a hozzájárulásukat az építési engedélyhez. Víz, csatorna, gáz, áram, kéményseprő - mindegyik máskor ügyfélfogad és más papírokat kér. Ehhez persze többször is el kellett mennem a székesfehérvári Földhivatalba (csak az ad térképmásolatot), meg egyéb helyekre beszerezni mindenfélét, rendszerint vidéken. Ráment a teljes november, pedig minden héten két napot is elszúrtam vele. Ha valakinek "normális" 8 órás állása van, akkor elképzelni sem tudom, hogy hogyan intézi el.

Egyébként ez egy undorító, törvényileg bebetonozott tuti biznisz a semmire.

A vizes úgy adta ki a hozzájárulást, hogy be kellett fizetnem 2400 Ft-ot a postán (náluk nem lehet, sárga csekk) azért, hogy 5 másodperc alatt kikeresse a címem a gépén (van-e ott vízcső?) és bepötyögje a Word sablonba az adatokat. A kéményseprő 20 másodpercig tanulmányozta a terveket és utána kinyomtatta a hasonló sablont, hétezerért. Tuti üzlet, államilag rögzítve.

December elején sikerült beadni az építési engedély kérelmet az összes szükséges papírral és aláírtuk a végleges építési szerződést is. Innentől kezdődött az idegtépő várakozás, mivel közben válság volt, a bankok össze-vissza alakították a hitelkonstrukciókat, szinte naponta változott, hogy kapunk-e hitelt vagy sem.

Mondanom sem kell, hogy a hivatal kihasználta a maximális 60 napot az engedély megadására, február elejére kaptuk meg. Ekkor azonban az még nem "érvényes", azaz nem jogerős! Csak akkor, ha az összes szomszéd (2 oldalsó + 1 hátsó) tértivevénnyel megkapta a határozatot és a kézhezvételtől számítva 15 napon belül nem fellebbez. Ha mondjuk külföldön van a kedves szomszéd X hónapig, akkor addig kellene várni...

Úgyhogy kikértem a szomszédok tulajdoni lapját, aztán elkezdtem nyomozni utánuk - a szomszédban még nincs építmény, sosem láttam őket... a hátsó pedig szántóföld, remek! Kettő telefonszámát megtaláltam a telefonkönyvben, egynek pedig elkocsikáztam a címére, hátha szerencsém lesz. Mázli, de minddel sikerült találkozni két nap alatt és lemondattam őket a fellebbezési jogukról, mert február közepén jártunk már és gyorsan kellett intézkedni. A hivatalban megadták rá a "jogerős" pecsétet, úgyhogy végre mehettem a vállalkozómhoz és a bankhoz.

Február közepe...

A vállalkozó nekilátott a kivitelezési terveknek (ezek nem a hivatalnak, hanem a munkásoknak és a házgyárnak szólnak), a banknál pedig elindítottuk a hitelfelvételt. Ehhez kellett még egy raklap mindenféle irat, beleértve sok feleslegeset is (pl. a jegyzőnek kell igazolnia a szocpolhoz, hogy van egy gyermekünk, de akkor minek a születési anyakönyvi kivonat?).

Hitel

A hitelfelvétel egy közvetítőn keresztül, kvázi "csókos" módon történt. Megismertük személyesen a fiókvezetőt és minden ügyintézőt - ennek ellenére sem volt zökkenőmentes a dolog, pedig minden papírt időben és hiánypótlás nélkül hoztunk (Ani nagyon ért az adminisztratív ügyekhez). Egyszerűen nem hiszem el, hogy valaki bemegy az "utcáról" és sikeresen veszi ezeket az akadályokat.

Persze ez építési hitel, jóval bonyolultabb, mint a "sima" lakásvásárlási. A bank előírásai miatt az építési vállalkozóval is módosítani kellett a fizetési ütemezést, illetve minden ütem után (jó pénzért) kijön az értékbecslő és ellenőrzi, hogy megtörtént-e aminek kell. Márciusban kezdtük a banki ügyintézést, május végén pedig az első részlet folyósításával (közvetlenül a vállalkozónak) nyugodhattunk meg, hogy megvan a finanszírozás. Kicsit parás volt, hiszen már márciusban elkészült az alap és május 5-én kezdődött a házállítás...

Alles zusammen

Ezekre a helyekre kellett járnom az utóbbi hónapokban, mindenhova többször:

Kispest, Polgármesteri Hivatal (szocpolhoz)
Gárdony, Polgármesteri Hivatal (építéshatóság)
Kápolnásnyék, Polgármesteri Hivatal (közmű ügyek)
APEH (Haller utcai rettenet)
DRV kirendeltség (vízművek, Velence)
E.ON ügyfélszolgálat (gáz + áram, Székesfehérvár)
Kémény Zrt. (kéményseprő, Székesfehérvár)
Földhivatal (Székesfehérvár, egyszerűbb ügyekben Pesten a Lurdy-ban)
hitelügyintéző
K&H kispesti fiók
Posta (épp ahol kellett)
víztervező + kivitelező
gáztervező
Anico Kft. (építési vállalkozó)
tervező (Navaran)

Ami a lényeg: nem szabad idegeskedni, hogy mit mi után, mennyi van még hátra és hasonlók, csak mosolyogva irány az ügyintéző és akkor ő is kedves és segítőkész lesz. Valamint legyen meg minden papír egy fakkban, akkor mindig kéznél lesz és sok kört spórolsz ( = "bugyi", mert mappákba már bőven nem fér).

De azért így is ledaráltam kb. 3 ezer km-t csak a papírügyek miatt, az meg úgy 5 tank benzin a Corsánknak. A Földhivatalban összesen 30e Ft-ot hagytam, pedig igyekeztem optimalizálni. Eddig összesen 750e Ft-ot költöttünk tisztán adminisztratív dolgokra (pl. ilyen-olyan bekötés adminisztrációs díja, illeték, közvetítői díj, ügyvédi költség) a tervezés díján felül, vagyonszerzési illeték nélkül. Mielőtt megkérdezitek: a vagyonadó szerint kb. 12 millió lesz az egész értéke...

Sajnos a papírdolgoknak még nincs vége, hátra van még a használatbavételi eljárás (ismét körbejárhatom az összes közművest) és a személyes + céges papírok átírása kismillió helyen.

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.

A csatlakozás az iPhone Developer Program-hoz szívás

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

iPhone App Store-os alkalmazás fejlesztéséhez csatlakozni kell az iPhone Developer Program-hoz és ezután lehet legálisan tesztelni az eszközön, valamint alkalmazásokat tolni az áruházba. Ez egy nagy szívás volt, de nem a papírmunka, hanem a várakozás. Step-by-step instrukciók, dátumokkal.

Kétféle tagság létezik, mindkettő 99 USD-ba kerül. Az egyiknél egyedüli fejlesztőként vagy jelen, azaz a tag te vagy, mint természetes személy. A másiknál jogi személy (cég) a tag, itt több fejlesztő is közreműködhet és kiosztható többféle jogosultság (ki hozhat létre appot, ki küldhet App Store-ba, stb.). A második eset több lehetőséget ad ugyanannyi pénzért, de valamivel több papírmunkát igényel. Én ezt választottam.

2008. november 24.: A Developer Connection oldalán kitöltöttem a szükséges adatokat.
November 25.: Az Apple küldött egy e-mailt, hogy melyik (USA) faxszámra milyen céges papírokat küldjek el, egyben. Ezek: aláírási címpéldány, cégkivonat és egy valamilyen APEH igazolás vagy regisztrációs űrlap (én a cégem APEH-es bejelentőjét küldtem el, 06201/T). Összeszedtem a papírokat és elfaxoltam. Csináltam neki cover page-et, amin feltüntettem az Apple-től kapott azonosítókat és lefordítottam nekik néhány magyar kifejezést, különben nem tudnák a csak magyar nyelvű papírokból, hogy mi micsoda. Egyébként tutira nem fordítják le/nézik meg, kilóra meglegyen, aztán jónapot.
December 8.: Küldtem nekik egy e-mailt, hogy mi a lófax van már.
December 9.: Megjött a válasz, azt mondták nem kaptak faxot tőlem. Pedig anno ott álltam a gép mellett, hallottam a fax csicsergését, OK-t kaptam válaszul... Elfaxoltam ismét.
December 10.: Felhívtam őket, a faxot nem találják, ismét elkavarták! Elfaxoltam ismét. E-mailt küldtek, megérkezett a fax. Wow, két hét alatt eljutottunk idáig.
December 16.: Küldtem egy e-mailt, hogy mi a helyzet.
December 18.: Küldtem egyet ismét.
December 22.: Rájuktelefonáltam és két órával később megjött a befogadó e-mail. Egy url-en el kellett fogadni a szerződést, aztán irány a 99 USD kifizetése iTunes-on keresztül. Hopp, Hungary nincs a listában... a FAQ szerint ki kell tölteni az "Apple store not available in my country" űrlapot (csak a befogadás után érhető el) és várni ismét.
December 30.: Megküldték e-mailen az "iDP BILLING Credit Card Processing Form" doksit, amit ki kell tölteni és elfaxolni. Hogy ezt mi a francért nem lehet elküldeni az űrlap kitöltése után automatikusan... Ezen kellett elküldenem a céges bankkártya adatait, hogy manuálisan húzzák le a pénzt.
Január 5-15.: Kétnaponta küldtem nekik e-mailt és hívogattam őket, hogy mi tart ennyi ideig egy szimpla kártyás tranzakción. Semmi érdemi válasz, csak sajnálkozás.
Január 22.: Megjött az aktiváló kód, bent vagyok a programban! Hurrá. Csak két hónapig tartott!

Innentől kezdve elérhető az összes fejlesztői erőforrás (tesztelés az eszközön, belső fórumok, doksik, letöltések). De! Az AppStore disztribúcióhoz még be kell jelentkezni az iTunes Connect-be, kitölteni egy csomó űrlapot, elfogadni egy csomó szerződést és végül postán/faxon elküldeni egy adópapírt.

Február 10-re igazolták vissza, hogy minden megvan... azaz két és fél hónap (78 nap) kellett hozzá. De ez még mind semmi ahhoz képest, amit szívok a DJ Player elfogadási eljárásával: majd egy másik bejegyzésben.

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.

WiFi-s szinkronizáció

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

Sok eszköz esetén felmerül a kérés, hogy legyen benne WiFi-s szinkronizáció, ne kelljen állandóan USB-re vagy valami másra dugni. Próbáljuk meg objektíven végiggondolni, hogy mennyire lenne ez jól használható? Nézzük meg mondjuk az iPhone-t, mert nekem az van.

Szerintem igazából egyetlen paramétert kell néznünk, ez pedig a sávszél, azaz milyen gyorsan mehet át az adat. A WiFi-nél játszik a B, G és az N. Az iPhone-ban jelenleg B és G van, 4.5 és 54 Mbit/s elméleti sávszélekkel. Ez a gyakorlatban 4.5 és 19 Mbit/s-ot jelent, azaz másodpercenként 560 és 2375 Kbyte-ot tudnánk átküldeni.

Az iPhone viszont hiába lóg egy G-s hálón, 1 Mbyte per másodpercnél többet nem tud feldolgozni, ráadásul ennek eléréséhez is low level BSD socket hívásokkal kell trükközni, mert ha a fejlesztő "sima" Cocoa API-t használ, akkor 170 Kbyte/s lesz a maximum. Tudom, próbáltam, szívtam vele.

Persze a hálózati pufferbe lehet, hogy gyorsabban csorog be az adat, csak éppen a fogadó szoftver nem tudja gyorsabban feldolgozni (lásd még "A feltöltés kezdete mindig gyorsabb mém"). Úgy tűnik, hogy az iPhone processzora korlátoz minket a dologban, ennyit bír.

N-es WiFi-t bele!

Az N-es WiFi a gyakorlatban kábé 10 Mbyte/s, ennyivel tudok vele két Mac között másolni. Hiába tennék az iPhone-ba, az még a G-t sem tudja "kihajtani", így nem lenne különbség. Annyi lehetne az összes előny, hogy a teljes otthoni háló N-es sebességgel mehetne, amit sajnos a G-n bejelentkező iPhone miatt nem állíthatok át, két routert meg nem akarok. Szóval jó lenne az N az iPhone-ba, de nem a sebesség miatt.

Mire elég?

Egy szó mint száz, van kb. 1 Mbyte/s-unk és nincsenek illúzióim afelől, hogy a többi telefon/kézi eszköz nagyságrenddel többet tudna. Ebből már látszik, hogy nagy fájlok mozgatásához és az iPod library feltöltéséhez ez nem igazán elég. A 6 GB szabad helyemet több, mint másfél óra alatt tudná megtölteni, lassú. Ennyi folyamatos CPU és WiFi pörgetés biztosan kétvállra fektetné az akksimat. (Igen, tehetem töltőre, de akkor már egyből az USB-re, szóval úgy minek a WiFi sync?)

A WiFi így nem lenne jó videók feltöltésére, sok kép vagy audió szinkronizációjára. Kíválóan megfelelne viszont a kontaktok, naptárbejegyzések és egyéb kisméretű szöszmötölésekre, vagy ha csak egy-két mp3-at vagy képet szeretnék áttenni.

Ez itt a bejegyzés vége, nagyobb csattanók nélkül.

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. :-)

Midem: a zeneipar és a web

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

A letöltéseket már senki sem kezeli ellenségként, a legnagyobbak is keresik a webes lehetőségeket, de még csak most kezdik felfedezni. Így bármilyen technikai jellegű dologgal "varázslónak" fognak titulálni.

Ennek egészen egyszerű oka van: a hagyományos fizikai produktumokból (pl. CD) hiába adnak el harmadannyit a letöltésekhez képest, de még így is legalább háromszor annyit keresnek vele. (Háttérinfó.) Sajnos ez igen lassan változik csak, a fizikai eladások kb. 20%-kal csökkennek, a letöltések pedig 30%-kal nőnek évente.

Nézzünk egy nem megengedhető, de muszáj-megmutatni-valahogy leegyszerűsítést! Kiadónk jelenleg 4 pénzt keres, 3-at CD-vel, 1-gyet pedig letöltéssel. Mennyit keresünk a mivel? Tételezzük fel, hogy szépen csordogálnak a dolgok 2011-ig, utána pedig összeomlik a CD piac, mert már lejátszót sem vásárolnak hozzá az emberek, addigra pedig bedöglik a nagy része. 2011-et susogtak mindenféle Midem falevelek egyébként is. A letöltések piaca pedig nem nőhet az égig.

év	CD	letöltés	össz
2008	3	1	4
2009	2.4	1.3	3.7
2010	1.8	1.6	3.4
2011	1.4	1.8	3.2
2012	0.7	2	2.7
2013	0.4	2.1	2.5

Tehát még jövőre is inkább a CD eladásokra kell koncentrálnunk és 2011-ig bőven van időnk megvárni a letöltések szent grálját, hátha eljövend. A zeneipar összeomlásán már túl vagyunk, a profit a felére esik össze, ez van.

Van még egyéb bevételünk is, nevezzük egyszerűsítve szerzői jogdíjnak (pl. rádiós lejátszás után). Ezek jól esnek, de különösebben nem fognak változni. Az eladások utáni profithoz képest nem túl nagy összegről van szó, mondjuk úgy egyharmaddal dobja meg a nyereséget, ha népszerű rádiós slágereink vannak (egyébként szinte semmi).

Nagyon durván így gondolkoznak tehát. Aztán ott vannak a mindenféle kettőpontnullás szociális oldalak, pl. Last.fm vagy YouTube. Innen sajnos csak a szerzői jogi díjakat várhatjuk, amik a letöltések utáni profithoz képest nem fognak nagy pénzt termelni. Éppen ezért nem igazán foglalkoznak velük, meghát nehéz is megérteni őket régi zeneiparos szemmel.

ISP-k

A Midem-en nagyon sokan emlegették az ISP-ket (közmagyarul internetszolgáltató). Azt szeretnék, hogy állambácsi vessen ki százalékot (kvázi adó vagy mint a tévédíj, pl. BBC) az ISP-kre, mondván a forgalom nem elhanyagolható része zenei eredet.

Ugyanis egy évi néhány dolláros díjjal már ma is több pénzt lehetne az iparágba pumpálni, mint amennyit összesen megkeres... Csakhogy ehhez kellene valami egységes mérési módszer, mármint az elosztásra. Különben megint csak a nagyok kaszálnak (lásd miért utálják annyian Bródy és Presser urakat).

MP3 áruházak

A letöltésvásárlások kulcsa az egyszerűség, éppen ezért az iTunes a legnagyobb. Eleve ott van az iPod-on, kitt-katt vásárolni (most tekintsünk el attól, hogy egzotikus helyeken, pl. Magyarországon nem lehet).

Más áruházak használata is lehet egyszerű, csak az egyszeri felhasználónak onnan még fel kell töltenie a zenét az iPodra, ami plusz egy-két lépés (miért iPod? mert azt használják a legtöbben). Az Apple éppen ezért nem engedi be a többi áruházat az AppStore-ba.

És bizony az átlagfelhasználó számára az iTunes kényelmesebb, mint ingyen tölteni (próbáltad már elmondani anyunak, hogy hogyan torrenteljen?). Márpedig amíg a zenék csak néhány centbe kerülnek, addig a kényelem felé húz az átlag keze, így biztosított a letöltéspiac jövője.

Ma már nagyon olcsó teríthetjük a zenénket egy lépésben, egyszerre mindenféle MP3 áruházakba, lásd pl. TuneCore. Éppen ezért sok zenekar ki is hagyja a kiadókat a rendszerből, mert az eladást maguk is el tudják intézni. Viszont itt ütközünk bele abba a problémába, hogy hiába van fent a zenéjük, a kutya nem fogja megtalálni őket. Mi éppen ezért csináljuk a Media2Radio-t.

Media2Radio

Ma és a jövőben is szükséges az iparági személyes kapcsolat és a jó promóció egy sikeres kiadványhoz, tökmindegy, hogy CD-n vagy letöltésben adjuk el. Az emberek a trendet mindig a kulcsmédiumokból látják, vannak fontos műsorok (tévé, rádió) és fontos blogok, ezeket követik. A műsort pedig műsorvezetők (bloggerek, DJ-k, stb., sokféle nevük van) állítják össze.

Mi már 6 (hat!!!6!) éve építgetjük a fontos műsorvezetők hálóját, ez a Media2Radio. Itt jópénzért promótálhatod amid van és mi statisztikát adunk vissza neked a fontos emberek visszajelzéseiről, plusz a promó disztribúció is egycsapásban megoldott. Mi tudjuk, hogy hogyan kell ezekkel az általában lusta emberekkel foglalkozni, hogyan kell hatni rájuk ésatöbbi. :-) És bizony egyre több kiadó fordul hozzánk, mert a csökkenő bevételekkel az elérés költsége egyre drágább.

Persze óhatatlanul felmerül a kérdés, hogy webkettes cociális megoldásokkal nem kerülhetők-e meg a fontosemberek? Hogy majd az emberek eldöntik, mi a jó zene? Mint a Last.fm például?

Hát nem. Mindenhol vannak megmondóemberek, rájuk figyelnek. Csak nézd meg, hogy hány név forog a Turulmeme címlapján megosztóként, kiket látsz gyakran. Vagy netán Te is olvasol Webisztánt? És azt hány ember írja? Naugye.

Midem mindennapok

Mon, 26 Jan 2009 01:00:00 +0100

Ha már befizette a rettenet belépőt a 8000 résztvevő, igyekszenek minél jobban kihasználni a lehetőségeket. A vásár minden napján szinte mindenki jelen van és egyenként végigjárja az őt érdeklő standokat, van rá idő, szép komótosan.

Mindenütt beszélgető társaságokat lehet látni, ebből áll az egész, nem bámész családok sétálgatása. A nyugisabb megbeszélésekhez ott vannak a privát tárgyalószobák (ingyen), ha van szabad hely. Pont előttünk volt néhány, így óhatatlanul is belénk akadt boldog-boldogtalan.

A zeneiparban erősen érezhető az angol dominancia, itt sincs másképp, a társaság majd egyharmada UK, a legnagyobb tömeg pedig mindig a British standnál volt, pedig nincs ott egyébként semmi érdekes. Kivéve az ingyen vizet.

Ha a standodat igazán látogatottá akarod tenni a Midemen, akkor állíts fel egy vizesmasinát. A büfében 2.5 EUR három deci víz, így mindenki hozzád jár majd, garantált siker. Sokat segíthet még az ingyen kaja/pia jól meghirdetett időpontokban (szórj egy cetlit minden standra), pl. volt ingyen whiskey és francia sajt mellettünk a MusicWeek újságnál. Mert ezek isznak!

A legtöbben a saját maguk által képviselt zenekarokat/zenéket próbálják eladni, mindenhol szól valami promó zene, sokszor volt iszonyatos hangzavar. A zenekarok kisebb kiadókat keresnek, a kiadók pedig a globális vállalatokat (pl. Universal) és/vagy a disztribúciós láncokat (pl. iTunes) kergetik. Ezt hívom "főcsapásnak".

Mondtam már, hogy ide csak és kizárólag valamilyen termékkel szabad kimenni, anélkül értelmetlen. Ha a terméked zenei jellegű, de nem esik a fenti főcsapásba, akkor biztos érdeklődésre számíthatsz.

Magyarok

Állítólag szombaton kint volt a mi kultúrális miniszterünk is, aki többek között azon kesergett, hogy a magyar ipar képviselői nem tudják megfelelő módon kezelni az itt lévő üzleti közeget, magyarul szarul tárgyalnak vagy nem érik el a megfelelő embereket.

Össz-vissz egyetlen magyar stand volt, Hungaroton Records, ők klasszikus zenében nyomultak (állítólag abban jók vagyunk). A megjelenésük iszonyúan béna volt, három plakát és kész. Persze attól még lehetnek üzletileg sikeresek, de a stand alapján meg sem piszkáltam volna őket. A leglátványosabb az összes közül a lengyel nemzeti stand volt, ők igazán kitettek magukért.

MidemNet

Az összes résztvevő (még én is) bekerült a Midem könyvbe (Midem Guide), amiben benne van, hogy ki mit csinál, személyes elérhetőségekkel együtt. Igen, a nagy fejesek is.

A MidemNet pedig ennek a webes változata, lehet keresni a résztvevők között és személyes üzeneteket küldözgetni, meg ilyesmik. Nosza küldtem is néhányat a jelenlévő Apple-s dolgozóknak, hogy ugyanmár rendezzék el a másfél hónapja húzódó dev regemet, meg a Benjáminét. Nem válaszolt senki, de egy nappal később mindketten bent voltunk a programban. Eleve időszerű volt, így nem biztos, hogy én dobtam a dolgon, de jólesik a tudat, hogy esetleg mégis.

Az egyik munkatársunk (Stephanie) erre szakosodott, még a Midem előtt kigyűjtötte a számunkra érdekes kontaktokat és mindegyiknek szervezett egy találkozót a standunk elé, vagy egy kávézóba, stb.. Minden órára volt tervezve egy, 4 napon keresztül, reggel 9-től este 8-ig... hát nem kicsit fáradt el. Persze nem mindenki válaszolt vagy jött el, de még így is lebonyolított vagy harmincat.

Alternatív konferencia

Sokan persze nem tudták/akarták megfizetni a belépőt, így a kongresszusi központtal szemben lévő kávézók dugig voltak kisebb kiadók és előadók képviselőivel. Tisztára úgy nézett ki, mint valami rotációs társkereső rendezvény. A központ a Cafe Roma volt, ott kellett vacsoráznunk zárás után, mert mindig vártak ránk néhányan, Steph szervezésében.

Vicces volt látni a sok nyilvánvalóan nem kávézó embert, és minden asztalnál akadt legalább egy fejhallgató - CD lejátszó. (Igen, még mindig CD-n hozzák a demókat, szánalmas.)

Stand

Mondtam Eddie-nek, hogy bízza rám, jómagyarként szarból (zéró pénz) is várat építek. Felhasználtuk az összes előző héten fotosoppolt plakátot, de tudtuk, hogy ez nem lesz elég, így összehaverkodtunk a kiszolgáló személyzettel. Ők szívesen vették ezt, mert sokan elég bunkón bántak velük. Így lett ingyen audió, hármat fizet ötöt kap szpotlámpa és dupla annyi helyszíni nyomtatás.

Megnéztük a szomszédokat és hozzájuk képest módosítottuk a designt, követtük a látogatók szemgolyóit, az öt lámpából hármat pedig a folyosóra irányítottunk, hogy fényesebbnek tűnjön előttünk. A végeredmény nem lett "designos" vagy szép, viszont nagyon hatékonyan vonzotta az embereket, néhány euróból sikerült egy elég látogatott helyet létrehozni. A többiek pedig kenjék a hajukra a drága cuccukat, nekünk nem kellett lepkehálóval fogdosni az embereket, megtehettük, hogy csak akkor beszélünk velük, ha megszólítanak.

Egy demózás 10-15 percig tartott, először rövid bemutatás (ezt és ezt csinálja a cég, mutogatás a prospektusokra meg grafikonokra), aztán site demo (néhány fontos oldal), végül bratyizás, mutasd a zenédet/előadóidat és hasonlók. 4 nap alatt több, mint 50 ilyet csináltunk (ketten), gyakorlatilag alig maradt szabad percünk. Szerintem Eddie még mindig írogatja a személyre szabott köszönő és kapcsolatfelvevő e-maileket, kismillió névjegykártyát kaptunk.

Végül visszatérve Hiller elvtárs kesergésére, az eredményes üzleti kapcsolathoz szerintem ezek kellettek a Midem-en:

Folyékony angol. Nem baj, ha hibás, ők is hibásan beszélnek, de ne nagyon keresgesd a szavakat. A nyelvtan nem érdekes, sodró legyen az előadásmód (twice as amazing!). Abszolút tolerálják, ha nem angol vagy, csak ne makogj.
Barátságos fellépés, mintha ezer éve együtt dolgoznánk már. Még a legnagyobb emberek is szóba állnak veled, egyáltalán nem nehéz megszólítani őket.
Azonnali üzlet felkínálása. Nincs idő kertelésre, ez a termék, ennyibe kerül, ezért jó neked, neked mid van, mit tudsz adni? Ha nem tudod két mondatban elmagyarázni a lényeget vagy legalább az előnyöket, akkor rossz a a terméked. Az emberek impulzusvásárlók, az üzletemberek méginkább.
Ha nem jön össze, akkor nice to meet you és irány a következő, nem bratyizunk, csak ha nagyon ráérünk. Illetve a nagy emberek ilyenkor koppantanak le.
Ha üzlet néz ki, akkor bratyizás ezerrel. Honnan jössz, mit szeretsz, jajdeszar a Nokia pavilon és hasonlók. Jössz este az XY kávézóba?

Midem 2009 beharangozó

Fri, 23 Jan 2009 01:00:00 +0100

A világ legfontosabb zenei vására, gyakorlatilag az összes zeneipari vezető jelen van és a legtöbb együttműködés itt születik, az old-school CD disztribúciótól az internetes dolgokig. Nagy szerencsém volt, mert idén én is jelen lehettem és rengeteget tanultam.

A fotók és az első percek alapján úgy tűnik, mintha egy BNV-hez hasonló sima vásárról lenne szó, pedig nagyon nem az. Nem itt mutatják be az új kütyüket, nincsenek új keverők és egyebek, nem erről szól: az óriási alapterület ellenére nem az a cél, hogy sok-sok ezer embert kergessenek át a pavilonokon, hátha vásárolnak valamit.

Mindössze 8000 résztvevőről beszélünk (ennyien vannak a kiállítók és a látogatók összesen), azonban majdnem mindegyikük (tehát nem én) komoly cégeket és/vagy termékeket képvisel és azért van itt, hogy új lehetőségeket keressen. Megtalálod itt az összes Universal, EMI, Warner és egyéb vezetőt, Apple, Microsoft, Google/YouTube fejeseket (Larry és Sergey persze nincs, hanem csak azok, akik zeneileg érintettek), lemezkiadók főnökeit, zeneáruházak igazgatóit (pl. Amazon, iTunes, Virgin), zenei fesztiválok képviselőit (pl. SXSW) és rengeteg előadó menedzsereit (a nagyokét feltétlen).

Vannak koncertek a nagyközönség számára: este mindig óriási tömeg volt a központ előtt, de engem mindenféle angol rockzenei előadók meg Enrique Iglesias hidegen hagy. A Groove Armada, híresebb DJ-k, egyéb elektronikusabb előadók és tuc-tuc zenészek éjszaka voltak, de én addigra sajnos rettenetesen elfáradtam - végülis nem szórakozni mentem oda. És higyjétek el, vacsorázni az MCA Records volt elnökével, dumálni a Prodigy menedzserével vagy privátban demózni a zürichi Google fejeseinek sokkal izgalmasabb.

Van egy csomó előadóterem, mindig van valami előadás, vita, prezentáció és hasonlók. Mi csak egyetlen egyre tudtunk elmenni, de arra egyszerűen kénytelenek voltunk (így korábban zártuk a standot): ez a YouTube-é volt, ahol bemutatták, hogy hogyan kereshetsz pénzt a zenéddel és hogyan kezelik a szerzői és egyéb jogi problémákat. Erről lesz külön post, óriási pénzről van szó, sokban segítheti a YouTube-ot, hogy végre profitot termeljen.

Ár

Ez az egész persze rettentő sok pénzbe kerül. Egyrészt az összes résztvevő jobbra-balra dőlt a Cannes környéki árak láttán (van-e ennél drágább régió Európában?), 3 deci víz a kongresszusi központban 2.5 EUR, 3 csillagos szállodai szoba 180 EUR (reggeli nélkül, egyetlen éjszaka, 15 km távolságban) és hasonlók. A nizzai reptéren minden drágább (víz, szendvics, kávé, akármi), mint a repülőgépen.

Másrészt borsos a részvétel, a sima belépő valamivel 1000 EUR fölött van, a kiállítói (én kiállító voltam, standdal meg minden) pedig 2000 EUR körül - nem standonként, hanem per fő. A kártyámra az volt írva, hogy a pótlása 1095 EUR + ÁFA, ha elvesztem. Óbazz, majdhogynem vele aludtam.

Nem, nem vagyok gazdag, ki nem bírtam volna fizetni mindezt. Az üzlettársam a Media2Radio-ban Eddie Gordon, aki régi motoros a szakmában, a nyolcezer résztvevő legalább felét ismeri. Többek között ő találta ki a BBC Radio 1-en az Essential Mix/Selection-t, ő juttatta a csúcsra Pete Tong-ot, övé volt néhány híres kiadó (pl. Manifesto), ésatöbbi. És ismeri a Midem szervezőit is, így majdnem ingyen mentünk.

A környék

Rettentően puccos, láthatóan felveti a helybélieket a pénz. Mi távolabb laktunk egy kis faluban, fent a hegyen úgy 15 km-re, hogy nyugiban lehessünk, ne zavarjon reggeli közben mindenféle "Midem people". Bizony még itt is bőven látszott a gazdagság, a helybeliek öltözködésén, mozgásán, autóin, házain és persze a környéken (egyszerűen nem tudnál már rajta mit fejleszteni, az összes járdakő elvágólag a helyén, tisztaság, utak mindenfelé).

Nincs szükségük több turistára, így az árakat emelték az égbe. A nagyobb épületek mind a hatvanas évek futurisztikus francia stílusa szerint készültek (Fantomas!), a Cannes-i kongresszusi központ vagy a nizzai repülőtér is. Nekem ez nagyon bejön, mintha mindenhol beton űrbázisok lennének.

A kaja rettentően jó. Nem szeretem a magyaros konyhához képest egzotikus ételeket (kagyló, csiga és társai, tengeri kaják), de a "hagyományos" vonalon nagyon finom érdekes ízeket ismerhettem meg, még a legolcsóbb helyeken is. A részletek nagyon a helyükön voltak. (Legolcsóbb hely: 20 EUR alatt nemigen úszod meg a vacsit, borzasztó.)

Cannes pedig szimplán egy kirakat (fennhagyták a karácsonyi dekorációt, ezért plusz pont), drága szállodák, drága bevásárlóutcák és az egész lényege a kongresszusi központ. Ejj, franciául sokkal szebben hangzik:

Palais des Festivals

Cannes enélkül nem sokat érne. Egy mesterséges félszigeten van a beach kellős közepén, bent a tengerben, nagyon látványos. (Mielőtt megkérdezed: igen, a filmfesztivál, meg az összes egyéb hülyeség is itt van.) Kívülről is nagyocskának néz ki, azonban a lényeg a föld alatt található. Óriási alapterületről beszélünk, az egész BNV-t bele lehetne pakolni, marhanagy labirintus. Csakhogy itt a szerencsésebb kiállítók a tengert nézegethetik, ha épp nincs dolguk.

Midem térkép itt: http://midem.plan-interactif.com/.

Egy szó mint száz, lesznek majd Midemes bejegyzések bőven, köztük a sokak által várt YouTube-os is. Arról is képet kaptam, hogy miért nem foglalkoznak a letöltésekkel igazán vagy miért nincs iTunes Magyarországon.

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?

Mennyi zenét adnak el?

Wed, 14 Jan 2009 01:00:00 +0100

Össze-vissza lehet mindenfélét olvasni arról, hogy mennyi zenét adnak el, de szinte mindig torzítottan kapjuk az adatokat, például CD + digital album sales. Összevonják az almát a körtével, szuper. Megpróbáltam magamnak kihámozni, hogy mennyi lehet kábé az annyi.

USA adatokat mutatok, a világ meg gondolom szorozva kettővel, hárommal, vagy ilyesmi.

formátum	USA eladás	változás 2008-ban
Vinyl (magyarul bakelit lemez)	1.8 millió	nő! +90%
CD	360 millió	csökken, -20%
download	1100 millió	nő, +27%

Tehát összesen mondjuk másfél milliárd zenei terméket adnak el (most tekintsünk el a zenei DVD-ktől és egyéb egzotikumoktól, engem a fenti három tétel érdekel). A legnépszerűbb kiadványok kb. 3 milliós forgalmat generálnak. (Ehh, a nyolcvanas években csak Magyarországon el lehetett ezt érni egy slágerrel.)

A becsült haszon (nem az előadóé, hanem kiadó plusz előadó meg akárki összesen) a Vinyl és a CD eladásokon kábé tízszeres a letöltésekhez képest. Nézzük meg így a táblát:

formátum	haszonegység
Vinyl	18 millió
CD	3600 millió
download	1100 millió

Tehát még mindig megéri a CD-eladás, csak nagyobb a kockázat, hogy bebukik a kiadvány. A download piacon pedig sokkal több szereplő osztozik, mert könnyű belépni: több eladó között osztozik meg az össz-haszon.

Mégha exponenciálisan változnak a százalékok, akkor se fog változni a CD elsősége idén. Esetleg 2010-ben egyenlíthetnek a letöltések, a CD szerepe pedig mondjuk 2012-re lesz elhanyagolható.

Úgyhogy a nagy kiadóvállalatok egyáltalán nincsenek elkésve és ahogy hallom mindegyik teljes gőzzel keresi a megfelelő digitális terjesztési formát. Szomorú vagyok, a gyorsabb technológiai haladást kedvelem.

Szombaton irány a MIDEM, vasárnap építjük a Media2Radio standot, jövő héten kiállítás.

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ő.