szantog.com - legfrissebbek

Az Apple felszabadította Korzikát

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

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

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

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

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

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

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

Jeff Dunham 2008 Karácsony magyar felirattal

Thu, 25 Dec 08 00:00:00 +0100

Nagy kedvencem és rendkívül jól oldja a túlzabálás okozta feszültséget. Majd 1 óra, én szóltam!

H.264 licencdíj? WTF?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Software is teh king, again.

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

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

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

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

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

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

USA

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

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

Amazon EC2 Europe

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

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

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

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

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

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

Inside the iPhone

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

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

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

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

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

Hardver

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

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

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

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

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

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

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

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

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

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

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

Fejlesztés

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

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

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

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

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

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

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

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

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

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

Keretrendszerek

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

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

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

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

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

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

Konklúzió

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

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

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

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

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

Kedves Ügyfelem!

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

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

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

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

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

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

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

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

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

Amazon CloudFront - CDN kicsiknek

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

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

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

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

Hogyan működik?

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

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

Árazás

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

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

Videó

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

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

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

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

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

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

Daráló

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

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

Szivárgás

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

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

Fagyás

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

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

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

Végre! Google Analytics Flash-re

Fri, 21 Nov 08 16:00:00 +0100

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

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

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

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

Apró pofon a Silverlightnak

Fri, 21 Nov 08 12:00:00 +0100

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

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

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

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

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

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

A Flash Media Server 3.5 újdonságai

Fri, 21 Nov 08 00:00:00 +0100

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

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

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

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

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

HTTP szerver

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

DVR

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

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

Konklúzió

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

A Thinkpad túl ronda lenne hozzám, ezért természetesen Macbook-ot használok

Thu, 20 Nov 08 00:00:00 +0100

Tapipadot tapizni jó és a képernyő is érdekesen változik olyankor

Kit érdekel a Zindexhu?

Többek között...

Vízben feszítek (sokkal izmosabb vagyok, mint Apa)

Eladtuk a lakásunkat

Tue, 18 Nov 08 00:00:00 +0100

A nagy családi ház projektünk keretén belül el kellett adnunk a jelenlegi 53 négyzetméteres panelünket, aztán pedig visszabérelni, amíg kész nincs a ház (szülőknél nem férünk el, 4 hónapos babával nem megyünk idegen albérletbe).

Egy ilyen ingatlan eladása nem könnyű, pláne ezzel a jövő nyárig visszabérelnénk feltétellel, mert ezekre a kecókra nem befektetők vadásznak, hanem átlagpénzű munkásemberek szeretnének lakni benne, ez nem villanegyed.

Előnye a lakásunknak, hogy a többi ilyenhez képest nagyon sok extra van benne, hiszen minden ki lett cserélve. Ilyenkor nem a fal színe számít vagy a járólap, azok esztétikai dolgok. Az számít, hogy új az ablak, extra a biztonsági ajtó, szűkítettük a közcső-szekrényt, hogy beférjen a hűtő (a mi lakástípusunkban senkinek nincs bent a konyhában, csak nekünk, tényleg). Ezekre nem kell költenie az új tulajnak.

Szóval a kategóriájában igencsak magasan van a lakás, de a visszabérléses feltétel miatt nem voltak illúzióink. Feldobtam a netre (szokásos helyek, ingatlan.com, Expressz, stb.) és kötöttünk néhány ingatlan-közvetítői szerződést is, mert náluk jobban pörögnek az ügyfelek. Sajnos a mi vásárlói körünk még nem annyira web-érzékeny, az általam felrakott hirdetésekre csak közvetítők reagáltak, egyetlen hús-vér vásárló sem jött onnan.

Rögtön reális piaci áron (+ egy kis alkupozíció) hirdettünk, ennek belövésében segítettek a közvetítők. A reális ár felett lehetetlen eladni, nagyon sok magánszemély hirdet felette és évekig sikertelen. Nekünk a pénz viszont most kell, nem két év múlva.

A közvetítők jellemzően 2-5% jutalékkal dolgoznak, ezt is beépítettük az árba, így közvetítőtől függően változott az irányár. Kijöttek, megnézték és körbefényképezték a lakást (igen, kitakarítottam, rendet raktam), aláírtuk.

