szantog.com - legfrissebbek

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.

Flash Media Encoding Server

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

Ősszel jelenik meg ez az új termék, ami a Flash videók tömeges konvertálására ad megoldást, kezeli a várakozási sort, skálázódik, több formátumot kezel, minden. Nem késő, kedves Adobe?

Minden nagy már ezer éve (kénytelen volt) elkészíteni a saját megoldását e célra, még én is csináltam ilyet a Webcsatorna számára. Az Amazon EC2 tele van konvertáló image-ekkel. És persze mindenki FFMPEG-et használ.

Nem tagadom, az Adobe palettából már nagyon hiányzott a termék, csak szerintem elkéstek vele. Nem baj, most már nem érheti szó a ház elejét. Vagyis de, mégis, óriási fekete pont: csak Windows! Ááááááááááá! Xar.

Mi a Webcsatornánál még tovább mentünk és átterheltük a teljes feladatot a felhasználó gépére egy központilag irányított desktop konvertáló megoldással. Ez a jövő, nem a szerver.

P2P hosting?

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

Tudjuk, van a torrent és hasonlók, de most nem erről van szó. Vannak ugye a hagyományos hosting szolgáltatások, bérelsz X darab szervert, aztán azok tudnak valamennyi teljesítményt, a csúcsok között pedig malmoznak és feleslegesen viszik a pénzed.

Aztán ott a buzzword, a cloud computing. Ez eggyel jobb, de sokkal bonyolultabb. Nem lehet egy-az-egyben áttenni rá a hagyományos hosting cuccokat, de ha jól raktad össze, akkor:

Nem fizetsz felesleges teljesítményért.
Jól kezeled a teljesítménycsúcsokat.

Itt tartunk ma, illetve itt sem, mert a legtöbb cuccot legtöbbször hagyományos hosting-gal toljuk. Az ok egyszerűen az, hogy a cloud cuccok még csak alakulgatnak és kevés a hozzájuk értő szakember, másrészt pedig sok kicsi oldal számára nem elég olcsó.

A kicsi oldalakat (pl. egy szimpla blogot) felteszel valamilyen megosztott hosting szolgáltatásra (persze garantált teljesítményért, különben gáz) és a szolgáltató a saját kis felhőjében teljesítményoptimalizál. Több teljesítményt ad el, mint amennyi neki van, mert a különböző oldalak teljesítménycsúcsai nem egyszerre történnek. Az üres időt ugyanúgy kifizeted, az pedig a szolgáltatód (extra) profitja.

A látogató gépe

A legizgalmasabb terület a látogató gépének minél jobb kihasználása, a lehető legtöbb ügy átterhelése oda. Számolgassa az ő processzora a dolgokat, ne kelljen nekünk ezer szervert fenntartani. Itt ugye bejön mindenféle JS és Ajax machináció, de nem ez a lényeg, többet is lehet.

P2P alapon kell megosztani az erőforrásokat, a sávszélt, a tárhelyet és a számítási kapacitást, ez a távoli jövő (internets mértékegységekben távoli, 5 éven belül várható szerintem).

A sávszélesség megosztására jó példa a Bittorrent vagy a Joost. Számítási kapacitásnál a SETI@Home volt a legismertebb.

Tárhely ügyben az első fecske a Wuala, ahol az állományaid a Wuala alkalmazást feltelepített felhasználók gépein kerülnek tárolásra valami überbiztonságos machinációval. Ezek a gépek egy felhőbe állnak össze és szinte végtelen tárhelyet, redundanciát, valamint biztonságot adnak. Nagyon bonyolult dologról lehet szó, sok-sok évig fejlesztették nagyon okos emberek, igazi klasszikus kutatás folyt a területen.

Ha ezek a dolgok összeállnának egy webes platformmá, amire ugyanolyan egyszerűen lehet fejleszteni, mint egy PHP-s szerverre, az lenne a tuti. Ki sem elemzem, mennyi előnye lenne a dolognak, gondolom egyből kipattan néhány gondolat a fejedben.

Kicsit olyan ez, mint az alternatív energia, sok az ellenérdekelt fél, nyugodtan behelyettesítheted az olajcégeket hosting szolgáltatókká. A havi limitált sávszélességű internetkapcsolatok sem ezirányba mutatnak. Szerencsére ez az internets, szóval bízzunk abban, hogy az open kurázsi győz ismét.

Utópia

Ha a böngészők már "összeszabványosodtak" és nem tudnak új felhasználói bizbaszokat kitalálni (az átlag felhasználó már ma sem lát különbséget az IE és a Chrome között, csak a geek), akkor figyeld meg, a P2P hosting lesz a legújabb terület.

Egyre több hosting ügyet kiváltó böngészőbe épített megoldás lesz, a végén pedig megkapjuk a P2P webszervert. Persze először az X böngésző X*2 megoldást fog felmutatni, aztán jöhet a szabványosodás, satöbbi. Ismerjük már a sztorit, de hát kell kihívás a 2010-es évekre is, nemde?

Today

Őszintén szólva nem nagyon találtam pezsgő alfa produktumokat a területen. Lehet, hogy nem voltam elég ügyes, minden hasonló linket szívesen várok a hozzászólásokban.

Egy biztos, hogy a Bittorrent és a Wuala technológiája rendkívül fontos és rettentő sok pénzt fognak keresni a licencelésével.

