szantog.com - legfrissebbek

AWS Import/Export for Physical Data Transfer

Thu, 18 Jun 09 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 09 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 09 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 09 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 09 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 09 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 09 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 09 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 09 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 09 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 09 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 09 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 09 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 09 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 09 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 09 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 09 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 09 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 09 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 09 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ő.

Kormányzár

Sun, 11 Jan 09 01:00:00 +0100

El akartunk menni valahova, lecihelődtünk (babahordozó, babakocsi, egyebek), de nem jött le a kormányzár, így anyázós otthonmaradás lett az ügyből. A zárszerkezet romlott el, így valahogyan "le kellett vágnom" a kormányról és megdöbbentem azon, hogy milyen könnyen ment. Megmutatom hogyan.

Elég sok autón láttam már ilyet vagy nagyon hasonlót, biztos olcsó, ha ennyire népszerű. Ne vegyetek ilyet, illetve akinek van szerezzen be valami mást, mert hamis biztonságérzetet ad. Így néz ki:

Először fémfűrésszel próbálkoztam, de autóban ez elég kényelmetlen dolog, viszont érdekes, hogy a kormányzár bármelyik pontja könnyen szelhető. Kb. 10 perc alatt az egész szétvágható egy jó kézi fémfűrésszel, de nekem csak egy ócska régi fűrészlapom volt, így 20 perc után feladtam.

És ekkor rájöttem, hogy egy egyszerű csavarhúzóval néhány másodperc alatt nyitható.

A felső fekete részt műanyagborítás fedi és egybeöntöttnek tűnik, de nem az. Az ott lévő fémsapka két másodperc alatt feszíthető fel egy átlagos, nem is túl erős csavarhúzóval. A következő képen már "kinyitva" látható:

A nyíllal jelölt tengely köti össze az alsó és a felső részt. A tengelyen két darab erősebb alátétnek tűnő fémgyűrű van, ezek tartják egybe az egészet. Mindkettő pár másodperc alatt pattintható le. Ezzel készen is vagyunk, a felső rész leemelhető:

Nekem fél perc volt az egész - gyakorlott polgártársaknak csak néhány másodperc kell hozzá.

Az Apple felszabadította Korzikát

Wed, 07 Jan 09 01:00:00 +0100

Térképbuzi vagyok, ez van - az Apple pedig felszabadította Korzikát a francia elnyomás alól, ami számomra a második legérdekesebb keynote infó.

A legfontosabb pedig az új akksi a 17"-es Macbook-ban. Na nem mintha érdekelnének a böszme laptopok, csak a tavalyi év legfontosabb motorháztető-alatti (under the hood) eseménye az Apple fejlett gyártástechnológiája, amit az unibody-val mutattak be és most itt ez az új akksi.

Nyilván az összes Apple termék profitálni fog belőle, ami jó lesz. Az, hogy egészen lemennek a gyártósor szintjéig azt jelenti, hogy tényleg minden részletre figyelnek és minden részletet kontrollálni szeretnének - ettől sikeres az Apple - és a kontroll miatt ezért utálják sokan.

Nincs még egy gyártó, ami a termék ennyi darabkáját tartja kézben, a tranzisztoroktól a felhasználói felületig.

Van webes analógia is: ha valami komoly rendszert szeretnél összehozni, akkor előbb-utóbb falakba fogsz ütközni és kénytelen leszel saját magad megcsinálni. Ezért nem jó nagy látogatottságra az alap Wordpress, ezért próbál az összes live-videós cég saját médiaszervereket fejleszteni (Jázmin -> Milgra, Justin.tv -> saját python cucc, stb.) az Adobe FMS helyett.

A Korzikás dolgot az új iPhoto promó videóban találjátok, ihol la:

H.264 licencdíj? WTF?

Wed, 17 Dec 08 01:00:00 +0100

Az egész netes videós banda a H.264 irányába nyomul, mivel szabványos, nagyon jó minőségű, sok minden kezeli és ingyenes eszközökkel is előállítható. És bizony szinte mindenki - beleértve engem is - azt hitte, hogy a cucc ingyenes, pedig elvileg nem. Persze semmi sem az, de tegye fel a kezét, aki fizetett már a Fraunhofer Intézetnek MP3 enkódolásért!