A szerződések után 2-3 nappal már jöttek az első telefonok, de a visszabérlés miatt sokan "visszapattantak". A kéró állapota, kinézete (ezekre rettentően büszkék vagyunk! Fájni is fog a szívünk érte...) és korrekt ára miatt akár egy héten belül el tudtuk volna adni, ha egyből kiköltözünk.

Aztán szerencsénk volt, így a második hét végére meglett a vevőnk. A sztori vége unalmas, megkötöttük az adásvételit és a bérleti szerződést (az ügyvédi költséget a vevő fizeti, én csak az ingatlanközvetítőt).

Az ügyvéd és a közvetítő végig profi és barátságos volt, a vevőnk pedig korrekt, mintha nem is kicsi hazánkban lennénk. Most már csak arra várunk, hogy a foglaló után megérkezzen a teljes vételár, mert hitelből veszik meg, ebben a kategóriában nem nagyon van készpénzes vevő. Apró infó, a vevő mázlijára az ügyvéd mindössze 0.5%-os díjjal dolgozik, ami nagyon alacsony, név/cím nálam.

Aztán pedig nem lesz hivatalosan lakásunk, így felvehetjük a szocpolt. Ja, és a telekre nem kellett illetéket fizetni (10%!!! tíz százalék!!!), mert vállaltuk, hogy négy éven belül felhúzzuk rá amit kell.

A következő postban elmondom, hogy mennyit szívok az építési engedélyhez szükséges papírokkal, meg mi a helyzet. Még egyszer összefoglalva, ez kellett a gyors eladáshoz:

Korrekt hirdetés tömör tájékoztatással.
Előnyös fotók, rend és tisztaság.
Ingatlanközvetítő.
Reális piaci ár.

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

Mon, 10 Nov 08 00:00:00 +0100

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

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

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

Wmode

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

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

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

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

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

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

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

A számok

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

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

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

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

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

Sun, 09 Nov 08 00:00:00 +0100

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

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

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

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

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

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

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

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

2. ActionScript 3 (három!)

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

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

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

4. Videó

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

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

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

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

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

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

6. Optimalizáld a libraryt

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

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

7. Allowdomain

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

Konklúzió

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

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

Calici

Thu, 06 Nov 08 00:00:00 +0100

Múlt hétfő óta (valamelyik) Calici vírussal küszködök, ami egy lázas-hasmenéses ügy. Sajnos nem sikerült egy hét alatt sem úrrá lenni rajta, úgyhogy türelem, hamarosan jövök, de még nem.

Attól meg előre félek, hogy mi lesz, ha ismét elkezdek melózni. Két hét alatt rengeteg restancia gyülemlik fel, úgyhogy a teljes novemberem a lemaradás behozásáról fog szólni. Már előre utálom az egészet.

Volt egy-két "high moment": 39.8 foknál hűtőfürdő (hisztiztem rendesen), 3 óra alatti teljes bélrendszer ürülés (na ez durva, ilyen szeleket még sosem láttam, szegény Aniék meg nem tudtak aludni a hangoktól - és a röhögéstől), vércukorszint hirtelen zuhanása miatti WC-ről leájulás, homlokkal koppanás a járólapon, négykézláb közlekedés (felállni nem volt erőm), ésatöbbi.

Szedem a gyógyszereket rendesen, de csak "nem keményedik". A kajákat pedig már utálom, két hete nem ettem rendeset, több napig csak üres pirítós és üres tea volt. Amiket most nem ehetek jó darabig: tejtermékek, zsír, cukor, fűszer. Csak száraz felvágottak (pl. sonka), egy darab per étkezés.

Szegény Ani is elkapta, szerencsére úgy néz ki, hogy könnyebben megússza. Nagyon féltjük Bogit, volt is egy-két furcsa produktuma, de jól van. Köszönjük Marcsi nagyi segítségét, mert egy-két napig nem tudtuk ellátni magunkat és nélküle nem ment volna.

Írd le!

Mon, 27 Oct 08 00:00:00 +0100

Van egy új ötleted, szeretnél egy új dolgot a rendszerbe vagy változtatnál valamin? Hiába mondod el szóban, én mindig azt fogom kérni, hogy írd le és küldd el e-mailen.

Az e-mail visszakereshető, nincs vita arról, hogy ki mikor mit mondott. Sajnos azt látom, hogy sokan még mindig inkább írnak plusz egy e-mailt (mi volt? mit beszéltünk meg?) ahelyett, hogy visszakeresnék. Pedig keresni jó.