Kicsiben

A Webcsatornánál nagyobb projektekre is szeretnénk lőni, ahol tömeges videókonvertálásokra van szükség, pl. sok felhasználó tölt fel egyszerre. Mindenki utálja, hogy a videókonverter szerverre várni kell, ha kiírja a szájt, hogy 15-ik vagy a várakozási sorban.

Tömeges videókonvertálási igény kielégítése hagyományos hosting-gal szopó, cloudban (pl. Amazon EC2) már sokkal jobb, de van olcsóbb megoldás. Csináljuk a felhasználó gépén!

Ezzel több legyet ütünk egy csapásra:

Elfelejthetjük a videókonverter szervereket, nem kell pénzt költeni rá.
Elfelejthetjük a várakozási sort, nincs várakozás.
A felhasználó direkt visszajelzést kap arról, hogy hol tart a konvertálási folyamat.
A feltöltendő fájlméret sokkal, de sokkal kisebb. A 10 perces 700 megás nyers videód helyett csak egy kb. 100 megás csomagot kell feltölteni (több formátum van a csomagban).

Végső soron ezerszer jobb felhasználói élmény. Tudjuk, mert ez a szoftver kész van és használjuk a napi munka során.

Amazon Elastic Block Store

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

Első látásra az EBS hivatott megoldani azt a problémát, hogy az Amazon EC2 szerverek nem perzisztens háttértárral rendelkeznek, azaz egy esetleges lefagyáskor elvész a tartalmuk. S3-ra meg macerás mentegetni és visszatölteni. De nem, nem erre való. Amazon EBS összefoglaló.

Méret: 1 GB - 1 TB. Elég.

Egy EBS diszket bármelyik EC2 példányhoz, akár egyszerre többhöz is fel lehet mountolni azzal a megkötéssel, hogy egy 'availability' zónán belül kell lennie a diszknek és a szervereknek. Ezt legegyszerűbben úgy lehet elképzelni, hogy az Amazon-nak több szerverparkja van, az EC2 szerverek létrehozásakor meghatározhatod, hogy melyikben jöjjön létre és a diszkednek is itt kell lennie. Ez érthető kompromisszum, hiszen ha egy fél USA választja el a lemezt a szervertől, az nem lesz izmos.

Ellenben a teljesítmény így sem túl nagy, erre a diszkre nem fogsz MySQL szervert telepíteni, hiába írtak erről több cikket. Az EBS network attached storage, így a limit a hálókártya (small EC2 példányoknál 250mbit, nagyobbaknál 1gbit) és így eszi a szervered sávszélét is. 70-120 MB/s sebesség érhető el vele, ami nem rossz, de a network attached dolog miatt adatbázis szervernek nem való, az I/O kérések indítása sokkal lassabb egy lokális lemeznél.

S3 Snapshot

Lehet snapshotolni egy parancssal a teljes EBS diszk tartalmát az S3-ra, illetve snapshotból visszaállítani. Szuper feature, de hiába ment az S3-ra, mégsem fogod látni a többi fájlod között... csak az EC2 API-ból érhető el ez a tartalom és csak snapshot készítésére/visszaállítására használható, a fájlok böngészése csak az EBS diszken lehetséges. A snapshot inkrementális, azaz csak a megváltozott tartalmat menti, sokat spórol ezzel.

A snapshot-ok által lefoglalt S3 tárhely nehezen becsülhető, ha egyáltalán. A rendszer blokkokban ment, egy blokkban több fájl/több része lehet. Ha készítesz egy snapshot-ot és utána egy másikat, akkor a közös rész csak egyszer tárolódik. Ez sok helyet takarít meg, csak épp nem tudod kiszámolni a tárhelyigényt.

Snapshot készítésekor szépen elkezdi másolni az adatokat. Éppen ezért ha intenzíven írsz az EBS diszkre nem tudhatod, hogy épp milyen állapotot fog elmenteni. Ilyenkor tehát érdemes megszüntetni minden műveletet és utána elvégezni a snapshot-ot.

Megbízhatóság

Erről nulla gyakorlati infó van, de mivel létezik az S3 snapshot feature, ne legyenek illúzióink. Gyanítom, hogy az EC2 példányok megbízhatósága körül lehet a dolog, azaz egy diszk akár 1-2 hónapig is elfuthat hiba nélkül, de számítani kell a bajra.

Azt mondják, hogy az EBS-en belül van redundancia, egy EBS diszk nem egy igazi HDD-t jelent, hanem több szolgál ki téged egyszerre, tehát egy HDD lehalása nem jelenti az EBS diszked meghibásodását.

Az EC2 oldalán az AFR rátával bűvészkednek és azt mondják, hogy ez tízszer jobb egy sima HDD értékénél, azaz 10-szer kevésbé hibásodik meg. Ez kb. megfelel egy tükrözött RAID-nek.

Havidíj

Na ezt a részét a büdös életben nem fogod megbecsülni. Már az EC2 tervezése is szopó, nade az EBS!

A tárhely ára 0.1 USD/GB, ez tiszta. És olcsóbb, mint az S3 (0.15/0.18), bár nem annyira megbízható és nagyteljesítményű, meg úgy egyáltalán, más célt szolgál.

0.1 USD/1 millió I/O request. Jelentkezzen, aki ezt meg tudja becsülni. Nem is mondok többet.

