(nem éreztem szükségesnek magyarázatot hozzáfűzni, ehhez képest többen próbáltak valami énblogos nyöszörgést emögé képzelni. nem, emberek, simán egy vicces rajzfilmsorozatról és egy frissen megnézett adaptációból jutott eszembe, milyen szépen le lehet csapni ezt a darabot is)

KIRÁLY.
Szép tőled, és ajánlja szíved’, Hamlet,
Leróni mind e gyász-adót atyádnak.
De lásd, atyád is vesztett egy atyát,
A vesztő újra mást, meg mást; s az élő
Siratta egykorig fiúi tiszte
Szerint. De így megátalkodni a
Bánatban: ez vétkes nyakaskodás,
Nem férfias bú; Isten elleni
Rugódozás, mely gyarló szívet és
Nem béketűrő elmét árul el,
És bárdolatlan, együgyű eszet.
Mert, a mi, tudjuk, meg kell hogy legyen,
És oly közös, mint érzékink alá
Eső akármi: mért izgága daczczal
Szívünkre venni? Fúj! Ez bűn az ég,
Bűn a halott, bűn a természet ellen,
Fonák az észnek, melynél az atyák
Halála közhely s szűntelen kiáltja,
Az első hullától a ma kimultig,
Hogy: „így kell lenni.” Vágd földhöz tehát,
Kérünk, e gyáva bút, s tekints atyádul;
Mert a világgal éreztetni kell,
Hogy trónusunkhoz legközelb te állsz;
S mi nem kevésbbé gyöngéden fogunk
Szeretni, mint legjobb nemző atya
Édes fiát. Mi czélod illeti,
Hogy Wittenbergbe visszamenj tanulni,
Ez óhajtásunk ellen van nagyon:
Tégy is le, kérlek, erről, és maradj
Nyájas szemünk előtt, szíves körünkben,
Mint első udvaroncz, öcsénk s fiúnk,

KIRÁLYNÉ.
Ne hagyd hijába kérni jó anyádat:
Maradj, ne menj Wittenbergába, Hamlet.

HAMLET.
Úgy engedelmes lészek, asszonyom.
Menj csak vissza Wittenbergbe, tanulmányod fontosabb mindennél.

HAMLET.
Rendben.

Szeretünk úgy tenni, mintha forradalmi korban élnénk. Emlékeztek még arra a tavaly októberben körbefutott videóra, amin egy kisgyerek az iPadhez hasonlóan próbálta böködni a magazint és a magazin pedig nem iPadhez hasonlóan reagált erre? Azon túl hogy egyből sikerült a printmédia halála című mesét is belekavarni, sokan vették ezt a videót bizonyítékként, hogy az iPad kezelőfelülete annyira végtelenül intuitív és forradalmi és varázslatos, hogy még egy ilyen tabula rasa kiskölyök is ilyen vidáman tudja használni a leghightechebb kütyüt.

Ehhez képest szembejött ez a videó Alan Kay egy előadásának részletéből, majdnem huszonöt évvel ezelőttről.

Ne kössetek bele hogy a lenti videón a kislány pár hónappal idősebb, a lényegen nem változtat: az embergyerek csodálatos, a technológiatörténelmet pedig mindig elfelejtjük.

Ha van még valaki, aki fel van iratkozva erre a blogra, biztosan meglepődött azon, hogy tegnap a nyakába zúdult egy csomó olyan bejegyzés, amit mintha már olvasott volna. Most hétvégén ugyanis nekigyűrkőztem a régóta halogatott feladatnak feltűrtem az ingujjamat és addig gyömöszöltem a Google Readerből kimentett bejegyzés- és hozzászólás-feedeket egy XSL transzformációba, amíg az eredmény WordPressbe importálhatóvá nem vált. Volt vele sírás-rívás és fogaknak csikorgatása, a végeredményben így is elvesztettem a bejegyzések kategóriáit és címkéit, illetve a hozzászólók url-jeit, de legalább a tartalom nagyja helyére került.