A fejlesztő specifikációból, azaz magyarul feladatmeghatározásból fejleszt. Pontosan le kell írni neki, hogy mire van szükség. Ha szóban mondod el vagy nem írod le részletesen, akkor ő fogja kitalálni helyetted, az pedig nem biztos, hogy egyezik az elképzeléseddel. Sőt, a fejlesztő inkább "fejlesztősen" fogja fel a dolgot és nem lesz feltétlenül felhasználóbarát a megoldás.

Ha leírod az ötleted, egyből másképp fog kinézni!

Leírva egészen más szemszögből látod a dolgokat és az ötletek fele ilyenkor kapásból elvérzik. Megspóroltál hát néhány felesleges kört. Ha az ötlet mégis jónak tűnik még így is, szinte 100%, hogy nem eredeti változatában fogod elküldeni.

Tehát mégegyszer: írd le és küldd el e-mailen!

Kiegészítés: a hibabejelentést is írd le. Meg a megbeszélés időpontját, hiába mondtad telefonon. Különben elfelejtődik.

A nagy Silverlight elemzés, DRM

Fri, 24 Oct 08 00:00:00 +0200

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

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

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

Kinek kell?

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

Hogyan működik?

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

Kinek van?

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

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

Min lehet lejátszani?

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

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

Új Silverlight! Új Flash!

Wed, 15 Oct 08 00:00:00 +0200

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

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

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

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

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

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

Fri, 10 Oct 08 00:00:00 +0200

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

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

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

Archívum

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

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

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

Enkódoló programok

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

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

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

Egymondatos konklúzió

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

A nagy Silverlight elemzés, bevezető

Thu, 09 Oct 08 00:00:00 +0200

Kísérletet teszek részletesebben kielemezni a két nagy webvideós platform közötti különbségeket, Adobe Flash és Microsoft Silverlight természetesen. Ez fontos nekem, hiszen tudnom kell, hogy mi a jövő, merre érdemes a tudásomat bővíteni. Ha érdekel a webes videó, akkor szerintem számodra is érdekes lehet.

Jelenleg Flash és open platformon ügyködök, ezt jól ismerem. Amikor elkezdtem még nem volt Silverlight, a hírekben sem, nem volt választásom. Ma viszont látszik, hogy a webes videó területén ezerrel próbálja behozni lemaradását a Microsoft.

Kis kitérő: miért írom így, hogy Flash és open platform?

Mert a Flash platform drága, a Flash Media Server és a hozzá való "gyári" videóenkódoló alkalmazások drágák. Éppen ezért széles open közösség jött létre, hogy megkerülje ezeket. Másrészt pedig a Flash dolgok általában ingyenes operációs rendszereken működnek.

Microsoft

Tegnap voltam egy megbeszélésen a Graphisoft parkban lévő Microsoft székházban. Találkoztam a méltán népszerű Bátorfi Zsolttal (WPF és így Silverlight szakértő) és Kollár Lászlóval (fejlesztői és partner üzletágvezető), akik kicsit megpromózták nekünk a Silverlight platformot.

Megpróbáltuk kihúzni belőlük a jövőbeli fejlődési irányokat, de szegények még nem árulhattak el a titkokat, csak homályos "sejtéseket" kaptunk. Azt is a lelkünkre kötötték, hogy a Flash és a Silverlight platform alma és körte, másképp kell bennük ügyködni, nem lehet direkben összehasonlítani.

Ez igaz, teljesen másképp kell bennük fejleszteni és a logikájuk alapvetően különbözik. Ellenben bármit is állít Zsolt, teljesen mindegy, hogy a Silverlight hogyan alakult ki, jelenleg egyértelműen a webes videó vonalán fejlődik és a Microsoft elsősorban ezen a területen szeretne vele pénzt keresni, mert itt a nagy lé, a média oroszlánrésze.

Éppen ezért a piaci szereplők és elsősorban a fejlesztők videós platformként tekintenek a Silverlightra és én is így teszek, az összehasonlítás pedig óhatatlanul következik a jelenleg piacvezető Flash-sel szemben.

Összehasonlítás