Az EBS snapshotok készítése megegyezik az S3 árakkal, csak amint említettem nem fogod tudni, hogy egy snapshot mennyi helyet igényel.

Konklúzió

Ezt az Amazon szolgáltatást se úgy fogd fel, mint sima hosting-ot. Az Amazon cuccokkal jó kis megbízható, skálázódó rendszereket lehet készíteni, de nem arra valók, hogy meglévő dolgokat egy-az-egyben feltegyél.

Kifejezetten Amazon-ra készített rendszerekkel érdemes használni, ez inkább egy fejlesztői platform, mintsem hosting szolgáltatás. Innentől fogva viszont megváltozik a leányzó fekvése és más szemmel tekintesz majd a képességeire.

H264 szívás az Apple-vel

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

Nem titok, hogy a Webcsatornánál egyszerre több formátumba konvertálunk. A nagy magyar iPhone mizériára felkészülve már több hónapja iPod/iPhone kompatibilis videókat is készítünk, amiket aztán a megjelenésre terveztünk élesíteni. Jó terv volt és jól is működött a 2.0-s iPhone verzióig.

Augusztus közepén frissítettem 2.0-ra és elhűlve láttam, hogy nem képes lejátszani a videókat, illetve az iTunesba sem lehetett már importálni őket, hibaüzenetettel visszadobta.

Rákerestem a neten. Találtam néhány panaszt, megoldás viszont sehol sem volt, az Apple honlapján is volt téma, de semmi válasz. A specifikáció nem változott. Fasza, csináld magad mozgalom tehát, indul a próbálgatás.

Fél nap után meglett a megoldás, de gondolom hiába számláznék az Apple részére, nem fizetik meg a munkaidőt. Ezt kell hozzácsapni az FFMPEG paramétereihez: -level 30. Tudatja a lejátszóval, hogy 3-as szintű H264-ről van szó.

A H264-ben a szintek mindössze néhány maximum paramétert, pl. felbontást vagy bitrátát határoznak meg. Hiába vagy ezeken belül, ha nincs meg a megfelelő header, az Apple nem engedi be a videót.

Egyéb esetekben nem érdemes a használni, mert egy-két egzotikusan kódolt videót nem fog az FFMPEG átalakítani, hiába maradsz belül a határokon. Mondjuk papíron nem így kellene, de ez van.

Egy szó mint száz, újra kellene kódolni az összes Webcsatorna videót, de ezt nem lépjük meg, macerás az archívumból előhalászni az eredetiket. Inkább egy-két fontosabb adás Flash H264 kész verzióját vettük elő és alakítottuk át. Nem túl jó minőség, de bőven elfogadható és még így is sokkal jobb a YouTube iPhone-os verziójánál. Az újabb videók természetesen már tűéles képpel érkeznek.

Képarány szívás

Megvolt a megoldás, gőzerővel kódoltunk, de egy-két adás kissé torz lett képarányilag. Lecsekkoltam, a felbontás pontosan a beállított érték lett, de egy-két lejátszó szoftver (pont iPhone meg QuickTime) laposra torzított. Pedig nem adtam meg neki, hogy nem square pixel vagyunk.

Egyébként gyűlölöm, hogy sok videónál a pixel nem egzakt négyzet, hanem mindenféle idióta téglalap alakú is lehet. Megértem, hogy egy-két esetben hasznos, de nem kicsit bonyolítja meg az életet. Azt már meg sem említem, hogy háromféle aránnyal kell játszani: PAR (pixel aspect ratio), DAR (display ...), SAR (sample ...).

Lényeg a lényeg, itt a megoldás az, hogy az eredménynél megmondod a helyes aspect ratio-t az FFMPEG-nek, ami mindig a célvideó szélességének és magasságának hányadosa padding-gal együtt (width + padding left + padding right /height + padding top + padding bottom). Például így néz ki: -aspect 1.7778. Fontos, hogy a felbontás (-s) paraméter után kell megadni.

Ezzel a beállítással a célvideó mindig négyzet alakú pixelekkel készül és egyértelmű lesz a helyzet, bármilyen idióta aránnyal készült forrásod is van.

Itt egy link egy már teljesen jó iPhone-os Webcsatorna videóra. (Persze csak iPhone-nal olyan.)

Miért szabványkövető? Web standards.

Mon, 11 Aug 08 00:00:00 +0200

Az elmúlt években (erős? nem erős?) kampány folyt a szabványkövető fejlesztés érdekében, mérsékelt sikerrel. Sajnos még ma is születnek a HTML, CSS és mindenféle egyéb W3C ajánlásokra fittyet hányó, táblázatokon alapuló oldalak. Elmondom miért rossz ez.

A szabványkövetés a webes fejlesztésben nem akkora kényszer, mint mondjuk az alkatrészgyártásban. Simán eladhatsz egy "nem szabványos" honlapot, nincs "hivatalos" szabályozás. Tulajdonképpen nem is szabványaink, hanem inkább csak ajánlásaink vannak, melyek közül a legfontosabbak megtalálhatók a W3C honlapján.

Szabványkövető fejlesztésben ökölszabály, hogy minden esetben a legszigorúbb, strict változat szerint próbálunk megvalósítani. Tény, hogy ez nem mindig sikerül, de ha csak egy-két helyen lóg ki a lóláb (mondjuk egy kulcs Flash objektum beillesztésénél), simán tolerálható.