Van itt egy cikk az egész ügyről. Engem csak az internetes rész érdekel, itt pedig a lényeg az, hogy 12 percnél rövidebb videóknál nem kell fizetni, fölötte pedig 2%-ot egy esetleges kapcsolt árból (pl. pay-per-view) vagy ingyenes esetben 0.02 USD videónként.

Szerencsére a pénzért feliratkozós oldalakra is gondoltak, itt nem kell videónként mérni, hanem évente fizetendő a licencdíj a regisztrált felhasználók számától függően. 100e user alatt minden ingyenes, fölötte pedig 25 000 USD-től kezdődnek a lépcsők.

Másik szerencse, hogy maximum licencdíj plafon is van, 2009-ben nem kell 4.25 millió dollár fölött fizetni. :-)

Azt hiszem ez is egy olyan licencdíj, amire mindenki magasan...

A feltöltés kezdete mindig gyorsabb mém

Tue, 16 Dec 08 01:00:00 +0100

Szerintem mindenki észrevette már, hogyha feltöltesz valamit valahová, akkor a feltöltés kezdete mindig gyorsabb, egy-két másodpercig úgy tűnik minden szép és jó, aztán megtorpannak a százalékok. Az okok:

A hálózati forgalomban sok-sok szereplő vesz részt, két végpont (a számítógéped és a távoli szerver) között számtalan kis kütyü, elosztó, satöbbi van. Ha elkezdesz forgalmazni, akkor ezek a kis (és néha igen nagy) bigyók tárolják az első elküldött bájtokat az átmeneti tárukban, ennek a feltöltése pedig gyors, így a feltöltésed kezdete "megszalad".

Utána az átmeneti tárak olyan gyorsan ürülnek és töltődnek az általad küldött további bájtokkal, amilyen gyorsan a sorban következő eszköz fogadni tudja őket. Itt lassul be tehát a dolog?

Ez elméletileg jól hangzik, azonba a gyakorlat az, hogy a forgalomban részt vevő hálózati eszközök nagy részének nem olyan nagy az átmeneti táruk, hogy a fenti mémet okozzák. Valójában leginkább a cső másik végén lévő szerverszoftver a ludas.

Ott is van átmeneti tár, amit az operációs rendszer kezel és minden egyes kapcsolathoz létrehoz egyet. Például ha elkezdesz forgalmazni egy Apple gép felé, akkor az azon lévő OSX létrehoz a kapcsolatodhoz egy 256 kbyte méretűt, ami pillanatok alatt megtelik. Az OSX erről a helyről táplál mondjuk egy Apache + PHP kombót, ami meg feldolgozza az adatokat, például folyamatosan fájlba írja, ha ez egy fájlfeltöltés.

A bibi itt van, az operációs rendszer (általában, jó beállítás esetén) piszok gyorsan kezeli az átmeneti tárat, tehát nagyon gyorsan tudná fogadni az adatokat, de az azon futó (szerver)szoftver már általában lassabb. Sok feltöltés tehát nem a hálózati sebesség, hanem a fogadó eszköz terheltsége és az azon lévő fogadó szoftver sajátosságából adódóan lassabb.

A fentieknek mekkora a hatása? Készítettem iPhone-ra egy kis webszervert, mert szükség volt fájlfeltöltésre WiFi-n keresztül a készülő programomhoz. Van erre Cocoa mintakód, de hiába optimalizáltam, nem tudtam 150 kbyte/s fölé menni, pedig SCP-n keresztül 900 kbyte/s-al is működik a dolog.

Tovább próbálkoztam hát és kiderült, hogy a buta Cocoa 510 bájtonként adta át az adatokat a programomnak és ezért marha sok fordulóra volt szükség egy nagyobb fájl fogadásához. Egy (nem Cocoa-s) trükkel megoldottam, hogy fordulónként akár 65 535 bájt is jöhessen, ami 150 helyett 1000 kbyte/s feltöltési sebességet eredményezett és drasztikusan csökkent a CPU használat is.

Software is teh king, again.

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

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

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

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

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

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

USA

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

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

Amazon EC2 Europe

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

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

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

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

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

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

Inside the iPhone

Tue, 09 Dec 08 01:00:00 +0100