Elsősorban a konzerv videók szemszögéből vizsgálok (konzerv, azaz előre felvett és a merevlemezen rendelkezésre áll, azaz nem live), aztán majd egy bejegyzés erejéig kitérek a live témára is. Gyakorlati vonalon fogok haladni, a videó enkódolásától a kiszolgálásán át a másik végéig, azaz a böngészőben történő megjelenítésig.

Holnap jön az enkódolással foglalkozó rész, már megírtam.

Windows az Amazon-on, de nem Windows Cloud

Sun, 05 Oct 08 00:00:00 +0200

Eddig csak Unix-alapú dolgok futhattak az Amazon EC2-n, de valamikor ősz végén lehet majd Windows vagy MS SQL szervereket is telepíteni. Mi az a Windows Cloud?

Gondolom nem ez a Windows Cloud, amiről Steve Ballmer regélt nemrég, bár az EC2-n futó Windows megoldás ténylegesen Windows IN the Cloud lenne.

Amit a Windows Cloud-ról sejteni lehet az az, hogy egy speciális funkciókkal kiegészített Windows szerver (nem desktop rendszer, nem a te otthonodba), valami olyasmi, amit az Amazon pont most valósít meg. Tehát lesz egy API-d, amin keresztül Windows szervereket monitorozol, indítasz és állítasz le, dinamikusan.

Ha erre készít az MS egy központi szolgáltatást (mondjuk MS Cloud Services) és még automatikussá is teszi (ne kelljen már API-kat hívogatni, legyen egy kényelmes grafikus interfész, belövöm mi és mennyi kell, mikor indítson újat, satöbbi), akkor a Microsoft óriásit lép előre a hosting világban.

Vegyük észre, hogy itt belép a licencelési probléma is (a Windows nem ingyér van) és a Windows Cloud elsődleges "nagy" vívmánya épp ez lesz, nem az API. Bár ez a Microsoft... lehet, hogy megvetetnek veled egy 40-es Windows Server csomagot féláron, és azon belül felhőzgethetsz. Remélem nem ilyen lesz.

Az Amazon palettájáról már csak az OSX hiányzik, bár azt már minek. (Egyébként béta állapotú OSX hosting van a Mediatemple-nél.)

Vigyázat, reklám! AVEncoder

Wed, 01 Oct 08 00:00:00 +0200

Volt néhány kérdés a videókódoló alkalmazásommal kapcsolatban, ismertetem hát, hogy mit tud. Dióhéjban arról van szó, hogy a szerveren történő konvertálás helyett inkább a user gépén végezzük el a dolgot, amivel több legyet is ütünk egy csapásra:

Nem kell saját kódoló infrastruktúrát fenntartani (szervert, kapcsolódó dolgokat).
Nem kell a saját kódoló szerverek terhelésével foglalkozni (ha nincs kihasználva azabaaaj, ha túl hosszú a várakozási sor az a baj).
A felhasználó látja, hogy hol tart a dolog, nem csak annyit, hogy you're the 56th in the queue.
Sokkal kevesebb bájtot kell feltöltenie, jó minőségben egy videó horror nagyságú, lekonvertálva webes formátumra még több változatban is sokkal kisebb.
Az egész videófeltöltési folyamat gyorsabbá válik.
Nincs várakozási sor.

Nem árulok zsákbamacskát, az AVEncoder az FFMPEG-et használja, mert az a legjobb erre a célra, de mégsem egy egyszerű wrapper, hanem tud egy-két plusz dolgot is:

Központból vezérelt. Egy megadott URL-ből húzza a konfigurációt (mit kell konvertálni, hogyan) és így mindig frissíti magát. Ha nemcsak a konfig változik, hanem maga a szoftver is átesett valami komoly frissítésen, akkor szól, hogy nincs konvert, hanem erről és erről a webcímről húzza le a felhasználó a legfrissebbet.

Windows és Mac OSX. Gondolhatjátok, hogy az FFMPEG lefordítása a megfelelő cuccokkal (finomhangolás) mekkora szívás volt, pláne Mac-re.

Nem kell telepíteni. Mac-en sima ZIP, Windows-on önkicsomagoló EXE. Közönséges futtatható alkalmazás van benne, nem kell hozzá semmi egyéb hülyeség, például .NET környezet vagy Java. Korlátozott user is futtathatja.