Következő sprintként az Internet Archive-ban megőrzött korábbi (pre-2006) bejegyzéseket kell majd kiszednem. Az lesz még a szép kihívás, de ott legalább nem érzem majd a probléma lecsalásának scrapert írni. Lényeg, hogy ne lepődjetek meg, amikor a betolató IFA leborítja a következő adag régi bejegyzést a feedolvasód küszöbére.

AJÁNLÁS. Herceg, bölcsebb vagy te nálam, lám van mindig friss backupod, amiből seperc alatt visszatöltheted a bejegyzéseidet, ha lelép velük a szervered. Ugye?

Nyom nélkül tűnt el nemrég a hosting szolgáltatóm — felmerül a gondolat, hogy talán tényleg nem volt fenntartható üzleti modell a $0.99-es havi díj, illetve dereng valami mondás a hús ára és a leve hígsága közötti összefüggésről — én pedig blog nélkül, de ami kicsit kellemetlenebb, minden backup nélkül maradtam.

Azért talán minden nincs veszve: ha minden igaz, majdnem teljesen helyre tudom állítani a tartalmat a Google Reader cache-éből, illetve az Internet Archive-ból. Ez viszont még egy szép kihívás lesz… A hétvégén XSLT-vel kínoztam magam, hogy WordPress Extended RSS-t csináljak a Reader Atom feedjeiből (a hozzászólásokat is sikerült kibányászni, cserébe külön fájlban van, amit valahogy egybe kéne illeszteni), ha valaki esetleg ért hozzá, neadj’ szereti is ezt a túlbonyolított  szörnyeteget, minden segítségnek örülök.

Mire kettőt pislogsz már kijött négy Chrome verzió és egy új Firefox is sunyiban. Eszméletlen tempóban gyarapodnak a lehetőségek, miket is tudsz csinálni egy weboldalon keresztül. A hétvégén a HTML5 kis barátai közül négy API-t próbáltam ki, a Canvast, a WebWorkereket, a File API-t és a Drag and Drop eventeket egy nagyon egyszerű kis projekten keresztül: feltöltesz egy képet, a böngésző pedig egy nagyon egyszerű szűrővel feldolgozza. Gyakorlatilag olyan, mint az Instagram, csak böngészőben fut, a retró képszűrőt meg annyi, hogy úgy néz ki minden kép, mintha egy huszonöt éves Macintoshon néznéd. Szóval valójában egyáltalán nem olyan.

Eddig a show része. Ha érdekel a tell is, a hajtás után kicsit körbetáncoljuk, hogy is készült.

Ja, a kódrészletekben CoffeeScriptet használok, ne ijedj meg, ha nem ismered még: ez olyan, mintha pszeudokódban írnál, ami aztán lefordul igazi JavaScriptre. A function(){} helyett elég a ->, a this helyett a @, ahol csak lehet, el tudod hagyni a zárójelet, satöbbi. Van még egy csomó remek egyszerűsítés, amivel lényegesen könnyebben tudsz JS-t írni, érdemes kipróbálni.

Atkinson dithering

Régen örültünk, ha a monitor (meg a nyomtató) képes volt megjelníteni a fekete mellett a fehéret is But you know, we were happy in those days, though we were poor. / Because we were poor. Az ennél színesebb képeket, hogy meg tudjuk jeleníteni, le kellett valahogy butítani. Erre sokféle algoritmus volt, de a legszebb eredményt szerintem az Atkinson dithering adta, és ezt most nem is fanboyságból mondom — Bill Atkinson annó az ősmacintosh csapat tagja volt.

Az Aktinson dithering végigmegy minden pixelen, leviszi feketére vagy fehérre, a pixelértékbeli maradékot pedig elosztja a szomszédos pixelek között. Azaz:

Plusz, mivel a bejövő kép minden valószínűség szerint színes lesz, le kell kevernünk szürkeárnyalatosba:

Canvas

(elérhető Safari, Chrome, Firefox 3 fölött, Opera 10 fölött, IE 7 fölött, meg a webkites mobilböngészőkön. Szóval gyakorlatilag mindenhol.)