Most, hogy már az iPhone fejlesztését is tanulgatom elég sok információm gyűlt össze a "belsejéről". Összegyűjtöttem a szélesebb kört is érdeklő, azaz nem fejlesztőknek, inkább csak gépnyomóknak szóló darabokat egy csokorba. Úgy gondolom, hogy ezeknek a birtokában jobb rálátást fogsz kapni az iPhone piaci elhelyezkedéséről és másképpen fogod összehasonlítani mondjuk egy Nokia készülékkel. Vigyázat, hosszú írás, én szóltam.

Alapszabályként úgy érdemes tekinteni az iPhone-ra, hogy ez egy kis laptop érintőképernyővel. Sokkal inkább számítógép, mintsem mobiltelefon, annyira, hogy a mobiltelefon részek (= baseband, kezeli a SIM kártyát, satöbbi) teljesen külön vannak benne.

Ugyanaz az OSX operációs rendszer fut rajta, mint a "rendes" Mac-eken, de ez leginkább csak a feltört telefonokon kezelhető. Nagyon sok szoftver lefordítható rá, pl. Apache vagy Lighttpd webszerver. A feltört telefonokra az OpenSSH feltelepítése után be lehet jelentkezni és ott ugyanaz a Bash parancssor fogad, mint a legtöbb Unix/Linux operációs rendszeren. Itt lehet a legjobban látni, hogy jé, tényleg.

Persze sok képesség egyáltalán nem vagy másképpen érhető el, mert ez mégsem egy asztali gép. Ezek egy része műszaki sajátosság miatt van (pl. az eltérő és igen egyedi felhasználói felület eltérő módszereket kíván), más része pedig az Apple üzleti döntése miatt (pl. nem érhetők el a tárolt MP3-ak, a Bluetooth vagy az USB-s szinkronizáció).

Hardver

ARM architektúra lakik bent (ez egy mobil eszközökben igen széles körben használt dolog, sok okostelefon erre épül), ARM11-es processzort használ. Az ARM11 maximális sebessége 620 Mhz, de az iPhone-okban csak 412 Mhz-en ketyeg.

Feltételezem, hogy erre a hőelvezetés és a kedvezőbb akku élettartam miatt volt szükség. Érdekes kivétel a második generációs iPod Touch, abban már 532 Mhz-re engedték a procit.

Van benne még 128 MB RAM és 8, 16 vagy 32 GB Flash HDD. A HDD sebessége: olvasás 11 MB/s, írás 3 MB/s. Egy sima 5400-es laptop vinyó a huszas tartományban mozog, így ez az érték igen-igen lassú. A RAM sebessége: 120 MB/s.

A legnagyobb megszorítás a memória és lemezkezelés

Az Apple nagyon tart a Flash lemezek limitált élettartamától (egy cella kb. 500 000 írást/törlést bír jelenleg, utána meghal), ezért a fejlesztői doksiban többször felhívja a figyelmet, hogy csak akkor írjunk a lemezre, ha nagyon muszáj és lehetőleg egy menetben.

Valószínűleg emiatt nincs benne virtuális memória, nincs memória swap! (Háttérinfó).

Van kb. 30-50 MB szabad memória a programok részére és kész, de egy fejlesztő sem bízhat abban, hogy ennyi valóban rendelkezésre is áll. Kevés hely esetén minden alkalmazás üzenetet kap, amit érdemes lekezelni. Ha elfogy a RAM, akkor kilövi a programunkat, tehát erre fokozottan kell figyelni.

Nincs benne garbage collection sem, azaz a fejlesztő lelkiismeretes és aprólékos munkáján múlik a memória hatékony kezelése. Memóriaszivárgás esetén nagyon gyorsan elfogyhat a RAM és akkor a rendszer leállítja a programot.

A fentiek miatt teljesen hibás az az állítás, hogy az iPhone teljesítménye hasonlítana a 8 évvel ezelőtt általános 400 Mhz-es 128MB RAM-os 4GB HDD-s asztali gépekéhez. Már a Win 3.1 is használt memóriaswap-et és garbage collectiont, ami itt nincs.

Ha mindenképpen hasonlítani kell valamilyen asztali masinához, akkor inkább egy 486-ost képzeljünk el 16 MB RAM-mal és MS DOS-szal. Kb. ennyi teljesítményre lehet számítani egy saját alkalmazás részére.