Bőrözhető (skin). A bőrök egyszerű Flash SWF (igen!) fájlok, magad is előállíthatod mindenféle ActionScript tudás nélkül, csak grafika. Így a felhasználód nem azt látja, hogy AVEncoder, hanem a saját neveddel a saját arculatod. Ugyanígy a nyelvi fájl is szerkeszthető, jelenleg HU és EN van, de bármire átírhatod a sztringeket.

Saját konfiguráció (XML fájlban). Beállíthatod, hogy milyen formátumokat készítsen, jelenleg ezekből választhatsz: Flash h264, Flash FLV, iPod/iPhone MP4, 3GP. (A Flash h264-et a Silverlight is le fogja játszani hamarosan.) Természetesen formátumonként állíthatod a bitrátát, felbontást, frémrétet. Maximumok is beállíthatók, pl. maximális videó hossz.

Preview képek. Bármennyit beállíthatsz, egyszerre több változatot is elkészít (pl. egy kisméretűt a thumbnailekhez és egy nagyot valami cikkhez).

A felhasználód természetesen semmit sem állíthat be, te kontrollálsz mindent. Ő csak kitallózza a videófájlt, kiválasztja valamelyik felkínált előnézeti képet (ha kell), elindítja a cuccot és nézegeti a progressbart.

A végén egy darab állomány készül el, ami egy TAR fájl. Benne vannak a kért formátumaid és egy hash, hogy tutira tudd a szoftver állította elő a cuccot és nem a felhasználó hekkelt valamit össze. A TAR fájlok kezelése a szervered számára valószínűleg nem újdonság, Linuxon alap.

Van egy minta PHP osztály is, ami kitömöríti neked a megfelelő helyre és lekezeli az esetleges hibákat. Nem kell FFMPEG-et, de még GD-t sem telepíteni a szerverre.

A szoftverben lévő formátumok kezelése webes videókhoz finomhangolt, de annyira, hogy pl. egy h264 paraméterezése 4 sor. Csak a megfelelő videókodekek finombeállítására 8 teljes munkanap ment rá. Minden konvertálás így a lehető legjobb minőséget hozza ki és természetesen kétmenetes.

A szoftver igyekszik kezelni a videókodekek esetleges bénázásait. Pl. sokszor futhatsz bitrate too low és hasonló ügyekbe, ilyenkor újrapróbálkozik és te állíthatod be a konfigurációban, hogy milyen stepping-gel menjen föl és meddig.

Automatikusan adagolja a megfelelő padding-et, tökmindegy, hogy a milyen a forrásvideó és milyen a célvideó képaránya. Az elkészült videó pedig mindig 1:1-es, azaz négyzetes pixelarányú lesz (hány kamera készít egzotikus téglalap pixeleket, amivel aztán nehéz küzdeni).

Ha a forrásvideó minősége bármelyik paraméterben kisebb, mint a cél, akkor megpróbálja a lehető legkevesebb veszteséggel járó konvertálást. Szélsőséges esetben, pl. ha egyből Flash kompatibilis és paramétereken belül eső h264-et tolsz neki, azt nem is fogja átkonvertálni, csak copy és már indítja is a következő formátumot. Másik példa: ha a bitráta jelentősen kisebb a célnél, akkor kb. másfélszerest fog neki adni, hogy további kockázódás ne alakulhasson ki.

Végzetes hiba esetén logfájlt ad, amit a felhasználó elküldhet a megadott e-mail címre és kielemezzük, hogy mi volt a probléma.

Elvégzi a megfelelő "patkolásokat", pl. QT-faststart az mp4-ekre, vagy Yamdi-s metaadatok az FLV-kre. Az elkészült fájlok kapásból mehetnek pseudo-streamingre is.

Bár én fejlesztem, de a szoftver az AVKreatív Kft. tulajdona, őket kell megkérdezni, hogy mennyi az annyi. Szerintem nem sok, kedves emberek. :-)

Építési telek

Sun, 28 Sep 08 00:00:00 +0200

Megvettük. Ha nem is építünk rá egyből (persze 4 éven belül kötelező, különben sarc), jobb, mintha a bankban állna a pénzünk, mert további enyhe áremelkedés várható a környéken. Az építkezéshez képest ez egy igen egyszerű történet, de még így sem rövid.

