http://szantog.com szantog.com hu Tue, 10 May 2011 02:00:00 +0200 http://szantog.imect.com/sites/szantog/media/etc/meetup.jpg Minden más http://szantog.com/page/low-level_ios-hogyan_lehetne_gyorsabb http://szantog.com/page/low-level_ios-hogyan_lehetne_gyorsabb <div><strong>A mai Meetup-on tartott előadásommal kapcsolatos fejlesztői infók, kódokkal. </strong></div><div><ul> <li>Látványos eredmény megfelelő szálkezeléssel, UIKit frissítés optimalizációval és ARM Assembly-vel érhető el.</li> <li>A szoftver a király: sokkal több erőforrás takarítható meg jó kóddal, mint mondjuk egy új szuper GHz kétmagos CPU-val. </li> <li>Ha egyébként rendben van a kód. Például használjunk "tiszta" C-t Objective-C objektumok helyett, ha lehetséges. </li> </ul> <h4>Hogyan mérjük a terhelést?</h4> <ul> <li>Instruments: elsősorban RAM, szivárgás és Core Animation mérésre. CPU-hoz nem jó, abból eleve sokat eszik, az apró különbségek nem látszanak.</li> <li>Csak a teljes, rendszerszintű idle idő számít. Mérése kódból megoldható (csatoltam).</li> <li>A felhasználó a teljes rendszer terhelését érzi, nem az alkalmazásunkét. Könnyű "átvinni" a terhelést a saját kódból az OS-hez (user % -&gt; sys %), de ez nem szabadít fel semmit.</li> </ul> <h4>Ökölszabály</h4> <p><em>25-30% szabad CPU mindig kell, különben "akadozik" az élmény.</em></p> <h4>NSRunLoop</h4> <ul> <li>A main thread NSRunLoop-ja fontos. Többek között ez fogadja az érintés és egyéb felhasználói eseményeket.</li> <li>Ha nincs 25-30% szabad CPU, akkor későn fut, későn érkeznek az események - akad. </li> <li>Main thread/main run loop blokkolására ügyelni, események lehető leggyorsabb feldolgozása, külön thread, ha kell.</li> </ul> <h4>Szálkezelés</h4> <ul> <li>Fontos a megfelelő prioritás, időszelet (mennyi CPU-t használhat adott időtartam alatt) és stratégia (FIFO, RR, OTHER) beállítása. </li> <li>Nincs rá jó SDK megoldás (NSThread setThreadPriority nem megfelelő), hibrid mach/pthread kód kell. Csatoltam. </li> <li>Ezzel lehetséges olyan szál futtatása, ami csak a "szabadidőben" fut (idle CPU). </li> </ul> <h4>UIKit</h4> <ul> <li>Egy UIKit objektum (pl. UIButton) módosítása "költséges", az UIKit a legtöbb esetben blokkol, amíg be nem fejezte a grafikát. </li> <li>Összegyűjteni a módosításokat (pl. UIButton.highlighted), és végrehajtani később, nem a touch event kezelésekor. </li> <li>CADisplayLink! Ezzel lehet időzíteni a frissítéseket. </li> <li>Az iPhone utálja az átlátszóságot, alpha csatornákat, belassul. </li> <li>A legtöbb objektum átlátszatlan legyen, opaque-ra Interface Builder-ben pipa (igen, végig kell kattintgatni az összeset). </li> <li>Még így se "halmozzuk egymásra" az objektumokat. </li> <li>Ha opaque egy objektum, de alpha-s PNG kép van benne, akkor átlátszó lesz így is... </li> <li>Irtsuk ki az alpha csatornát a felhasznált képeknél, ha lehet.</li> <li>A szövegek, UILabel módosítása költséges. Saját drawRect metódus és [self.text drawInRect: vagy CGContextShowTextAtPointsokat segít. </li> <li>A saját drawRect metódusok sokszor gyorsabbak. </li> <li>Instruments - Core Animation - Flash Updated Regions. Meg fogsz lepődni.</li> </ul> <h4>Thumb mód</h4> <ul> <li>ARM CPU-k, kétféle futási mód: Thumb és ARM. </li> <li>Thumb mód: kisebb kód és más utasításkészlet, ezért kisebb memória sávszél igény - gyorsabb futás, régi eszközökön (nem iPhone). </li> <li>Nem tud lebegőpontos számítást, ilyenkor a fordító átkapcsolja a CPU-t ARM módba, aztán pedig vissza. Ez lassú. </li> <li>iOS fordító: a Thumb mód alapértelmezett, kapcsoljuk ki. Iterációknál sokat számíthat. </li> </ul> <h4>Iterációk optimalizálása - ha az Assembly "túl sok" lenne</h4> <ul> <li>Nézzük meg, hogy a compiler milyen kódot gyárt. </li> <li>Elé és mögé inline asm sorok ( __asm__ volatile ("#innen"); ), majd pedig Build - Show Assembly Code. </li> <li>Próba: "register" kulcsszó néhány fontos változónál, mennyit változik az Assembly kód. Nem kell annyit töltögetni a memóriából. </li> <li>A compiler nem mindig jó a regiszterek hatékony elosztásában, csak néhányat használ. </li> <li>Egyszeres lebegőpontos számokat érdemes használni (sima, 32-bites float), hogy a compiler használja a lebegőpontos egységet. </li> <li>A memóriahozzáférés sokkal drágább, mint az asztali gépekben. A memcpy is!</li> </ul> <h4>Assembly</h4> <ul> <li>XCode-ban lehet inline Assembly-t írni. </li> <li>A C-változatot is meg kell hagyni, mert a Simulatorhoz felesleges külön Assembly verzió. A Simulator x86-os, a régebbi iOS eszközök-ok ARM6-os (VFP), iPhone 3GS-től felfelé pedig ARM7-es (Neon) kódot kérnek.</li> <li>Universal binary kell (Build Settings - Architectures - Standard (armv7 armv7), illetve -mfloat-abi=softfp -mfpu=neon kapcsolók (Other C Flags).</li> <li>Az Assembly-be átírás nem triviális, ne "automatikusan" csináljuk. Jó Assembly kód csak "kézműves" munka eredménye lehet. </li> <li>A regiszterek hatékony kihasználása, a lehető legkevesebb memóriahozzáférés (és lehetőleg blokkban), valamint az utasítások ciklusszámának ismerete sokszoros sebességkülönbséget jelent! </li> <li>Minden utasítást adott számú ciklus alatt hajt végre a processzor, de képes többet párhuzamosan is! </li> <li>Használjuk az "egybeépített" segédprocesszort, lebegőpontos számításokra (32 bit float), főleg vektorokhoz, mátrixokhoz. Egy ilyen szorzás pl. 8 ciklus alatt megy végbe, ez idő alatt mást is csinálhat a CPU, ha a következő utasítás nem a szorzás által használt regisztereken dolgozik (párhuzamosítás).</li> </ul> <h4>Példa: DJ PLAYER keverő (mixer) kód iPhone 2G-n</h4> <ul> <li>C: 18% CPU. </li> <li>VFP Assembly, a ciklusszámok figyelembe vétele nélkül: 8% CPU. </li> <li>Végleges, optimalizált változat: 2% CPU.</li> </ul> <h4>Kódok</h4> <p><a href="http://szantog.imect.com/sites/szantog/media/etc/thread.h">Szálkezelés.</a> <a href="http://szantog.imect.com/sites/szantog/media/etc/cpu.c">Idle CPU mérés.</a></p></div> Fri, 04 Mar 2011 01:00:00 +0100 http://szantog.imect.com/sites/szantog/media/etc/rbamstthumb.jpg Minden más http://szantog.com/page/red_bull_bpm_launch_event http://szantog.com/page/red_bull_bpm_launch_event <div><strong>A sajtó meggyőzése fontos, ezért különleges bulikkal próbáljuk lekenyerezni őket. Egy Red Bull BPM Launch Event mindig sokkal érdekesebb, mint egy sajtótájékoztató, vagy bármi, amit általában szoftverek körül szoktak rendezni. </strong></div><div><img src="http://szantog.imect.com/sites/szantog/media/etc/rbamstthumb.jpg" alt=" " /></div><div><p>Minden ilyen esemény egy sajtótájékoztatóval kezdődik, ahol egy műsorvezető segítségével rövid bemutatót tartunk (Ralf vagy én), majd pedig az aktuális sztár is megmutat néhány érdekességet, ami igen vicces szokott lenni, mert eddig szinte mindig csak őrültekkel volt dolunk.</p> <p>Ezután van egy fél/egyórás lazaság a nagyközönség beengedéséig, ez idő alatt próbálunk meg válaszolni a legáltalánosabb kérdésekre. Ez már nem színpados/konferencia-szerű szerencsétlenkedés, hanem lemegyünk és mutogatunk, ilyesmi. Természetesen Red Bull módra minden igen precízen meg van szervezve, kaja/pia pedig bőven akad, messze feljebb a pogi/aprósüti szintnél - az újságírók különösen szeretik a jó ingyenkaját.</p> <p>Ez a laza rész így nézett ki a hollandoknál:</p> <p> <iframe src="http://www.youtube.com/embed/-PLrr1xNVkc" width="480" height="390" frameborder="0"></iframe> </p> <p>Végül beengedik a jónépet, akik általában valami nyereményjáték vagy egyéb részvételi izé keretében szereztek jegyet, elkezdődik a show. Általában két helyen van zene (nagyterem, kisterem), plusz ott a demószoba tele iPad-ekkel és iPhone-okkal.</p> <p>A legnagyobb a legelső Launch Event volt Amszterdam-ban, ott kilenctől éjfélig ki sem tudtam jönni a demószobából, demózni kellett és válaszolni, folyamatos volt a roham. Jöttek újságírók, fejlesztők, hírességek, mindenféle emberek. A sajtó kb. 150 fővel volt jelen, ehhez jött még 1000 fél tízkor. Nem egy átlagos szoftverbemutató...</p> <p>Kb. éjféltől pedig már csak a bulizás volt téma, például így:</p> <p> <iframe src="http://www.youtube.com/embed/vTAeAiHM93I?rel=0" width="480" height="300" frameborder="0"></iframe> </p> <p>A londoni bulira is el tudtam menni (kalandos 14 óra volt odajutni az óriási 5 centis hó miatt), ott a közönség nemigazán akarta elhinni, hogy Sinden meg én a tánctér közepéről, mászkálás közben játszunk mindenféle kábelek nélkül, érzékelhető késleltetés nélkül. Mókás volt bevonni mindenkit a játékba, direkt megkértük az embereket, hogy nyúlkáljanak az effektekbe. Volt nagy rötyögés meg meglepetés, mikor az iPad megérintése azonnal hatással volt a többezer W-os hangrendszeren keresztül a tömegre.</p> <p>A berlini és a madridi eseményekről sajnos lemaradtam, nem volt rá időm. A madridi nagyon szép, múzeum-szerű helyen volt, Forma-1-es pilótákkal meg ibizai rezidens DJ-kel. A berliniek pedig nem normálisak, pont karácsony előtt volt a buli, mert ott ez nagy divat.</p> <p><a href="http://www.flickr.com/photos/djbroadcast/show/with/5404860279/">Madrid slideshow</a>, szép!</p> <p>Ezúton is köszönöm a szervezőknek, hogy ilyen puccos rendezvényt tesznek a seggünk alá. Nem volt semmi látni, amikor 50 ember rohangál, fúr, farag, telepít, fuvarozza a VIP-ket a reptérről és hasonlók. Mindig egy igen részletes, több oldalas táblázat tartalmazza a teendőket melósokra leosztva, aztán persze mindig csúszunk, úgyhogy be kell szállni pl. a DJ pult építésébe. :-)</p> <p>Jelenleg a márciusi nagy eseményre készülünk, egészen konkrétan az SXSW konferencia kellős közepén, 15-én Austin-ban USA Launch Event, Felix da Housecat, DJ Manny, meg persze mi. Nem kell ragoznom, hogy ez miért fontos. Április végén pedig irány Párizs, úgy haknizunk, mintha valami falunapos mulatósbanda lennénk.</p> <p>A galériában: így készül az amszterdami esemény, nekem pedig feltétlenül be kell magolnom az aktuális, feltétlenül elhangzandó kulcsszavakat.</p></div> Fri, 10 Dec 2010 01:00:00 +0100 http://szantog.imect.com/sites/szantog/media/web/iwiwvideotelefon.png Web http://szantog.com/page/viszlat_iwiw http://szantog.com/page/viszlat_iwiw <div><strong>Töröltem magam az iWiW-ről, mert nem használtam régóta, az ismerőseim nagy része pedig már átvándorolt a Facebook-ra (mondjuk ott sem vagyok igazán aktív). Ez pedig magával vonta azt is, hogy megszüntettem az iWiW Videótelefon alkalmazást, ugyanis haszna már rég nem volt annak sem. </strong></div><div><img src="http://szantog.imect.com/sites/szantog/media/web/iwiwvideotelefon.png" alt=" " /></div><div><p><a href="http://szantog.com/page/iwiw_videotelefon">A kezdetek még egész jók voltak</a>, a Videótelefon sokáig a legnépszerűbb 3 alkalmazás között volt az első egy-két hónapban. Összesen 276 147-szor telepítették és 58 121-szor törölték le. Tettem bele Google Analytics kódot is, hogy jobban mérhessek: "fénykorában" napi átlag 100 000 visit-et produkált napi több száz lebonyolított hívással. A kiszolgáló ingyenes Google AppEngine számla kihasználtsága még így sem haladta meg a 15%-ot.</p> <p>Hosszasan nyüstöltem az Origo AdHouse-t, hogy a fenti adatok alapján reklámozzunk egy kicsit, de nemigazán foglalkoztak velem. A szerződés szerinti időszakos riportot is csak egyszer küldték el és sikerült összesen ötszáz-valamennyi Forintot keresni (igen, ebből még egy Big Mac menü sem jön ki). Egyszerűbben fogalmazva le voltam sz*rva, pedig az egyszerű fejlesztő azt gondolná, hogy ilyen forgalom mellett legalább havi egy mekizés összejön.</p> <p>Emellett további gyanús jel volt, hogy az iWiW OpenSocial evangelistájára, Bártházi Andrásra sem tartottak tovább igényt, drasztikusan csökkentve az iWiW appok-kal kapcsolatos kommunikációt.</p> <p>2009 áprilisa óta folyamatos és erős csökkenés mutatkozott a napi visit-ek számában, mostanra a felére esett vissza, 45-50 000-re. Mindenki tudja és érzi, hogy az iWiW most már komolyan süllyed és nem érzem, hogy a már régóta esedékes redesign ezen különösebben változtatni tudna, bár értékelem az erőfeszítést.</p></div> Mon, 25 Oct 2010 02:00:00 +0200 http://szantog.imect.com/sites/szantog/media/etc/rbbpmgraylogo.jpg Minden más http://szantog.com/page/dj_player_red_bull_bpm http://szantog.com/page/dj_player_red_bull_bpm <div><strong>A projekt a DJ PLAYER nevű iPhone app körül forog, aminek a fejlesztése 2008 novemberében kezdődött. A célja egy komplett DJ pult megvalósítása iOS eszközökön. </strong></div><div><img src="http://szantog.imect.com/sites/szantog/media/etc/rbbpmgraylogo.jpg" alt=" " /></div><div><p>A kezdet igen nehéz volt, például 10 hónapon keresztül tartotta vissza az Apple:</p> <p><a href="http://szantog.com/page/a_csatlakozas_az_iphone_developer_program-hoz_szivas">Gond volt a csatlakozással a Developer Program-hoz.</a> <a href="http://szantog.com/page/dj_player_blue_edition">Bejutás az App Store-ba.</a></p> <p>Majdnem abba is hagytam, de közben szerencsére összejöttem egy német csapattal (Stereomusik), akikkel közösen dolgozunk. Még a Red Bull BPM-ek előtt jött ki a ma látható verzió alapja, a DJ PLAYER 2.0 és a NetOut:</p> <p><a href="http://szantog.com/page/dj_player_20">http://szantog.com/page/dj_player_20</a></p> <p>A NetOut közben 59 milliszekundum helyett már 0 (zéró) késleltetést tud, abszolút egyedülálló cucc, amit a versenytársak még mindig nem tudnak.</p> <h3>A cél</h3> <p>Célunk egy komplett érintőfelületes termékpaletta létrehozása, egy újfajta DJ élmény megteremtése. Ennek a mobil része van kész, így iOS eszközökkel bárhol lehet diszkózni. A launch event-en több diszkós is megjegyezte, hogy milyen érdekes és jó érzés 1000 embert a saját telefonjáról/iPad-ről szórakoztatni. A DJ pult a zsebükben van, mindig azt használják, amit jól ismernek. Arra is nagyon jó, ha valami technikai zűr van egy "hagyományos" pultban, sok DJ "életét" mentette már meg valamelyik alkalmazásunk.</p> <p>Jelenleg 9 app van a Store-ban, mind ugyanazon a kódon alapul (egy XCode project az egész):</p> <ul> <li>DJ PLAYER - komplett DJ pult (iPhone/iPod touch) </li> <li>NetOut - második sztereó kimenet a DJ PLAYER-hez </li> <li>Red Bull BPM Pro - a DJ PLAYER "brandelt" változata </li> <li>Red Bull BPM MasterOut - a NetOut "brandelt" változata </li> <li>Red Bull BPM HD - a Pro iPad verziója </li> <li>Red Bull BPM Compact - egyszerű, olcsó változat a DJ szakmával ismerkedőknek </li> <li>Lite változatok - ingyenes kipróbálás saját számok feltöltése nélkül, 4 fix szám </li> </ul> <p>Ehhez jön még egy desktop alkalmazás az iTunes-szal való WiFi-s szinkronizációhoz (Windows és Mac). A fejlesztés nem állt meg és pár éven belül nem is fog, ez nem egy "elkészítjük, aztán már csak finomítgatunk rajta" app, nem egy átlagos iOS fejlesztés.</p> <h3>Workshop</h3> <p>A Red Bull BPM paletta bemutatója (launch event) szeptember 16-ra volt a legtrendibb amszterdami klubban, a Trouw-ban. Azért Amszterdamot választották, mert egy európai bemutatóhoz jó helyszín, közel van a fontos angol és német piacokhoz, valamint a Red Bull nagyon erős stábbal rendelkezik arrafelé (egyébként lesznek "nemzeti" bemutatók is a fontosabb országokban a következő hónapokban).</p> <p>Kiválasztottak néhány feltörekvő, már ismert, de még épp nem über nagy sztár előadót/DJ-t, akik a launch event arcaiként fognak játszani. Ezzel a trendi fiatalokat célozzák, számukra ezek az előadók nagyobb vonzerőt jelentenek, mint a legismertebb (és unalmas) nemzetközi nevek. Carl Cox amúgy is túl sokat kért (tényleg), Fatboy Slim meg amúgy sem ért rá (tényleg). Szóval a húzónevek Modeselektor, Joris Voorn, Darko Esser, Nuno dos Santos és Brutuzz lettek, a kisteremben pedig helyi ismertebb DJ-k játszottak.</p> <p>Augusztus közepén készítettük elő a dolgokat a helyszínen, valamint fejtágítást tartottunk a fontos embereknek és előadóknak. A Red Bull iszonyú profin ügyel a részletekre, ez a workshop is úgy meg volt rendezve, hogy csak na. A kényelem érdekében extra minőségű kanapékat hozattak angliából, komplett tévéstáb vette a ténykedésünk, fények, kaja (már amennyire Hollandiában, ugye), anyámkinnya.</p> <p>Engem rettenetesen bedrótoztak, mikroport a tévéseknek (adó a zsebben, miksi a pólón), fejmikrofon a nagycucchoz (adó a másik zsebben), matricák a megfelelő helyen (a telómon is), tíz centivel arrébb ülni, másik logót nem kitakarni, erre fordulhatsz, arra ne menj, satöbbi. Workshop helyett inkább valami élő tévéshow vezetőjének éreztem magam.</p> <p>A launch event-ről majd később írok, itt pedig néhány kép a workshop-ról:</p></div> Mon, 28 Jun 2010 02:00:00 +0200 http://szantog.imect.com/sites/szantog/media/ Minden más http://szantog.com/page/uzsidoboz_led_video http://szantog.com/page/uzsidoboz_led_video <div><strong>Sajnos csak egy régi Canon fényképezőgép volt kéznél, így a színek nem az igaziak, de azért talán visszaad abból, hogy mire képesekek a kütyük. </strong></div><div><p> <object height="385" width="480"> <param name="movie" value="http://www.youtube.com/v/4P1SSaQWipQ&amp;hl=en_US&amp;fs=1&amp;rel=0&amp;color1=0x006699&amp;color2=0x54abd6" /> <param name="allowFullScreen" value="true" /> <param name="allowscriptaccess" value="always" /><embed src="http://www.youtube.com/v/4P1SSaQWipQ&amp;hl=en_US&amp;fs=1&amp;rel=0&amp;color1=0x006699&amp;color2=0x54abd6" type="application/x-shockwave-flash" width="480" height="385"></embed> </object> </p> <p> <a href="http://www.youtube.com/watch?v=4P1SSaQWipQ" tabindex="0">http://www.youtube.com/watch?v=4P1SSaQWipQ</a></p> <p>A felvétel nem teljes sötétben, alkonyat végén készült teliholdnál. A ház színe világossárga (ezért nem látszik a fehér szín).</p></div> Thu, 24 Jun 2010 02:00:00 +0200 http://szantog.imect.com/sites/szantog/media/ Minden más http://szantog.com/page/a_java_nevu_karamba_kenyszeritett_fejlesztoi_kozosseg http://szantog.com/page/a_java_nevu_karamba_kenyszeritett_fejlesztoi_kozosseg <div><strong>A minap jelent meg @HH Android fanboi (szerintem egyáltalán nem baj fanboy-nak lenni!) tollából <a href="http://webisztan.blog.hu/2010/06/23/az_objective_c_nevu_karamba_kenyszeritett_fejlesztoi_kozosseg">Az Objective-C nevű karámba kényszerített fejlesztői közösség</a>, ahol egy külföldi szerző cikkét idézve próbálja egy picit ekézni az iOS platform fő nyelvét. </strong></div><div><p>A külföldi szerző a Java felől érkezett, <a href="http://greensopinion.blogspot.com/2009/07/android-versus-iphone-development.html">ezt meg is írja</a>, így természetes, hogy az Android környezete egyből ismerős. Szerintem aki Java felől érkezik, annak az Android lesz tetszetősebb, aki pedig C felől, annak az iOS.</p> <p>Ugyanis az Objective-C inkább csak a sztenderd C kiegészítése, így nem jelenthet gondot egy C/C++ fejlesztő számára, hiszen azok képességei egyből használhatók, ugyanúgy. Az Objective-C furcsaságait pedig további egy nap alatt meg lehet tanulni, ami leginkább a következőkkel fog telni (ezek azok a furcsaságok, amik miatt egy laikus visszahőköl egy Objective-C példakód láttán):</p> <ul> <li>Messaging. Ez az oka a sok hülye szögletes zárójelnek []. </li> <li>Memóriakezelés (nincs gc, ezért sok alloc, release, retain). </li> <li>Header és kódfájlok, osztálydefiníció, változók elérése (@synthesize). Itt még az Apple programozói is sokszor túlzásba esnek, a sok @synthesize és @property később egy kis tapasztalattal csökkenthető. </li> </ul> <p>Az is fontos, hogy <strong>az Apple példakódok tragikusan bonyolultak</strong> és nehéz kihámozni a legtöbbször csak 4-5 sornyi lényeget.</p> <h4>Ekézzük kicsit az Android-ot viszont</h4> <p>Az UI kezelése az iOS-hoz képest tragikus. Az iOS-ban az Interface Builder, kód oldalról pedig az UIView-re alapozott mechanizmus elég kényelmes, egyedül a ctrl nyomvatartásával történő kapcsolatok létrehozása nem magától értetődő a kezdőknek (az Interface Builder-ben).</p> <p>Ez messze nincs ilyen kényelmesen megoldva az Android-on, ráadásul ott a többféle képernyő/felbontás támogatása, amitől már egy egyszerű gomb mérete/elhelyezése is problémás. iOS-on csak egy @2x-szel kiegészített fájlnevű képet kell megadni, ezzel a több felbontás kezelése nagyrészt megoldott, a natív SDK kontrolokkal pedig semmit sem kell csinálni. </p> <p>Ezzel szemben Android-on ott a mindenféle képernyőméret és sűrűség (density), valamit a tesztelés problémája. Hányféle készüléken? Mennyire jó a touch érzékelés pl. a széleken, melyik modellen? Egyáltalán melyik Android verzió?? </p> <p><strong>Az Objective-C annyira karám, amennyire a Java az.</strong> <em>Szerintem az Android fanboi-ok "szabadságharcosnak" érzik magukat és minden iOS dolgot zártnak, egyedinek látnak, azt is, amit nem kéne. Ellenben minden Android-os ügyet nyíltként kezelnek, ami természetesen nem igaz.</em></p> <p>Csak egy példa: egy csomó izgalmas library C-ben vagy C++-ban van megírva, tonnaszám tölthetők le mondjuk a SourceForge-ról. Egy csomó izgalmas példakód C-ben vagy C++-ban van megírva. Nagyon sok ezek közül kapásból beépíthető az iOS programomba, mindenféle változtatás nélkül. Főleg teljesítményigényes cuccok ezek, amik az Android NDK-val sokkal nehezebben használhatók, ha egyáltalán.</p> <p>Egyébként én személy szerint fázom, ha az Eclipse-t kell használnom, nekem az XCode sokkal gördülékenyebb. Egy szó, mint száz: ha valaki innen jön, akkor ez lesz a jobb, ha valaki onnan, akkor pedig amaz.</p> <p>@HH pedig erős kapufát rúgott a cikkével, ráadásul át is kellene keresztelni a Webisztánt, mert hogy jönnek ide a mobilos cikkek? :-)</p></div> Thu, 24 Jun 2010 02:00:00 +0200 http://szantog.imect.com/sites/szantog/media/etc/uzsidoboz/uzsidobozlead.jpg Minden más http://szantog.com/page/uzsidoboz_led http://szantog.com/page/uzsidoboz_led <div><strong>Le szerettem volna cserélni a <a href="http://tagmasterz.com">Tagmasterz</a> járatokban található futófényt valami ütősebbre, RGB színkeveréssel és strobi lehetőséggel. Az egyedüli megoldás a LED technológia, de a piacon található ledes falszínezők és reflektorok nem mérhetők a költségvetésünkhöz, ezért saját gyártásra kellett adnom a fejem. Szerencsére épp a nagy ledes robbanás előtt állunk, aminek előszele már a nagy áruházaik polcain is érezhető, de ez csak gyenge szellőcske. </strong></div><div><p>Az eBay-en körülnézve mindjárt látszik, miért. Az áruházainkban általában kapható, jó esetben 1-3 W-os cuccokhoz képest már a nagy teljesítményű, 10/20/50/100W-os power ledek játszanak itt, nem is vészes áron. Ökölszabályként 6-10-szeres a fényerőkülönbség a hagyományos izzókhoz képest, pl. a 10W-os LED határozottan világosabb a 60W-os izzókörténél és csak valamivel tol kevesebbet a 100W-osnál. El lehet képzelni, hogy a 100W-os LED mire képes.</p> <p>Én a 10W-os, eleve színes (piros, zöld, kék) ledek darabját 2100 Ft-ért szereztem be szállítással együtt, közvetlenül a kínai gyártótól (szerintem a tulaj lánya van fent az eBay-en, vagy valami ilyesmi). A "szállítás" mindössze egy nagyobbacska bélelt postai boríték volt a 24 db ledhez és négy nap alatt az asztalomon is volt:</p> <p><img alt="ledposta.jpg" src="http://szantog.imect.com/sites/szantog/media/etc/uzsidoboz/ledposta.jpg" /></p> <p>6 db készüléket terveztem, mindegyikbe 2 db piros, 1 kék és 1 zöld került (a piros ennél a típusnál 40%-kal gyengébb fényerejű). Ezeket a ledeket 6.5 és 12 V-tal kell hajtani, áramgenerátoros táppal, különben többet vesz föl és elfüstöli magát. A konstans áramerősség abban is segít, hogy minden időjárási körülménynél (hőmérséklet, páratartalom) azonos legyen a fényerő. Megfelelő meghajtás esetén a ledek csak 10000 üzemóra után mutatnak kb. 20%-os fényerőcsökkentést, állítólag.</p> <p>A dimmelhető (fényerőszabályozható) ledes tápok már drágább dolgok (kb. 5-8000 Ft), de házilag is megépíthető egy PC tápból és néhány kiegészítő alkatrészből, van recept a weben. Én viszont megkérdeztem egy kínai gyártót, hogy mennyiért tudna építeni nekem 24 db egyedi, vízhatlan tápot, és a bolti árnál jóval olcsóbbra jött ki szállítással együtt. Nagyon kedves csapat, Skype-on pikk-pakk le lehet dumálni a dolgot, de nagy tételben kell vásárolni (belengettem, hogy esetleg végleges termék is lehet a készülékekből, ezért kell nekem 24 termékminta): <a href="http://kishay.com">kishay.com</a>.</p> <p>Fontos foglalkozni a ledek hőleadásával, ezért gázos a régi technológia, ahol sok pici ledet ültettek egymás mellé egy nagyobb panelbe a megfelelő fényerő érdekében, jelentősen csökkentve az élettartamot. A power LED-eknek méginkább kell ez, csak 1-2 másodpercet megy hűtés nélkül. Szerencsére nem ördöngösség a dolog, sokan PC-s procihűtőre szerelik, egy izmos procihűtő a hozzá való ventilátorral együtt még a 100W-os típushoz is elég (vessük össze a P4-es proci hőleadásával!).</p> <p>Én inkább 230V-os ventilátort vettem és sima hűtőbordát, mert olcsóbb és halkabb (a készülékekben nincs 12V-os táp, ami úgyis csak a ventihez kellene). A Lomex-ben minden kiegésző megvásárolható (még power LED-jük is van!), egy sarokkal odébb a pedig a szükséges csavarok (az Osram boltban). Hővezető paszta a led aljára, rögzítés átmenő csavarral, sima ügy. A legkisebb teljesítményű 230-as ventilátorral a hűtőborda még csak kézmeleg sem lesz a 40W-os teljesítmény ellenére. A megengedett legmagasabb hőmérséklet egyébként 60 celsius fok, annál feljebb kampec.</p> <p>A készülékek háza lehetett volna méregdrága műszerdoboz is, de inkább a párszáz Ft-os átlátszó uzsidobozokat választottam, mert könnyű megmunkálni és olcsó, a 60 celsius fokos limit miatt pedig nem olvad meg.</p> <p><img alt="uzsidobozegybe.jpg" src="http://szantog.imect.com/sites/szantog/media/etc/uzsidoboz/uzsidobozegybe.jpg" /></p> <h4>Vezérlés</h4> <p>A dimmelhető tápok optikailag leválasztott 5-12V-os PWM bemenettel rendelkeznek, egy Arduino PWM lábára közvetlenül ráköthető, vezérelhető. A legolcsóbb megoldást választottam, az egy darab Arduino közvetlenül UTP kábelen keresztül kapcsolódik a készülékekhez sima telefoncsatikkal. Mondjuk ehhez meg kellett tanulnom krimpelni, de az csak pár perc.</p> <p>A vezérlés is természetesen egy uzsidobozban kapott helyet. Egy állapotjelző RGB LED is került ide, mert a Tagmasterz barlangban nem lehet belátni, hogy mit csinálnak a lámpák épp, a visszajelző RGB LED viszont ugyanazt mutatja, amit a nagy lámpák. Az egyedüli probléma az Arduino lábak száma volt, mert kellett még 7 láb a billentyűzet számára, de az 1-es és 2-es lábakon nem akart működni a dolog. Szerencsére az analóg lábak is használhatók digitalRead-re, így ez megoldódott (összesen 3 + 3 PWM láb, 3 digitalWrite láb, 4 digitalRead/analóg láb).</p> <p>Az eltérő színű power LED-ek fényereje nem azonos, ezt szoftverből korrigáltam. Nagyon izgalmas volt kísérletezni a színekkel és programokkal. Gyönyörű színátmenetek, tiszta színek és iszonyú gyors strobizás is lehetséges. Érdekes volt látni, hogy a 20 ms-nál rövidebb strobivillanásokat mennyivel gyengébbnek ítéli az emberi szem, illetve a túl gyors színváltoztatások hogyan befolyásolják a színérzékelést (nagyon gyengül).</p> <p>A 35 négyzetméteres nappali/konyhánkat már egy készülék is tökéletesen bevilágítja, a 6 db pedig valószínűleg elég lesz a barlanghoz. Vicces, hogy ennek ellenére milyen kicsi és könnyű az egész szett. Egy uzsidoboz LED mindössze 1.3 kg, a maximális fogyasztása pedig 32 Watt. Ezek falszínezők, nincs optikával meghúzva a fényük, így egészen elképesztő 170 fokos szögben majdnem egyenletesen világítanak, érzetre a széleknél is csak kb. felére csökken a fényerő. Belenézni nem lehet, nem olyan, mint egy izzó, kisebb helyről jön a fény, vakít.</p> <p><a href="http://szantog.com/sites/szantog/media/etc/uzsidoboz/uzsidoboznagy.jpg">Uzsidoboz porn! Képek nagyban mindenfélő szögből.</a></p> <p><a href="http://szantog.com/sites/szantog/media/etc/uzsidoboz/vezerlonagy.jpg">Vezérlő porn! Képek nagyban a vezérlőről.</a></p> <p><a href="page/uzsidoboz_led_video">Videó a készülékek képességeiről.</a></p></div> Fri, 04 Jun 2010 02:00:00 +0200 http://szantog.imect.com/sites/szantog/media/etc/djpicon.jpg Minden más http://szantog.com/page/dj_player_20 http://szantog.com/page/dj_player_20 <div><strong>A napokban küldtem el jóváhagyásra az új változatot, ez a munka kötötte le az elmúlt 5 hónapomat, így nagyon sok minden változott. Végre már beszélhetek is róla, egyelőre csak a technológiai újításokról, az üzletiekről majd a nyár folyamán. A sajtóközlemény innentől indul: </strong></div><div><img src="http://szantog.imect.com/sites/szantog/media/etc/djpicon.jpg" alt=" " /></div><div><p>Az iPhone/iPod touch és az iPad már nem kötött egyetlen sztereó kimenethez, mert elkészült az iMect Bt. és a német Stereomusik együttműködésében a DJ PLAYER alkalmazás 2.0-ás verziója. Az előző verzió egyetlen profi lejátszójához képest ez már kettőt tartalmaz egy virtuális keverővel összekötve, azaz a DJ PLAYER egy komplett DJ pult egyetlen alkalmazásban. A vadonatúj NetOut kiegészítő app használatával ötféle kimeneti módja különböző igényeket elégít ki.</p> <p>A zenék feltöltése továbbra is WiFi-n keresztül történik, iTunes szinkronizációval vagy böngészős feltöltéssel, teljes metaadat kezeléssel, előadó, cím vagy BPM szerinti rendezéssel. A fejlesztés során a minél alacsonyabb késleltetés (latency) és a teljesítmény volt elsődleges a grafikai trükkök ellenében. A fejlesztők a kis képernyő miatt csak a megfelelő felhasználói interfész és munkamenetek kialakításával heteket töltöttek el.</p> <p>A DJ-k munkájához két sztereó kimenet kell, egy a közönség, egy pedig a belehallgatás számára. Ez eddig nem volt lehetséges az iPhone OS-t futtató készülékeken, mert csak egyetlen sztereó kimenetük van, a mono szétválasztás pedig nem minőség a profi DJ-k számára. A DJ PLAYER megoldja a problémát.</p> <p>"Home" kimeneti módban a fejhallgató kimenet a belehallgatásé, a master pedig WiFi-n keresztül egy másik készülék kimenetére kerül a DJ PLAYER NetOut alkalmazás segítségével. Bár a WiFi-s audió streaming eddig sem volt újdonság, de az átlagos 2-6 másodperces késleltetés használhatatlanná tette a DJ-k számára.</p> <p>Egyik jelenlegi protokoll sem volt megfelelő ahhoz, hogy alacsony késleltetéssel és CPU használattal mobil eszközök audiót sugározzanak, ezért a DJ PLAYER-hez egy teljesen újat kellett fejleszteni, az alapoktól kezdve. A DJ PLAYER 59 ms (0.059 másodperc) késleltetéssel sugároz, amit a "Latency Balance" beállítással 0 ms-ig lehet kompenzálni. Igen, ZÉRÓ, NULLA.</p> <p>Persze az ilyen alacsony késleltetésű WiFi-s sugárzás nem mindig problémamentes, ezért a "Home" mód csak otthoni bulikhoz és gyakorláshoz ajánlott, nem pedig nagy klubok számára. Nekik a "Club Master" mód lett kifejlesztve, ahol a fejhallgató kimenet a master, a belehallgatás pedig a hálózaton keresztül a DJ zsebében található iPhone-ra kerül, így a közönség mindig tökéletes minőséget kap, a DJ pedig megszabadul a fejhallgató zsinórjától.</p> <p>Nem minden DJ szeretne virtuális mixeren keverni, ezért nekik készült a "Classic" kimeneti mód, ahol továbbra is csak egyetlen lejátszó érhető el, és így két iPhone csatlakoztatásával lehet a teljes pultot kialakítani. Rendelkezésre áll még az iPhone-os DJ-zésben "hagyományos" split cable mód is (monósítás), illetve ennek egy továbbfejlesztett változata, ahol ha nincs belehallgatás, a kimenet automatikusan sztereó lesz.</p> <p>A keverőn minden általánosan elvárható kezelőszerv megtalálható, de az új kimeneti módoknak hála split vagy sztereó belehallgatás is választható, az arányt pedig master/pfl potival lehet állítani. A crossfader és a csatornapotik karakterisztikája állítható, de a crossfader két újfajta keverési módot is ismer: hozzákapcsolt rezonáns szűrők segítségével nemcsak hangerőben lehet keverni, de frekvenciában is.</p> <p>Minden csatornán háromcsatornás (hi/mid/low) EQ van, ami kétféle üzemmódban működik: "adjust" módban a hangszínt lehet állítani (plusz-mínusz 6 db), "mix" módban pedig vágás ("mínusz végtelen" db) és 0 db között működik, amit egy rejtett kill kapcsoló tovább segít.</p> <p>Hamarosan megújul a weboldal, és új videókat is készítünk. Az alkalmazás továbbra is drága marad (25 USD), de a 2.0-s verzió elfogadásáig a jelenlegi (kissé bugos) változat 19 USD, és ugye ez fog frissülni.</p> <h5>Feature lista angolul:</h5> <p>Features</p> <ul> <li>output modes: Classic, Split Headphone, Split Headphone with Auto Stereo, Home, Club Master </li> <li>2 independent stereo outputs for stereo PFL and stereo master on WLAN with the DJ PLAYER NetOut app </li> <li>clickless/popless 32-bit sound engine </li> <li>guaranteed resistance against any vibration :-) </li> </ul> <p>Mixer</p> <ul> <li>crossfader with 3 curves (beatmix, constant power, scratch) and 3 modes (classic volume cross, lo-hi/hi-lo filtered cross) </li> <li>for each channel: fader with 2 curves (smooth, hard), smooth gain, low/mid/high ±6 db adjust eq (double tap a fader for zero position), low/mid/high mixing eq from cutoff to 0db, hidden cutoff switch below each mixing eq, PFL switch </li> <li>calibrated VU meter per channel and stereo VU meter for master, balance control </li> <li>pre-listening: master/PFL fader, headphone volume, PFL split or stereo PFL </li> </ul> <p>Deck</p> <ul> <li>play/pause, rew/ff, regular and frame precise search, adjustable rew/ff step </li> <li>Vinyl Vision display shows you the softer and louder parts just like on a vinyl, touch on it to jump instead of search </li> <li>cue, back cue, hot cue, cue rec, cue pre-listen, 3 levels auto cue (off/soft-digital/hard-vinyl), 3 different modes to store cue points </li> <li>pitch control in four ranges: ±4, ±8, ±16 and ±100%, fine adjust pitch step buttons with AutoStep, pitch bend with adjustable strength </li> </ul> <p>Effects</p> <ul> <li>beatcounter, BPM sync </li> <li>bpm-based echo, reverb, flanger, highpass, lowpass, eq </li> <li>adjustable effect parameters on TouchPad or with accelerometer, adjustable frequency range </li> </ul> <p>Tracks</p> <ul> <li>convenient track search via table display with textual search/filter </li> <li>sort by artist, title or BPM, section views by first letter or BPM range </li> <li>MP3, WAV, AAC, Apple Lossless, AIFF, OGG and FLAC, all formats with the same features and low latency, metadata read </li> <li>WiFi upload with iTunes sync or web browser </li> </ul> <p><a href="http://djplayer.net">http://djplayer.net</a></p> <h3>Nos, eddig tartott a sajtótájékoztató rész.</h3> <p> A megvalósításban rengeteg ARM-os Assembly kódott kellett írni (külön ARM6-ra és 7-re), mert két MP3 szimultán kikódolása, keverése, effektezése az iPhone-on nem triviális feladat. A fejlesztés a legrégebbi modellen történt, hogy még ott is jó teljesítménnyel fusson a cucc.</p> <p>A keverőre vagyok a legbüszkébb, az konkrétan 84 sor Assembly (csatornapotik, gain, cross, balance, belehallgatás és annak keverése), csak regisztereket használ és 2% CPU-t eszik. A hálózati kimenet UDP alapú, ennek az előállítása (kompresszálás, pakolgatás és UDP sendto) is mindössze 18%.</p> <p>Picit az iPhone-ban található hardveres audio kodek is meg lett piszkálva, hogy jó legyen, nem a példakódok szerint használjuk. Az össz memória igény teljes terheléskor mindössze 8-9 MB, ebből 2-3 MB megy csak audióra.</p> <p>Persze az 5 hónap alatt rengeteg új igény is jött, meg eszünkbe jutott, úgyhogy még nagyon sokáig van fejlesztenivaló ezen a rendszeren. Most egy pici pihenő jön, aztán gyúrunk a marketingre.</p> <p>Kiszivárogtatott képernyőképek, a titkosszolgálat sajnos csak ennyit tudott rögzíteni, mert elmosta az árvíz:</p> <p><img alt="djpleak.jpg" src="http://szantog.imect.com/sites/szantog/media/etc/djpleak.jpg" /></p></div> Tue, 01 Jun 2010 02:00:00 +0200 http://szantog.imect.com/sites/szantog/media/etc/ipad.jpg Minden más http://szantog.com/page/ipad_tapasztalatok_1_honap_utan http://szantog.com/page/ipad_tapasztalatok_1_honap_utan <div><strong>A laptopokat nem nekem találták ki. Munkához kicsi és kényelmetlen a billentyűzetük (kéz és kar tartása), kicsi a monitor, lassú a háttértár, ár/teljesítmény arányban meg sem közelítik az asztali gépeket - dolgozni asztali gépen kell (fyi: nem újságíró vagy fényképész vagyok).   </strong></div><div><img src="http://szantog.imect.com/sites/szantog/media/etc/ipad.jpg" alt=" " /></div><div><p>Persze ott van még a szórakozás (értsd: nem munka, hanem netezés, levelezés, filmnézés, YouTube, játék, satöbbi), de ahhoz is nehéz és nehézkes a laptop, inkább valami netbook lenne jó, de az meg olyan lassúcska és béna. Ide az iPad a nekem való termék, mert kisebb, könnyebb, nagy a kijelzője, gyorsabb a felhasználói élmény, sokkal jobban néz ki (a szórakozásnál ez számít!), a DJ pultra pedig egyenesen fenomenális.</p> <p>Íme a tapasztalataim, összevissza, lényeges sorrend nélkül.</p> <h3>Negatívok</h3> <p>Az iPad nehéz, alátámasztást igényel. Itt nem arról beszélek, az egyik táblagép 750 gramm, a másik 850, az iPad meg 680, az nem különbség, hanem csak <em>játék a számokkal idióta specifikáció-fetisiszta geekek számára</em>. Egy kézben, papírszerű használathoz maximum 250 grammos súly kellene, olyan masinát viszont senki sem gyárt még.</p> <p>Az iPad huzamosabb kézben tartása közben megfájdul az ember tenyere és néha az ujjai (a karom meg sem érzi, járok kondizni, bibibí), így alá kell támasztani, térddel, combbal, bármivel. Azért szerencsére ilyen testhelyzetet könnyű találni.</p> <p>Az iPhone-os alkalmazások bár ugyanúgy működnek rajta, de bénán néznek ki. Kicsiben béna, nagyítva rondán pixeles. Az ikonjaik is rondák, mert az 57 pixel felnagyítva 72-re nem az igazi.</p> <p>Az iPad-es alkalmazások többsége nagyon bugos még, bár az update-ek mennyiségén látszik, hogy folyamatosan javítják. Kell még neki vagy fél év, mire igazán ütős lesz a kínálat. Nem találtam rá igazán jó Twitter klienst vagy RSS olvasót egyelőre (jelenleg Twitterific és Tweetdeck, valamint Bulletin van fent).</p> <p>A Weather HD iszonyatosan szép, de parasztvakítás.</p> <p>A Wired alkalmazás kidobott pénz, jól néz ki, de sekélyes és kevés a tartalom. Az a kevés animáció meg a rengeteg reklám ennyit nem ér. Bár a szerkesztők szerint ez még csak kísérletezés, hát csak kísérletezzenek tovább, hajrá.</p> <p>A fentiek miatt állandóan az App Store-t bújom, az iPhone-nál ez nem volt. Persze ennek az Apple örül, én nem annyira.</p> <p>Nincsenek tabok a böngészőben, pedig elférnének, az iPhone-os page kontroll ide nem passzol. Tudom, hogy van rá third-party alkalmazás, de nekem natívan kellene.</p> <p>Mobilon hozzászokott az ember, hogy a webes videós oldalak többsége nem megy iPhone-on a Flash hiánya miatt, de az iPad asztali böngészési élményt ad és így jobban hiányzik ez. Ezzel én nem Flash-t szeretnék, hanem h264-es embedet. A Webcsatornánál (béke poraira) már 2008-ban megvalósítottam ezt, 2010-ben miért ügy? A HTML5 videó alapvető kellene, hogy legyen, még a Flash-t amúgy futtató mobilokon is jobb vele a videós élmény!</p> <h3>Pozitívak</h3> <p>Az akksija rettentő sokat bír, egyfolytában nyomkodom, de csak 2-3 naponta kell rádugnom a töltőre.</p> <p>Instant-on, nem olyan, mint egy alvó módban lévő laptop vagy asztali gép, egyből kezelhető.</p> <p>Egy csomó dolgot sokkal gyorsabban lehet rajta végrehajtani, mint bármilyen egyéb géppel. Például az e-mailek megnézése: megnyomom a gombot, slide, mail ikon tap és ott is vagyok. Ez kb. annyi ideig tart, amíg a leggyorsabb laptop kijön sleep módból. </p> <p>Böngészni is gyorsabban lehet vele, például hasonlítsuk össze ezt a két szcenáriót (böngésző nyitva, Indexet akarjuk megnézni):</p> <ul> <li>tapi a címsorra, i betű, tapi az Index.hu-ra a listából </li> <li>egérmutatót elviszem a címsorra, click, i betű, Index.hu-ra viszem az egérmutatót (vagy a nyilakkal tallózom ki), click/enter </li> </ul> <p><strong>Egyszerűen összefoglalva: a tapizás sokkal gyorsabb, mint az egerészés.</strong></p> <p>Nem kell elzarándololni a számítógépasztalhoz, több helyre letehető, mint egy laptop. Ez tényleg egy olyan eszköz, ami bárhol a lakásban működik.</p> <p>Nagyon masszív, az aluház és az üvegfelület igen strapabíró, sajnos csúszott már le a barlangban a lépcső tetejéről (!!! két méter !!!), lent puffant a betonon, és csak néhány karc lett a sarkán.</p> <p>Univerzális DJ cucc, jól mutat a pulton, jó a kimenet hangminősége és ereje, telepíthető egy csomó audió alkalmazás rá, színesíti a szettet.</p> <p>A We Rule nagyon cuki és rettentően ki van találva, a Farmville röhejes kis izének tűnik mellette. A szociális behúzó funkciói félelmetesen jól működnek, pillanatok alatt ismerősi hálót épít ki az ember, mert cserébe sokat lehet kapni, ráadásul arra is rávesz, hogy naponta többször is csekkoljam az ismerősök királyságait.</p> <p>Az Air Video asztali gépről streamelése überfasza.</p> <p>Pinball HD-vel flipperezni a WC-n priceless.</p> <p>Nagyon jó vele a YouTube-on böngészni, jobb érzés, mint az asztali böngészőben. Bogi innen követeli már a Gumimaci-t, de helyette az MTV Dance aktuális slágereit kapja inkább.</p> <p>Orientation lock. Nem is értem, hogy miért volt ez mute kapcsoló korábban.</p> <p><em>Paraszthifi.</em> Nagyon hangos és elég jó minőségben szól a hangszórója, egészen érdekes, hogy a "kezedben érzed a basszust". Amikor a Pinball HD golyója valahol elrejtve "gurul" a flipper belsejében, teljesen úgy tűnik, mintha az iPad belsejében egy igazi golyó mozogna.</p> <p>Nagyon sok apró pozitív élmény. Meg kell tapasztalni, otthoni szórakoztató izének az iPad féle megoldásoké a jövő. Persze <strong>a sok hülye geek</strong> jöhet nekem azzal, hogy milyen sok dolgot nem lehet vele csinálni, de ez nem univerzális számítechnikai eszköz gépnyomóknak, hanem szórakoztató, esetleg produktivitási (pl. zenész) cucc általános, hétköznapi felhasználók (lefordítom a geekeknek: hülyék) számára.</p> <p>Az iPad sok esetben kiváltja az asztali gépet, de nem teljesen, és egyelőre az sem látszik, hogy a jövőben ez megváltozna, ahhoz még sokat kell fejlődni.</p></div> Mon, 10 May 2010 02:00:00 +0200 http://szantog.imect.com/sites/szantog/media/web/mobile.jpg Web http://szantog.com/page/egy_alternativ_mobilos_megoldas http://szantog.com/page/egy_alternativ_mobilos_megoldas <div><strong>Vége a szép időknek, amikor egy weboldalt elég volt 1024x768-ra tervezni, ma már érzékelhető forgalom érkezik mobil eszközökről. Erre az első válasz a mobil változatok megjelenése volt, de ez szerintem nem elég, nem így kellene. A Media2Radio-val már két hónapja kísérletezünk egy másik megközelítéssel. </strong></div><div><p>A következő problémáim vannak a "klasszikus" mobil változatokkal:</p> <ul> <li>A fenntartása drágább, hiszen minden front-end dologból új kell neki (HTML, CSS, interfész-tervezés), duplán dolgozunk. </li> <li>A duplán dolgozást sokszor elfelejtik, a mobilos változat "mostohagyerek", nem követi a desktop változat változásait. Előfordul, hogy rosszul működik, régen jó volt, de valami kimenet megváltozott a desktop miatt, így hibával száll el. </li> <li>Eszközspecifikus mobil változatok, például iPhone skin: a többi mobilon nem biztos, hogy jó ez, csak egyfajta mobilra készülünk? Ne már! (Pedig iPhone-buzi vagyok.) </li> <li>Macerás többféle eszközre tervezni, márpedig ezekből egyre többféle van. Egy oldalnak ma már egészen hihetetlen felbontásokban is kell menni, a mindenféle kézi-kütyük pedig összevissza méretekben érkeznek, ráadásul forgathatók. Ez egyre "rosszabb" lesz. </li> <li>A mobilos (handheld) stylesheet nem igazán működik, egyre több mobil böngészője hazudja magát desktop-nak. Olvasd el az <a href="http://www.alistapart.com/articles/return-of-the-mobile-stylesheet/">A List Apart vonatkozó cikkét</a>, tragikusan kaotikus a dolog, a cikkben lévő megoldási javaslat bonyolult, nehezen tartható karban. </li> </ul> <h4>A Media2Radio-nál kísérletezett megoldásról</h4> <p>A Media2Radio egy "klasszikus" elrendezésű weboldal, ezekből a részekből áll: fő tartalom, kiegészítő tartalom, navigáció, fejléc és lábléc. A fő és kiegészítő tartalom alkotja az oldal "törzsét", két oszlopban. A kiegészítő tartalomban vannak a keresztbeajánlások és egyéb kevésbé fontos "bizbaszok", a fejléc szerepe leginkább az, hogy szép legyen, a lábléc pedig azért van, hogy "ne lógjon az oldal a levegőben", és oda tettünk néhány kevésbe fontos navigációs elemet is.</p> <p>Első lépésként érdemes a fentiek szerint felosztani a tartalmat, mert egyből nyilvánvalóvá válik, hogy mit kell a mobilos részből kidobni: a kiegészítő részt és a fejlécet. A mobilos megjelenés a navigációval kezd, ami lehetőleg csak néhány pontból álljon, senki nem fog 6-7 elemnél több lehetőségben böngészgetni, nem kényelmes. A tartalmi részben minden rugalmas szélességű legyen, így jól fog megjelenni a desktop változat kb. 500 pixel szélességű dobozában és egy mobil képernyőjén is. A mobilos megjelenés végén ismét a lábléc érkezik, a kevésbé fontos linkekkel.</p> <p>Csak egyféle CSS-t készítettünk, nincs handheld és @media, meg egyebek. A lehető legtöbb elem mérete em-ekkel lett megvalósítva, hogy mindenhol rugalmasan jó legyen. És most a legfontosabb:</p> <h5>Mindenhol a mobilos változat az első, a CSS és a HTML kimenet is így lett megírva, csak akkor érkeznek a desktop elemek, ha a képernyő szélessége elég nagy.</h5> <p>Minden munkamenet elején megnézzük JavaScript-tel a screen.width tulajdonságot, ez szerencsére minden böngészőben elérhető és jól működik. Ha nagyobb 800-nál, akkor jelenítjük meg (szintén JavaScript-tel) a többi tartalmat. Ezeket nem húzzuk be mondjuk egy AJAX kéréssel, hanem ott van már a JavaScript kódban sima változóban tárolt HTML kódként, hogy gyors legyen. Amúgy is csak néhány kByte.</p> <p>Mi van, ha nincs JavaScript? No problem, akkor csak a mobilos változat látszik, attól még használhatók maradunk.</p> <p>A CSS kód nem változik, mindössze a body tag kap egy 'bigscreen' class-t. A CSS úgy van megírva, hogy a végén található néhány sornyi body.bigscreen kivétel, így lesz a mobilos CSS-ből desktop. Bumm.</p> <h4> Egyéb apróságok, in no particular order</h4> <p>A margók mindenhol meg lettek növelve, szép nagy white-space-ek vannak mindenhol azért, hogy tapiképernyőn is könnyen lehessen a bumfordi ujjakkal nyomkodni.</p> <p>Az űrlapokat lerövidítettük, csak a legszükségesebb mezőket tartalmazzák, mert mobilon nehézkes a kitöltés, és desktop-on is lusta mindenki. 2010-ben már pláne nem szabad olyan modellekben gondolkodni, ami sok mezőn alapul.</p> <p>Csak egeres dolgoknál van mouse over, mindennek működnie kell anélkül is, maximum nem lesz olyan szép.</p> <p>Ha embed-delünk valami objektumot (hogy legyen zoxigén), akkor tegyük alá/mellé a tartalomra mutató direkt linket is, mert ahány mobil eszköz, annyiféle képpen eszi az ilyesmit. Példa: egy YouTube videónál az embed kód alá kerüljön a videó saját oldalára mutató link, hogy azok az eszközök, amik nem jelenítenek meg ilyesmit, el tudják indítani a saját YouTube appjukat, ha van nekik olyan.</p> <p> Másik példa: az mp3-akat Flash lejátszókban mutatjuk, de adunk direkt mp3 linket is, ha nincs a gépen Flash (és nem, a HTML5 audio player-ek sem működnek minden mobilos eszközön!). A noembed és egyéb alternatív tartalom csacsiságok sajnos nem működnek minden mobilos böngészővel, ezért kell ez a fapados megoldás.</p> <h4>Képek</h4> <p>Érthető, hogy minél kisebb letöltési méret kell, de sokan nem gondolnak a memóriaigényre.</p> <p> A mobilos böngészők általában nagyon kevés RAM-ot használhatnak (a desktop-hoz képest), és hiába a kis letöltési méret (mondjuk 3 kB), a képek általában a felbontásuknak megfelelő szeletet hasítják ki a memóriából, pl. egy 100x100-as 4 csatornás PNG rögtön 40 kB-ot. Ha ezekből több van, akkor pillanatok alatt el lehet érni a több mB méretet, a böngésző pedig elszáll. <strong>Hányszor dobott ki a mobilos böngésződ emiatt, ugyeugye?</strong></p> <h4>Miért jó ez nekünk?</h4> <p>Biztos van még valami, amit kifelejtettem, de a lényeget olvashattátok. A végére itt a slusszpoén, hogy miért érte meg ezt az egészet csinálni azon kívül, hogy többféle eszközön is kábé használhatók maradunk: állandó, tartós növekedést eredményezett a látogatásokban (17%), az oldalon eltöltött idő pedig 23%-kal nőtt.</p></div> Fri, 09 Apr 2010 02:00:00 +0200 http://szantog.imect.com/sites/szantog/media/ Minden más http://szantog.com/page/iphone_cpu_teljesitmeny_ajanlasok http://szantog.com/page/iphone_cpu_teljesitmeny_ajanlasok <div><strong>Az iPhone vs. Android konferencián tartott workshop-om "prezentációja". </strong></div><div><ul> <li>Látványos eredmény főleg UIKit optimalizációval és ARM Assembly-vel. </li> <li>Ha egyébként rendben van a kód. </li> </ul> <p><strong>Hogyan mérjük a terhelést?</strong></p> <ul> <li>Instruments: elsősorban RAM, szivárgás és Core Animation mérésre. CPU-hoz nem jó, abból eleve 35%-ot eszik. </li> <li>Shark: ha már minden kötél szakad, vagy az OS funkciói is érdekesek. </li> <li>Megoldás: jailbreak, SSH és top. 10% CPU. </li> <li>A top-ban csak a teljes, rendszerszintű idle időt nézzük. </li> <li>Könnyű "átvinni" a terhelést a saját kódból az OS-hez (user % -&gt; sys %), de ez nem szabadít fel semmit. </li> </ul> <p><strong>Ökölszabály</strong></p> <p><em>25-30% szabad CPU mindig kell, különben "akadozik" az élmény.</em></p> <h4>NSRunLoop</h4> <ul> <li>A main thread NSRunLoop-ja fontos. </li> <li>Többek között ez fogadja a touch eseményeket és vezérli a legtöbb NSTimer-t. </li> <li>Ha nincs 25-30% szabad CPU, akkor későn fut, későn érkeznek az események - akad. </li> <li>Main thread/main run loop blokkolására ügyelni, események lehető leggyorsabb feldolgozása, külön thread, ha kell. </li> <li>NSRunLoop vezérli, ezért egy NSTimer sohasem pontos, "csúszkál". </li> </ul> <p><strong>UIKit</strong></p> <ul> <li>Állítólag 2D "hagyományos", "nyomkodható" felületeknél az UIKit ugyanolyan gyors, mint az OpenGL. </li> <li>És sokkal kényelmesebb (Interface Builder). </li> <li>Egy UIKit objektum (pl. UIButton) módosítása "költséges", az UIKit a legtöbb esetben blokkol, amíg be nem fejezte a grafikát. </li> <li>Összegyűjteni a módosításokat (pl. UIButton.highlighted), és végrehajtani később, nem a touch event kezelésekor. </li> <li>CADisplayLink objektummal! </li> <li>Az iPhone utálja az átlátszóságot, alpha csatornákat, belassul. </li> <li>A legtöbb objektum átlátszatlan legyen, opaque-ra Interface Builder-ben pipa (igen, végig kell kattintgatni az összeset). </li> <li>Még így se "halmozzuk egymásra" az objektumokat. </li> <li>Ha opaque egy objektum, de alpha-s PNG kép van benne, akkor átlátszó lesz így is... </li> <li>Irtsuk ki az alpha csatornát a felhasznált képeknél, ha lehet. </li> <li>Ami nem látszik, az legyen .hidden = YES (elég a szülőt), különben fölös CPU megy a touch eventek fogadására. </li> <li>A szövegek, UILabel módosítása költséges. Saját drawRect metódus és [self.text drawInRect: sokat segít. </li> <li>A saját drawRect metódusok sokszor gyorsabbak. </li> <li>Instruments - Core Animation - Flash Updated Regions. Esetenként meg fogunk lepődni. </li> <li>A fenti UIKit módosításokkal 160-180%-ról 90%-ra esett vissza a DJ PLAYER erőforrásigénye. </li> </ul> <h4>Thumb mód</h4> <ul> <li>ARM CPU-k, kétféle futási mód: Thumb és ARM. </li> <li>Thumb mód: kisebb kód és más utasításkészlet, ezért kisebb memória sávszél igény - gyorsabb futás, régi eszközökön (nem iPhone). </li> <li>Nem tud lebegőpontos számítást, ilyenkor a fordító átkapcsolja a CPU-t ARM módba, aztán pedig vissza. Ez lassú. </li> <li>iPhone: a Thumb mód alapértelmezett, kapcsoljuk ki. Iterációknál sokat számíthat. </li> </ul> <p><strong>Iterációk</strong></p> <ul> <li>Nézzük meg, hogy a compiler milyen kódot gyárt. </li> <li>Elé és mögé inline asm sorok ( __asm__ volatile ("#innen"); ), majd pedig Build - Show Assembly Code. </li> <li>Próba: "register" kulcsszó néhány fontos változónál, mennyit változik az Assembly kód. Nem kell annyit töltögetni a memóriából. </li> <li>A compiler nem mindig jó a regiszterek hatékony elosztásában, csak néhányat használ. </li> <li>Egyszeres lebegőpontos számokat érdemes használni (sima, 32-bites float), hogy a compiler használja a lebegőpontos egységet. </li> </ul> <p><strong>Assembly</strong></p> <ul> <li>XCode-ban lehet inline Assembly-t írni. </li> <li>A C-változatot is meg kell hagyni, mert a Simulatorhoz felesleges külön Assembly verzió. </li> <li>A Simulator x86-os, a régebbi iPhone-ok ARM6-os, az újabbak pedig ARM7-es kódot kérnek. </li> </ul> <p><strong>ARM CPU</strong></p> <ul> <li>Alapvetően kétféle iPhone létezik. </li> <li>Régi: iPhone 2G/3G, iPod touch 1G/2G, 400 Mhz ARM6 architektúra, 128 MB RAM. </li> <li>Az ARM architektúra nem egyenlő az ARM család számozásával (pl. iPhone 2G: ARM11). </li> <li>Vadhajtás: az iPod touch 2G 533 Mhz-en fut. </li> <li>Új: iPhone 3GS, iPod touch 3G, 600 Mhz ARM7 architektúra, 256 MB RAM. </li> <li>iPad: ARM7 architektúra, 1 GHz, 256 MB RAM ("gyors iPhone 3GS"). </li> <li>Tehát a fejlesztés során alapvetően ARM6 és ARM7 eszközökkel kell foglalkozni. </li> </ul> <p><strong>Lebegőpontos egység</strong></p> <ul> <li>"Beépített" segédprocesszor, lebegőpontos számításokra, főleg vektorokhoz, mátrixokhoz. </li> <li>ARM6: VFP (Vector Floating Point Unit), "VFP utasításkészlet". </li> <li>ARM7: NEON, "NEON utasítások", multimédiára (SIMD). </li> <li>A VFP-s Assembly kód általában lassabban fut az iPhone 3GS-en, mint a C változat! </li> <li>Megoldás: universal binary app (build settings - Architectures - Optimized (armv6 armv7)). </li> <li>Egy kódrészlet így valószínűleg háromféle lesz: C (Simulator), VFP (régi iPhone), NEON (új iPhone). </li> <li>Szerencsére a legtöbb ARM7-es VFP utasítás csak az ARM6-os változat "átnevezése" (pl. fmuls - vmul.f32). </li> <li>Az Assembly-be átírás nem triviális, ne "automatikusan" csináljuk. </li> <li>A regiszterek hatékony kihasználása, a lehető legkevesebb memóriahozzáférés (és lehetőleg blokkban), valamint az utasítások ciklusszámának ismerete akár négyszeres sebességkülönbséget is jelenthet! </li> <li>Minden utasítást adott számú ciklus alatt hajt végre a processzor, de képes többet párhuzamosan is! </li> <li>Egy VFP szorzás pl. 8 ciklus alatt megy végbe, ez idő alatt mást is csinálhat a CPU, ha a következő utasítás nem a szorzás által használt regisztereken dolgozik (párhuzamosítás). </li> </ul> <h4>DJ PLAYER keverő (mixer) kód</h4> <ul> <li>C: 18% CPU. </li> <li>VFP Assembly, a ciklusszámok figyelembe vétele nélkül: 8% CPU. </li> <li>Végleges, optimalizált változat: 2% CPU. </li> </ul> <h4>iPhone OS 4.0</h4> <ul> <li>Accelerate Framework: az Apple megírta helyettünk egy csomó gyakran használt számítás Assembly változatait, és ezeket egyszerű C függvényekként tették elérhetővé. </li> <li>Komplex számításokhoz valószínűleg nem jó, a "kézzel gyártott" Assembly kód (a már említett hatékony regiszterhasználat, ciklusszámok, satöbbik miatt) mindig gyorsabb lesz. </li> </ul></div> Tue, 06 Apr 2010 02:00:00 +0200 http://szantog.imect.com/sites/szantog/media/ Minden más http://szantog.com/page/lassan_ket_honapja http://szantog.com/page/lassan_ket_honapja <div><strong>... nem írtam bejegyzést, mert annyi, de annyi dolog volt, hogy csak na. Elsősorban termékfejlesztés köti le az időmet, ami a kütyük felé érdeklődőknek érdekes lehet. Ezekről hamarosan részletes bejegyzések fognak születni, de egy kis sneak preview sosem árt: </strong></div><div><h4>DJ PLAYER</h4> <p>Ezerrel készül az új DJ PLAYER, ami alapjaiban fog különbözni a jelenlegi változattól. Sajnos erről most még nem mondhatok többet, viszont iszonyatos energiák mentek arra, hogy a prociból a lehető legtöbbet hozzam ki, mert az új funkciók számára sokkal több kell, mint azelőtt.</p> <p><a href="http://iphonevsandroid.hu/">Az iPhone vs. Android konferencián</a> tartok majd egy workshop-ot a témában, ami már csak azért is érdekes, mert egyedül még sosem adtam elő, úgyhogy izgulok.</p> <h4>Mobil weboldal</h4> <p>Átalakítás alatt áll a <a href="http://www.media2radio.com">Media2Radio</a>, ami mobilos kísérleti tereppé vált: megfordítottuk a prioritást, a fő megjelenítési forma a mobilos változat a desktop helyett.</p> <p>Egy új, az eddigiektől eltérő megközelítést fejlesztek, ahol nincs külön mobil és desktop változat, nincs iPhone verzió, Android verzió meg nemtudommilyen verzió, nincs browser agent és egyéb detect.</p> <p>A megoldás 17%-os látogatás (session) növekedést eredményezett, rögtön az első naptól, ami meglepő. Ezzel a projekttel próbálom megváltoztatni az eddigi webes fejlesztési gyakorlatomat, mert attól tartok már messze nem olyan érdekes, nem pezseg annyira.</p> <h4>Tagmasterz</h4> <p>A Tagmasterz két és fél év után elért valamilyen kritikus tömeget, az utóbbi két hónapban már alig bírjuk a foglalásokat, és ezért sokmindent kell továbbfejleszteni.</p> <p>Szerződést írtunk alá a fegyverrendszer eredeti fejlesztőcégével, ezentúl hivatalosan is részt veszünk a fejlesztések egy részében, aminek az első eredménye egy open source hosting állomás lesz.</p> <p>A fényrendszer is továbbfejlesztésre kerül: szerencsére épp a LED technológia robbanásának kellős közepén vagyunk, amit felhasználva izgalmas saját fejlesztésű és gyártású RGB megvilágítást készítek, "Uzsidoboz LED" jeligére.</p> <p>Mindkét új Tagmasterz cucc <a href="http://arduino.cc">Arduino</a> vezérléssel készül, éppen ezért mindenféle <strong>Internet of Things</strong> cucc prototípusa is itt formálódik az asztalomon.</p> <h4>Miről fog szólni tehát a következő pár hónap?</h4> <ul> <li>Mobilos webfejlesztésről, hiszen a desktop böngészés fontossága csökken, a megjelenítési módok pedig hihetetlen változatosak lesznek a legbutább telefontól az iPad-en át a nagy monitorokig. </li> <li>Mobilos alkalmazásfejlesztésről, hiszen nem mindent lehet a weben megoldani, a számítógép viszont sokszor nincs kéznél vagy nem kényelmes. </li> <li>Internet of Things, hogy ne csak a számítógépekről szóljon a világ (ideértve az okostelefonokat és az egyéb hordozható táblákat is). Szeretném a "hatalmamat" némiképp a hardverekre is kiterjeszteni. </li> </ul></div> Tue, 06 Apr 2010 02:00:00 +0200 http://szantog.imect.com/sites/szantog/media/ Minden más http://szantog.com/page/kohog_az_imac http://szantog.com/page/kohog_az_imac <div><strong>Feltettem a 10.6.3-as Snow Leopard frissítést és elkezdett fagyogatni a gépem, amit eddig sohasem tett 2.5 év alatt. Elsődleges munkaeszközöm elvesztése akár csak pár napra is óriási gond, ezért teljesen letaglózott az ügy. </strong></div><div><p>Természetesen átböngésztem a netet megoldás iránt, de egyik sem jött be, újrafrissítettem, ürítettem, töröltem, beállítottam, semmi eredmény.</p> <p>10-20 percenként elszállt a gép, de néhányszor ezt látható videókártya "zizivel" tette, amivel egyből a GPU-ra esett a gyanú. Sajnos a log fájlok nem mutattak semmit az ég világon, viszont safe boot esetén nem volt probléma.</p> <p>Végső elkeseredésemben újratelepítettem mindent, ami egy fejlesztői gépen egy napos mutatvány, hátha. Kicsit jobb lett, már csak óránként fagyott le...</p> <h4>Megoldás?</h4> <p>Olvastam az <a href="http://appleblog.blog.hu/2010/04/01/sokkal_gyorsabb_lett_a_macem_az_update_utan">Appleblog-on</a>, hogy a frissítés jelentősen gyorsított az OpenGL-en, márpedig az OSX ablakkezelője ezt használja. Aztán olyanokat is olvastam, hogy az iMac szériám (első alu ATi 2400 XT-vel) GPU-ja nem strapabíró, sokat kellett cserélni.</p> <p>Valami tehát jobban használja a videókártyámat, ami egy hardverhiba miatt nem bírja úgy, ahogy kellene. Sajnos azonban egy alaplapcsere nem olcsó és sok ideig tart, tehát drága (két és fél éves a gép).</p> <p>Feltelepítettem egy fan control alkalmazást, hogy megnézzem a ventilátorok fordulatszámát, hátha valami szmötyi miatt nem pörög az egyik úgy, ahogy kellene. Végülis egyszer sem mentek 100%-on, hátha csak beragadt valamelyik. Meghajtottam őket 100%-on is: az iMac olyan hangzavart és szélvihart tud csinálni, hogy ihaj!</p> <p>Szétszedni nem tudtam a gépet torx csavarhúzó hiánya miatt, de a képernyőt védő üveg leszedése azért igen mókás volt: WC pumpával kell megfogni és lehúzni (mágneses tüskék tartják). Így lehet a glossy hatást megszüntetni. :-)</p> <h4>Szoftveres megoldásféle</h4> <p>Végül azt találtam ki, hogy elhitetem az OSX-szel, hogy egy gyengébb videókártya van a gépben, nem játszok amúgy sem vele.</p> <ol> <li>Átneveztem a /System/Library/Extensions/_ATIRadeonX2000.kext fájlt, hogy az operációs rendszer ne találja meg (ez a videókártya meghajtója). </li> <li>Töröltem a /System/Library/Caches/com.apple.kext.caches/Startup/Extensions.mkext fájlt, hogy frissüljön az indításkori meghajtó gyorsítótár. </li> <li>Újraindítás. </li> </ol> <p>Sajnos azonban ez sem végleges megoldás, napi 1-2 fagyást még így produkál a rendszer. Van valakinek valami javaslata? 10.6.2-re egyéb okok miatt nem mennék vissza.</p></div> Wed, 13 Jan 2010 01:00:00 +0100 http://szantog.imect.com/sites/szantog/media/etc/djplayer_logo_blue.png Minden más http://szantog.com/page/hazai_fejlesztesu_dj_alkalmazas_iphone-ra_profi_dj-knek http://szantog.com/page/hazai_fejlesztesu_dj_alkalmazas_iphone-ra_profi_dj-knek <div><strong>Azonnali közlésre: Az iMect Bt. a német Stereomusik-kal együttműködve adta ki a DJ PLAYER sorozat első darabját, mely a "Blue Edition" névre hallgat. </strong></div><div><img src="http://szantog.imect.com/sites/szantog/media/etc/djplayer_logo_blue.png" alt=" " /></div><div><p>Több nemzetközileg ismert DJ is bekapcsolódott a fejlesztésbe, hogy "játék" helyett egy igazi, a DJ pultban is jól használható alkalmazás készülhessen el. Óriási harc folyt minden egyes pixelért, hogy a készülékek kis mérete ellenére se kelljen közelről vakoskodni a pultban. Kiemelt szempont volt a lehető legkisebb késleltetés, sikerült a legtöbb asztali "hardvernél" is gyorsabb eszközt készíteni.</p> <p>A megszokott lejátszó funkciók mellett egy teljes értékű effekt szekciót is kapott a szoftver, a TouchPad mellett a készülék billentésével is vezérelhetők az effektek paraméterei.</p> <p>A DJ PLAYER "ütötte ki" elsőként az Apple-nél a "DJ biztosítékot", ez volt az első professzionális DJ szoftver, ami miatt az Apple több, mint 10 hónapig gátolta a hasonló termékek megjelenését az App Store-ban. Az okok nem ismertek, de december hónap folyamán többször is telefonon kértek elnézést Szántó Gábortól (iMect ügyvezető) ezért, ami legalábbis furcsa az Apple-től.</p> <p>A DJ PLAYER Blue Edition ára 24.99 USD, mellyel a prémium kategóriát célozza meg. Árcsökkenés hosszú távon sem várható, de hamarosan megjelenik majd egy ingyenes próbaverzió. A magas ár miatt az sem valószínű, hogy bármilyen App Store toplistában megjelenne a szoftver, de az eladások így is várakozáson felüliek.</p> <p>Weboldal: <a href="http://djplayer.net">http://djplayer.net</a> Videó: <a href="http://www.youtube.com/watch?v=vpWRxPmFJ-4">http://www.youtube.com/watch?v=vpWRxPmFJ-4</a> Sajtófotók: <a href="http://djplayer.net/page/product_media">http://djplayer.net/page/product_media</a></p> <p>Web, mobil és buli, fejlesztés a legújabb technológiák irányában. Videós CMS-től a lasertag diszkóig, ez az iMect: internet, média és egyéb király dolgok.</p> <p>A német Stereomusik több, mint 30 éves tapasztalattal rendelkezik professzionális audio berendézesek tervezésében és gyártásában, melyeket aztán főként ismert világmárkák számára licencel, így a vásárlók sokszor nem is tudják, hogy Stereomusik terméket használnak épp.</p> <p> </p></div> Wed, 09 Dec 2009 01:00:00 +0100 http://szantog.imect.com/sites/szantog/media/web/utube.jpg Web http://szantog.com/page/videos_apro http://szantog.com/page/videos_apro <div><strong>Pre-roll reklámok, embed nézettség, csillagozás. </strong></div><div><img src="http://szantog.imect.com/sites/szantog/media/web/utube.jpg" alt=" " /></div><div><p>A pre-roll reklámok végignézése 70%, azaz elvileg 30% nézőt veszít egy oldal a pre-roll-okkal. Ez azért fontos, mert jelenleg a pre-roll a leginkább eladható videós reklámozási forma. Ebben persze a véletlen odakattintások is benne vannak, tippem szerint a tényleges veszteség úgy 20%.</p> <p>A YouTube éppen ezért (is) átugorható pre-roll videókkal kísérletezik, nemcsak azért, hogy jobb legyen a nézettség, hanem a reklámozók felé is visszajelzést tud küldeni: a minél jobb egy reklám, annál kevésbé ugranak át rajta logika mentén.</p> <h3>Fontos az embed</h3> <p>A YouTube globális videónézettségi részesedése 60%, de az embed piacon 82. Vimeo 8.8%-kal, DailyMotion 4%, MySpace 1.1%, Google Video 1%, a többiek pedig mind-mind alattuk vannak. Ebből szerintem az következik, hogy a tartalom átlagos minősége/eredetisége a YouTube-on és a Vimeo-n a legjobb.</p> <h3>Nem jó a csillagozás</h3> <p>Szintén YouTube hír, hogy fontolgatják az ötcsillagos felhasználói minősítések megszüntetését, mert nagyon torz:</p> <p> <ul> <li>Legjobb minősítést hatszor többször adnak, mint a többit összesen.</li> <li>Csillagozni általában egy jól körülírható "véleményvezér" felhasználói csoport szokott és ez nagyon nem reprezentatív (kevesen vannak). </li> </ul> </p> <p>Úgy tűnik, hogy inkább a végignézést fogják mérvadónak tekinteni ("hányan meddig nézték a melyik részét a videónak").</p> <p> </p></div> Thu, 26 Nov 2009 01:00:00 +0100 http://szantog.imect.com/sites/szantog/media/etc/djplayer_logo_blue.png Minden más http://szantog.com/page/dj_player_blue_edition http://szantog.com/page/dj_player_blue_edition <div><strong>Január 30-a óta vártam rá, hogy bekerüljön az App Store-ba, hát végre. Minden, amit érdemes tudni róla, meg amit egyáltalán elárulok. :-) </strong></div><div><img src="http://szantog.imect.com/sites/szantog/media/etc/djplayer_logo_blue.png" alt=" " /></div><div><p>A nyár folyamán több (nálam sokkal nagyobb és erősebb) cég is DJ alkalmazások fejlesztésébe fogott, amiket szeptember környékén szerettek volna kiadni az App Store-ban. Még augusztusban összeálltam egy német csapattal, akik több ismert cégnek fejlesztenek DJ termékeket (pl. Stanton, Vestax), velük pedig felcsillant a remény, mert vannak kapcsolataik.</p> <p>Persze mindig is voltak bent komolytalan alkalmazások ilyen-olyan "DJ" névvel, de csak november közepén kezdődött el az igazi, tényleg használható szoftverek beengedése, hála az egészpályás letámadásnak (több belsős Apple kontakt, a többiek médiazaja, satöbbi). <em>Ezzel persze elveszett az elsőség, az Apple meg kapja be. </em></p> <p>Azt feltétlenül megjegyezném, hogy próbálkoztam én mindenféle szívélyes e-maileket írni a nagy amerikai blogoknak, hátha fel tudom kelteni az érdeklődést, hiszen minden szir-szar 6-7 hetes csúszásokat is megírnak, én meg már ezer hónapja várok. Á, semmi esély, pedig egész jól tudok külföldi kapcsolatokat szerezni. Sajnos nem vagyok benne a kis szilícium-völgyi mutyiban, nem foglalkoztak velem.</p> <h3>A szoftverről</h3> <p>A DJ PLAYER az asztali médialejátszók versenytársa (CDJ és klónjai), szinte mindent tud, amit kell, ráadásul egy komoly effektrész is került bele. Nem igazán arra való, hogy ezzel szaladgálj a városban, inkább a DJ pultra terveztük. Még sötétben is könnyen eltalálhatók a vezérlők, nem kell közelről matatni rajta. <strong><em>Minden egyes pixelért vérre menő csatákat folytattunk</em></strong>, sok-sok profi DJ eltérő igényét kellett kielégíteni.</p> <p>Nagyon fontos volt az alacsony késleltetés (latency), ezért az alap UIKit-es kontrolkezelést szinte teljes mértékben ki kellett játszani. Meglepően kicsi lett a CPU étvágy, egy mp3 folyamatos kikódolása és lejátszása a teljes UI-val együtt mindössze 18-20%-ot eszik a legrégebbi 2G-s iPhone-on, ez a jellemző terhelési érték. Egy effektel megspékelve 30-40%, kivéve a reverb-et, úgy már 60-70%. Érdekes, hogy a korai fázisban a folyamatos időkijelzés (másodpercenként 15-20-szor) ette meg a legtöbb procit, képes volt akár 30%-is harapni, ezért saját rendert kellett írni hozzá.</p> <p>A minőségre garancia a béta-tesztelők köre, a Media2Radio-nak köszönhetően könnyű volt nemzetközileg ismert arcokat szerezni, pl. a Numark fejlesztési vezetői, Victor Calderone, Misjah... A szoftver neve pedig azért "Blue Edition", mert lesz még több is, ez meg olyan... kék színű. <em>Csak nem fogjuk "basic"-nek hívni.</em></p> <h3>Egy lejátszó?</h3> <p>Igen, egyelőre ez csak egy darab lejátszó keverő nélkül, hiszen az iPhone-nak csak 1 db sztereó kimenete van, amatőr megoldásokba (pl. szétválasztás két monóra) nem szeretnénk belemenni. Dolgozunk rajta.</p> <p>A többi alkalmazáshoz képest drágán adjuk (5 rugó környékén) és a képernyőképekről talán nem is derül ki igazán, hogy mit tud, mert nem eléggé csillog-villog. <strong>Profiknak szánjuk, nem pedig a szélesebb tömegeknek, ráadásul az App Store-os eladások nem igazán fontosak az üzleti tervben.</strong></p> <p>Azt sem gondoltuk, hogy egyáltalán bekerül... úgyhogy most kapargatjuk össze a marketinget, ehhez dobtam össze gyorsan ezt az intró videót. Még rendes weboldala sincs, de majd lesz szebb, színesebb és szagosabb is.</p> <p> <object height="295" width="480"> <param name="movie" value="http://www.youtube.com/v/vpWRxPmFJ-4&amp;hl=en_US&amp;fs=1&amp;rel=0&amp;color1=0x3a3a3a&amp;color2=0x999999" /> <param name="allowFullScreen" value="true" /> <param name="allowscriptaccess" value="always" /><embed src="http://www.youtube.com/v/vpWRxPmFJ-4&amp;hl=en_US&amp;fs=1&amp;rel=0&amp;color1=0x3a3a3a&amp;color2=0x999999" type="application/x-shockwave-flash" width="480" height="295"></embed> </object> </p> <p><a href="http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=339810085&amp;mt=8">iTunes link.</a></p></div> Mon, 02 Nov 2009 01:00:00 +0100 http://szantog.imect.com/sites/szantog/media/ Minden más http://szantog.com/page/harmonic_mixing http://szantog.com/page/harmonic_mixing <div><strong>A harmonic mixing egy olyan DJ technika, ahol nemcsak a számok tempóját veszik figyelembe, hanem odafigyelnek a hangzatra is ("milyen akkordokat használ"). Először cool DJ-zéssel kezdünk, aztán átmegyünk nerdbe, végül a geek tudással megvalósított iPhone-os alkalmazásommal térünk vissza a DJ pultba. Hosszú olvasnivaló. </strong></div><div><p>Sok kezdő/béna/igénytelen DJ szinte kizárólag úgy kever, hogy megvárja a szám végén lévő "üres" (jóformán csak groove-ot tartalmazó) részt és ott úsztatja be a következőt. Ezt hívják "free beats" technikának, ami rendkívül unalmas tud lenni. Azt pedig pláne rühellem, ha egy számot 6-7 percig is hagynak menni, kevés olyan zene van, ahol tényleg szükséges a megfelelő hatás eléréséhez. Ha a teljes szett ilyen, akkor egyszerűen béna a DJ, <em>bár a legnagyobbak is sokszor lusták.</em></p> <p>A harmonic mixing-gel úgy lehet keverni, hogy a mix ne legyen disszonáns ("hamis"), hanem szépen egymásba ússzhasson a két zene, így nem kell megvárni a végét és érdekesebb az egész. A DJ szett hangulata folyamatosan kellemes lehet, de drasztikus pozitív hangulatváltó hatás is elérhető a megfelelő hangzat kiválasztásával.</p> <p>A harmonic mixing alapja a zenére jellemző "alapakkord" megtalálása, azé az akkordé, amelyik a legtöbbször vagy legerősebben van jelen. Ez nem új technika, régen a DJ-k leültek a zongora mellé és addig nyomogatták a különböző akkordokat, amíg nem passzolt, aztán felírták jól. Természetesen megérkeztek már azóta a harmonic mixing szoftverek.</p> <h2>Mixed In Key</h2> <p>Ez a leghíresebb/legjobban marketingelt harmonic mixing szoftver, aminek a készítője birtokolja a <a href="http://www.harmonic-mixing.com/HowTo.aspx">Camelot jelzésrendszer</a>t. Ez semmi mást nem csinál, mint könnyen megjegyezhető és az óra számlapjára asszociáló jelzést ad az uncsi akkordneveknek.</p> <p><img alt="camelot.jpg" src="http://szantog.imect.com/sites/szantog/media/etc/camelot.jpg" /></p> <p>Nagyon egyszerű a használata, az a szabály, hogy a következő szám csak 1 órával térhet el a jelenlegitől, tehát ha a 6-odikban vagyunk, akkor lehet 5 vagy 7. Hangulatváltást pedig úgy lehet elérni, hogy az azonos órában lévő ellenkező modalitású akkordra váltunk (pl. 6B-ről 6A).</p> <p>Aki nem jártas a zenélésben: a harmonic mixing alapvetően kétféle modalitással foglalkozik, ezek a Major (magyarul dúr) és a Minor (magyarul moll) neveket kapták. Azért fontosak ezek, mert a Minor (A) <em>szomorkásabb hangulatú</em>, mint a Major (B).</p> <p>Profi DJ mixeknél általában "körbejárnak az órában", a számok +1 órával következnek egymás után. Ha lanyhul a hangulat, akkor a következő szám +7 vagy +2 órás bedobása (hirtelen váltással vagy free beats-szel, különben disszonáns lesz) sokat segít, mintha "megnövekedett volna az energia" - ezt hívják "Energy Boost Mixing"-nek.</p> <p><strong>A Mixed In Key nem jó fej, licencdíjat kér a Camelot jelzésrendszer használata után. </strong>Állítólag patent pending a dolog, de néhányan rákérdeztek már, és a cégvezető állítása szerint a Camelot a Mixed In Key akkordfelismerő algoritmusában van védve (???). Ráadásul ez csak a "circle of fifths", azaz a kvintkör átnevezgetése, amit pedig nem biztos, hogy egyáltalán le lehet védeni.</p> <p><img alt="kvintkor.png" src="http://szantog.imect.com/sites/szantog/media/etc/kvintkor.png" /></p> <p>Szóval a jogi helyzet kissé tisztázatlan, a cég pedig "keni" a dolgot, a rivális Beatunes épp ezért inkább kivette a Camelot jelzéseket és egy "arra utaló" izével helyettesítette. Én az iPhone-os alkalmazásomba épp ezért nem tettem be a Camelot kört, de a jelzést igen, hátha nem lesz belőle gond.</p> <h2>Algoritmus</h2> <p>Az akkordfelismerés nem egyszerű dolog és nincs rá kész vagy könnyen újrahasznosítható megoldás. A cégek védik a saját eljárásaikat, így az egyszerű halandó egyetemi és egyéb tudományos publikációk elmélkedéseiből indulhat csak ki. Én is ezt tettem, ilyeneket olvasgattam egy-egy kósza pillanatban és próbáltam kitalálni, hogy mit és hogyan kellene - szolid fél évig. <em>Ebben sokat segített a Velence - Déli pályaudvar viszonylat lassúsága.</em></p> <p>Aztán nekiültem és kb. 1 hét alatt kikísérleteztem a saját metódusomat, ami 80-90%-ban egyező eredményeket ad a többi szoftverhez képest. A különböző szoftverek sokszor különböző értékeket adnak, így ez a százalék bőven elegendő ahhoz, hogy jónak ítéljem meg az eredményeket. Dióhéjban és az igazi "titkok" felfedése nélkül a következő a módszer:</p> <p>1. Kb. 0.37 másodperces hangmintákra kell felbontani az audiót, ezeket kell külön-külön megvizsgálni. Azért 0.37, mert így lesz a legkisebb a zengések és egyéb effektek által keltett felharmónikusok hatása, ez a legjobban közelítő statisztikai érték, ami minden zenére jó.</p> <p>2. FFT analízissel kell felbontani a hangmintát, ezzel kapod meg, hogy egy megadott frekvencián mekkora volt a hangerő. Az FFT egy külön tudomány, ablakozni kell és egyebek. Mindenki látott már FFT eredményt, hiszen a leggyakoribb FFT kijelző az audió spektrométer:</p> <p><img alt="visualizer.jpg" src="http://szantog.imect.com/sites/szantog/media/etc/visualizer.jpg" /></p> <p>3. A C1-B6 hangjegyek által határolt tartományt kell megvizsgálni (kb. 32-1975 Hz), az FFT-t érdemes minél részletesebbre venni és a hangjegyek között szépen elosztani (egy hangjegyre általában több FFT adat jut, de okosan kell szétosztani őket).</p> <p>4. Normalizálni kell az adatokat, hogy a halkabb minták is érvényesülhessenek. Érdemes persze egy minimumot is megadni, például -70db-es átlaghangerőnél már biztosan nem fontos egy hangminta.</p> <p>5. Az akkordok modalitásának van egy jellemző "profilja", ami az akkordban lévő egyes hangok hangerőinek egymáshoz való viszonyát mutatja (pl. az első hang mennyivel hangosabb az ötödiknél).</p> <p><img alt="kstemp.jpg" src="http://szantog.imect.com/sites/szantog/media/etc/kstemp.jpg" /></p> <p>Ezt a profilt kell illeszteni a normalizált FFT értékekre, hogy megtaláljuk a leginkább közelítő akkordot. <strong>Nem olyan rettentő régi dolog</strong>, a 80-as évek végén fedezte fel Carol L. Krumhansl és csak 2000 körül tökéletesítette David Temperley.</p> <p>6. Végül a közelítő akkordokat kell ügyesen súlyozva átlagolni, hogy megkapjuk a végeredményt.</p> <h2>Harmonic Mixing for iPhone</h2> <p>Szerencsére ebből a bonyolultságból a felhasználó már semmit sem vesz észre, így néz ki az alkalmazás, mindössze két gomb van rajta:</p> <p><img alt="hm1.jpg" src="http://szantog.imect.com/sites/szantog/media/etc/hm1.jpg" /></p> <p><img alt="hm2.jpg" src="http://szantog.imect.com/sites/szantog/media/etc/hm2.jpg" /></p> <p>Sajnos a már említett licencgondok miatt nincs rajta Camelot jelzés. A design from-scratch készült a kis kezemmel Photoshopban. Sokat kellett dolgozni azon, hogy a bonyolult matekizé elfusson iPhone-on is, de végül jó eredmény született, mert az alkalmazás jellemzően csak 40% CPU-t eszik detektálás közben iPhone 2G-n.</p> <p><a href="http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=338231703&amp;mt=8">iTunes link.</a></p></div> Sat, 31 Oct 2009 01:00:00 +0100 http://szantog.imect.com/sites/szantog/media/web/amazon.jpg Web http://szantog.com/page/amazon_mysql http://szantog.com/page/amazon_mysql <div><strong>Pontosabban Relational Database Service (RDS), ami egy speciális EC2 példány, ami csak MySQL-t futtat. Érdekes, de nem tudom még hova tenni. </strong></div><div><img src="http://szantog.imect.com/sites/szantog/media/web/amazon.jpg" alt=" " /></div><div><p>Az Amazon dolgok bonyolultabbak, mint egy hagyományosabb szolgáltatónál hostolni, ezért nem értem ennek a helyét. Persze könnyebb vele egy MySQL-t megvalósítani, de úgyis kell egy ügyes rendszergazda az Amazon-os cuccokhoz, akinek egy ilyen MySQL összeállítása biztosan nem ügy.</p> <p>Ráadásul a saját megvalósításban totális kontrol van, az RDS-nél nincs saját patch, parancssori és SSH elérés, replikáció. Akkor lesz majd valóban használható, ha megoldják a replikációt is (ígérik), akkor már tényleg sok terhet vesz le a rendszergazda válláról (aki így kénytelen lesz olcsóbb lenni). Viszont drágább, mint a már jelenleg is elérhető third-party, teljes körű Amazon-os MySQL megoldások, például a RightScale-féle.</p> <p>A futtatása kb. 30%-kal kerül többe, mint a vele egyenlő teljesítményű EC2 példányé. Az ár teljesítményfüggő és a fix díjon felül az I/O kérésekért és a sávszélért kell fizetni. Nem kell megijedni, a régión belüli sávszél ingyenes, a webszerver meg úgyis ott van. Már a legkisebbbet is 1.7 GB RAM-mal adják, ez jó, mert tudjuk, hogy a MySQL akkor gyors, ha az adatbázis befér a memóriába.</p> <p>A jelenleg elérhető MySQL verzió 5.1.38 és folyamatosan frissítik/patchelik. Nagyon jó, hogy az árban már benne van az automatikus backup (teljes méretű), lehet nightly és snapshot is. Az adatbázis egy EBS (hálózati) lemezen van, így ha onnan kell olvasni, akkor nyilván lassú: <em>be kell férni a RAM-ba, nincs mese</em>. Csak InnoDB és MyISAM van, de az szerintem bőven elég.</p> <p>Különleges lehetőség, hogy valamennyi díjért (nincs fent, call us!) szinkronban tartanak egy másik farmon lévő replikát is biztonsági célból. Egyébként kaptunk még 15%-os EC2 árcsökkentést is, de <strong>így lassan 2010 táján már kevésnek/drágának érzem a benne foglalt CPU erőket</strong>.</p> <p>Az RDS egyelőre csak az USA-ban érhető el, EU majd később. That's all folks. Használjatok Slicehost-ot, az a legtöbb magyar projektre bőven elég.</p></div> Sat, 31 Oct 2009 01:00:00 +0100 http://szantog.imect.com/sites/szantog/media/etc/iphone.jpg Minden más http://szantog.com/page/a_jailbrake_lassitja_az_iphone-t http://szantog.com/page/a_jailbrake_lassitja_az_iphone-t <div><strong>Jópár helyen olvastam már, pl. <a href="http://appleblog.blog.hu/2009/08/31/gps_lett_az_iphone">Handrástól egy Appleblog-os kommentben</a>, hogyaszondja <em>"Allandoan jossz azzal, hogy milyen lassu a telefonod, de ha vegre kiirtanad azt a jailbrakes szart ami allandoan fut, akkor mingyar gyors lenne :)"</em>. Nade az én telefonom jailbrake-s és nem lassabb, mint a gyári, ezért megnéztem, hogy mi okozhatja. </strong></div><div><img src="http://szantog.imect.com/sites/szantog/media/etc/iphone.jpg" alt=" " /></div><div><p>A jailbrake sokat segít az iPhone fejlesztőnek, beesesházni a telefonra jó dolog (megnézni mi hol van, mi lesz a fejlesztett app-pal, hova kerül, satöbbi). Így kaphatunk bash parancssort is és fel lehet tenni a <strong>top</strong> unix-os segédeszközt, amivel monitorozható, hogy mi eszi a mennyit.</p> <p>A top szerintem jobban használható, mint az XCode-os Instruments CPU monitorja, de ez más téma. Itt van a telóm top-ja egy olyan pillanatban, amikor épp semmi nem fut:</p> <p><img alt="top.png" src="http://szantog.imect.com/sites/szantog/media/etc/top.png" /></p> <p>Látható, hogy a rendszer terhelése szinte 0, a jailbrake-s cuccok nem esznek semmit.</p> <h2>Mik futnak?</h2> <dl> <dt>SCHelper</dt><dd>System Configuration Helper: alapvető rendszerbeállítások kezelése, pl. IP cím, WiFi beállítások, stb. - nélküle nem megy szinte semmi.</dd> <dt>bash</dt><dd>Ez a shell (Windows-osoknak: "parancssor"), ahonnan elindítottam a top-ot.</dd> <dt>sshd</dt><dd>SSH démon: SSH-val jelentkeztem be a telefonba.</dd> <dt>MobilePhone</dt><dd>A telefonkezelő (hívások bonyolítása, minden, amitől telefon az iPhone).</dd> <dt>SpringBoard</dt><dd>Az ikonokat is tartalmazó indítóképernyő/asztal.</dd> <dt>apsd</dt><dd>Apple Push Service Daemon: Push értesítések démona.</dd> <dt>CommCenter</dt><dd>SMS és hasonlók kezelése, de szinte az összes kapcsolatra hatása van, nélküle nem lehet telefonálni, WiFi-zni, Bluetooth-olni.</dd> <dt>accessoryd</dt><dd>A készülékhez kapcsolt kiegészítők kezelése (bármi, amit az alján lévő [dock] konnektorba dughatsz) + TV kimenet.</dd> <dt>configd</dt><dd>Ez is valami rendszerbeállítás-kezelő izé, állítólag főleg hálózati bigyó. :-)</dd> <dt>fairplayd</dt><dd>A DRM-mel védett számok lejátszásához kell, ezt az "iTunes DRM".</dd> <dt>mediaserverd</dt><dd>Ez a keverő démon, ez keveri/hangerőszabályozza a különböző audio csatornák (pl. mikrofon, fejhallgató) és alkalmazások hangjait.</dd> <dt>lockdownd</dt><dd>Egy csomó "biztonsági" és aktivációs dolgot csinál, védi az Apple-t attól, hogy neki nem tetsző dolgokat műveljenek a telefonnal. A jailbreak/unlock miatt ez már biztos nem az eredeti a telefonomon.</dd> <dt>BTServer</dt><dd>Bluetooth-kezelő démon.</dd> <dt>mDNSResponder</dt><dd>Multicast DNS Service Discovery: DNS, Bonjour és egyéb nevek feloldása.</dd> <dt>notifyd</dt><dd>Rendszerüzenetek kezelése processzek között.</dd> <dt>launchd</dt><dd>Alkalmazások/folyamatok/démonok indítása/leállítása és hasonlók.</dd> </dl> <h2>Winterboard</h2> <p>Sok Jailbrake-es beállítással/alkalmazással együtt felkúszhat a Winterboard is, ami az Apple-féle indítóképernyő (Springboard) feltúrbózott/széthekkelt változata. </p> <p><strong>NA EZ AZ A "JAILBRAKES SZAR", AMI CPU-T ZABÁLJA.</strong></p> <p>Persze eheti még több más rosszul megírt "illegális" alkalmazás is, de <em>a legtöbb laikusnak a szép háttérkép miatt feltett Winterboardja lassítja az iPhone-ját</em>, nekem folyamatosan 20-30%-ot evett meg.</p> <p><strong>Ne tedd fel, ennyi az egész.</strong></p> <p>Egyébként a Winterboard-dal érkező Supreme Preferences nevű xar pedig még teleszemeteli a logot is, minden app indítása előtt lefut és ilyen hülyeségeket írkál be (még XCode-ból futtatott "legális" fejlesztési processznél is):</p> <p><em>Supreme Preferences. This makes springboard ya bitch ;)</em></p> <h2>Update</h2> <p>Igen, direkt írtam, hogy jailBRAKE (fék) és nem jailbreak. Poénnak szántam, nem jött be? Nem.</p></div> Tue, 06 Oct 2009 02:00:00 +0200 http://szantog.imect.com/sites/szantog/media/web/adobemax.png Web http://szantog.com/page/ott_lesz_a_flash_minden_okostelefonon http://szantog.com/page/ott_lesz_a_flash_minden_okostelefonon <div><strong>Épp zajlik a <a href="http://max.adobe.com">MAX</a>, az Adobe fejlesztői konferenciája, ami olyan, mint az Apple WWDC, csak kevésbé hájpolt. A tegnap folyamán izgalmas bejelentéseket hallhattunk, mert 2010 első félévében kijön a Flash 10.1, ami ott lesz a legfontosabb okosteló platformokon és egy ügyes húzással úgy-ahogy az iPhone-on is. </strong></div><div><img src="http://szantog.imect.com/sites/szantog/media/web/adobemax.png" alt=" " /></div><div><p>A Flash 10.1-gyel vége a Flash Lite-nak, a mobilok teljesértékű Flash-t kapnak a böngészőjükbe, úgy, mint az asztalon. Állítólag rengeteg optimalizációt tartalmaz azért, hogy a mobilokon is jó legyen a teljesítmény és ne egye az akksit, ráadásul ezek (állítólag) az asztalon is vissza fognak köszönni, így (állítólag, talán) a Flash még jobban fog futni. Persze eddig is jobbára a fejlesztőkön múlt, hogy a Flash mennyi erőforrást zabált, alapjában véve a Flash ma is gyorsabb, mint bármelyik böngészős JavaScript megvalósítás. Tehát kevesebb CPU, kisebb memóriaigény, és a Flash 10.1 már nem asztali player, hanem cross-platform.</p> <p>Végre rendesen használni fogja a futtató eszköz hardveres gyorsítási képességeit, nem fog egy H.264-es videót szoftveresen kikódolni például és a GPU-t is kapásból igénybe veszi (asszem OpenGL-lel).</p> <p>Kapunk HTTP Streaming támogatást, <em>az FMS egyre kevésbé vonzó</em>. Nem kell majd pseudo-streaming-gel szórakozni (bár ez végülis az...) és adaptív bitrátával adhatunk sima HTTP szerverrel. Az FMS-t persze nem hagyta el az Adobe, az RTMFP protokollal P2P területen erősíti a terméket, úgy tűnik jön a P2P live adás lehetősége (a jelenlegi P2P szinte csak chat-hez jó néhány résztvevővel).</p> <p>A Flash 10.1 a mobilos dolgok miatt alapból támogatja a <em>többujjazást</em> (multitouch), a giroszkópot (accelerometer) és a képernyőforgatást. A Flash 10.1 simán a böngészőben fog futni a következő platformokon: Windows Mobile, Palm webOS, Android, Nokia Symbian. Itt van például ez a videó, ahol egy Palm Pré-n megy a Flash egész jól, beszarás:</p> <p><a href="http://www.adobe.com/devnet/flashplayer/articles/mobile_demos_fp10.1/popup01.html"><img alt="flashonpalmpre.jpg" src="http://szantog.imect.com/sites/szantog/media/web/flashonpalmpre.jpg" /></a></p> <p><strong>Az iPhone bizony szenvedni fog a böngészőben lévő Flash hiányától.</strong></p> <p>Lesz még PCM (ha nem tudod mi az: wav) audió adathozzáférés, automatikus mp3 kikódolással, és ugyanez a mikrofonra is, pl. Flash-sel elemezheted a mikrofonból jövő jelet vagy egy mp3 fájl tartalmát.</p> <h2>iPhone</h2> <p>Az Adobe ügyesen kerülte meg az Apple-t és megoldotta, hogy Flash CS5-tel natív App Store-os alkalmazásokat készíthessenek a Flash-es fejlesztők. Tehát semmi köze a böngészőhöz, ezek natív appok kéremszépen. </p> <p><strong>Csak néhány iPhone API lesz elérhető:</strong> multitouch, képernyőforgatás, photo library-be mentés, giroszkóp (accelerometer), geolocation, kopipészt. Nem lehet majd HTML tartalmat embeddelni, az RTMP kódolt változatával streamelni (RTMPE), a H.264-et pedig a beépített QuickTime játsza le - külön indít egyet, az alkalmazásodban nem lehet. ActionScript-et sem lehet embeddelni, mert <strong>nem fut majd semmilyen ActionScript értelmező</strong>, minden natív iPhone: SWF-et behúzhatsz skinezéshez, de benne kódot már nem.</p> <p>Csak tisztán Flash-ben ajánlják a fejlesztést, mert a Flex által gyártott kód túl terjengős és lassú ahhoz, hogy iPhone-on fusson, bár lehetséges. A CS5 olyan kódot készít, amit be lehet tolni az XCode-ba, az szépen összerakja és a továbbiak a már ismert iPhone SDK-s módon mennek majd. Tesztelni csak készüléken lehet, az iPhone szimulátorban nem: feltételezhetően a CS5 ARM-os bájtkódot gyárt, amit statikusan linkel be az app. Az egyik Flash-es azt nyilatkozta, hogy könnyű volt jó teljesítményű kódot gyártani, mert sok tapasztalatuk van az ARM-os dolgokról (lásd Flash Lite).</p> <p>Az a legérdekesebb, hogy néhány szerencsés fejlesztő az alfaváltozattal készített már olyan iPhone-os alkalmazásokat, amik bent vannak az App Store-ban. <em>Szerintem az App Review Team nem is vette észre, hogy mivel készültek.</em> A publikus CS5 béta december környékére várható.</p> <h2>Konklúzió</h2> <p><a href="http://szantog.com/page/webvideos_tortenesek_a_nyaron">A HTML5-tel a Flash videóplatform-os jövője inogni látszik</a>, de ezzel a mobilos húzással ismét megkerülhetetlennek tűnik a Flash. Nincs még egy olyan mobilos fejlesztőeszköz, ami egyszerre ennyi platformot fed le jó teljesítménnyel (a Java ehhez képest vicc). <em>Bizonyára sok Flash fejlesztő kezd el most kisebb képernyőkben gondolkodni.</em></p> <p>Habár nyilván eltér majd a megvalósítás itt-ott és foglakozni kell az egyes platformok sajátosságaival is, de mégiscsak <strong>olcsóbb lesz fejleszteni mobilra</strong>: a mobilos alkalmazások többségét Flash-ben is létre lehet hozni majd, a platformokra készített eredeti fejlesztőeszközöket pedig csak speciálisabb esetekben lesz érdemes használni.</p> <p><em>Hiába volt eddig is rengeteg mobilos app, úgy tűnik jövőre jön a lavina.</em></p></div> Thu, 24 Sep 2009 02:00:00 +0200 http://szantog.imect.com/sites/szantog/media/web/utube.jpg Web http://szantog.com/page/webvideos_tortenesek_a_nyaron http://szantog.com/page/webvideos_tortenesek_a_nyaron <div><strong>Az év első felében úgy tűnt, hogy a H.264 lesz a befutó kvázi-szabvány a weben: kiforrt a Flash/Silverlight támogatás, ez lett az iPhone egyetlen használható formátuma, egyre-másra jelentették be a nagy médiaszerver fejlesztők a H.264 képességeket (pl. Microsoft, Adobe FMS, Wowza), élőzésre is. De jön a HTML5 és a Google megvette az On2-t. </strong></div><div><img src="http://szantog.imect.com/sites/szantog/media/web/utube.jpg" alt=" " /></div><div><p>Ma az egyetlen épkézláb (széleskörben elérhető és támogatott) webes videólejátszó platform a Flash. A Silverlight műszakilag már elég jó, de nem terjedt el, jogi okok miatt nem tolhatja be a Microsoft automatikus frissítésként <em>(biztos sóhajtoznak miatta épp eleget)</em>.</p> <h2>Flash Access 2.0</h2> <p>A Flash mostanában látszik behozni a Silverlight egyetlen jelentősebb előnyét, a DRM képességet <em>(igen, fúj, de sok tartalomszolgáltatónak kell, neked meg a pénzük, nem?)</em>. Eddig volt a Flash Media Rights Management Server, amivel csak AIR-hez lehetett DRM-es videókat tolni, most viszont sokkal barátságosabb nevet kapott (Flash Access 2.0) és működik a sima player-rel is. Sőt, a DRM megy a sima progresszív download-ra, nem kell hozzá feltétlen FMS. Persze ez még csak a jövő, 2010 első félév.</p> <h2>HTTP video streaming...</h2> <p>... azaz sima progresszív download. Ez a menő, nem a médiaszerver, hiszen nem kell hozzá "semmi". Az Apple a 3.0-s iPhone szoftverrel egyidőben mutatta meg, hogy lehet rajta mit fejleszteni: az új Quicktime (desktopon, iPhone-on és az iPhone Safari böngészőjében is!) tudja az adaptív bitrátát http letöltéssel, azaz dinamikusan állítja a képminőséget a felhasználó sávszélességéhez. Live stream is lehetséges.</p> <p>Az adaptív bitráta egyébként úgy működik, hogy egyszerre több változatba kódolják a videót, aztán bizonyos időközönként megnézi a szerver vagy a player, hogy épp mennyi sávszéle van a felhasználónak és aszerint szolgálja/kéri a megfelelőt/legközelebbit. Az Apple megoldásában ezt tisztán a player tudja, de amíg a többiek a médiaszerverükkel kb. 2 másodperces időközönként vizsgálnak, addig a http-vel azért nem érdemes ilyen gyakran.</p> <h2>On2</h2> <p>A VP6 volt sokáig a Flash platform egyetlen jó minőségű videokodekje, az On2-tól licencelte az Adobe. A VP6-ba kódolás költséges volt, az On2 drágán adta hozzá az eszközöket, ezért tűnt jó ötletnek a H.264, hiszen az halvánnyal jobb minőséget adott és ingyenes eszközökkel (FFMPEG) is előállítható. Igenám, csak sokan megnézték az apróbetűt: <a href="http://szantog.com/page/h264_licencdij_wtf">a H.264 felhasználása sok esetben pénzes dolog</a>.</p> <p>A Google-nak érthető módon fontos a webes videó, így nem csoda, hogy vettek maguknak egy "formátumot", amivel jó minőségben lehet tolni a tartalmakat és nincsenek járulékos költségek - <strong>kérdés, hogy hogyan arányul ez a 106.5 millió USD vételárhoz</strong> (állítólag igen rosszul).</p> <p>Az On2-val jön még a VP7 és VP8 kodek is: állítólag a VP8 jobb minden jelenlegi vetélytárs kodeknél, <strong><em>de igazából senki sem látta</em></strong>, hiába jelentették be 2008 végén. Ezzel a fegyvertárral a Google jó eséllyel indul a webes videószabványért folytatott harcban, mely a HTML5-tel kap új erőre.</p> <h2>HTML5</h2> <p>Az új HTML szabvány egyik újítása a beépített video és audio tag, így nem kell mondjuk Flash-be bújtatni a videót, hanem ugyanúgy kezelhető, mint egy sima kép, illetve JavaScript-ből közvetlenül buzerálható. Az Adobe Flash platform lényege, fejőstehene pedig a videó lenne, pont ennek megy neki.</p> <p>Jópár videós oldalnak van már kísérleti HTML5 verziója, <a href="http://www.youtube.com/html5">a YouTube-nak is</a>. A "natív" videókezelés jót tesz a fejlesztőknek, egyszerűbb és átláthatóbb lesz a kód (nem kell külön platformon fejleszteni) és nem kell ki-be ugrálni a Flash meg a JavaScript között. A reklámozóknak is jó, mert:</p> <ul> <li>Jó minőségű bannert (pl. ami nem tekeri a CPU-t) gyártani/megfizetni továbbra sem hajlandók.</li> <li>Flashben nincs széleskörűen elfogadott/használt/egységes reklámbeépítési lehetőség, a rossz minőségű bannerek pedig az egész Flash-es videólejátszót belassítják, tönkreteszik a felhasználói élményt.</li> <li>Nincs széleskörűen elfogadott/használt/egységes Flash videólejátszó.</li> <li>A fentiekre tett erőfeszítések rendre elbuknak (pl. Open Video Player Initiative). </li> </ul> <h2>HTML5 kodek?</h2> <p>Ez eddig szép is lenne, csakhogy a HTML5 nem szabja meg, hogy a böngészőknek a video tag "alatt" milyen videóformátumokat kellene elfogadniuk, nem mondja meg, hogy akkor mostantól minden legyen H.264 vagy akármi.</p> <p>Eredetileg az Ogg/Theora volt a célpont, de az ellenérdekelt felek a saját favoritjukat tolják: a Mozilla az Ogg/Theora-t, az Apple Quicktime-ozik (azon belül inkább H.264), a Google most talán VP-zni fog, a Microsoft pedig nyilván WMV. Ezek közül egyelőre csak az Ogg/Theora open source, de a többihez képest sajnos gyengébb a képminősége és természetesen mindenki a sajátját szeretné a HTML5-ben alapértelmezettként látni. Az álláspontok:</p> <ul> <li>Az Apple nem szeretné az Ogg/Theorát szerzői jogi problémák és a hardweres támogatás hiánya miatt <em>(tehát kamuznak, mint mindig)</em>.</li> <li>A Google betette az Ogg/Theora és a H.264 támogatást is a Chrome-ba, de egyrészt valószínűleg VP-zni fog, másrészt szerintük az Ogg/Theora "minőség per bit mutatója nem elég jó a YouTube forgalmához". Ez igaz, több sávszél kellene ugyanolyan minőséghez, ami YouTube méretekben túl drága.</li> <li>Az Opera és a Mozilla nem építi be a H.264-et, mert sokba kerül a licenc és ők kicsik - érthető álláspont.</li> <li>A Microsoft csak most augusztustól szállt be publikusan a buliba (5 év után...), még nincs véleményük. Egyelőre csak annyit mondtak, hogy támogatják a video tag-et. </li> </ul> <h2>Talán a Google-nál a labda</h2> <p>A webes videóipar több, mint fele maga a YouTube, tök mindegy, hogy a videók számát vagy a nézett perceket vizsgáljuk. A Google döntése a YouTube jövőbeli formátumának irányában valószínűleg meghatározó lesz. A VP6 végülis jó választás:</p> <ul> <li>Jó minőségű. </li> <li>Ha a böngésző nem támogatja HTML5/natív módban, akkor Flash-sel még mindig lejátszható. </li> <li>Ingyér van a Google-nek most már.</li> </ul> <p>Ehhez viszont az is kellene és suttogják (remélik?), hogy szabaddá teszik a formátumot, hadd kódoljon mindenki VP6-ba ingyen, az FFMPEG például tudná már most is. Szerintem akkor jönne el a paradicsom, ha bilibe lóg a kezem:</p> <ul> <li>Legyen a VPV8 teljesen ingyenes és open. </li> <li>Legyen a VP8 a HTML5 default. </li> <li>Lehessen FFMPEG-gel VP8-at készíteni. </li> <li>Ha mégsem, akkor H.264, de csak akkor, ha az is ingyenes lesz. </li> <li>Tudja minden böngésző az adaptív bitrátájú http streaming-et (és a kodek is legyen jó hozzá).</li> </ul> <h2>Konklúzió</h2> <p>Jövőre még biztos Flash-ezni fogunk, távolabbra pedig nem merészkednék, hiszen egy év óriási idő ezen a területen. Remélem el fog dőlni a formátumháború és nem lesz patthelyzet, mert az a legrosszabb: minden böngészőhöz külön kódolni? Neeee, akkor marad a Flash.</p></div> Mon, 31 Aug 2009 02:00:00 +0200 http://szantog.imect.com/sites/szantog/media/ Minden más http://szantog.com/page/elokeszuletek_es_alapozas http://szantog.com/page/elokeszuletek_es_alapozas <div><strong>Az építkezés megkezdésének volt néhány feltétele, amit az alapozás megkezdéséig (kb. március eleje) biztosítani kellett. Egyedül áram volt a telken, de a többi közművet hiába rendeltem meg, tudtam, hogy nem lesznek meg időben. </strong></div><div><p>Először a kútnak fogtunk neki még novemberben, hiszen víz nélkül nincs alap. Egy helybélit bíztam meg vele, ő ismeri legjobban a terepet, a talajviszonyokat. A talajvíz kb. 14 méteren van (enyhe dombon vagyunk), így egy talajvizes kút fúrása kb. 200e Ft-ra jött volna ki: ebben 30 méteres mélység van a jó vízhozamhoz és mellé gyöngykavicsos szűrőréteg kialakítása.</p> <p>Inkább a karsztvizes megoldást választottuk, mert csak 50e Ft-tal drágább és ivóvíz-minőséget ad tuti vízhozammal. A karsztvíz fölött vízzáró réteg van, a talajvíz nem ér el oda, viszont 60 méterre kellett fúrni. A kútban így van 36 méter cső és alatta a vízgyűjtő.</p> <p>Szerencsénkre volt a telken némi építési/hulladék fa, így gyorsan összedobtunk egy kocsibejárót a kutasnak (végig árok van mellettünk). Egy hétig dolgozott, az utolsó két napban már nem fúrt, "csak" a vízgyűjtőt alakította ki. Elég bonyolultnak tűnt a dolog, nem is hittem volna. Fúrás közben folyamatosan figyelte a feljövő szmötyit és szorgosan jegyzetelte, hogy milyen mélyen milyen föld van.</p> <p>Egyik nap szívott is egy nagyot, mert a fúrással laza homokos rétegben nem lehet megállni, így sötétedés után is addig kellett dolgoznia, amíg meg tudott állni. Miután elkészült a kút, letesztelte és bemérte, hogy milyen teljesítményű szivattyút milyen mélyre kell elhelyezni adott vízhozamhoz.</p> <p>Szerencsére sikerült az egyik barkácsáruházban ráakadni az általa ajánlott olasz (egyébként hiánycikk) szivattyúra, ami ráadásul a kínai tesók árában volt 40e Ft-ért (TM-10). 11-14 méteren kellett elhelyezni, amihez kellett jó erős műanyag kötél meg 1-es slag, hogy amíg felér a víz ne legyen szűkítés (ne erőlködjön). Ez az összeállítás mindössze 750W-tal 35 liter/perc vizet hoz fel, bármilyen hosszú ideig (azaz nem fogy ki). Ez a 35 liter/perc kábé olyan, mint a vezetékes víz maxigázon, bőven elég.</p> <p>Bár még nem vizsgáltattam be az ÁNTSZ-nél, azért lehet sejteni, hogy ivóvíz minőségünk van. 2 hétig ezt itták az ácsok, utána mi is rákaptunk, mert nagyon finom, hideg és hihetetlenül átlátszó - fél év alatt még senkinek sem lett baja tőle.</p> <h3>WC</h3> <p>Minden építkezéshez kell egy budi (előírás és szerződési feltétel!), amit édesapám a szomszédja leselejtezett parkettájából ácsolt össze lapraszerelve, majd a helyszínen pikk-pakk telepítettük is (tiszta IKEA), épp az alapozás (március) előtt. Összköltség: 0 Ft. Barkácsáruházban készen 30-40e Ft, mobil WC pedig 3 hónapra horror. Mondjuk a pikk-pakk telepítés az első napon a nagy szél miatt nem sikerült, gyakorlatilag a szél egyedül pakolta le a táblákat a kocsi tetejéről, jó kis vitorlák voltak.</p> <p>Még műanyag deszkát is raktunk bele, a melósok pedig szépen belakták (WC papír, stb.), csak a csöcsös képeket hiányoltuk. Már nincs az eredeti helyén, most a kert sarkában szolgál szerszámosként. :-)</p> <h3>Ideiglenes kocsibejáró</h3> <p>Szükségünk volt egy "melós" kocsibejáróra az árok miatt: jó szélesnek és erősnek kellett lennie, hogy elbírja a teherautókat és a mixert, tehát úgy 30-40 tonnát... A végleges (vasbeton) kocsibejáró ezeket nem bírta volna el, összetört volna, mint a ropi.</p> <p>Ezt is sikerült 0 Ft-ból megoldani, volt a telken némi építési hulladék, onnan kikukáztunk két 30-as műanyag félcsövet, aztán jött rá némi föld, betonhulladék, megint föld, megint betonhulladék, megint föld...</p> <p>Novemberben készítettük, így volt ideje télen "összeállni", majd pedig az alapozáskor tömörödött meg a betonmixer alatt, jó 10 centit süllyedt a teteje. Még most is bírja a strapát, pedig az oldala már többször bedőlt. Lassan el kell majd bontani, de annyira összetömörödött, hogy a csákány sem igazán viszi, a víz már nem árt neki, valami gépi trükk kell, nem is tudom.</p> <h3>Építési-szerelési biztosítás</h3> <p>Ilyet is kellett kötnöm, mert az építési vállalkozónak a még be nem épített anyagokra ugyan van biztosítása, de ha már be van építve, onnantól az én felelősségem. Ez 50e Ft volt és másfél óra ügyintézés. Nagyon fontos.</p> <h3>Alapozás</h3> <p>Kicsit hosszúra sikerült ez a tél, így csak márciusra lett olyan idő, hogy az előrejelzés szerint 1 hétig nem volt fagy és nappal legalább +5 a meleg. Mindössze 6 nap alatt végeztek vele, pedig teljesen hagyományos sávalap készült, semmi extra. Hétfőn kitűzték (kimérték és madzagokkal megjelölték) és ki is ásták, szombat délelőtt pedig már csak a készet láttam.</p> <p>80-100cm-re ástak, itt van hazánkban a fagyhatár. Aztán ezt majdnem színig töltötték betonnal, arra pedig két sor zsalukő került (vasalva). A zsalukövekbe is beton jött, majd pedig kitöltötték az alap közeit földdel és sóderral, jól bevibrálva (tömörítve). Erre szigetelést tettek, majd pedig az egészre egy 10 centis vasbeton lap került (a szerelőbeton). Ja, és persze közben behelyezték a víz bemenő és lefolyócsöveket is.</p> <p>Ezután már csak annyi dolgunk volt, hogy az első két hétben naponta locsoljuk az alapot, aztán pedig kétnaponta, háromnaponta: eltartott egy hónapig és jó sok benzin kellett hozzá (Kispestről). Ezt hívják a beton utókezelésének, nélküle "megég" és nem lesz olyan tartós, úgyhogy csak mi csináltuk vagy megbízható családtagok, mégiscsak az alapról van szó.</p> <p>Végül az alapozás után egy napig takarítottuk a telket, összeszedtük a törmeléket, betont, kavicsokat, hogy ne legyen dzsuva. Ezt a jó szokásunkat megtartottuk az építkezés végéig, így egy későbbi gyepesítéshez nem kell majd földet hozatnunk marha drágán.</p> <p> </p></div> Mon, 13 Jul 2009 02:00:00 +0200 http://szantog.imect.com/sites/szantog/media/etc/toiletpaper.jpg Minden más http://szantog.com/page/papirmunka http://szantog.com/page/papirmunka <div><strong>Az építkezés időigénye 3, a papírmunkáé pedig 7-8 hónap, undorító, ezért egy bejegyzésben le is tudom. Fúj. Először szerződést kell kötni az építési vállalkozóval, utána megterveztetni a házat, aztán jön az építési engedély. Hitelt a bankok csak akkor adnak, ha már beépítetted az önrészt (pl. áll az alap), szóval az a legutolsó, hiába lenne a költségvetés a legfontosabb. </strong></div><div><img src="http://szantog.imect.com/sites/szantog/media/etc/toiletpaper.jpg" alt=" " /></div><div><p>Gyakorlatilag 1 hét alatt megállapodtunk a részletekben: úgy haladtunk, hogy a kulcsrakész kivitelezésből kivettük azokat a részeket, amiket mi is meg tudunk csinálni, így olcsóbb. A vállalkozó adott egy részletes listát az építési fázisokról (ez lett a műszaki melléklet), beárazta azokat, mi pedig alkudoztunk. A végösszeg ekkor még egy becsült dolog volt a körülbelüli négyzetméter alapján.</p> <p>Itt hagytuk ki például a garázst: <strong>kicsit luxus 3-5 millió Ft-ért a házba terveztetni, ennyibe kerül egy komplett autó.</strong> Elfér majd az udvaron, saját kivitelezéssel, sokkal olcsóbban.</p> <p>Ezután aláírtuk az (elő)szerződést és indult a tervezés. Itt rengeteg mindent figyelembe kell venni. Érdemes végigmenni a mindennapi folyamatokon, például a mosásnál: honnan hozom a ruhát, hova teszem, hol legyen a mosógép, aztán hol szárítok, merre fordulok. És még bele is kell férni 90 négyzetméterbe, de jó legyen a bevilágítás (honnan süt a nap, mikor) és a terasz se az utca vagy a szomszéd felé nézzen, satöbbi. Meg kell felelni a szocpol feltételeinek (helyiségek száma, mérete, költséghatárok), valamint épp ekkor változott az OTÉK is ("építési törvény"). Egy hónap kellett hozzá és az eredmény a "Lakóépület építése - építési engedélyezési tervdokumentáció".</p> <h3>The quest for építési engedély</h3> <p>Közben elkezdtem járni a közműszolgáltatókat, hogy beszerezzem a hozzájárulásukat az építési engedélyhez. Víz, csatorna, gáz, áram, kéményseprő - mindegyik máskor ügyfélfogad és más papírokat kér. Ehhez persze többször is el kellett mennem a székesfehérvári Földhivatalba (csak az ad térképmásolatot), meg egyéb helyekre beszerezni mindenfélét, rendszerint vidéken. Ráment a teljes november, pedig minden héten két napot is elszúrtam vele. Ha valakinek "normális" 8 órás állása van, akkor elképzelni sem tudom, hogy hogyan intézi el.</p> <p><em>Egyébként ez egy undorító, törvényileg bebetonozott tuti biznisz a semmire.</em></p> <p> A vizes úgy adta ki a hozzájárulást, hogy be kellett fizetnem 2400 Ft-ot a postán (náluk nem lehet, sárga csekk) azért, hogy 5 másodperc alatt kikeresse a címem a gépén (van-e ott vízcső?) és bepötyögje a Word sablonba az adatokat. A kéményseprő 20 másodpercig tanulmányozta a terveket és utána kinyomtatta a hasonló sablont, hétezerért. Tuti üzlet, államilag rögzítve.</p> <p>December elején sikerült beadni az építési engedély kérelmet az összes szükséges papírral és aláírtuk a végleges építési szerződést is. Innentől kezdődött az idegtépő várakozás, mivel közben válság volt, a bankok össze-vissza alakították a hitelkonstrukciókat, szinte naponta változott, hogy kapunk-e hitelt vagy sem.</p> <p>Mondanom sem kell, hogy a hivatal kihasználta a maximális 60 napot az engedély megadására, február elejére kaptuk meg. Ekkor azonban az még nem "érvényes", azaz nem jogerős! Csak akkor, ha az összes szomszéd (2 oldalsó + 1 hátsó) tértivevénnyel megkapta a határozatot és a kézhezvételtől számítva 15 napon belül nem fellebbez. Ha mondjuk külföldön van a kedves szomszéd X hónapig, akkor addig kellene várni...</p> <p>Úgyhogy kikértem a szomszédok tulajdoni lapját, aztán elkezdtem nyomozni utánuk - a szomszédban még nincs építmény, sosem láttam őket... a hátsó pedig szántóföld, remek! Kettő telefonszámát megtaláltam a telefonkönyvben, egynek pedig elkocsikáztam a címére, hátha szerencsém lesz. Mázli, de minddel sikerült találkozni két nap alatt és lemondattam őket a fellebbezési jogukról, mert február közepén jártunk már és gyorsan kellett intézkedni. A hivatalban megadták rá a "jogerős" pecsétet, úgyhogy végre mehettem a vállalkozómhoz és a bankhoz.</p> <h3>Február közepe...</h3> <p>A vállalkozó nekilátott a kivitelezési terveknek (ezek nem a hivatalnak, hanem a munkásoknak és a házgyárnak szólnak), a banknál pedig elindítottuk a hitelfelvételt. Ehhez kellett még egy raklap mindenféle irat, beleértve sok feleslegeset is (pl. a jegyzőnek kell igazolnia a szocpolhoz, hogy van egy gyermekünk, de akkor minek a születési anyakönyvi kivonat?).</p> <h3>Hitel</h3> <p>A hitelfelvétel egy közvetítőn keresztül, kvázi "csókos" módon történt. Megismertük személyesen a fiókvezetőt és minden ügyintézőt - ennek ellenére sem volt zökkenőmentes a dolog, pedig minden papírt időben és hiánypótlás nélkül hoztunk (Ani nagyon ért az adminisztratív ügyekhez). Egyszerűen nem hiszem el, hogy valaki bemegy az "utcáról" és sikeresen veszi ezeket az akadályokat.</p> <p>Persze ez építési hitel, jóval bonyolultabb, mint a "sima" lakásvásárlási. A bank előírásai miatt az építési vállalkozóval is módosítani kellett a fizetési ütemezést, illetve minden ütem után (jó pénzért) kijön az értékbecslő és ellenőrzi, hogy megtörtént-e aminek kell. Márciusban kezdtük a banki ügyintézést, május végén pedig az első részlet folyósításával (közvetlenül a vállalkozónak) nyugodhattunk meg, hogy megvan a finanszírozás. Kicsit parás volt, hiszen már márciusban elkészült az alap és május 5-én kezdődött a házállítás...</p> <h3>Alles zusammen</h3> <p>Ezekre a helyekre kellett járnom az utóbbi hónapokban, mindenhova többször:</p> <ul> <li>Kispest, Polgármesteri Hivatal (szocpolhoz) </li> <li>Gárdony, Polgármesteri Hivatal (építéshatóság) </li> <li>Kápolnásnyék, Polgármesteri Hivatal (közmű ügyek) </li> <li>APEH (Haller utcai rettenet) </li> <li>DRV kirendeltség (vízművek, Velence) </li> <li>E.ON ügyfélszolgálat (gáz + áram, Székesfehérvár) </li> <li>Kémény Zrt. (kéményseprő, Székesfehérvár) </li> <li>Földhivatal (Székesfehérvár, egyszerűbb ügyekben Pesten a Lurdy-ban) </li> <li>hitelügyintéző </li> <li>K&amp;H kispesti fiók </li> <li>Posta (épp ahol kellett) </li> <li>víztervező + kivitelező </li> <li>gáztervező </li> <li>Anico Kft. (építési vállalkozó) </li> <li>tervező (Navaran) </li> </ul> <p><em>Ami a lényeg: nem szabad idegeskedni, hogy mit mi után, mennyi van még hátra és hasonlók, csak mosolyogva irány az ügyintéző és akkor ő is kedves és segítőkész lesz. Valamint legyen meg minden papír egy fakkban, akkor mindig kéznél lesz és sok kört spórolsz</em> ( = "bugyi", mert mappákba már bőven nem fér).</p> <p>De azért így is ledaráltam kb. 3 ezer km-t csak a papírügyek miatt, az meg úgy 5 tank benzin a Corsánknak. A Földhivatalban összesen 30e Ft-ot hagytam, pedig igyekeztem optimalizálni. Eddig összesen 750e Ft-ot költöttünk tisztán adminisztratív dolgokra (pl. ilyen-olyan bekötés adminisztrációs díja, illeték, közvetítői díj, ügyvédi költség) a tervezés díján felül, vagyonszerzési illeték nélkül. Mielőtt megkérdezitek: a vagyonadó szerint kb. 12 millió lesz az egész értéke...</p> <p>Sajnos a papírdolgoknak még nincs vége, hátra van még a használatbavételi eljárás (ismét körbejárhatom az összes közművest) és a személyes + céges papírok átírása kismillió helyen.</p></div> Thu, 18 Jun 2009 02:00:00 +0200 http://szantog.imect.com/sites/szantog/media/web/amazon.jpg Web http://szantog.com/page/aws_importexport_for_physical_data_transfer http://szantog.com/page/aws_importexport_for_physical_data_transfer <div><strong>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. </strong></div><div><ol> <li>Felteszed az adataid egy HDD-re vagy akár egy komplett rack-be szerelt storage megoldásra (max. 22 kiló lehet). </li> <li>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. </li> <li>Megcsinálod a szükséges autentikációt (digit aláírás és társai). </li> <li>Elpostázod a cuccost az Amazon-nak. </li> <li>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.</li> </ol> <p>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?</p></div> Mon, 01 Jun 2009 02:00:00 +0200 http://szantog.imect.com/sites/szantog/media/web/amazon.jpg Web http://szantog.com/page/automatikus_skalazodas_az_amazon_ec2-n http://szantog.com/page/automatikus_skalazodas_az_amazon_ec2-n <div><strong>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. </strong></div><div><img src="http://szantog.imect.com/sites/szantog/media/web/amazon.jpg" alt=" " /></div><div><p>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.</p> <h3>CloudWatch</h3> <p>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:</p> <ul> <li>CPU használat (százalék) </li> <li>hálózati forgalom (összes interfész) kifelé, befelé (bájt) </li> <li>háttértár használat (operation, bájt) írás/olvasás </li> </ul> <p>A következők pedig csak a terheléselosztáshoz (Elastic Load Balancing) figyelhetők:</p> <ul> <li>latency (kérések és válaszok közötti idő, ahogy a load balancer látja) </li> <li>kérések száma per másodperc </li> <li>"egészséges" és "beteg" szerverek száma (értsd: hány bírja és hány van leterhelve) </li> </ul> <p>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:</p> <ul> <li>adott szerverpéldány (instance) </li> <li>szerverpéldány típus (pl. m1.small) </li> <li>image (csak azok a szerverek, amik egy adott image-et futtatnak) </li> <li>szerverfarm </li> <li>autoscaling csoport név (lehet saját csoportokat csinálni, ezekbe szerverazonosítókat pakolni stb.) </li> <li>terheléselosztó (load balancer) neve (tehát azok a szerverek, akik ugyanazon az elosztón lógnak) </li> </ul> <h3>Elastic Load Balancing</h3> <p>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".</p> <p>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.</p> <h3>Auto Scaling</h3> <p>Ő 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.</p> <h3>GUI-t neki!</h3> <p>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.</p> <p>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.</p> <h3>Árak</h3> <p>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.</p> <p>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.</p></div> Thu, 07 May 2009 02:00:00 +0200 http://szantog.imect.com/sites/szantog/media/etc/iphone.jpg Web http://szantog.com/page/szopat_az_apple_kemenyen http://szantog.com/page/szopat_az_apple_kemenyen <div><strong><a href="http://szantog.com/page/a_csatlakozas_az_iphone_developer_program-hoz_szivas">Már írtam róla</a>, 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 <a href="http://djplayer.imect.com">DJ Player alkalmazás</a>, 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! </strong></div><div><img src="http://szantog.imect.com/sites/szantog/media/etc/iphone.jpg" alt=" " /></div><div><p> 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. </p> <h3>Nem konzisztens</h3> <p> Ez volt az első hibám. <strong>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.</strong> Az elfogadási eljárás nem konzisztens! </p> <h3>Ikon</h3> <p> 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.) <em>Nem lehet semmilyen Apple-s termékre hasonlító ikonod vagy képed az alkalmazásodon belül!</em> </p> <p> 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. </p> <h3>Béta</h3> <p> 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. </p> <p> 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... <strong>De csak ő, Te nem!</strong> </p> <h3>Egy körben?</h3> <p> 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á). </p> <p> 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. </p> <p> 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... </p> <h3>Fekete lyuk</h3> <p> 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ő! </p> <p> 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. <em>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. </em></p> <p> 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. </p> <h3>iTunes Library Access</h3> <p> 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. </p> <p> 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. </p> <p> 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. </p> <h3>Nem fizet</h3> <p> A napokban pattant ki <a href="http://www.techcrunch.com/2009/04/30/iphone-app-developers-threaten-to-sue-apple-over-late-payments/">a TechCrunch-on egy másik sztori</a>, 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. </p> <p> 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. </p> <h3>Nagyok</h3> <p> 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. </p> <p><strong> 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. </strong></p> <p> 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. </p> <h3>Startup?</h3> <p> Ezek alapján a StartUP konferencián azt tanácsoltam, hogy iPhone-os fejlesztésben bízni nagyon rizikós. Összefoglalva: </p> <ul> <li>Bekerülni a Developer Programba Magyarországról macerás, de kivitelezhető.</li> <li>Egy alkalmazás nem biztos, hogy bejut az App Store-ba még akkor sem, ha más alkalmazások ugyanolyan funkcionalitást tartalmaznak.</li> <li>Ha mégis bekerül és vannak eladások, akkor sem biztos, hogy kifizetnek.</li> <li>Az Apple nem válaszol szinte semmire, elérhetetlen.</li> <li>Az App Review Team a legjobban őrzött részleg, a döntései szubjektívek és nem konzisztensek.</li> <li>A nagy és/vagy haverka cégek előnyben vannak, velük sosem fogsz tudni versenyezni, mert lejegelnek.</li> </ul> <p> 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.</p> <h3>Nincs versenytárs</h3> <p>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.</p> <p>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.</p> <p><strong>Update:</strong> <a href="http://szifon.com/2009/05/09/kommentar-nelkul-2/">a szifon.com bekopizta a cikket</a>, vannak hozzászólások ott is.</p></div> Thu, 23 Apr 2009 02:00:00 +0200 http://szantog.imect.com/sites/szantog/media/ Web http://szantog.com/page/egy_kis_gyorsitas_az_iwiw_appokhoz http://szantog.com/page/egy_kis_gyorsitas_az_iwiw_appokhoz <div><strong>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. </strong></div><div><p>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.</p> <p> Ő 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:</p> <ul> <li>Függ az iWiW rendszerétől, pedig külső kérésnél nem szeretném terhelni a nagy tesót. </li> <li>Lassú még akkor is, ha gyors: felesleges http kéréseket eredményez. </li> <li>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. </li> <li>Nem lehet leállítani, eldobni a kéréseket, ha azok még nem tértek vissza. </li> </ul> <p>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.</p> <h3>FlashIO</h3> <p>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.</p> <p><a href="sites/szantog/media/web/flashio.zip">Az egész pakk letölthető innen</a>, 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ő.</p></div> Tue, 21 Apr 2009 02:00:00 +0200 http://szantog.imect.com/sites/szantog/media/ Web http://szantog.com/page/adobe_strobe http://szantog.com/page/adobe_strobe <div><strong>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 <a href="http://www.openvideoplayer.com/" tabindex="0">Open Video Player Initiative</a>, ami egy Akamai-os lufi/reklám volt, most pedig itt az <a href="http://www.adobe.com/products/strobe/" tabindex="0">Adobe Strobe Framework</a> ígérete. </strong></div><div><p>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. <em>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.</em></p> <p> Tök jó lenne, ha nem több ezer sorból állna egy használható videólejátszó, lásd <a href="http://player.imect.com" tabindex="0">iMectPlayer</a>, ezért szurkolok a Strobe-nak, csak ne lenne ennyire reklámszagú az egész. Része az <a href="http://www.openscreenproject.org/">Open Screen Project</a>-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.</p> <p> 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.</p></div> Thu, 09 Apr 2009 03:00:00 +0200 http://szantog.imect.com/sites/szantog/media/etc/iphone.jpg Minden más http://szantog.com/page/a_csatlakozas_az_iphone_developer_program-hoz_szivas http://szantog.com/page/a_csatlakozas_az_iphone_developer_program-hoz_szivas <div><strong>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. </strong></div><div><img src="http://szantog.imect.com/sites/szantog/media/etc/iphone.jpg" alt=" " /></div><div><p>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.</p> <dl style="clear: both"> <dt>2008. november 24.</dt> <dd>A <a href="http://developer.apple.com/">Developer Connection</a> oldalán kitöltöttem a szükséges adatokat.</dd> <dt>November 25.</dt> <dd>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.</dd> <dt>December 8.</dt> <dd>Küldtem nekik egy e-mailt, hogy mi a lófax van már.</dd> <dt>December 9.</dt> <dd>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.</dd> <dt>December 10.</dt> <dd>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.</dd> <dt>December 16.</dt> <dd>Küldtem egy e-mailt, hogy mi a helyzet.</dd> <dt>December 18.</dt> <dd>Küldtem egyet ismét.</dd> <dt>December 22.</dt> <dd>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.</dd> <dt>December 30.</dt> <dd>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.</dd> <dt>Január 5-15.</dt> <dd>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.</dd> <dt>Január 22.</dt> <dd>Megjött az aktiváló kód, bent vagyok a programban! <em>Hurrá. Csak két hónapig tartott!</em></dd> </dl> <p>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). <strong>De!</strong> 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.</p> <p>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.</p> <p> </p></div> Thu, 09 Apr 2009 02:00:00 +0200 http://szantog.imect.com/sites/szantog/media/web/amazon.jpg Web http://szantog.com/page/amazon_cloudfront_tapasztalatok http://szantog.com/page/amazon_cloudfront_tapasztalatok <div><strong>A <a href="http://media2radio.com">Media2Radio</a> 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. </strong></div><div><img src="http://szantog.imect.com/sites/szantog/media/web/amazon.jpg" alt=" " /></div><div><p>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ő.</p> <p>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.</p> <p>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).</p> <p>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.</p> <p><a href="http://icanhascheezburger.com/2007/12/04/meep-meep-2/"><img alt="funny pictures" src="http://icanhascheezburger.wordpress.com/files/2007/12/funny-pictures-speedy-cat.jpg" /></a></p> <h3>Minden startupnak CloudFront-ot, Magyarországra is!</h3> <p>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.</p> <p>É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 href="http://szantog.com/page/a_feltoltes_kezdete_mindig_gyorsabb_mem">a letöltés eleje mindig gyorsabb</a>, ez idő alatt átjön a zöm, így a jellemző letöltési időm 3 másodperc.</p> <p>A CloudFront-ot minden startupnak ajánlom, csak a forgalom után kell fizetni. <em>Nekünk az első 10 napban eddig 5 dollárba került az egész...</em> 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.</p> <p> </p></div>