A szabványkövető weblapok főbb jellemzői:

A HTML kódban nincs formázásra, megjelenésre vonatkozó utasítás, csak szöveg és struktúra.
A megjelenés szinte teljes mértékben CSS-ből jön.
Táblázatmentes, a <table> kódot csak igazi táblázatok bemutatására használja (hiszen a táblázat egy struktúrális fogalom, nem megjelenítési).
A fentiekből következik, hogy a "tartalom" és a "kinézet" teljesen szét van választva.
Megfelel valamelyik (lehetőleg strict) HTML előírásnak, CSS szabványnak.
Akadálymentes és megfelel néhány ezzel kapcsolatos előírásnak (pl. WCAG level 1-2-3, Section 508). Például minden képnél van alt tulajdonság.
"Diszkrét" szkripteket (pl. JavaScript) tartalmaz, a HTML elemek kódjába ez sem "keveredik bele" (pl. nincs onclick=).

Azt nem vitatom, hogy a nem szabványkövető ("hagyományos"), táblázatos kódú weblapok nem működnek.

Ezekkel is megvalósítható (jelenleg, és még néhány évig) a minden fontos böngészőben ugyanúgy megjelenő weblap. Akadálymentesség ügyében már nem olyan jó a dolog, de azon emberek száma, akik emiatt nem tudják használni olyan kevés, hogy nem üti meg az ingerküszöböt (ami persze nem szép dolog, de ez van).

Az is biztos, hogy úgy mindösszesen nézve jelenleg nincs jelentősen kevesebb szívás a szabványkövetéssel, mint a hagyományos hozzáállással. Ennek fő oka az Internet Explorer 6, a többi fontos böngészőben már egész jó a helyzet, még az IE7 sem tragikus (az a JS-ben gáz inkább).

A böngészők fejlődésében fontos trend, hogy egyre inkább könnyebb szabványkövető kódokat használni. Személyes tapasztalataim szerint jellemzően már olyan kódokat írok, hogy kapásból ugyanúgy megy minden Safari, FF és Opera alatt, kevesebb, mint 4 kivétel szabályt kell csak írnom IE7 alá (kb. 10 perc) és utána tépem a hajam az IE6-tal (kb. egy óra).

Mik az előnyei a szabványkövető hozzáállásnak? (In no particular order.)

"Tisztább" lesz a kód, nem keverednek össze annyira a dolgok.
Valamivel könnyebb designt változtatni.
Szinte minden esetben kisebb méretű lesz a böngésző által letöltendő bájtok száma, valamivel kisebb szerverterheléssel és sávszélességgel kell számolni.
Könnyebb odafigyelni az akadálymentes ügyekre.
A legtöbb új dolog (pl. új JavaScript és CSS trükkök, keretrendszerek, satöbbi) egyre inkább csak a szabványkövető kódokat veszi figyelembe.
A jövőben egyre inkább könnyebb lesz szabványkövető kódot írni a hagyományossal szemben.
A szabványkövető kód inkább kompatibilis a jövőbeli böngészőváltozatokkal, mint a régi.

De a legfontosabb:

Ha még mindig nem szabványkövető kódot írsz, akkor rosszul képzed magad és nem vagy eléggé tájékozott a szakmádban.

Nem azt mondom, hogy minden újnak egyből neki kell ugrani, mert a stabil, robusztus kód (ideálja) nagyon fontos. De a Web Standards ügye nem új, több éves, kipróbált dolog (és persze nem hibátlan, hogy is lenne az). Sőt, továbbmegyek: a szabványkövetés 2008-ban már ne legyen kérdés.

Nézd meg a Maxdesign listáját, már négy éves, de a nagy része még mindig abszolút aktuális.

Kormányszóvivő.hu

Fri, 08 Aug 08 00:00:00 +0200

9 és fél évig voltam köztisztviselő és vettem részt közbeszerzésekben (központosítottban is) a kiírói oldalról. Most a másik oldalon üzemelek (versenyszféra), a webfejlesztői piac egyik (kvázi) ismert szereplője, (kvázi) webes videó szakértő vagyok. Úgy érzem, hogy érdekes lehet az én véleményem is e tárgyban.

Nézzük először a tervet, aminek a címében szerepel a "szakmai megalapozás" kifejezés, tehát nemcsak egy ötletelésről van szó. Alapvetően három videós feladatot határoznak meg:

Sajtótájékoztatók élő közvetítése. Itt válaszolnak az írásban feltett kérdésekre is, valamilyen live chat-szerű dologgal. Az élő közvetítéseket archiválják. Ez olyan, mint a Ustream.tv.
Archív anyagok lejátszása, tehát sima videólejátszó. Olyan, mint bármelyik videós oldal, videómegosztó.
Kereshető médiaarchívum. Ez sem újdonság.

A szokásos adatok (cím, lead, kulcszavak, stb.) mellett feltöltéskor az anyagokat átvezetik egy hangfelismerő rendszeren, így rendelkezésre áll a törzsszöveg, az is kereshető. Ez unikum a magyar weben és jó ötletnek tartom.

Helyes a megállapítás, miszerint az elterjedt alkalmazásokon felül ne kelljen újabb alkalmazásokat telepíteni, tehát a legelterjedtebb böngészőket és a Flasht kell támogatni.