Gyors kitérő az elején: a pénznek forogni kell. Ha esetleg elhomályosítanak téged az akciós banki kamatok: még a kamatadó előtt sem adtak annyit, hogy a pénzed reálértéke ne csökkenjen. A sima bankbetéteknél az "igazi" (tehát nem hivatalos KSH) infláció alatt voltál egy hajszállal mindig. Erre pedig ma már a 20%-os kamatadó is rájön.

Meghatároztuk a költségvetést, ami a megtakarításainkból, a jelenlegi lakásunk reális piaci értékéből és egy felvehető hitel (amit bírunk havonta) összegéből áll, plusz szocpol (Boglárkánk már van, egy másikat pedig beígérünk majd). Ebből megnéztük, hogy a hozzánk legjobban passzoló ház felépítése mennyibe kerül, a maradék mehet telekre.

Miért telek, miért nem újépítésű valami?

Néztük azt is természetesen, hiszen jóval egyszerűbb egy kész újépítésű házat vásárolni (netán sorházi lakást), mint építeni. Körbenéztünk és egy sem volt, ami megfelelő elrendezésben, megfelelő méretű kerttel, megfelelő minőségben készült volna. Valahol mindig kilógott a lóláb.

Jártunk építkezéseken is és elborzadtam a minőségen. Összevissza futó téglasorok (mintha mézeskalácsház készülne), összevissza szigetelés (egyik helyen 2,5 cm, mellette (!!) 5 cm) és hasonlók. Aztán bevakolják, lefestik és minden nagyon szép, a kutya sem látja, mi van a falban. Utána pedig lehet csodálkozni a hőhidakon és repedéseken.

Úgyhogy inkább egy saját építésű készházas ügyet lőttünk be, ott nagyobb az esély az egységes és megállapodott minőségre, ami persze nem olcsó, drágább egy "hagyományos" téglaháznál.

Így csináltuk

Nem volt egyszerű megtalálni a megfelelő telket, hiszen rengeteg paramétert kell figyelembe venni, például elhelyezkedés, szomszédok, a kistérség fejlődése/fejlesztése, egészségügy, oktatás, vásárlási lehetőségek, lejtés, a környező házak alapmagassága, közművek, esetleges szolgalmi és egyéb kötelezettségek.

Internet, internet, internet. Ingatlanhirdetések. Hamar leesett, hogy a legtöbb hirdetést egy helyi ingatlaniroda tette fel, felhívtuk őket, hogy adjanak címeket a megadott paramétereken belül (települések, ár, közművek, stb.). Elmentünk az irodába, ahol alá kellett írni egy szerződést, hogy az irodát nem hagyjuk ki az adás-vételből, ami nem nekünk kerül pénzbe, hanem az eladónak (szerződésszegés esetén a vételár 3%-át kellene kifizetnünk az iroda részére).

Bejártuk a környéket, jónéhány telket néztünk meg. Ha jó helyen volt és az utcában láttunk még egyéb eladó területeket is, felhívtuk a kiírt telefonszámokat. Végül egy ilyen utcában vásároltunk be. Már a környéken lévő porták is szépek voltak, de ahogy bekanyarodtunk egyből kitört belőlünk, hogy itt bármelyik üres telek megfelelne. A páratlan oldalt már beépítették, a pároson még alig áll néhány ház.

Körbetelefonáltam a póznákon lévő telefonszámokat és ajánlatot tettünk az ingatlaniroda által forgalmazott telekre is. Hogy-hogynem pont ezt fogadták el és megbeszéltünk egy találkozót a tulajdonossal. Átbeszéltük a részleteket, megvizslattunk mindent (el sem hiszed, hogy egy töküres telken is mi mindent lehet nézni!). Egy-két dolog nem úgy volt ahogy szerettük volna, ezért módosítottuk az ajánlatunkat, de meg tudtunk egyezni.

Köszönöm Csabának a gyors Takarnetes tulajdoni lapot, nagy biztonságot adott, hogy az üres telken állva pár perc alatt megérkezett az iPhone-ra a tulajdoni lap PDF-ben, így pár perc alatt leinformáltuk az eladót, nem kellett felesleges órákat (!) ezzel tölteni.

Visszamentünk az irodába, ahol írtunk egy egyoldalas papírost, kifizettünk 10% előleget és megállapodtunk az adásvétel időpontjában, valamint kértünk időpontot egy közeli ügyvédi irodától.