Pontosan ezen okok miatt nem hagyja az Apple, hogy háttérben futó szoftvereket is készítsünk az iPhone-ra, egyszerűen nincs hozzá elegendő erőforrás, nagyon könnyen instabillá lehet tenni a rendszert és tönkrevágni az Apple által szigorúan vett felhasználói élményt.

Fejlesztés

A fejlesztés a csak OSX-en futó XCode fejlesztői rendszerben történik, ebben fejlesztik az OSX-es asztali alkalmazásokat is. Az Apple-nek szerintem amúgy sem lett volna ereje egy külön valamire, most meg van egy nagy integrált izéje, amiben fejleszthetünk asztalra és mobilra. Minden egyben, így szép.

Mint minden hasonló rendszernek, ennek is megvan a sajátos logikája, először átláthatatlanul kusza, aztán ha belejössz minden összeáll szépen. A tesztelés történhet az asztali gépeden szimulált környezetben (iPhone Simulator) és magán a készüléken is.

Kényelmes az Interface builder, ahol grafikus felületen lehet összerakni a felhasználói felületet. Nagyon hasznos az Instruments, ahol többek között a CPU használatot és a memóriaszivárgást lehet monitorozni (nem csak a szimulátorban, hanem magán a telefonon is).

Ezeken a nyelveken lehet fejleszteni: Objective-C, C++, "Pure" Java, AppleScript, Ruby és Python. Mielőtt belelkesedsz: azért Objective-C-re van kihegyezve minden. Némi ASM kód is becsempészhető, illetve a nyelveket lehet kombinálni. C-ben az összes ANSI C funkció elérhető, ugyanúgy malloc-olni és memcpy-zni kell, mint régen. Egészen alacsony szintekre is lemehetsz.

Anno a diplomamunkám egy Windows-os program volt, amit C++-ban készítettem a Windows API felhasználásával. Hiszed vagy sem, az iPhone fejlesztésben ez az ismeretanyag nagyon hasznos lett, szinte teljesen ugyanúgy történnek a dolgok...

Fontos, hogy az iPhone alkalmazások nem látják egymást, egy "homokozóban" (sandbox) futnak, csak a saját mappáikba írhatnak, csak onnan olvashatnak.

Érdekes dolog még a telefonos megszakítások kezelése, pl. ha jön egy hívás vagy naptáresemény. Ilyenkor pause állapotba kell tennünk a programot, aztán ha a felhasználó úgy dönt, hogy felveszi a hívást, akkor a rendszer leállítja az appot.

Alapvetően úgy kell megtervezni egy alkalmazást, hogy ilyen megszakítások bármikor jöhetnek, a felhasználó bármikor leállíthatja a programot és nagyon gyors válaszidők kellenek ezekre. Ez a szemlélet jól tenne sok asztali alkalmazásnak is egyébként...

Azzal is foglalkozni kell, hogy az akkut minél kevésbé terheljük. Ha azt nézzük, hogy a fejlesztői doksi szerint mi mennyire fontos (hányszor írnak róla, milyen sorrendben és nyelvezetben), akkor az akkuzabáló eszközök érdekes sorrendje alakul ki:

WiFi (ez eszi a legtöbbet)
Baseband radio (GSM, 3G, stb. mobil forgalmazás)
GPS
gyorsulásmérő
Flash disk (ez meg a legkevesebbet?)

Keretrendszerek

A legtöbb lehetőséget keretrendszerekkel, magyarul Framework-ökkel érik el a fejlesztők. Például UIKit-nek hívják a felhasználói felülettel kapcsolatosat, vagy AddressBook-nak a kontaktkezelőset.

Ezek közül néhány keretrendszer szabványos és más operációs rendszereken is elérhető, így nem kell a fejlesztőknek újat tanulni. Például van OpenGL és OpenAL, ez ismerős lehet a játékok háza tájáról, ezért emlegetik az iPhone-t mint új játék platformot. Persze van olyan, hogy teljesítmény vagy egyéb okból egy-két funkció nem érhető el, pl. az Audio Units keretrendszerből jópár audio effekt hiányzik.

Főleg üzletpolitikai dolgok miatt sok keretrendszer nem használható (Private Frameworks), de ügyes programozók megmutatták, hogy hogyan lehet ezeket használni, például hozzáférni az MP3-akhoz az iPod részben és hasonlók. Ilyen szoftverek csak feltört telefonokra telepíthetők, az AppStore nem fogad be Private Framework-öt használó programot! Igen, van rá eszközük, hogy kiderítsék.