Javasolják, hogy a médiaszerver az Adobe Flash Media Server legyen, elsősorban élő közvetítés céljára. Ennél olcsóbb megbízható megoldás nincs, az a megállapítás viszont, hogy ez jól skálázható és kiemelkedő terhelés mellett is megbízhatóan működik, sántít. Kérdezzétek meg a Ustream-es vagy Jázmin-os srácokat. Sajnos nincs olyan médiaszerver termék a piacon, ami a dobozból kivéve képes bármilyen terhelésre skálázódni, megbízhatóan. Ehhez szakemberek kellenek és mágia.

A javaslat kifejezetten megemlíti az FMS 2-es verzióját: óhatatlanul felmerül a gyanú, hogy valakikre méretezett tervről van szó? Ugyan az FMS 3 viszonylag új dolog, így meg tudom érteni a félelmet, de verziószámokat betonozni egy tervbe nem szerencsés, hiszen nem lehet tudni, hogy mikor kerül megvalósításra. Itt viszont úgy tűnik tudták.

A rendszert két részre osztják, egy publikus (mindenki látja) és egy zárt részre. A bonyolultabb ügyek (pl. élő közvetítés) csak a zárt részen állnak rendelkezésre. Ez jó, mert kisebb és jól tervezhető terhelésre kell ezeket az amúgy igen drága dolgokat megvalósítani.

Terhelés???

A terv óriási hibája, minden oldalról, hogy nem tartalmaz becsléseket a várható terhelésre, látogatottságra vonatkozóan. Semmilyen webes terméket sem lehet létrehozni enélkül. Olyan rendszer nincs, ami bármilyen terhelésre skálázódik, éppen ez a következő évek nagy kihívása és a cloud computing lényege. A terhelés nemcsak a felhasznált szervertermékek és hardverek számát határozza meg, hanem a teljes kódot.

A publikus rész várható látogatottsága nehezebben tervezhető, de lehet sejteni, hogy nem fogja elérni egy közepes hazai magazin látogatottságát. Nyugodtan kijelenthető, hogy a napi 50e unique látogatást nem fogja meghaladni, a videós részé pedig ennél kevesebb lesz, hiszen ez a szám már összemérhető a legnépszerűbb hazai videómegosztó, az Indavideo látogatottságával.

A zárt rész látogatottsága ehhez képest drasztikusan kevesebb és jól tervezhető. Feltételezem, hogy eddig is voltak fogalmaik a kormány sajtótájékoztatóin jelenlévő újságírók jellemző számáról. A Maróy Ákos részére küldött MEH válaszból kiderül, hogy a webes rendszerrel már nemcsak a 30-40 budapesti politikai újságíró munkáját segítik, hanem több száz vidéki újságíróét is. Ebből arra lehet következtetni, hogy a zárt rendszerre tervezhető maximális látogatottság 1000 fő, és erre kell a (live) médiaszervert méretezni.

A levél később túloz ezzel a számmal kapcsolatban és megemlíti, hogy "Az újságírók számára hasznos szolgáltatásokat ... élő követítés ... akkor lehet zavartalanul biztosítani, ha a rendszer elérést egyelőre a több száz médiumra és az ott dolgozó több ezer újságíróra koncentráljuk".

Nyilván nincs hazánkban több ezer olyan újságíró, aki élőben követné a kormány sajtótájékoztatóit. Valóban több ezer újságírónk van több száz médiumnál, de hogy az Index sportrovata élőben inná a kormányszóvivő szavait, azt erősen kétlem. Az pedig még hihetetlenebb, hogy az összes Index-es újságíró egyszerre nézné a közvetítést Uj Péterrel az élen.

A megvásárolt eszközök és az azokhoz közvetlenül kapcsolódó szolgáltatások

Innentől kezdve ebből a két doksiból próbálok okoskodni: rendszerköltségek és eszközök listája.

A korábbi sajtóból és fenti becsült terhelési adatok ismeretében már gondolom mindenki számára világos, hogy a megvásárolt eszközök (vasak, szoftverek, kapcsolódó szolgáltatások) számát és körét felültervezték. Tudok a kormányzati szabályról, hogy a biztonságos blabla üzemeltetéshez mindent legalább duplikálni kell, de még ezen felül is igaz a pazarlás.

Az pedig teljesen horror, hogy a tesztüzemhez ugyanakkora infrastruktúra kellene, mint az eredeti. Ugyanmár. A tesztüzemet a fejlesztő saját parkján kell végezni, hiszen amúgy is valamin, azaz ott fejlesztik ki a cuccot. Eleve alapvető, hogy a fejlesztő rendelkezzen a szükséges licencekkel a fejlesztéshez. Csak indokolt, igen ritka esetben kell a fejlesztő részére licencet vásárolni. Nézzük részletesen:

Az Adobe Premiere Pro licencekkel egyet tudok érteni, kiváló videóvágó szoftver, profi anyagokat lehet vele készíteni. Kettőt vettek, nem sok, elég.