Két nap múlva megkötöttük az adásvételi szerződést, kifizettük a maradék vételárat, az ügyvéd díját (a telek értékének 1%-a), és 6000 Ft Földhivatali eljárási izét. Meg kell jegyeznem, hogy az eladó mindvégig korrekt és együttműködő volt, jobbat nem is találhattunk volna.

Az egész folyamat a netes keresgéléstől, kitalálósditól a vételig kb. 2-3 hét volt, azaz ultragyors. Én ilyen vagyok, addig tolom az ügyet, amíg meg nem oldódik, addig viszont egész nap foglalkoztat és nem tudok nyugton lenni. Sajnos a melóval is így van néha, ami az ügyfélnek jó, de a családomnak nem.

A következő bejegyzésben a finanszírozásról mesélek, na az igazán bonyolult lesz, már két hete tekerjük, de a legapróbb részletekig még mindig nincs kidolgozva.

Rövidhírek 2008.09.24.

Wed, 24 Sep 08 00:00:00 +0200

Joost P2P nélkül, böngészőben? Nem jók az asztali videólejátszók? Amazon CDN.

Nem új hír, hogy a Joost inkább hagyja az asztali lejátszóját a francba és a böngészőbe vándorol. Ezek szerint az asztali (értsd: telepítendő) lejátszók nem működnek fényesen, pedig a Joost megoldása igen fejlett volt minden téren.

Ezek szerint a fejlett technológia (P2P) helyett inkább ráköltöttek a hagyományosabbra (gondolom valami CDN), hiszen a tartalmaikat nem gagyi helyekről szerezték és ki kell belőlük termelni a hasznot.

Szerintem várnak a 10-es Flash playerre, ami az új Flash Media Server-rel karöltve már P2P-t is tud majd, de ez még kb. 1 év, mire széles körben elterjed.

Az Amazon CDN-t indít hamarosan, vagy valami hasonlót

Úgy fog működni, hogy:

kijelölsz egy bucketet az S3-on
feltöltöd a fájlokat
tolsz egy API hívást, ami "regisztrálja" a bucketet és visszakapsz egy domainnevet (nem egy URL-t inkább? majd meglátjuk)
a kérést mindig a legközelebbi szerver fogja kiszolgálni

Annyival több a jelenlegi S3-nál, hogy az mindig egy kijelölt szerverfarmról szolgált ki, az új viszont a látogató földrajzi helyéhez legközelebbi helyről fog. Csak HTTP kiszolgálás lesz, streamingről vagy akár csak pseudo-streamingről ne is álmodjunk.

Az év vége előtt várható a szolgáltatás, remélem nem lesz aranyárban. Az is kell még, hogy gyorsan bővítsék a jelenlegi farmok számát, mert az USA-n kívül egy szem EU van, ami kevés egy "hagyományos" nagyobb CDN-nel szemben.

Drukkoljunk nekik, hiszen a kicsik számára az Amazon szolgáltatásai sokkal olcsóbbak és kevesebb kötöttséggel járnak, mint egy "igazi" CDN.

Építkezés!

Fri, 19 Sep 08 00:00:00 +0200

Úgy tűnik, hogy újabb színfolttal gazdagodik a blog, mert (ha a bank, az építési vállalkozó, az állam, satöbbi is úgy akarja) építkezésbe fogunk. Részletesen le fogok írni mindent, mert nagyon sok dologgal kell majd foglalkozni és odafigyelni kismillió izére.

A motivációnk könnyen érthető: jelenleg egy 53 négyzetméteres panelban vagyunk Kispesten, ami nem egy hosszútávú álom és értelmesen nem fér el benne egy második gyerkőc, pedig szeretnénk (majd).

Olyan 25 éves koromig úgy gondoltam, hogy városban szeretnék élni és jó nekem itt Kispesten. Kell a nyüzsi meg a minden közeli elérhetősége. Aztán rájöttem, hogy mégsem szeretek bejárni a belvárosba, nincs ott már számomra semmi érdekes, ritkán van csak szükségem rá. Elegem van a zajból, a koszból, a környéken lakókból.

Jobb lesz nekünk valahol vidéken, kertvárosi övezetben, valami fejlettebb helyen, ahol ugyanolyan bevásárlási lehetőségek vannak, mint itt, illetve a többi (pl. egészségügy, oktatás) sem rosszabb olyan sokkal, ha egyáltalán. Aztán érkezett Boglárka és dobott még egyet a szemléletmódon, ezen nem is csodálkoztam, hiszen a szülővé válás miatt számítottam rá.

