szantog.com - címlap

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.

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.

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.