A Canvas egy remek eszköz elméletben arra, hogy olyan képmanipulációkat csinálj, amikre alapból képtelen lennél a böngészővel. Kőprimitív, pár segédfunkción (pont-pont-vesszőcske) kívül magadra vagy hagyja: nesze itt vannak a pixelek, oldd meg. Nekünk mondjuk pont ez kell, szóval hajrá. Képet betölteni canvasra így lehet:

A fenti kódban a ctx a kétdimenziós kontextus. Ha jól értem, a WebGL használja a 3d-s kontextusát a Canvasnak, de ezzel még nem volt dolgom. Constructorral létrehozunk egy új kép elemet, megadjuk a forrását és rácsatolunk egy eseménykezelőt, hogy mihelyst betöltötte, tegye ki a kép tartalmát a canvasra (drawImage [kép elem], [x], [y]), majd kérje is vissza azonnal a pixelértékeket (getImageData [startX, [startY], [endX], [endY]). Itt viszont álljunk meg egy szóra.

origin-clean

A canvas nagyon szigorú kóserszabályokat tart. Ha bármi tisztátalan dolgot csinálsz, azzal a canvas is tisztátalanná válik, tisztátalan canvashez meg gyakorlatilag nem érhetsz hozzá, a pixeladatokat meg pláne nem kérheted le. Ezért kapsz SECURITY_ERR exceptiont ha file:///-ből akarsz képet betölteni, még akkor is, ha a böngészőlap is ott van mellette, ugyanabban a mappában. Emlékszel még az XMLHttpRequest same-origin korlátozására? Ez olyan, csak lényegesen bosszantóbb. Szóval uccu, nyiss meg egy statikus szervert, csak azért, hogy továbbléphess.

WebWorker

(elérhető Firefox 3.5, Safari 4, Chrome 10, Opera 10.6 és későbbi verziókban. Szóval még nem nagyon)

Ha a képfeldolgozó funkciókat kiszervezzük egy Workerbe, a feldolgozástól nem fog beakadni a weblap, pláne a böngésző; közben lehet mást is csinálni. A WebWorker lehetőséget ad arra, hogy háttérben futó threadeket hozzunk létre, amik igaz csak egy kis résen keresztül tudnak kommunikálni az anyascripttel, de cserébe háborítatlanul tudnak dolgozni, anélkül, hogy felpattanna a ‘script not responding, vesd a földle, dulván’ ablak.

Egy script bárhány workert tud létrehozni (worker is tud workert csinálni (házi feladat forkbombot írni!)), egymással eseménykezelőkön keresztül kommunikálnak. Valahogy így:

A Worker és anyja kölcsönösen feliratkoznak a másik message eseményére, majd postMessage-en keresztül tudnak adatot küldeni egymásnak, a feldolgozott képet vagy akár azt, hogy hol tartanak, hogy aztán abból szép <progress> csíkot tudj csinálni. A fenti kódra a worker így válaszol:

A this/@ a CoffeeScript bábáskodása miatt kell, ugyanis alapból minden lefordított kódot saját closure-ba pakol, hogy véletlenül se lógjon ki semmi a globális scope-ba. Egyébként WebWorker kontextusban a self is a globális scope-ra vonatkozik, de így… szebb.

Drag and Drop

Internet Explorerben az 5.0(!!) óta elérhető a drag and drop, ez lett szépen beemelve a HTML5-be, miután a Safari, majd a Firefox is implementálta. Sajnos nem a leg…egyszerűbb és kényelmesebb dolog a világon, PPK például lazán kijelentette, hogy annyira katasztrófa az egész, hogy soha, semmilyen körülmények között nem szabad használni, mégis, mivel ezen keresztül jobban tudunk a böngészőn túli világgal kommunikálni, ki kellett próbálnom.

Az egyszerűség kedvéért a HTML-ünk összesen ennyi:

<img src="default.png" id="imagewell">

Ahhoz, hogy ez az <img> tudjon fogadni ráhúzott dolgokat, először kapásból ki kell lőnünk az alapviselkedést, ami ezt megakadályozza (értitek, dupla tagadás):

És ha már ottvagyunk, jelezzük valahogy, hogy itt biza elfogadjuk a ráhúzott dolgokat, csillogtatva GIMP skilljeimet:

Ha feliratkozol a drop eseményre, megkapsz mindent, amit rádhúznak, abból aztán neked kell kimazsolázni azt, ami számodra hasznosítható. Egyelőre nézzük meg mi történik ha egy fájlt húzunk be:

FileReader

(Firefox 3.6 vagy Chrome 10. Még a Safari se viszi tisztességesen, nem hogy az IE.)

A FileReader segítségével be tudunk… olvasni egy… fájlt. Ha akarjuk, szövegként (readAsText), ha akarjuk, blobként (readAsBinaryString, readArrayBuffer), de nekünk data url-ként kell (readAsDataURL).

Ezt meg egyből küldhetjük is tovább a fennebb már darabjaiban bemutatott draw függvénynek, ami betölti a képet, átönti a tartalmát a canvasba, nyit egy workert, feldolgoztatja vele a képet, kerék alá teszi, onnan is kiveszi. A kész képet a canvasból pedig ugyanúgy data url-ként tudjuk kiszedni, ezt aztán be tudjuk rakni az imagewell forrásának.

És mi van ha nem desktopról akarsz behúzni fájlt?

Akkor meg kell nézned az event.dataTransfer.types-ban, hogy kaptál-e olyan MIME típust, amire szükséged van. Például ha böngészőablakból húzol át bármit is, text/html-t fogsz kapni. Ha nem lenne teljesen idióta a canvas origin-cleanje, tudnánk ilyet csinálni:

De mivel a másik böngészőlapról behúzott képnek más az originje, ezért elkezd rinyálni, mi pedig nem tudunk semmit se tenni. Fenébe.

Vissza a desktopra

Meg tudod mondani, mi történjen, ha kihúzzák az ablakból az elemedet. Emlékszel fennebb, ahogy meg kellett nézned, van-e olyan MIME típus, amivel tudsz mit kezdeni? Na, itt pont annak a fordítottját kell csinálnod: össze kell állítanod egy batyut, benne az összes (szerinted) lehetséges formátumát a kihúzott elemnek. A 280 Slides egyik fejlesztője rinyáltjegyezte meg, hogy az összes exportálandó formátumot egyszerre kell lerenderelned, csak hogy aztán ezeket egy kivételével mind eldobják, amikor célbeér. Ez lassú és pazarló megoldás, amikor elég lenne a célbaérés után lerenderelni azt az egyfélét, amire valójában szükség van. (Zárójel: ha jól értem, és javítsatok ki kérlek, ez a Macintosh-féle D&D amit ők szeretnének, amit meg az Internet Exploreren keresztül örököltünk a böngészőbe, az a Windowsos, ami már a desktopon se volt jó élmény.)

Egyetlen korlát,you can have any color as long as it’s black: text/*-on kívül nem igazán fogják engedni a böngészők, hogy bármit kihúzz. Képfájlra text/uri-list formátumot javasol az MDC, valahogy így:

Egyetlen gond van: a data url-es képünkkel nem tud mit kezdeni a desktop (legalábbis Linuxon és Macen nem volt szerencsém). Marad a Jobbkatt-Mentés másként, és igen, ezért dolgoztunk ennyit. Vagy én nem látok valami egyértelműt?

Tada.wav

És körbeértünk: drag, drop, fájlbetöltés, háttérben futó javascript, rajzolás. Ha ez mind működik, szinte teljesen el tudjuk felejteni, hogy még mindig a böngészőben vagyunk és már-már belelobog a hajunk a lebegőautós, holdbázisos, mindenre képes böngészős jövőbe.

Aztán belebotlunk egy same-origin korlátba és ráébredünk, hogy krumplipüréből akarunk polcot építeni. De ne rontsuk el az illúziót, mert kezdek belejönni a krumplipürébe.

• A forrás a GitHubon, virágokat az öltözőbe.

Sokáig vezette az Android Market játékrészlegének Top Free listáját egy gyönyörű iPhone játék otromba, elfuserált koppintása, ami a platform helyi sajátosságainak megfelelően ingyenes, cserébe reklámokkal dúsított volt.

Mindent egybevetve az még a legkisebb gond volt, hogy a megjelenített banner rátenyerelt a kijelző jelentős részére, ezzel szinte ellehetetlenítve a játékot, pláne hogy a reklám megjelenítése és animálása akkora megterhelést jelentett a telefon processzorának, hogy mihelyst betöltötte a reklámot, a framerate a felére leesett, az érintőképernyőre a játék pedig alig reagált. Végülis megértem, valamilyen módon jövedelmet kell szereznie a fejlesztőnknek, hogy aztán legyen miből új iPhone játékot lekoppintani, fizetni a programért pedig nem tudok a Marketen keresztül.

Elég viszont egy pillantást vetni a megjelenített hirdetésekre, hogy kiderüljön mennyire Milo Minderbinder-i az egész rendszer: a meglepően sok bibliaolvasó alkalmazás mellett nagyrészt más, szintén hasonló hirdetéseket megjelítő ingyenes játékok reklámai jönnek szembe. Még azelőtt gyanakodni kezdünk, hogy valami itt bűzlik, mielőtt szembejön a fejlesztőnk egy másik ingyenes, ugyanilyen hirdetéseket tartalmazó játékát hirdető banner.

Fejlesztőnk egy külső cégnek fizet, hogy egyik ingyenes játékát egy másikban hirdesse, az átkattintások alapján pedig… jutalékot kap, saját eredetileg befektetett pénzének ezredrészét. Mindezt úgy, hogy közben a meglevő felhasználóit hergeli.

Kinek lehet jó ez a mélyen törött szituáció? Kinek érdeke, hogy így lerontsa a felhasználói élményt, így ellehetetlenítse a fejlesztőket? Az egyetlen, aki ebből a szituációból jól jön ki, az az AdMob, ami a Google része, ami pedig … az Android platformot tulajdonosa. Ah.

Kecske, meet káposzta.

Van arra az érzésre szó, amit akkor érzel, amikor a Pokemon Silver fő storyline-ját befejezve magad mögött hagyod Johtót és pár év után előszőr látod újra Kanto régiót, ahol minden pont olyan, mint ahogy hagytad a Blue végén, kivéve pár apró változást, amiket viszont nem tudsz hova hagyni: minden egyszerre jól ismert és mégis újszerű; javítottak a grafikán, de valahogy az egész mintha sokkal kisebb lenne, mint ahogy emlékszel rá? Tegnap a Kertvárosban járva egyik bokorból se ugrott elő még egy Bulbasaur sem.

Gibson a Pattern Recognitionben adja egyik szereplője szájába azt a gondolatmenetet, hogy szerinte az amerikai és az európai digitális kultúra közötti alapvető különbség az volt, hogy míg errefelé Sinclair a ZX-81-gyel és társaival egy generáció előtt húzta el a mézesmadzagot, hogy meg kell tanulniuk programozni, ha bármit is akarnak kezdeni a kütyüjükkel, a tengeren túl az emberek másként viszonyultak ahhoz, hogy miután megveszed, összeszereled majd bekapcsolod a gépet, nem tudsz vele egyből semmit sem kezdeni.

“You have programmers, but America is different. America wanted Nintendo. Nintendo gives you no programmers.”

Az mondjuk vitatható, hogy mennyiben kizáró ok a Nintendo, a gondolatmenetet viszont kis átfogalmazással megmenthető: Amerikában elhanyagolható a demoscene, ezzel párhuzamosan és cserébe viszont ott alakult ki a chiptune. Míg az egyik a mikroszámítógépekre, azok warezolhatóságára és programozhatóságára épül, a másik a már-rég-kinőtt-de-aztán-padláson-megtalált konzolok félig-nosztalgikus kreatív újrafelhasználásából született.