Ha kijön egy új frissítés, mint legutóbb a 2.2, az nemcsak azt jelenti, hogy mondjuk megjelent a Google Maps-ben a Street View, hanem ilyenkor szoktak bővülni a fejlesztők lehetőségei is, azaz messze nem csak a felhasználói felületet és a csilivilit polírozzák!

A keretrendszerek folyamatosan bővülnek, és fejlesztői oldalról is szembetűnő a fejlődés. Igen messze járunk még attól, hogy az iPhone kész legyen.

Például a TV kimenet keretrendszere még csak most alakul és úgy tűnik, hogy hamarosan publikus és dokumentált lesz. Azaz jövőre jöhetnek az olyan játékok, ahol az iPhone lesz a kezelőfelület de a TV-re jön a kép. Tiszta Nintendo.

Konklúzió

A fentiek figyelembevételével talán már másképp látod az iPhone helyzetét. Már-már hihetetlen, hogy az igen limitált hardver erőforrások mellett ennyit ki tudtak hozni belőle. Minden fejlett telefonnál, az Android platformnál is bele fognak futni (belefutottak?) a fenti problémákba és az azokra adott válaszoktól függ, hogy mennyire lesz sikeres egy platform - hiszen most már mobilplatformok versenyeznek, nem gyártók.

A hagyományos telefonokhoz képest világok választják el az iPhone (és Android) platformokat. Míg egy hagyományos telefonhoz elég volt a Nokia vagy a SonyEriccson fejlesztői kapacitása, ide alapvetően másra és bizony jóval többre van szükség. Úgy tűnik, hogy egyelőre csak az Android lesz képes felvenni a technológiai (technológiai, nem üzleti!) versenyt.

A Symbian és a Windows meg lemaradt? Mindenki az iPhoneról és az Androidról beszél, azokra jön ki a legtöbb új szoftver.

Nem csoda, ha sokan azt állítják, hogy az iPhone előnye jelenleg legalább másfél év. Az sem csoda, hogy ezidáig nem tudtak a nagy mobilgyártók egyetlen olyan modellt (vagy inkább platformot) sem kihozni, ami megszorongatná az iPhone-t. Olyan összetett fejlesztőkörnyezetet kell felmutatni, mint amit az előző bekezdésekben éppen, hogy csak megkarcoltam.

Ömlengésnek hangzik de igaz, hogy az iPhone alapjaiban változtatta meg a mobilvilágot és a hagyományos mobilgyártók válasza még mindig nem tiszta. Ezért úgy kell nekik az Android, mint egy falat kenyér.

Kedves Ügyfelem!

Mon, 08 Dec 08 01:00:00 +0100

Pitiáner ügyről van szó, de megosztom, mert jólesik, másrészt pedig érinthet Téged. Számtalan rossz tapasztalatom volt már a magyar postával (így, szándékosan kisbetűvel), külföldi csomagok elvesztése a határon, satöbbi. Most ez történt:

Pénteken kaptunk a postaládába kettő darab "ismételt értesítés..." cetlit olyan küldeményekről, amikről addig nem tudtunk, mivel nem kaptunk értesítést. Minden nap rendkívül tüzetesen tanulmányozzuk át a láda tartalmát, hogy a sok reklámszemét között még véletlenül se maradjon ilyen, nagy valószínűséggel nem mi vagyunk a hunyók.

Zárójeles kitérő: volt már olyan, hogy a postás lustaságból meg sem kísérelte a kézbesítést, hanem egyből az értesítést dobta be, de éppen akkor jöttem le a lakásból és elkaptam.

Az értesítésen a feladó adatai helyett a sajátunkat írta be a remek postai alkalmazott (feladó címkével...), így fogalmunk sincs, hogy kitől-mit kaptunk.

Pénteken nem értem rá, hétvégén nem lehet átvenni a küldeményt (miért?), maradt a hétfő, ami egyben a határidő is, utána visszaküldik a feladónak. Hétfőn egyetlen időpontot tudtam csak találni az átvételre, elfáradtam hát a postahivatalba, de a sorszám húzása után (új rendszer!) kiderült, hogy 35-en vannak előttem. És tényleg annyian álltak sorba a küldeménykiadás mellett.