Adobe Flash Media Server 2.0: oké, 2-est vettek, a hármashoz képest szinte ugyanannyiba kerül, ez a része nem gáz. 1000 néző kiszolgálásához kettő darabra szükség lehet, abszolút indokolható. De minek négy? Annak az esélye, hogy kettő egyszerre száll el igen csekély. Egy harmadik példány a meghibásodás esetére elegendő lett volna. Ez magával vonja azt is, hogy kevesebb vas kell háromhoz mint négyhez. A pazarlás mértéke itt összesen kb. nettó 7 millió Ft.

Beszédfelismerő szerver: hogy ebből minek kettő, azt nem értem. Hiába áll le, a weboldalak attól még ugyanúgy üzemelnek tovább, mindössze a videó teljes szövege lesz később olvasható/kereshető, ha a megszerelték az elromlott eszközt. Ez a néhány perc, esetleg néhány óra kiesés simán tolerálható. A pazarlás mértéke itt összesen kb. 3 millió Ft.

MySQL adatbázis-kezelő: a már ismertetett terheléshez (és annál jóval nagyobbhoz is) bőven elegendő az ingyenes változat. A gyári támogatásra semmi szükség, hanem egy 24 órás MySQL szakértői szolgálat rendelkezésre állása kell, ha valami baj van, módosítás kell vagy csak kérdezni szeretnének. Ezt úgy hívják, hogy DBA és mindenképpen hazai szakembergárda kell, akit akár a helyszínre is lehet rántani. A pazarlás mértéke itt kb. 17 millió Ft, a szakértői támogatás pedig "szakértői konzultáció + projektmenedzsment-támogatás" címen benne van a projektben. Azt pedig végképp nem értem, hogy mihez kell 14 (!!!) darab MySQL szerver. Egy darab (illetve duplikált) nagy MySQL szerverrel és izmos dedikált vassal el lehet a feladatot látni, nem várható nagyobb terhelés.

Terheléselosztó: szükség van rá, mert mindegyik funkciót legalább két szerver látja el (pl. az egyik az "éles", a másik a "tartalék"). Azonban egyik funkcióhoz sem kell 5 szervernél több, így a puccos, sokat tudó elosztókra semmi szükség, ingyenes eszközökkel (pl. pound, haproxy, nginx) megoldható az ügy, csak vas kell hozzá. Három nem kell, kettő elég (éles + tartalék). Pazarlás: kb. 4 millió Ft.

Menedzsment szerver (2 darab!). Mit menedzselnek ezekkel? Esetleg kell egy vas, ami figyeli, hogy a többi komponens megy-e, de ehhez a legkisebb vacak szerver elegendő és kettő meg pláne nem kell belőle, mert meghibásodás esetén akár egy munkaállomásról is ellátható a feladat. A pazarlás itt kb. 2.5 millió Ft.

Backup szerver (2 darab): egy darab elegendő lenne. Ha leáll, akkor is megjavítható pár óra alatt, illetve ez idő alatt mondjuk az S3-ra is mehet az adat, olcsón. Kb. 2.5 milliós pazarlás feltételezhető.

EVA storage: a HP EVA egy igen nagy teljesítményű tárhely megoldás, amire szükség van, de gyanítom, hogy hazánkban csak a leges-legnagyobb webes rendszereknek van hasonló, a kormányszóvivő viszont meg sem közelíti ezeket. Az EVA-ra szánt 11 millió Ft helyett sokkal jobb lenne egy sima Linux-os megoldás, olcsóbb vassal, egyedi fejlesztéssel, S3 (vagy hasonló) backup-pal kiegészítve. Ez megoldható lett volna a feléből, ide beírok 5.5 milliót pazarlásnak.

Szolgáltatások!

A megvásárolt eszközök és a hozzájuk közvetlenül kapcsolódó szolgáltatások körében a fentiek alapján kb. 41.5 milliós pazarlást látok, ami sok, de a 200 millióhoz képest nem. Nade a szolgáltatások: itt lehet a legjobban elszállni és belemenni a zavarosba, ez a lényeg, nem az, hogy hány szerver van!

Biztonsági rendszerek tervezése és kialakítás: semmi extrára nincs szükség, a webes rendszerek biztonsága pedig alapvetően a webes alkalmazás kódján múlik. A tűzfal és egyebek is fontosak, de semmi különleges dologra nincs szükség, így a 2.6 millió Ft-ot túlzónak találom, százas nagyságrendű munkaórára nincs szükség. Nem vagyok szakértő ebben a témában, de 50%-os, azaz 1.3 milliós pazarlást valószínűsítek.

Infrastruktúra és hálózat fizikai tervezése: összesen 8 millió Ft! Azt a pár szervert nem köti össze olyan grandiózus hálózat, és a szoftverkomponensek összeállítása, a system architect meló ellátása sem többszáz munkaóra. Itt óriási a pazarlás, 2 millió Ft-nál semmiképpen sem tartom többre a feladatot, legalább 6 millió Ft kifizetése indokolatlan. Még a legnagyobb hazai weboldalak hasonló feladatai sem kerültek ennyibe, ez pedig messze van azoktól.

Szervereszközök telepítése és konfigurálása: ez nem kis meló, 2 millió Ft annyira nem is drága érte, ezért hagyjuk.

Rendszerintegráció: 13 millió Ft. Mi az a rendszerintegráció? Ez egy olyan bullshit fogalom, aminek itt semmi, de semmi értelme. Egy új rendszert fejlesztenek ki, nem meglévő cuccokat integrálnak össze. Milyen meglévő kormányzati rendszert kapcsoltak ehhez? Ennyiért? A teljes 13 milliós összeget pazarlásnak minősítem.