Hol?

Szóba jött Sopron környéke Bécs és Pozsony közelsége miatt, illetve Budapest környéke, így lett sok-sok beszélgetés után a Velencei-tó a befutó. Ez már nem az agglomeráció (ott nem szerettünk volna), de mégsincs olyan távol a megszokott helyektől és a családtól.

Jelen pillanatban ott állunk, hogy megvan már a telek és irányárat kértünk egy kiszemelt építési vállalkozótól. Lesz még sok-sok bejegyzés, mire eljutunk a beköltözésig.

Panda!

Wed, 17 Sep 08 00:00:00 +0200

"Imádom" az olyan open/ingyenes megoldásokat, amelyek nagy sajtót kapnak és megoldást kínálnak valamilyen bonyolult ügyre, aztán az apróbetűből vagy a tapasztalatokból derül ki, hogy mégsem, vagy csak kicsiben. Panda videó megoldás.

A döntéshozók csak a reklámot olvassák, aztán pedig csodálkoznak, ha a fejlesztő le szeretné beszélni őket mindenféle bonyolult magyarázattal. Gondoljunk csak arra, hogy mennyi mindent lehet a hírös blogmotorokkal elérni, de ha sok felhasználóra, nagy biztonságra és rendelkezésre állásra lövünk sok-sok egyedi dologgal, akkor a megoldások száma általában 0-ra csökken és jön a házon belüli fejlesztés.

Van ez a Panda dolog, ami teljes open source megoldást kínál, videófeltöltés/kódolás/streaming. Sőt, Amazon EC2/S3/SimpleDB, cloud computing in da house. Hol lóg ki a lóláb?

A videók az S3-ra kerülnek. Tehát NINCS streaming. Csak progresszív download, ami ugye sima letöltés. Nincs pseudo-streaming se, nemhogy igazi. Azaz nem lehet beletekerni a videó még nem letöltött részeibe, ami ma már alapszolgáltatás.

Az Amazon szerverein fut, azaz cloud computing gyanús. De csak gyanús, valójában nem az. Attól, hogy valami az EC2-n fut még nem lesz skálázódó. Azt meg kell írni, egyediben. Azaz van 1 db EC2 példány, és az fut. Ha nem elég, akkor nem fog automatikusan újat indítani, vagy kis kihasználtsággal leállítani. Szép csúsztatás.

Tehát mit csinál a Panda? Feltöltöd a videódat, bekódolja amibe kell és ad hozzá egy embed kódot, alapesetben JWPlayer-rel. Nem skálázódik, nem streamel, ráadásul az S3-ról szolgál ki, ami nem a kisforgalmú megoldásokra van árazva. A Panda viszont a már említett olcsó, gagyi és kicsi megoldás, nem oda való. Ennél olcsóbban jössz ki egy sima hosting-gal.

Mire jó hát? Fogalmam sincs. Talán a készítőit reklámozza.

Microsoft H264

Tue, 16 Sep 08 00:00:00 +0200

Tudjuk, hogy a Flash-Silverlight harc a webes videóról szól. Az MS által használt legjobb videókodekek minősége épp eléri a H264-et, de csak Win alatt állíthatók elő. Holnap már nem így lesz.

Jön a H264 Silverlight alá. Ezzel a lépéssel közelebb kerülnek a Flash platformhoz és a Flash alá kódolt videók (elvileg) azonnal lejátszhatóak lesznek Silverlight alatt is.

Így nem kell más kódoló cuccokkal harcolni, igazából már csak a player kódja más. Nem szokása a Microsoftnak (kvázi) feladni a saját bezárt dolgait, de jelen esetben ez rendkívül ügyes húzás volt.

Természetesen a H264-hez jön az AAC audió is, hiszen párban járnak. A kódoló eszközük (Expression Encoder) és szerverük (Windows Server 2008) is képes lesz a formátumok kezelésére, nem csak a Silverlight, így teljes a megoldás.

Egyébként még nincs kint, az épp zajló IBC konferencián demózzák. Gondolom megjelenés pár hónap múlva, de valószínűleg még idén. Asszem el kell kezdenem Silverlight-ot tanulni, bár a hátam közepére kívánom.