Egy szó mint száz, kedves Ügyfelem, ha visszaküldte a posta az általad küldött akármit (szerintem számla), akkor küldd el ismét légy szíves.

Szeretném, ha végre rendszerváltás történne a posta és a vasút, mint két utolsó cocialista szörny és embertemető területén. Igazi piaci versenyt akarok.

P.S.: valaki derítse már ki, hogy az Ady Endre úton lévő másik kicsi posta mire jó, ha délután háromkor bezár.

Amazon CloudFront - CDN kicsiknek

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

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

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

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

Hogyan működik?

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

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

Árazás

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

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

Videó

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

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

Miért instabilak a programok, miért fagynak le, miért lassú a gépem?

Mon, 24 Nov 08 01:00:00 +0100

Általában a rossz memóriakezelés miatt. Megmutatom, hogy miért darál a gép vagy miért lesz gyorsabb egy újraindítás után. Szigorúan laikusoknak, a fejlesztők olvassanak valami mást (ne). Sőt, ez a bejegyzés egyben bevezető is egy "Amit (esetleg) nem tudtál az iPhone működéséről" cikkhez.

Alkalmazásaink sok memóriát használnak, rendszerint jóval többet, mint arra akárcsak a fejlesztőjük gondolt volna. Lehet, hogy 4 GB RAM soknak tűnik, de nem egy népszerű program játszva beleharap a gigabájtos tartományba, mi pedig általában több ilyen népszerű szoftvert futtatunk egyszerre. De sokszor elég egy böngésző is jó sok megnyitott füllel.

Daráló

Tehát memóriából sosem elég, ezért a fizikailag létező memória helyett szinte minden operációs rendszer ún. virtuális memóriát használ. Ennek többek között az a lényege, hogyha a fizikai memória elfogyni látszik, akkor a ritkán használt/legrégebben használt/statikus tartalmú memóriafoglalásokat kiírja a merevlemezre és csak akkor tölti vissza, ha ismét szükség van rá. A merevlemez persze sokkal-sokkal lassabb a memóriánál, így a visszatöltés is az.

Ennek legszembetűnőbb példája a következő: használjunk valamilyen sok memóriát zabáló alkalmazást (pl. Photoshop), aztán indítsunk el egy böngészőt és nézzünk meg jópár weboldalt. Ezzel jó eséllyel a Photoshop által elfoglalt rengeteg memóriát oprendszerünk kénytelen lesz kiírni a lemezre, hogy legyen hely a böngészőnek. Aztán csukjuk be a böngészőt és klikk vissza a Photoshopra. A válasz rendszerint őrült darálás lesz.

Szivárgás

További probléma, hogy sok alkalmazást nem túl jó minőségben fejlesztenek és nem a leghatékonyabban használják a memóriát. Ez még csak-csak elmegy, de a szivárgás (leak) már nem: nagyon könnyű olyan kódot írni, ami a felhasznált memóriatartományokat nem szabadítja fel, így folyamatosan használtként tartja (úgy, hogy gyakorlatilag nem is tud róla). Ezzel memóriánk "elszivárog".

Sajnos alig van olyan szoftver, ami ne szivárogna. A szivárgás által lekötött területek csak akkor szabadulnak fel, ha véglegesen bezárjuk a szivárogtató programot, de persze folyamatosan a háttérben futó dolgok is szivároghatnak, amiket az egyszerű felhasználó nem tud bezárni. Ezért van az, hogy egy újraindítás sok problémát megold, hiszen minden nulláról indul.

Fagyás

A fagyások túlnyomó többsége is memóriakezelési gondokból adódik. Általában akkor száll el egy program, ha olyan memóriaterületre hivatkozik, amire nem kellene: nem férhet hozzá biztonsági okok miatt vagy nem az van már ott, aminek kellene, satöbbi. Ez szinte minden esetben a fejlesztő hibája, nem gondolt olyan esetekre, amire pedig kellett volna.

Szerencsés és általános esetben a hibás memóriaterületre történő hivatkozást észleli az operációs rendszer és egy érthetetlen (a fejlesztő számára is haszontalan!) hibaüzenettel leállítja a programot, azaz "elszáll".

Rossz esetben pedig annyira sikerül összekavarni az operációs rendszer működését, hogy az is elszáll, azaz "lefagy a gép", jöhet a reset.