Szerverek rendszertámogatása: kell támogatás a szerverekhez, 2 millióért ez nem is drága, persze kérdés, hogy mennyi ideig adják a támogatást. Hagyjuk.

A szolgáltatásoknál tehát összesen kb. 20 millióra nézek furcsán, illetve ne feledjük, hogy a megvásárolt eszközöknél is a közvetlenül kapcsolódó szolgáltatások miatt lett nagy az összeg.

Rendszertervezés és konfiguráció

Óriási, 83 milliós tételről van szó. Gyakorlatilag ez lenne a "fejlesztés". A benne lévő tételek egy valós webes fejlesztés folyamataival köszönőviszonyban sem vannak, fogalmam sincs, hogy például mi a webfejlesztésben a "paraméterezés" vagy a "rendszerbevezetéshez kapcsolódó folyamatkialakítás". Értem, hogy a központosított közbeszerzés miatt be kellett szuszakolni a valós folyamatokat ilyen idétlen nevű semmikbe, ezért ezt nem is kritizálnám tovább. Két részre osztható a 83 millió:

fejlesztés (tervezés + fejlesztés + oktatás): kb. 57 millió
támogatás 1 évig: kb. 26 millió

Kábé ismerem a piac árait és hasonló rendszereket nem szoktak 57 millióból készíteni, sőt, 20 millió fölött sem. Sőt-sőt, az átlag 10 millió alatt van. Szóval húzzunk ide be egy egészséges, 50%-os, azaz 28 milliós pazarlást.

A támogatás jó dolog, nagyon kell, de havi 2 millióért kicsit sokallom. Legyen ő is inkább a fele, 13 milliót pazaroltunk. Tehát a fejlesztéssel együtt 41 milliót.

Mindösszesen

Mindent együttvéve kb. (41 + 20 + 41) nettó 102 millió Ft-nak nem látom az értelmét a nettó 171 millióból, azaz szerintem nettó 69 millióból fejlesztéssel, hardvervásárlással, szoftver licencek beszerzésével, 1 év támogatással meg lehetett volna oldani a dolgot.

Sőt, picit még ez is sok... én ennyire sem adtam volna ajánlatot. Persze az is igaz, hogy néhány feltétellel és tervezési tétellel nem értek egyet és másképp oldottam volna meg.

Publikus videórész kritika

A videó menüpont alatt látható egy kis részlet abból, hogy milyen videóarchívummal rendelkezik az oldal. A kritikám műszaki jellegű:

A videólejátszó arcpirító. Ez ugyanis a Flash fejlesztőkörnyezet videólejátszó "demója", pár perc alatt lehet vele összerakni 10 sornál kevesebb kódból, 0 (zéró!) grafikai munkával egy alap lejátszót. A komoly Flash-es videólejátszók ezekből a "demó" komponensekből egy gramm kódot sem tartalmaznak, de az Adobe sem azokhoz készítette ezt, hanem tanuláshoz és tűzoltó jellegű férceléshez. A fejlesztői költsége ennek maximum 20 perc.

A lejátszott videófájlok FLV formátumúak, a legalapabb Sorenson h263 videó kódolással, 320x200 felbontásban, 25 fps, átlag 400 kbps-en. 2008-ban ilyet már egyszerűen nem szabad, sőt már 2007 végén is látszott, hogy nem ez az út. Tessék legalább VP6-os kódolást használni (pár száz USD a szoftver hozzá), hogy jobb minőséget kapjunk vagy sokkal kisebb fájlméretet. H264-ről már nem is merek álmodni, netán egyszerre több médiaformátumról, hogy mobil eszközökön is élvezhessem a kormány nyilatkozatait.

Hogyan kellett volna?

Először meg kellett volna fizetni egy szakértő(csapat)ot, valamelyik ismert hazai webes műhelyből, hogy ugyan már tervezzék meg a dolgot és határozzák meg az alapvető infrastruktúrát (system architect meló + egy kis interface plan). Ez még kormányzati árakon sem érte volna el az értékhatárt, egy-két-három millióból megvan.

Aztán kommunikálni a civil szféra felé, hogy itt a terv, ezt és ezt szeretnénk csinálni, nézzétek milyen jól van összeállítva. Ez javította volna a kormányzat megítélését, legalábbis a szakmán belül.

Utána lehet megvalósítani.

Központosított közbeszerzésben lebonyolítani egy ilyen speciális feladatot egyébként nem kicsit homályos ügy. A központosított közbeszerzés lényege az, hogy az ismétlődő és az államigazgatás nagy részét érintő beszerzéseket egyszerűsítsék. Ne kelljen minden egyes intézménynek ugyanazokat a köröket lefutnia, mert a "rendes" közbeszerzés időigényes és sok papírmunkával jár. Például számítógépre mindegyiknek szüksége van, a beszerzés menete ugyanaz, csak a kért paraméterek térnek el.

Az is elv volt, hogy a központosított jellegből adódó nagyobb volumen miatt olcsóbb legyen a beszerzés, de sajnos ez nem teljesül, a piacinál drágább ("kormányzati") árak az informatikai közbeszerzéseknél itt is jelen vannak. Könnyen belátható, hogy a kormányszóvivő.hu beszerzése egyedi ügy, nem központosított eljárásra való.

A hozzászólásokban arra is várok tippeket, hogy a Synergon mely ismert magyar webes szolgáltatásokat, netán videós szolgáltatásokat fejlesztette.

Készíts terméket!

Wed, 06 Aug 08 00:00:00 +0200

Olvastam egy érdekes cikket arról, hogy ügyfelek helyett inkább termékekre alapozott üzletet érdemes vezetni. Egy ideje már hasonlóan gondolkodom, ezért összefoglalom a gondolataimat és a cikkben olvasottakat. A megállapítások szerintem nem csak fejlesztőkre érvényesek, hanem mindenkire, aki gyakorlatilag a szaktudását adja el.

A klasszikus webfejlesztői biznisz úgy néz ki, hogy valahogyan szerzel ügyfeleket (reklámozol, ismerősökön keresztül, tökmindegy) és kielégíted a fejlesztési igényeiket. Általában két dologra szerződsz: projektekre (nagyobb összeg, de egyszer) és támogatásra/havi fix óraszámra (kisebb összeg, rendszeresen).

Tekintettel az óriási fejlesztőhiányra ezzel a konstrukcióval is a magyar átlag fölött lehet keresni, de nagyon nehéz növekedni, gyakorlatilag bezárod magad egy burokba, amit áttörni csak termékekre alapozott üzlettel lehet.

Mert mi van, ha még több ügyfelet szerzel?

A munkaidőd véges, tehát fel kell venni valakit, aki megcsinálja a melót helyetted. Már ha egyáltalán találsz jó minőségű munkaerőt, ez manapság rendkívül nehéz, sok szerencsét hozzá. Ezen már nem fogsz olyan sokat keresni, ráadásul állandóan ellenőrizned kell a munkatárs hozzáállását, minőségét, satöbbi. Melóval jár az ő felügyelete is, legyen akár a legjobb fej a világon.

Nagyságrendeket így nagyon nehéz ugrani és a végén ott leszel, hogy lesz X fejlesztőd, aki nem hoz X-szer annyi pénzt. Tisztelet a kevés kivételnek. Az ügyfelek számának halmozása helyett ezért érdemes inkább egy saját terméket kitalálni (saját webkettes szolgáltatás, akármi) és annak szerezni minél több ügyfelet, felhasználót, reklámozót, satöbbit.

Lehetőleg minél többen használják a termékedet úgy, hogy közben nem kell speciális igényeket kielégíteni.

Mindig lesznek olyan emberek, akik valamilyen különleges funkció fejlesztését fogják kérni, de elsősorban fókuszálj azokra, akik a cuccost mindenféle változtatás nélkül, annak aktuális állapotában használva pénzt hoznak neked. Persze nem azt mondom, hogy ne fejleszd vagy tökéletesítsd, csak ne hagyd, hogy fókuszt veszítve eltérítsenek.

A termékfejlesztés kockázatosabb, mert a kockázatot közvetlenül te viseled, elsősorban rajtad múlik a sikere. Ha ügyfélnek fejlesztesz, akkor az elkészült dolog sikerességéért ő felel, te "csak leszállítod a bájtokat". A termékfejlesztés több befektetést igényel. A ráfordított időd is befektetés, ráadásul nem biztos, hogy valaha megtérül.

Persze meg lehet tartani néhány, de minél kevesebb kulcs ügyfelet, így legalább több lábon állsz, hiszen simán bedőlhet bármelyik terméked, bármikor.

Viszont az ügyfeleket inkább üzleti partnerként tekintsd, hiszen nem egy hamburgeres standot üzemeltetsz, aminek mindenkit ki kell szolgálnia. Nyugodtan dobj vissza melókat, ha úgy érzed, hogy nem biztosítja számodra a megfelelő hasznot (ami nem csak pénz lehet, hanem mondjuk tudás, kapcsolat vagy érdekesség is).

Természetesen a fentiek csak a vállalkozói hajlammal rendelkezőkre érvényesek. Akinek az alkalmazotti lét jobban fekszik, annak nem marad más, mint egy minél több hasznot (pénzt, tudást, kapcsolatot, érdekességet) hozó állás megtalálása.

Ez a mai fejlesztőhiány ismeretében könnyebb, mint valaha. Ki jön a Webcsatornához melózni? Tényleg kellene a munkaerő!

Backup billentyűzet!

Mon, 04 Aug 08 00:00:00 +0200

Tegnap bedöglött az Apple billentyűzetem, szép lassan eltünedeztek a gombok, először a delete, aztán az F, V és így tovább. Pár óra alatt elment az összes.

Ugyan látszik a System Profilerben, hogy csatlakoztatva van, felismeri, satöbbi, de kakukk. Nem is ez a fontos.

Hanem az, hogy ha hozzám hasonlóan te is gépnyomásból élsz, akkor mindig legyen kéznél egy akármilyen gagyi, de működőképes billentyűzet. Nekem el kellett rohannom venni egy kemény 1300 Ft-os csodát és a billentyűzettel kapcsolatos ügyintézésem így meghaladta az egy órát.

Ennél az összegnél te óradíjad is magasabb, így veszteséget okoz, ha nincs kéznél egy backup billentyűzet. Legyen hát, egy tartalék egérrel együtt.