Strach ze ztráty cesta k temné straně je. - Mistr Yoda
Že je léto? Nic se neděje? Ale houbeles, v těchto měsících nejde o nic menšího než o budoucnost Internetu. A pokud považujete Twitter nebo další sociální sítě za místo vhodné k provozování demokracie, tak jde i o svobodu slova.
Čtete-li tento text, nejspíš víte, o co se jedná v kauze Snowden. Možná jste se dozvěděli i o britské snaze zavést cenzuru Internetu, pamatujete si na humbuk kolem dohody ACTA a tušíte, že její hrozby sotvakdy budou zažehnány.
Nemusíte být příliš paranoidní, aby vás napadlo, že jde o jeden jediný problém s různými projevy. Jestliže jste momentálním vývojem znepokojeni, přečtěte si určitě Four Fears for authoritarians a vše vám začne dávat mnohem větší smysl.
Ano, jde tu o kontrolu. O strach ze ztráty moci. O drolící se status quo. Je dobré si uvědomit, jak velké síly jsou dnes v pohybu, takže si neodpustím určitou odbočku:
Člověk je sociálním zvířetem, funguje vždy jako součást nějakých komunit, organizací. Ať už jde o společenství malé (rodina, sousedstvo, malá firma) nebo velké (korporace, státní instituce, církve) vždy je nutné, aby se jedinec do jisté míry podřídil celku, jehož je součástí. Dokud jde o malou oběť ze strany jednotlivce, je vše v pořádku. Jedinec za to, že přistoupí na pravidla hry, získává od celku nějaké výhody.
Problém je ale ve společenské dynamice. Programátoři tuší: Neškáluje to dobře. Aby celek prosperoval, jeho jednotlivé součásti musí mezi sebou efektivně komunikovat. Množství interakcí roste s kvadrátem počtu komponent na určité úrovni, což se v praxi řeší nárůstem počtu úrovní. Neboli: Čím větší organizace, tím větší hierarchii (vyšší pyramidu lidí) je třeba navrstvit.
Malá společenství jsou akceschopnější než velká: Je snazší domluvit pravidla mezi sousedy než zákony ve sněmovně, korporace mění svou strategii pomaleji než malá firma, atd.
Setrvačnost ale není jediným prvkem odlišujícím velká společenství od malých. Další důležitou a netriviální vlastností je rozdíl zájmů jednotlivců a celku. Ten roste s velikostí organizace: Dáte-li dohromady víc lidí, je větší šance, že budou chtít každý něco jiného. Dokonce si můžeme představit organizaci jako samostatnou inteligentní entitu a označit ji třeba jako právnickou osobu. Tato osoba je pak vybavena vlastní agendou a směrem, jenž představuje jakousi výslednici různě velkých motivačních vektorů jejích členů. V krajních případech je touto výslednicí dokonce ideologie či náboženství.
Dost už ale motivační geometrie -- proč jsou mi menší společenství sympatičtější než větší, jsem se pokusil naznačit už dříve. Dnes chci především zdůraznit toto:
Každá organizace se v určitém bodě růstu soustředí na obranu vlastních zájmů, které jdou přímo proti zájmům nemalého počtu jejích členů.
Říkejte si tomu třeba "demokratický deficit". Jeho projevy pozorujeme čím dál častěji a vše naznačuje, že konflikt bude dál narůstat. Je to ale v podstatě konflikt stejně starý jako lidstvo. V minulosti byla kontrola mocných nad ovládanými masami mnohem zjevnější než dnes, kdy jsou politickoekonomické nitky a nepřímé metody vlivu rafinovaně skryty. Ale nenechte se mýlit. To, že žijeme stále v poměrně svobodném světě, se může postupně stát pouze všeobecně sdílenou iluzí. Jak praví známý bonmot: Kdyby volby mohly něco změnit, dávno by je zakázali.
I když se vše zatím odehrává hlavně ve Státech, Británii a Německu, jde i o nás a naše mocné.
Sebestřednost českého politickomediálního cirkusu je nejspíš hlavní příčinou toho, proč se tuzemští politici a veřejně viditelní potentáti ke kauze Snowden nevyjadřují. S výjimkou konzistentně konzervativního Romana Jocha, jenž Snowdena označil za zrádce, nevím o nikom z naší "oficiální sféry", kdo by se pokusil zaujmout nějaké stanovisko.
Což je ovšem jen jedno možné vysvětlení. Dalším může být, že naši politici prostě jen strkají hlavu do písku: Podpořit Snowdena by znamenalo rozhněvat si mocné spojence, postavit se proti němu pak ztrátu popularity u informovaných voličů.
Jinými slovy: Mají strach.
Zobrazují se příspěvky se štítkemweb. Zobrazit všechny příspěvky
Zobrazují se příspěvky se štítkemweb. Zobrazit všechny příspěvky
23. srpna 2013
7. září 2009
Ve verzi to nebude
Všichni ajťáci (tedy ajťáci s rozhledem) už vědí, že se v říjnu budou na jinak poklidné lokální scéně konat hned dvě zajímavé IT události: V Brně pořádá Petr Koubský (ákábéčko), v rámci Invex Fora sérii přednášek s názvem IT 1.0/2.0, zatímco v Praze zorganizoval Václav Stoupa, jenž si říká dvanula, druhý ročník specializované konference WebExpo 2009.
Přiznám se, že v tom vidím určitou polaritu, i když se možná pletu. Posuďte sami:
Invex býval dlouhá léta velký, úspěšný, všeobjímající veletrh, široko daleko jediný svého druhu. Mnoho peněz, mnoho marketingové muziky, ožralí VIP, novinářské dny, atd. Vše je dnes většinou pryč.
Loňské debutující WebExpo naopak mnohým návštěvníkům vyrazilo dech tím, jak kvalitní a a fundované přednášky přineslo. O webu přednášeli živnostníci (freelancers), tedy autoři webů, opět autorům webů, tedy sobě rovným, někteří vůbec poprvé.
Brněnská konference má v názvu 1.0, ta suchdolská pak nepřímo 2.0. Je druhá pokračováním té první? Asi sotva, i když tématicky si budou podobné. Obě konference zřejmě navštíví jiní posluchači, což je dáno cílením propagace (WebExpo je zaměřeno více technologicky), výběrem přednášejících, historickými vlivy, místem, atd. Konkurují si tedy obě události? Nevím.
Konference typu 1.0 byly o hardware, software, klientech, serverech, o integraci, o IT průmyslu. Webově orientované konference organizované v O'Reillyovském duchu pak vyšly z původních IT veletrhů stylem, jakým se Vetřelec líhne ze svého lidského hostitele. Jsou o startup podnikání.
A tak podobně, jako je třeba onkologie celý samostatný vědní obor ukrytý v tom, co laik vnímá pod slovem medicína, je i web celé samostatné odvětví ukryté v IT. Je to důsledek zvyšující se složitosti IT systémů: Zatímco před dvaceti lety se ajťáci dělili nejvýš na softwéráře a hardwéráře, před deseti lety si už administrátor databáze jen těžko popovídal s vývojářem programů pro telefony. Dnes je babylonizace oboru ještě větší. Vlivem specializace si dokonce přestávají rozumět i programátoři, kteří používají stejný programovací jazyk -- stačí jen, aby používali odlišný webový framework nebo knihovnu.
Není pak divu, že vznikají konference pro balkanizované webaře, a že zbytek, tedy "IT 1.0" může mít obavy ze ztráty sféry vlivu.
Nebo je to jinak? Jsou v tom nakonec generační vlivy?
Nemyslím si to. Není přece důležitá "verze IT", důležitý je výsledek. O tom ostatně asi bude na IT1.0/2.0 vyprávět právě Roman Staněk, jehož zaměstnanci pak budou o něčem podobném povídat na WebExpu 2009. Good Data jsou pro mne důkazem, že to vlivné není vůbec o nějakém "Us and Them", není to o IT versus Web, celek versus část, 1.0 versus 2.0.
To podstatné, o čem je třeba diskutovat, se táhne napříč verzemi, ať už jde o produkt nebo konferenci.
Proto mi přijde z tohoto pohledu trochu škoda, je, že organizátoři obou akcí nespojili síly. Co tak dát dohromady zkušenost, přehled, konktakty a profesionalitu IT s energicky agilní a neokoukanou neformálností Webu?
Co říkáte, pánové Petře a Vašku? Vím, že letos už je pozdě a věřím, že vaše konference budou určitě skvělé. Neuděláte ale nějaký "WebIT! 2010"?
To by byla teprve bomba.
Přiznám se, že v tom vidím určitou polaritu, i když se možná pletu. Posuďte sami:
Invex býval dlouhá léta velký, úspěšný, všeobjímající veletrh, široko daleko jediný svého druhu. Mnoho peněz, mnoho marketingové muziky, ožralí VIP, novinářské dny, atd. Vše je dnes většinou pryč.
Loňské debutující WebExpo naopak mnohým návštěvníkům vyrazilo dech tím, jak kvalitní a a fundované přednášky přineslo. O webu přednášeli živnostníci (freelancers), tedy autoři webů, opět autorům webů, tedy sobě rovným, někteří vůbec poprvé.
Brněnská konference má v názvu 1.0, ta suchdolská pak nepřímo 2.0. Je druhá pokračováním té první? Asi sotva, i když tématicky si budou podobné. Obě konference zřejmě navštíví jiní posluchači, což je dáno cílením propagace (WebExpo je zaměřeno více technologicky), výběrem přednášejících, historickými vlivy, místem, atd. Konkurují si tedy obě události? Nevím.
Konference typu 1.0 byly o hardware, software, klientech, serverech, o integraci, o IT průmyslu. Webově orientované konference organizované v O'Reillyovském duchu pak vyšly z původních IT veletrhů stylem, jakým se Vetřelec líhne ze svého lidského hostitele. Jsou o startup podnikání.
A tak podobně, jako je třeba onkologie celý samostatný vědní obor ukrytý v tom, co laik vnímá pod slovem medicína, je i web celé samostatné odvětví ukryté v IT. Je to důsledek zvyšující se složitosti IT systémů: Zatímco před dvaceti lety se ajťáci dělili nejvýš na softwéráře a hardwéráře, před deseti lety si už administrátor databáze jen těžko popovídal s vývojářem programů pro telefony. Dnes je babylonizace oboru ještě větší. Vlivem specializace si dokonce přestávají rozumět i programátoři, kteří používají stejný programovací jazyk -- stačí jen, aby používali odlišný webový framework nebo knihovnu.
Není pak divu, že vznikají konference pro balkanizované webaře, a že zbytek, tedy "IT 1.0" může mít obavy ze ztráty sféry vlivu.
Nebo je to jinak? Jsou v tom nakonec generační vlivy?
Nemyslím si to. Není přece důležitá "verze IT", důležitý je výsledek. O tom ostatně asi bude na IT1.0/2.0 vyprávět právě Roman Staněk, jehož zaměstnanci pak budou o něčem podobném povídat na WebExpu 2009. Good Data jsou pro mne důkazem, že to vlivné není vůbec o nějakém "Us and Them", není to o IT versus Web, celek versus část, 1.0 versus 2.0.
To podstatné, o čem je třeba diskutovat, se táhne napříč verzemi, ať už jde o produkt nebo konferenci.
Proto mi přijde z tohoto pohledu trochu škoda, je, že organizátoři obou akcí nespojili síly. Co tak dát dohromady zkušenost, přehled, konktakty a profesionalitu IT s energicky agilní a neokoukanou neformálností Webu?
Co říkáte, pánové Petře a Vašku? Vím, že letos už je pozdě a věřím, že vaše konference budou určitě skvělé. Neuděláte ale nějaký "WebIT! 2010"?
To by byla teprve bomba.
8. srpna 2009
Kterak David, král Internetu, přemohl vzpurné agnostiky
Část I - Vzestup pana Davida z Railsů
Bylo nebylo, v jedné malé IT firmě, přemýšlel jednoho dne programátor David H. nad svou prací. Měl toho hodně na todo listu a nešlo mu to příliš od ruky.
Jazyky, jimiž popisoval své webové dílo, byly příliš upovídané, neohrabané a navíc hustě nejednotné: Javascriptové motlitbičky, kratičké to prohlížečové otčenáše, se stále opakovaly a proplétaly v HTML křoví, databáze na druhém konci se nechala oslovovat pouze "YOUR HIGHNESS, PLEASE SELECT SOME DATA FROM YOUR TABLE TREASURE, ORDER IT AND SEND IT VERY QUICKLY BACK TO ME THROUGH MY TCPIP INTERFACE, NOW(), YES, FROM ALL AVAILABLE ENCODINGS USE THAT OF UNICODE, NO ANOTHER PROCESSING IS REQUIRED, THANK YOU VERY MUCH INDEED". S každým datovým typem byla spousta práce a nějaké knihovny nebo užitečné abstrakce -- pokud vůbec byly k mání -- byly příliš nepružné.
Takhle to nejde, řekl si David. Pořád se musím opakovat v tom, co chci napsat, a na to důležité, co odlišuje mou aplikaci od ostatních, se pak vůbec nesoustředím. Prohledávám mnoho různých referenčních manuálů od různých jazyků. Esence mého webu je příliš rozpuštěna v banalitách nižších úrovní kódu. Nešlo by to nějak stručněji? Abych stále nemusel vymýšlet ty samé identifikátory -- vždyť Customer je stále Customer a je to vlastně pořád jen řádek v tabulce customers. A má stále svůj jedinečný id, tak jako jakýkoliv jiný objekt webu. Vždyť stále konfiguruju databáze stejným způsobem, ať už píšu jakoukoliv aplikaci. Vždyť tu svoji Ajaxovou vychytávku kopíruju do všech stránek, ba co víc -- každou novou stánku mohu dokonce vytvořit automaticky skriptem -- tak jsou si podobné -- a pak ji teprve rozrůznit individuálním kódem.
Nepotřebuji stále činit ty samé volby, nemusím, když začínám psát aplikaci, dělat stále ta samá rozhodnutí, uvědomil si David. Chtělo by to to, co se opakuje, nějak jednoduše generovat. A chtělo by to celé slepit nějakým děsně pružným jazykem... Hm...
I vzal jazyk Ruby, do té doby nepříliš známou kuriózní japonskou napodobeninu Pythonu, a shledal jej krásným. "It is fun to code again!", zaradoval se. A ta skvělá komunita Ruby pohodářů!
Posílen na duchu, jal se David na serveru obalovat databázi abstrakcí, která každou relaci namapuje do Ruby objektu. Podobně obalil v prohlížeči javascriptovou knihovnu Prototype (dost dobrou pro každého), aby se nemusel trápit s Ajaxem. Aplikační logiku soustředil na jediné místo, do Řadiče, kde byla snadno pod Controllou, předvod URL adres do Řadičových metod pak svěřil univerzálnímu Výhybkáři. Na tvorbu nových HTML šablon zapojil mohutné Generátory a Lešenáře.
Po nějaké době radostného prgání vzhlédl David na své dílo. Je to jednotné, elegantní a vyjadřuje to můj názor na to, co je pro web dobré. Sviští to jak rychlík po kolejích. Název je dobrý, ještě logo by to chtělo. Do ERBu si dáme běloskvoucí kolej -- tak trochu připomínající šaškovskou čepici s rolničkami -- vetknutou do rubínového kamene.
Tak se zrodily Ruby on Rails.
A fungovalo to. David pak sekal rychle aplikaci jednu za druhou a vydělal spoustu peněz.
Ostatní weboví kodéři zpozorněli, nebylo možné dále přehlížet tolik (prý 37) Signálů. Jak to, že je ten David tak rychlý? Co on to používá za zázračný nástroj? Nechtěl by se o něj s námi podělit? Že Ruby? Nešlo by to celé rozjet jako open source? Prosíme... Když tak pěkně prosíme...
Weboví lidé dlouho Davida přesvědčovat nemuseli. Lichotilo mu, že se jeho tvrdohlavý ("opinionated") přístup k webovému frameworku podařil. Ano, co bylo dobré pro Davida, bylo určitě dobré pro ostatní kodéry. Rails stačilo vybalit z krabice, nahodit párkrát generátor a modelová železnice se rozjela ještě pod vánočním stromečkem. Nic nebylo třeba pracně spojovat, konfigurovat, atd. Kdysi suverénní databázový aristokrat byl uvržen do domácího vězení na hradě ActiveRecord. Dštil sice vzteky síru a chrlil lávu, nebylo mu to ale vůbec platné, jenom to trošku prosakovalo abstrakcí do hradních zdí, to ale nikomu nevadilo. A ten tajemný mág Ajax? Díky Davidovi jeho služeb teď mohl používat opravdu každý, nebylo nutné se učit nějaká kouzla.
A Davidova hvězda začala stoupat. Lidé po celém světě psali tutoriály, protože používat Rails bylo tak snadné, že napsat o tom, jak to udělat hello world, se vešlo do jednoho blogpostu. Začaly vycházet nejprve recenze, pak celé články v časopisech a nakonec knihy. Známý radar lorda Reillyho zaregistroval rychle letící objekt RoR a tak museli knihkupci ve svých obchodech brzy vyklidit novou poličku (tu mezi poličkami JavaScript a SQL), aby se tam knihy o Ruby a Rails vůbec vešly.
Rails vzkvétaly, k Davidovi přicházeli noví a noví kodéři a dobrovolníků, ochotných položit ruku k dílu, přibývalo. Zprvu tenké a pružné Rails se začaly plnit funkcionalitou a David, jenž v sobě rozpoznal náhle dar vůdce a génia, vyslyšel hlasu obchodníků a stal se králem.
Za pár let byly Rails Enterprise Ready a po drahém kameni Ruby najednou pošilhával skoro každý. A skoro každý líný hipík, jenž si na svém webu ještě donedávna vystačil jen s krabicí skriptózních Perel, chtěl najednou vyzkoušet Railsy.
Část II - Šlechta z Engine Yard
Zde bychom mohla naše pohádka končit, jenže... pak se to celé příšerně zamotalo.
Na Strojovém Dvoře se kníže Yehuda a hrabě Ezra bavili sestavováním a laděním virtuálních strojů. Byli to hračičkové, vše, co je zajímalo, byl tuning motoru v té nádherně lesklé, ale přecejen trošku pomalé káře jménem Ruby. Ladění výkonu je uživit nemohlo a tak si založili manufakturu na webové aplikace. Díky známému Davidově frameworku to šlo snadno a tak měli brzy dvůr plný urozených zákazníků.
Částečně kvůli své šťouravosti, částečně kvůli vrozenému citu pro rychlost, začali si Yehuda a Ezra brzy všímat určitých nedostatků Railsů. RoR byly, stručně řečeno, trochu pomalé a velké.
Ok, řekli si pánové, vyměníme pár součástek -- třeba objektově relační Mapovač by to chtělo nový, nebo... máme tu čím dál víc těhle RESTafariánů, co si stěžujou, že URL výhybka skřípe, co tak vyměnit ložiska? Aby nám to rychleji routovalo... Nebo tenhleten Prototype, neměli bychom to vyměnit za něco intuitivnějšího? A co když každému nevyhovuje šablonizér od ERBů? Co tak sjednocené rozhraní k různým webserverům?
A tak přátelé konstruktoři rozebrali Railsy na součástky a snažili se je poskládat jinak, lépěji. Jenže to do sebe nepasovalo, původní framework tvrdošíjně omítal nové díly tak, jako tělo nemocného odmítá transplantované orgány. Davidova Tvrdohlavá Konfigurace(TM) se vždy novému uspořádaní vzpírala. Ať už chtěli zamontovat do celku DataMapper, jQuery nebo Haml, původní staré díly byly natolik srostlé se zbytkem frameworku, že se nedaly jednoduše vyměnit.
Nu což, když to nejde zapojit do Rails, postavíme si framework nový, lepší. Bez tvrdohlavé konfigurace. Mít předvařené nastavení je fajn, každý začátečník jistě ocení, že všechno hned funguje. Co ale my, pokročilá tuningová aristokracie? Přece nechceme, aby nás David stále vodil za ruku. A co jiní šikovní web autoři na vyšší úrovni? Vždyť každému jen trochu schopnějšímu progišovi musí za chvíli lézt jediný správný Davidův názor na nervy.
Však jádro frameworku nemusí být napojeno na to ostatní. Nemusí nic dopředu vědět o relační abstrakci, o javascriptové knihovně, o technologii HTTP šablon. Náš framework může být takto krásně agnostický, co nepotřebujeme, to nepoužijeme.
No a samozřejmě, že je to pak celé jednodušší, čitelnější a rychlejší.
Naši konstruktoři si vzápětí uvědomili, v čem je podstata problému: Autoritativní přístup krále Davida je to, co pomohlo říši Railsů vybudovat a šířit její slávu, o tom žádná. Je to ale zároveň i nepřekonatelná filozoficko-teologická bariéra. Ten samý názor, co Railsy proslavil, teď brání jejich rozvoji. Co bylo dobré pro středověký venkov, není dobré pro nové renesanční město.
Chce to víc demokracie. Co takhle nabízet framework ve dvou krabicích? Jednu "opinionated", pro rychlý start, druhou pak jako stavebnici plnou dílů pro hraní. Ať si každý vybere, co mu vyhovuje.
Jak řekli, tak udělali a brzy se začalo o Merbu (tak svůj framework pojmenovali) mluvit mezi Railsovými odborníky. Uznalí kodéři oceňovali jeho rychlost, agnosticitu, čistý a elegantní návrh, jaký si může dovolit jen framework rostlý na zdravě zelené louce.
Jistě, Rails jsou náš bohatě vybavený a lety prověřený framework a Merbu bude dlouho trvat, než se stane "Enterprise Ready"... Ještě to ani není hotové a už je to tak dobré? No, počkáme na verzi 1 a zkusíme to místo Rails, honily se hlavou kacířské myšlenky nejednomu Davidově podanému.
Mem Merbu získal brzo své hlasatele a evangelizátory (zvláště pak slovutného pana Aimonettiho) a rychle se šířil všemi progišovsky zaměřenými sociálními sítěmi.
Část III - Zpětnovazební Signály
Na Davidově zámku zavládlo napětí a nervozita. Král byl poslední dobou stále zamračenější a zlostnější. "Co je to za pohůnky? Tak blbé jméno, jako je Merb, můžou vymyslet jen lidé s Java minulostí!", klel David, kudy chodil, a začal opět vysílat Signály kolem sebe: "Vám se to líbí?", ptal se svých rádců. "No jo, ta myšlenka je... přinejmenším použitelná, Vaše výsosti.", navrhovali rádci opatrně.
Dobrá, řekl po dlouhém uvažování David. Chci to taky. Chci agnosticitu, veřejná rozhraní garantovaná, tak, aby se jednotlivé části Rails do sebe daly zapojovat bez ohledu na verze. Chci rychlejší výhybky.... Nechci ale měnit svou jasnozřivou konfiguraci, která je dobrá pro mě i pro ostatní. A navěky bude.
"Vaše eminence.... ehm.... to není snadné", namítali rádci. "Do Railsů se nám nalepilo spoustu nového kódu, všechno se vším souvisí, těch vrstev, pořád chodí někdo s něčím novým, původní Vaše jasná myšlenka a geniální stavba se nám začíná pomalu hroutit pod tíhou všech těch přístavbiček a ozdůbiček na různých místech. Nepřítel má výhodnější pozici štíhlého lehkooděnce, jenž se ještě nedopustil vážnější chyby, lépe manévruje, je to miláček blogosféry. Merb má méně kódu, proto ho může pružně přizpůsobovat potřebám uživatele a nemusí stále dávat pozor na to, aby zůstával Enterprise Ready jako my."
To je pravda, musel David připustit. Léta strávená nad narůstající kódovou bází Railsů se začínala projevovat, prgání v Ruby už dávno nebylo tolik funny, dokumentace k frameworku začínala pomalu ale jistě připomínat onu nesourodou knihovnu referencí, babylon webových jazyků. To, co tak kdysi nenáviděl.
Co když... co když Merb ve své popularitě Railsy brzo úplně zastíní? Co když se má říše rozpadne a mí věrní odejdou k Merbu? Co když byznys přestane přijímat naše Signály a pokladna postupně vyschne? Co když nebudu slavný?
Ne, na zoufalství mám dosud čas. Poličku Merb vedle své poličky v knihkupectví prostě nesnesu, musím rychle zakročit, rozhodl se David.
Toho bohdá nebude, abych musel měnit Názor.
Část IV - Together we stand
I pozval David v předvečer velkého koncília celou družinu ze Strojového Dvora, jakože na pokec. Že by je jako seznámil se svým nápadem. Že respektuje všechna odlišná stanoviska. ("Pojďme nechat stranou -- jen pro teď samozřejmě -- naše rozdílné Názory a pojďme se bavit řečí, která je nám společná, tedy jazykem Ruby. Však jsme, chlapi, všichni kodeři, ne?").
A tehdy udělal Yehuda a jeho blízcí svou první -- bohužel však zásadní -- chybu: Davidovo pozvání přijal.
"Hele kluci, jste vážně dobrý speed démoni. Takhle vybudovat framework od základu není sranda, vím, o čem mluvím", začal nadšeně David. " Ta vaše agnosticita, to je vážně bomba. Vyměňovat knihovny podle libosti, o tom jsem snil dávno, to už jsem pro Railsy dávno plánoval. Jenže ty moje vladařský povinnosti. Na prgání už nemám vůbec čas, pořád nějaký interview, pořád samý konference. Ruby fun? No more. Heleďte, co byste tomu řekli, kdybychom se usmířili a kdybychom... tak nějak... ehm... spojili síly? Potřebuju šikovného ředitele vývoje, obratného ministra propagandy, pár schopných refaktorizátorů a evangelizátorů... všem bych se bohatě odměnil."
Yehudovi poklesly čelisti: "Vaše výsost promine, ale to nejde. Ceníme si vaší nabídky, ale máme své záměry spojeny s budoucností Merbu a na víc už nám příliš času nezbývá..."
"Samozřejmě víme, jak na tom jsme", náhle zvážněla králova tvář. "Signálům se celkem daří, zatímco váš Dvůr musel nedávno propouštět.... Víte, doslechlo se mi, že se objevily nějaké pochybnosti ohledně originality vašeho kódu. Já bych nechtěl -- na to si vás opravdu vážím -- abyste někde u soudu museli vysvětlovat, co to vlastně znamená, že Merb jsou vlastně Railsy udělané pořádně, jak vy s oblibou říkáte. Proč je tam tolik společných prvků, stejných názvů. Já tohle opravdu nepotřebuju, tenhle negativní marketing, myslím, že všechny zlý jazyky můžu ještě a včas snadno umlčet, pokud budete... totiž budeme spolu spolupracovat."
"Ale, to přece nejde..." hledal Yehuda jen obtížně slova. "Nemůžeme mít vedle sebe dva frameworky. A tvářit se, že spolupracujeme."
"No, já myslím, že si ještě úplně nerozumíme", pousmál se král David. "Ať jsem se se to snažil promýšlet z různých konců, pořád mi vychází, že není pod sluncem místo pro dva dobré webové frameworky psané v jednom jazyce."
Ticho bylo dlouhé a absolutní, přerušil ho až cvrkot startujícího slideshow na královském noteboku.
"Představuju si to nějak takhle: Vyhlásíme sloučení obou frameworků. To nejlepší z frameworku Merb... tedy, říkejme mu nyní pracovně Větev Merb, bude sloučeno do hlavní vývojové větve Railsů. Rails3 rovná se Rails2 plus Merb1", nastínil David vskutku jednoduchou rovnici na prvním slajdu. "Co je dobré pro Rails, je dobré pro všechny Rubyisty, a to jak pro věrné, tak i pro ty, co náhodou sešli na hříšnou stezku, svedeni vábením lákavého agnosticismu. Na konferenci budete tvrdit, že jste vlastně psali Merb s úmyslem poukázat na chyby v Railsech a já se vší pompou vyhlásím, že je mi ctí uvítat v týmu skvělé odborníky, jakými jste vy. Budete Těmi, kdo zbavili Rails hnoje. Kredit zajištěn. Nakonec je to jasný win-win pro vás i pro mě, ne?".
"No... a co komunita?" vzmohl se schlíplý Aimonetti na jakýsi odpor. "Nemůžeme přeci tvrdit , že Raisy jsou super, když ještě včera jsme říkali, že nejsou. Lidi budou naštvaný a přestanou nám věřit."
"Podívej, kámo... můžu ti říkat šéfevangelizátor?", zeptal se král, aniž by očekával nějakou odpověď. "Lidi budou brblat a nakonec si stáhnou nový Railsy, znám je. Vždycky to tak bylo, nakonec si stáhli poslední verzi, přestali žvanit a zvykli si.... A co se týče nějaké změny názorů... jsem připraven dokonce připustit, že jsem se -- jen v něčem, samozřejmě -- mýlil. No představte si to, takovou oběť z mý strany... Tím vytvoříme prostor pro Amonioniho, zdatného to nového ministra propagandy, jenž připraví názorovou platformu pro nastávající velký Merge. Nikdo z nás nemusí ztratit svou čest... a když, tak jen kapku. V budoucnosti plné zářivě lesklých Railsů si na to stejně nikdo nevzpomene."
Yehuda vydechl: "Rozmyslíme si to, králi, musíme se teď poradit."
Králův rubínový mobil se náhle rozezněl. "Eh, tyhlety právníci, to jsem mu říkal, ať teď nevolá", umlčel David telefon. "Dobrá, kluci, já myslím, že se rozhodnete správně... jak říkám, ten váš agnosticismus, to bylo fakt dobrý... Jo, ještě jsem se chtěl zeptat, kdo z vás napíše naše společné komuniké?"
Část V - Ve starých dobrých Kolejích
Měsíce již uplynuly od chvíle, kdy David zachránil svoji říši.
Geniální galejník Yehuda už plně fixuje bugy v přechodové verzi Rails2 a když si potřebuje trochu odpočinout, refaktorizuje Rails2 do podoby Rails3.
Schopný politruk Aimonetti evangelizuje, až se mu z blogu práší, a připomíná nám, co všichni dobře víme: cílem není glorifikovat své jméno, ale vyvinout nejlepší řešení. A pokud zánik Merbu pomůže, aby se Railsy staly opravdu nejlepším frameworkem pod sluncem, je to win-win pro všechny.
Slíbený Merb 1.1 (jakési spasení pro hrstku poražených agnostiků pomocí cesty k Rails3) je v nedohlednu, připravované knihy o Merbu mění názvy. A Merb komunita? Ona tu nějaká byla?
Král David, mistrný státník s pevnou rukou, měl tedy nakonec pravdu. Ještě trochu brbláme, ale už se všichni těšíme, až zase budeme "Enterprise Ready".
Bylo nebylo, v jedné malé IT firmě, přemýšlel jednoho dne programátor David H. nad svou prací. Měl toho hodně na todo listu a nešlo mu to příliš od ruky.
Jazyky, jimiž popisoval své webové dílo, byly příliš upovídané, neohrabané a navíc hustě nejednotné: Javascriptové motlitbičky, kratičké to prohlížečové otčenáše, se stále opakovaly a proplétaly v HTML křoví, databáze na druhém konci se nechala oslovovat pouze "YOUR HIGHNESS, PLEASE SELECT SOME DATA FROM YOUR TABLE TREASURE, ORDER IT AND SEND IT VERY QUICKLY BACK TO ME THROUGH MY TCPIP INTERFACE, NOW(), YES, FROM ALL AVAILABLE ENCODINGS USE THAT OF UNICODE, NO ANOTHER PROCESSING IS REQUIRED, THANK YOU VERY MUCH INDEED". S každým datovým typem byla spousta práce a nějaké knihovny nebo užitečné abstrakce -- pokud vůbec byly k mání -- byly příliš nepružné.
Takhle to nejde, řekl si David. Pořád se musím opakovat v tom, co chci napsat, a na to důležité, co odlišuje mou aplikaci od ostatních, se pak vůbec nesoustředím. Prohledávám mnoho různých referenčních manuálů od různých jazyků. Esence mého webu je příliš rozpuštěna v banalitách nižších úrovní kódu. Nešlo by to nějak stručněji? Abych stále nemusel vymýšlet ty samé identifikátory -- vždyť Customer je stále Customer a je to vlastně pořád jen řádek v tabulce customers. A má stále svůj jedinečný id, tak jako jakýkoliv jiný objekt webu. Vždyť stále konfiguruju databáze stejným způsobem, ať už píšu jakoukoliv aplikaci. Vždyť tu svoji Ajaxovou vychytávku kopíruju do všech stránek, ba co víc -- každou novou stánku mohu dokonce vytvořit automaticky skriptem -- tak jsou si podobné -- a pak ji teprve rozrůznit individuálním kódem.
Nepotřebuji stále činit ty samé volby, nemusím, když začínám psát aplikaci, dělat stále ta samá rozhodnutí, uvědomil si David. Chtělo by to to, co se opakuje, nějak jednoduše generovat. A chtělo by to celé slepit nějakým děsně pružným jazykem... Hm...
I vzal jazyk Ruby, do té doby nepříliš známou kuriózní japonskou napodobeninu Pythonu, a shledal jej krásným. "It is fun to code again!", zaradoval se. A ta skvělá komunita Ruby pohodářů!
Posílen na duchu, jal se David na serveru obalovat databázi abstrakcí, která každou relaci namapuje do Ruby objektu. Podobně obalil v prohlížeči javascriptovou knihovnu Prototype (dost dobrou pro každého), aby se nemusel trápit s Ajaxem. Aplikační logiku soustředil na jediné místo, do Řadiče, kde byla snadno pod Controllou, předvod URL adres do Řadičových metod pak svěřil univerzálnímu Výhybkáři. Na tvorbu nových HTML šablon zapojil mohutné Generátory a Lešenáře.
Po nějaké době radostného prgání vzhlédl David na své dílo. Je to jednotné, elegantní a vyjadřuje to můj názor na to, co je pro web dobré. Sviští to jak rychlík po kolejích. Název je dobrý, ještě logo by to chtělo. Do ERBu si dáme běloskvoucí kolej -- tak trochu připomínající šaškovskou čepici s rolničkami -- vetknutou do rubínového kamene.
Tak se zrodily Ruby on Rails.
A fungovalo to. David pak sekal rychle aplikaci jednu za druhou a vydělal spoustu peněz.
Ostatní weboví kodéři zpozorněli, nebylo možné dále přehlížet tolik (prý 37) Signálů. Jak to, že je ten David tak rychlý? Co on to používá za zázračný nástroj? Nechtěl by se o něj s námi podělit? Že Ruby? Nešlo by to celé rozjet jako open source? Prosíme... Když tak pěkně prosíme...
Weboví lidé dlouho Davida přesvědčovat nemuseli. Lichotilo mu, že se jeho tvrdohlavý ("opinionated") přístup k webovému frameworku podařil. Ano, co bylo dobré pro Davida, bylo určitě dobré pro ostatní kodéry. Rails stačilo vybalit z krabice, nahodit párkrát generátor a modelová železnice se rozjela ještě pod vánočním stromečkem. Nic nebylo třeba pracně spojovat, konfigurovat, atd. Kdysi suverénní databázový aristokrat byl uvržen do domácího vězení na hradě ActiveRecord. Dštil sice vzteky síru a chrlil lávu, nebylo mu to ale vůbec platné, jenom to trošku prosakovalo abstrakcí do hradních zdí, to ale nikomu nevadilo. A ten tajemný mág Ajax? Díky Davidovi jeho služeb teď mohl používat opravdu každý, nebylo nutné se učit nějaká kouzla.
A Davidova hvězda začala stoupat. Lidé po celém světě psali tutoriály, protože používat Rails bylo tak snadné, že napsat o tom, jak to udělat hello world, se vešlo do jednoho blogpostu. Začaly vycházet nejprve recenze, pak celé články v časopisech a nakonec knihy. Známý radar lorda Reillyho zaregistroval rychle letící objekt RoR a tak museli knihkupci ve svých obchodech brzy vyklidit novou poličku (tu mezi poličkami JavaScript a SQL), aby se tam knihy o Ruby a Rails vůbec vešly.
Rails vzkvétaly, k Davidovi přicházeli noví a noví kodéři a dobrovolníků, ochotných položit ruku k dílu, přibývalo. Zprvu tenké a pružné Rails se začaly plnit funkcionalitou a David, jenž v sobě rozpoznal náhle dar vůdce a génia, vyslyšel hlasu obchodníků a stal se králem.
Za pár let byly Rails Enterprise Ready a po drahém kameni Ruby najednou pošilhával skoro každý. A skoro každý líný hipík, jenž si na svém webu ještě donedávna vystačil jen s krabicí skriptózních Perel, chtěl najednou vyzkoušet Railsy.
Část II - Šlechta z Engine Yard
Zde bychom mohla naše pohádka končit, jenže... pak se to celé příšerně zamotalo.
Na Strojovém Dvoře se kníže Yehuda a hrabě Ezra bavili sestavováním a laděním virtuálních strojů. Byli to hračičkové, vše, co je zajímalo, byl tuning motoru v té nádherně lesklé, ale přecejen trošku pomalé káře jménem Ruby. Ladění výkonu je uživit nemohlo a tak si založili manufakturu na webové aplikace. Díky známému Davidově frameworku to šlo snadno a tak měli brzy dvůr plný urozených zákazníků.
Částečně kvůli své šťouravosti, částečně kvůli vrozenému citu pro rychlost, začali si Yehuda a Ezra brzy všímat určitých nedostatků Railsů. RoR byly, stručně řečeno, trochu pomalé a velké.
Ok, řekli si pánové, vyměníme pár součástek -- třeba objektově relační Mapovač by to chtělo nový, nebo... máme tu čím dál víc těhle RESTafariánů, co si stěžujou, že URL výhybka skřípe, co tak vyměnit ložiska? Aby nám to rychleji routovalo... Nebo tenhleten Prototype, neměli bychom to vyměnit za něco intuitivnějšího? A co když každému nevyhovuje šablonizér od ERBů? Co tak sjednocené rozhraní k různým webserverům?
A tak přátelé konstruktoři rozebrali Railsy na součástky a snažili se je poskládat jinak, lépěji. Jenže to do sebe nepasovalo, původní framework tvrdošíjně omítal nové díly tak, jako tělo nemocného odmítá transplantované orgány. Davidova Tvrdohlavá Konfigurace(TM) se vždy novému uspořádaní vzpírala. Ať už chtěli zamontovat do celku DataMapper, jQuery nebo Haml, původní staré díly byly natolik srostlé se zbytkem frameworku, že se nedaly jednoduše vyměnit.
Nu což, když to nejde zapojit do Rails, postavíme si framework nový, lepší. Bez tvrdohlavé konfigurace. Mít předvařené nastavení je fajn, každý začátečník jistě ocení, že všechno hned funguje. Co ale my, pokročilá tuningová aristokracie? Přece nechceme, aby nás David stále vodil za ruku. A co jiní šikovní web autoři na vyšší úrovni? Vždyť každému jen trochu schopnějšímu progišovi musí za chvíli lézt jediný správný Davidův názor na nervy.
Však jádro frameworku nemusí být napojeno na to ostatní. Nemusí nic dopředu vědět o relační abstrakci, o javascriptové knihovně, o technologii HTTP šablon. Náš framework může být takto krásně agnostický, co nepotřebujeme, to nepoužijeme.
No a samozřejmě, že je to pak celé jednodušší, čitelnější a rychlejší.
Naši konstruktoři si vzápětí uvědomili, v čem je podstata problému: Autoritativní přístup krále Davida je to, co pomohlo říši Railsů vybudovat a šířit její slávu, o tom žádná. Je to ale zároveň i nepřekonatelná filozoficko-teologická bariéra. Ten samý názor, co Railsy proslavil, teď brání jejich rozvoji. Co bylo dobré pro středověký venkov, není dobré pro nové renesanční město.
Chce to víc demokracie. Co takhle nabízet framework ve dvou krabicích? Jednu "opinionated", pro rychlý start, druhou pak jako stavebnici plnou dílů pro hraní. Ať si každý vybere, co mu vyhovuje.
Jak řekli, tak udělali a brzy se začalo o Merbu (tak svůj framework pojmenovali) mluvit mezi Railsovými odborníky. Uznalí kodéři oceňovali jeho rychlost, agnosticitu, čistý a elegantní návrh, jaký si může dovolit jen framework rostlý na zdravě zelené louce.
Jistě, Rails jsou náš bohatě vybavený a lety prověřený framework a Merbu bude dlouho trvat, než se stane "Enterprise Ready"... Ještě to ani není hotové a už je to tak dobré? No, počkáme na verzi 1 a zkusíme to místo Rails, honily se hlavou kacířské myšlenky nejednomu Davidově podanému.
Mem Merbu získal brzo své hlasatele a evangelizátory (zvláště pak slovutného pana Aimonettiho) a rychle se šířil všemi progišovsky zaměřenými sociálními sítěmi.
Část III - Zpětnovazební Signály
Na Davidově zámku zavládlo napětí a nervozita. Král byl poslední dobou stále zamračenější a zlostnější. "Co je to za pohůnky? Tak blbé jméno, jako je Merb, můžou vymyslet jen lidé s Java minulostí!", klel David, kudy chodil, a začal opět vysílat Signály kolem sebe: "Vám se to líbí?", ptal se svých rádců. "No jo, ta myšlenka je... přinejmenším použitelná, Vaše výsosti.", navrhovali rádci opatrně.
Dobrá, řekl po dlouhém uvažování David. Chci to taky. Chci agnosticitu, veřejná rozhraní garantovaná, tak, aby se jednotlivé části Rails do sebe daly zapojovat bez ohledu na verze. Chci rychlejší výhybky.... Nechci ale měnit svou jasnozřivou konfiguraci, která je dobrá pro mě i pro ostatní. A navěky bude.
"Vaše eminence.... ehm.... to není snadné", namítali rádci. "Do Railsů se nám nalepilo spoustu nového kódu, všechno se vším souvisí, těch vrstev, pořád chodí někdo s něčím novým, původní Vaše jasná myšlenka a geniální stavba se nám začíná pomalu hroutit pod tíhou všech těch přístavbiček a ozdůbiček na různých místech. Nepřítel má výhodnější pozici štíhlého lehkooděnce, jenž se ještě nedopustil vážnější chyby, lépe manévruje, je to miláček blogosféry. Merb má méně kódu, proto ho může pružně přizpůsobovat potřebám uživatele a nemusí stále dávat pozor na to, aby zůstával Enterprise Ready jako my."
To je pravda, musel David připustit. Léta strávená nad narůstající kódovou bází Railsů se začínala projevovat, prgání v Ruby už dávno nebylo tolik funny, dokumentace k frameworku začínala pomalu ale jistě připomínat onu nesourodou knihovnu referencí, babylon webových jazyků. To, co tak kdysi nenáviděl.
Co když... co když Merb ve své popularitě Railsy brzo úplně zastíní? Co když se má říše rozpadne a mí věrní odejdou k Merbu? Co když byznys přestane přijímat naše Signály a pokladna postupně vyschne? Co když nebudu slavný?
Ne, na zoufalství mám dosud čas. Poličku Merb vedle své poličky v knihkupectví prostě nesnesu, musím rychle zakročit, rozhodl se David.
Toho bohdá nebude, abych musel měnit Názor.
Část IV - Together we stand
I pozval David v předvečer velkého koncília celou družinu ze Strojového Dvora, jakože na pokec. Že by je jako seznámil se svým nápadem. Že respektuje všechna odlišná stanoviska. ("Pojďme nechat stranou -- jen pro teď samozřejmě -- naše rozdílné Názory a pojďme se bavit řečí, která je nám společná, tedy jazykem Ruby. Však jsme, chlapi, všichni kodeři, ne?").
A tehdy udělal Yehuda a jeho blízcí svou první -- bohužel však zásadní -- chybu: Davidovo pozvání přijal.
"Hele kluci, jste vážně dobrý speed démoni. Takhle vybudovat framework od základu není sranda, vím, o čem mluvím", začal nadšeně David. " Ta vaše agnosticita, to je vážně bomba. Vyměňovat knihovny podle libosti, o tom jsem snil dávno, to už jsem pro Railsy dávno plánoval. Jenže ty moje vladařský povinnosti. Na prgání už nemám vůbec čas, pořád nějaký interview, pořád samý konference. Ruby fun? No more. Heleďte, co byste tomu řekli, kdybychom se usmířili a kdybychom... tak nějak... ehm... spojili síly? Potřebuju šikovného ředitele vývoje, obratného ministra propagandy, pár schopných refaktorizátorů a evangelizátorů... všem bych se bohatě odměnil."
Yehudovi poklesly čelisti: "Vaše výsost promine, ale to nejde. Ceníme si vaší nabídky, ale máme své záměry spojeny s budoucností Merbu a na víc už nám příliš času nezbývá..."
"Samozřejmě víme, jak na tom jsme", náhle zvážněla králova tvář. "Signálům se celkem daří, zatímco váš Dvůr musel nedávno propouštět.... Víte, doslechlo se mi, že se objevily nějaké pochybnosti ohledně originality vašeho kódu. Já bych nechtěl -- na to si vás opravdu vážím -- abyste někde u soudu museli vysvětlovat, co to vlastně znamená, že Merb jsou vlastně Railsy udělané pořádně, jak vy s oblibou říkáte. Proč je tam tolik společných prvků, stejných názvů. Já tohle opravdu nepotřebuju, tenhle negativní marketing, myslím, že všechny zlý jazyky můžu ještě a včas snadno umlčet, pokud budete... totiž budeme spolu spolupracovat."
"Ale, to přece nejde..." hledal Yehuda jen obtížně slova. "Nemůžeme mít vedle sebe dva frameworky. A tvářit se, že spolupracujeme."
"No, já myslím, že si ještě úplně nerozumíme", pousmál se král David. "Ať jsem se se to snažil promýšlet z různých konců, pořád mi vychází, že není pod sluncem místo pro dva dobré webové frameworky psané v jednom jazyce."
Ticho bylo dlouhé a absolutní, přerušil ho až cvrkot startujícího slideshow na královském noteboku.
"Představuju si to nějak takhle: Vyhlásíme sloučení obou frameworků. To nejlepší z frameworku Merb... tedy, říkejme mu nyní pracovně Větev Merb, bude sloučeno do hlavní vývojové větve Railsů. Rails3 rovná se Rails2 plus Merb1", nastínil David vskutku jednoduchou rovnici na prvním slajdu. "Co je dobré pro Rails, je dobré pro všechny Rubyisty, a to jak pro věrné, tak i pro ty, co náhodou sešli na hříšnou stezku, svedeni vábením lákavého agnosticismu. Na konferenci budete tvrdit, že jste vlastně psali Merb s úmyslem poukázat na chyby v Railsech a já se vší pompou vyhlásím, že je mi ctí uvítat v týmu skvělé odborníky, jakými jste vy. Budete Těmi, kdo zbavili Rails hnoje. Kredit zajištěn. Nakonec je to jasný win-win pro vás i pro mě, ne?".
"No... a co komunita?" vzmohl se schlíplý Aimonetti na jakýsi odpor. "Nemůžeme přeci tvrdit , že Raisy jsou super, když ještě včera jsme říkali, že nejsou. Lidi budou naštvaný a přestanou nám věřit."
"Podívej, kámo... můžu ti říkat šéfevangelizátor?", zeptal se král, aniž by očekával nějakou odpověď. "Lidi budou brblat a nakonec si stáhnou nový Railsy, znám je. Vždycky to tak bylo, nakonec si stáhli poslední verzi, přestali žvanit a zvykli si.... A co se týče nějaké změny názorů... jsem připraven dokonce připustit, že jsem se -- jen v něčem, samozřejmě -- mýlil. No představte si to, takovou oběť z mý strany... Tím vytvoříme prostor pro Amonioniho, zdatného to nového ministra propagandy, jenž připraví názorovou platformu pro nastávající velký Merge. Nikdo z nás nemusí ztratit svou čest... a když, tak jen kapku. V budoucnosti plné zářivě lesklých Railsů si na to stejně nikdo nevzpomene."
Yehuda vydechl: "Rozmyslíme si to, králi, musíme se teď poradit."
Králův rubínový mobil se náhle rozezněl. "Eh, tyhlety právníci, to jsem mu říkal, ať teď nevolá", umlčel David telefon. "Dobrá, kluci, já myslím, že se rozhodnete správně... jak říkám, ten váš agnosticismus, to bylo fakt dobrý... Jo, ještě jsem se chtěl zeptat, kdo z vás napíše naše společné komuniké?"
Část V - Ve starých dobrých Kolejích
Měsíce již uplynuly od chvíle, kdy David zachránil svoji říši.
Geniální galejník Yehuda už plně fixuje bugy v přechodové verzi Rails2 a když si potřebuje trochu odpočinout, refaktorizuje Rails2 do podoby Rails3.
Schopný politruk Aimonetti evangelizuje, až se mu z blogu práší, a připomíná nám, co všichni dobře víme: cílem není glorifikovat své jméno, ale vyvinout nejlepší řešení. A pokud zánik Merbu pomůže, aby se Railsy staly opravdu nejlepším frameworkem pod sluncem, je to win-win pro všechny.
Slíbený Merb 1.1 (jakési spasení pro hrstku poražených agnostiků pomocí cesty k Rails3) je v nedohlednu, připravované knihy o Merbu mění názvy. A Merb komunita? Ona tu nějaká byla?
Král David, mistrný státník s pevnou rukou, měl tedy nakonec pravdu. Ještě trochu brbláme, ale už se všichni těšíme, až zase budeme "Enterprise Ready".
9. října 2008
Vaše data? Místy oblačno.
Máme s kamarádem Jirkou takovou hru, jmenuje se tříbení názorů. Aniž bychom mohli (nebo snad chtěli) jeden druhého přesvědčovat o své pravdě, pouštíme se opakovaně do diskuse na určitá známá témata. Odměnou za zdánlvě promrhaný čas je nám většinou nějaký nový nápad, jenž společně vykřešeme.
Jedním takovým evergreenem našich debat jsou webové aplikace. Když jsem dopsal odpověď na Jirkův blogpost, napadlo mě, že jsem narazil na zajímavé vedlejší téma, takový malý nugetek, který volá po podrobném rozpracování, totiž: Jsem přesvědčen o tom, že nastupuje věk webových aplikací, jistě. Co ovšem při bližším zkoumání vypadá jako hlavní brzda rozvoje SaaS, clouds, atd. (říkejte si tomu, jak chcete), jsou uživatelova data uložená na serveru provozovatele aplikace. Zkrátka prima materiál pro pozdější zpracování.
I přikryl jsem nugetek opět hlušinou a věnoval se jiným věcem.
A jako už mnohokrát předtím, byl jsem okraden. Po mém nápadu sáhl Stallman, svatý muž z pravoslavné odnože církve Opravdu Svobodného Software. Jakousi podivnou synchronicitou se stalo, že zveřejnil úvahy, které zaměstnávaly mé podvědomí -- naplno se do toho obul a uživatele označil za tmel v rukou autorů webových aplikací.
Užuž jsem se chtěl tématu vzdát -- co vzmůžu proti Stallmanovu pěstěnému charismatu? Ale pak mi to došlo: ono to totiž není vůbec jednoduché.
Předně: Výtky kritiků oblačného počítání s uživatelskými daty se dají rozdělit do dvou velkých skupin. První z nich je:
Ztráta a nedostupnost dat
Zde jde o to, že se ke svým datům občas nedostanete, když je potřebujete. Příčiny mohou být různé, nejčastěji jde o selhání webové aplikace nebo technický problém toho, kdo aplikaci hostuje. Obecně je možno říci, že čím větší korporace, tím větší pozor si na výpadky dává -- i když výhrady jsou na místě. Úplná ztráta dat je spíše výjimečná a většinou souvisí i s úplným odchodem autora aplikace ze scény.
Pokud existuje k webové aplikaci slušně napsané API, má (pokročilý) uživatel k dispozici více či méně komfortní možnost svá data pravidelně lokálně zálohovat. Je pochopitelně rozdíl mezi pasivní datovou zálohou a fungující aplikací, nicméně je dobré vědět, že máme, po určitém úsilí, vždy nějakou nenulovou šanci svá data oživit jinde.
Pro webové aplikace mluví skutečnost, že z pohledu fyzického uložení dat není příliš rozdíl mezi plotnou disku na pracovní stanici a plotnou v diskovém poli poskytovatele aplikace. Naopak, ať už jde o pouhý RAID nebo o jiné technologie datového úložiště (např. GFS), je váš bajt lépe a s vyšší redundancí zapsán spíše na cizím disku než na vašem vlastním -- pokud si to nemyslíte, měli byste se sami sebe zeptat, jak často a na jak spolehlivá média zálohujete důležitá data ze svého počítače nebo mobilu.
Doposud jsem se zabýval jen tou méně zajímavou polovinou celého problému. Tou podstatnou je samozřejmě:
Datové soukromí a autorita
Důležitější, než důvěra v to, že data přečteme my, kdykoliv se o to pokusíme, je jen víra v to, že je nepřečte někdo jiný, ať už se o to bude snažit sebevíc.
Soukromí našich dat v rukou provozovatelů webové služby je většinou zaručeno slovně, přesněji řečeno v jazyce zvaném právničtina. V textech, s nimiž vždy souhlasíme, aniž bychom se namáhali je číst, stojí psáno, že poskytovatel vynaloží nemalé úsilí, aby naše data nikomu neukázal -- tedy, pokud k tomu nebude donucen, třeba soudem. Ovšem v případě, že se veškerá snaha držet jazyk za zuby mine účinkem, nebudeme ho za to, chudáka, nijak popotahovat, třebas před soudem.
Stručně: texty tohoto typu jsou bezcenné, protože nám nepomohou v situacích, kdy už si je opravdu musíme přečíst. Jakou mám záruku, že se má citlivá data nedostanou do nepovolaných rukou -- třeba jen vinou hloupé chyby v klauzuli databázového dotazu? Klidu mi nepřidá, když tuším, že leží v té samé tabulce jako záznamy mého konkurenta, jen jde o jiný řádek.
Nabízejí se analogie s bankou: máte raději své peníze pod matrací nebo v rukou spolehlivých finančních institucí? Důvěra v banky nebyla vždy tak samozřejmá jako dnes (já vím, teď se nabízí příležitost k aktuálním vtipům na účet bankovního sektoru, kterou nevyužiji). Pro účely přirovnání je dobré si uvědomit, že důvěra v banku, jakož i důvěra v poskytovatele webové aplikace, se opírá o autoritu instituce.
Důvěra v takovou autoritu je značně asymetrický vztah: Na jedné straně spotřebitel / zákazník / klient / uživatel -- prostě človíček s omezenými možnostmi obrany, na straně druhé silně se tvářící instuituce, která chce, aby jí bylo věřeno (přestože všichni víme, že každá instituce je utvořena z normálních, tj. náladových, chybujících, případně i zkorumpovatelných človíčků).
Zde se Stallmanem souhlasit mohu. Spolehneme-li se na slovní záruky autorit, budeme vždy jen tvárnou konzumní hmotou v rukou institucí -- bank nebo IT korporací.
Datové soukromí a technologie
Nexistují jiné záruky? Zdá se, že zatím příliš ne. Problém uživatelských dat si lidé uvědomují, o tom žádná. Pokud považujeme zajištění dat založené na důvěře v instituce za nedostatečné, není možné řešení založit na důvěře v technické prostředky?
Příklady by tu byly: Jediný bezpečný způsob, jak uložit autorizační heslo na serveru, je -- neukládat ho vůbec. Zadá-li uživatel při prvním přihlášení heslo, je toto nejprve převedeno z otevřeného tvaru do zašifrované podoby (hashed) a teprve v tomto tvaru je uloženo. Způsob převodu by měl zajistit, že získat otevřený tvar hesla z jeho zašifrované podoby je prakticky neproveditelné a že opakovaným šifrováním stejného hesla získáme vždy stejnou šifrovanou podobu. Pokud později potřebujeme uživatele autorizovat, postačí porovnávat šifrovanou podobu nově zadaného hesla s jeho dříve uloženou verzí. I když se pak někdo zmocní šifrovaných hesel na serveru, moc mu nepomůže ani to, že má k dispozici šifrovací algoritmus.
Je jasné, kam směřuji: Šifrování je celé založeno na obecně přijatelném předpokladu, že dobrý šifrovací algoritmus je veřejně přístupný a jediné, co je třeba udržet v tajnosti, je heslo, jímž jsou data šifrována. Čím více očí kryptologů vidí do toho, jak šifrovací systém funguje, tím je daný systém bezpečnější, protože jeho potenciální slabiny jsou pod veřejnou kontrolou.
Je tedy možné, aby datové soukromí webových aplikací bylo založeno na podobné technologické transparenci?
Představme si takovou podporu aplikace v prohlížeči, jež zajišťuje, že citlivá data vůbec neopustí uživatelův počítač. Server webové aplikace pak může pracovat pouze s daty, jejichž zneužití útočníkovi nepřináší velkou výhodu.
Samozřejmě, že taková architektura je o poznání složitější než to, co známe v oblasti webových aplikací dnes a vyžaduje obecně rozšířený prohlížeč s dobře propracovanou podporou uložení dat. Také je nutné, aby vzniklo více různých implementací této datové podpory, navíc se standardizovaným aplikačním rozhraním (JavaScript API), jinak hrozí klasický vendor lock-in (neboli: ''Jo tak vy nemáte nainstalovaný tohlencto naše rozšíření? Jak si to pak představujete, že vám naše aplikace poběží?").
(Vsuvka pro C++ programátory: Vedle šifrování se k lokálnímu úložišti nabízí se ještě jedna analogie, sice ve smyslu funkcionálního programování. Ten, kdo zkusil použít šablonovou knihovnu STL, pravděpodobně narazil na koncept tzv. iterátoru, oddělujícího datový kontejner od algoritmu. Osobně považuji tento koncept za jednu z největších výhod STL. Omlouvám se neprogramátorům za ztíženou čitelnost článku na tomto místě.)
Smrt "nativních" aplikací?
Ano, můžeme namítnout, že navrhované rozšíření o lokální úložiště dat prohlížeč více přibližuje nativním aplikacím, tak, jak je známe. Proč tedy nepsat rovnou nativní aplikace? Nebo -- proč nedat zákazníkovi rovnou do rukou kromě klienta i server aplikace?
Ještě jednou tedy a stručně -- proto, že webové aplikace na serveru poskytovatele jsou pružnější, praktičtější a zkrátka životaschopnější než všechny ostatní varianty. Jistě, že budou existovat odůvodněné vyjímky a stále bude vznikat určité nezanedbatelné procento nativních aplikací. Probírat všechny aspekty nehodlám, kdo dnes zpochybňuje jeden z nejviditelnějších trendů současného vývoje IT, asi by mé argumenty stejně nepřijal.
Soukromí uživatelových dat zkrátka vnímám jako nejvíce oprávněnou výhradu proti používání webových aplikací. Důsledné oddělení uživatelových dat od kódu aplikace na serveru -- i když jeho provedení může být složité -- tuto výhradu odstraňuje.
V rukou programátora zcela budiž algoritmus, protože jen programátor dovede zařídit, aby byl algoritmus k užitku. V rukou uživatele budiž data, protože jen uživatel ví, jak cenná data jsou.
Jedním takovým evergreenem našich debat jsou webové aplikace. Když jsem dopsal odpověď na Jirkův blogpost, napadlo mě, že jsem narazil na zajímavé vedlejší téma, takový malý nugetek, který volá po podrobném rozpracování, totiž: Jsem přesvědčen o tom, že nastupuje věk webových aplikací, jistě. Co ovšem při bližším zkoumání vypadá jako hlavní brzda rozvoje SaaS, clouds, atd. (říkejte si tomu, jak chcete), jsou uživatelova data uložená na serveru provozovatele aplikace. Zkrátka prima materiál pro pozdější zpracování.
I přikryl jsem nugetek opět hlušinou a věnoval se jiným věcem.
A jako už mnohokrát předtím, byl jsem okraden. Po mém nápadu sáhl Stallman, svatý muž z pravoslavné odnože církve Opravdu Svobodného Software. Jakousi podivnou synchronicitou se stalo, že zveřejnil úvahy, které zaměstnávaly mé podvědomí -- naplno se do toho obul a uživatele označil za tmel v rukou autorů webových aplikací.
Užuž jsem se chtěl tématu vzdát -- co vzmůžu proti Stallmanovu pěstěnému charismatu? Ale pak mi to došlo: ono to totiž není vůbec jednoduché.
Předně: Výtky kritiků oblačného počítání s uživatelskými daty se dají rozdělit do dvou velkých skupin. První z nich je:
Ztráta a nedostupnost dat
Zde jde o to, že se ke svým datům občas nedostanete, když je potřebujete. Příčiny mohou být různé, nejčastěji jde o selhání webové aplikace nebo technický problém toho, kdo aplikaci hostuje. Obecně je možno říci, že čím větší korporace, tím větší pozor si na výpadky dává -- i když výhrady jsou na místě. Úplná ztráta dat je spíše výjimečná a většinou souvisí i s úplným odchodem autora aplikace ze scény.
Pokud existuje k webové aplikaci slušně napsané API, má (pokročilý) uživatel k dispozici více či méně komfortní možnost svá data pravidelně lokálně zálohovat. Je pochopitelně rozdíl mezi pasivní datovou zálohou a fungující aplikací, nicméně je dobré vědět, že máme, po určitém úsilí, vždy nějakou nenulovou šanci svá data oživit jinde.
Pro webové aplikace mluví skutečnost, že z pohledu fyzického uložení dat není příliš rozdíl mezi plotnou disku na pracovní stanici a plotnou v diskovém poli poskytovatele aplikace. Naopak, ať už jde o pouhý RAID nebo o jiné technologie datového úložiště (např. GFS), je váš bajt lépe a s vyšší redundancí zapsán spíše na cizím disku než na vašem vlastním -- pokud si to nemyslíte, měli byste se sami sebe zeptat, jak často a na jak spolehlivá média zálohujete důležitá data ze svého počítače nebo mobilu.
Doposud jsem se zabýval jen tou méně zajímavou polovinou celého problému. Tou podstatnou je samozřejmě:
Datové soukromí a autorita
Důležitější, než důvěra v to, že data přečteme my, kdykoliv se o to pokusíme, je jen víra v to, že je nepřečte někdo jiný, ať už se o to bude snažit sebevíc.
Soukromí našich dat v rukou provozovatelů webové služby je většinou zaručeno slovně, přesněji řečeno v jazyce zvaném právničtina. V textech, s nimiž vždy souhlasíme, aniž bychom se namáhali je číst, stojí psáno, že poskytovatel vynaloží nemalé úsilí, aby naše data nikomu neukázal -- tedy, pokud k tomu nebude donucen, třeba soudem. Ovšem v případě, že se veškerá snaha držet jazyk za zuby mine účinkem, nebudeme ho za to, chudáka, nijak popotahovat, třebas před soudem.
Stručně: texty tohoto typu jsou bezcenné, protože nám nepomohou v situacích, kdy už si je opravdu musíme přečíst. Jakou mám záruku, že se má citlivá data nedostanou do nepovolaných rukou -- třeba jen vinou hloupé chyby v klauzuli databázového dotazu? Klidu mi nepřidá, když tuším, že leží v té samé tabulce jako záznamy mého konkurenta, jen jde o jiný řádek.
Nabízejí se analogie s bankou: máte raději své peníze pod matrací nebo v rukou spolehlivých finančních institucí? Důvěra v banky nebyla vždy tak samozřejmá jako dnes (já vím, teď se nabízí příležitost k aktuálním vtipům na účet bankovního sektoru, kterou nevyužiji). Pro účely přirovnání je dobré si uvědomit, že důvěra v banku, jakož i důvěra v poskytovatele webové aplikace, se opírá o autoritu instituce.
Důvěra v takovou autoritu je značně asymetrický vztah: Na jedné straně spotřebitel / zákazník / klient / uživatel -- prostě človíček s omezenými možnostmi obrany, na straně druhé silně se tvářící instuituce, která chce, aby jí bylo věřeno (přestože všichni víme, že každá instituce je utvořena z normálních, tj. náladových, chybujících, případně i zkorumpovatelných človíčků).
Zde se Stallmanem souhlasit mohu. Spolehneme-li se na slovní záruky autorit, budeme vždy jen tvárnou konzumní hmotou v rukou institucí -- bank nebo IT korporací.
Datové soukromí a technologie
Nexistují jiné záruky? Zdá se, že zatím příliš ne. Problém uživatelských dat si lidé uvědomují, o tom žádná. Pokud považujeme zajištění dat založené na důvěře v instituce za nedostatečné, není možné řešení založit na důvěře v technické prostředky?
Příklady by tu byly: Jediný bezpečný způsob, jak uložit autorizační heslo na serveru, je -- neukládat ho vůbec. Zadá-li uživatel při prvním přihlášení heslo, je toto nejprve převedeno z otevřeného tvaru do zašifrované podoby (hashed) a teprve v tomto tvaru je uloženo. Způsob převodu by měl zajistit, že získat otevřený tvar hesla z jeho zašifrované podoby je prakticky neproveditelné a že opakovaným šifrováním stejného hesla získáme vždy stejnou šifrovanou podobu. Pokud později potřebujeme uživatele autorizovat, postačí porovnávat šifrovanou podobu nově zadaného hesla s jeho dříve uloženou verzí. I když se pak někdo zmocní šifrovaných hesel na serveru, moc mu nepomůže ani to, že má k dispozici šifrovací algoritmus.
Je jasné, kam směřuji: Šifrování je celé založeno na obecně přijatelném předpokladu, že dobrý šifrovací algoritmus je veřejně přístupný a jediné, co je třeba udržet v tajnosti, je heslo, jímž jsou data šifrována. Čím více očí kryptologů vidí do toho, jak šifrovací systém funguje, tím je daný systém bezpečnější, protože jeho potenciální slabiny jsou pod veřejnou kontrolou.
Je tedy možné, aby datové soukromí webových aplikací bylo založeno na podobné technologické transparenci?
Představme si takovou podporu aplikace v prohlížeči, jež zajišťuje, že citlivá data vůbec neopustí uživatelův počítač. Server webové aplikace pak může pracovat pouze s daty, jejichž zneužití útočníkovi nepřináší velkou výhodu.
Samozřejmě, že taková architektura je o poznání složitější než to, co známe v oblasti webových aplikací dnes a vyžaduje obecně rozšířený prohlížeč s dobře propracovanou podporou uložení dat. Také je nutné, aby vzniklo více různých implementací této datové podpory, navíc se standardizovaným aplikačním rozhraním (JavaScript API), jinak hrozí klasický vendor lock-in (neboli: ''Jo tak vy nemáte nainstalovaný tohlencto naše rozšíření? Jak si to pak představujete, že vám naše aplikace poběží?").
(Vsuvka pro C++ programátory: Vedle šifrování se k lokálnímu úložišti nabízí se ještě jedna analogie, sice ve smyslu funkcionálního programování. Ten, kdo zkusil použít šablonovou knihovnu STL, pravděpodobně narazil na koncept tzv. iterátoru, oddělujícího datový kontejner od algoritmu. Osobně považuji tento koncept za jednu z největších výhod STL. Omlouvám se neprogramátorům za ztíženou čitelnost článku na tomto místě.)
Smrt "nativních" aplikací?
Ano, můžeme namítnout, že navrhované rozšíření o lokální úložiště dat prohlížeč více přibližuje nativním aplikacím, tak, jak je známe. Proč tedy nepsat rovnou nativní aplikace? Nebo -- proč nedat zákazníkovi rovnou do rukou kromě klienta i server aplikace?
Ještě jednou tedy a stručně -- proto, že webové aplikace na serveru poskytovatele jsou pružnější, praktičtější a zkrátka životaschopnější než všechny ostatní varianty. Jistě, že budou existovat odůvodněné vyjímky a stále bude vznikat určité nezanedbatelné procento nativních aplikací. Probírat všechny aspekty nehodlám, kdo dnes zpochybňuje jeden z nejviditelnějších trendů současného vývoje IT, asi by mé argumenty stejně nepřijal.
Soukromí uživatelových dat zkrátka vnímám jako nejvíce oprávněnou výhradu proti používání webových aplikací. Důsledné oddělení uživatelových dat od kódu aplikace na serveru -- i když jeho provedení může být složité -- tuto výhradu odstraňuje.
V rukou programátora zcela budiž algoritmus, protože jen programátor dovede zařídit, aby byl algoritmus k užitku. V rukou uživatele budiž data, protože jen uživatel ví, jak cenná data jsou.
30. září 2008
Prokletí sémantického webu
Kdykoliv se utká dobro se zlem, dochází ke zrychlení pokroku. Střetávají-li se good guys a bad guys, zbrojí se nutně na obou stranách a vedlejším produktem tohoto úsilí ("arms races") jsou dokonalejší zbraně, čili technologie. To platí ve světě IT dvakrát -- kdybychom neměli autory virů, neprosperoval by trh s antivirovými programy, například.
Jedním z buzzwordů poslední doby je tzv. Sémantický web, neboli Web 3.0. Jde o... hnutí... (znáte snad výstižnější slovo?) hodných hochů s chvályhodnou motivací -- zlepšit užitnou hodnotu webu. Stručně řečeno: Vytvořit sémantické standardy a technologie umožňující vznik nových aplikací, které by chápaly význam skutečností na webových stránkách uváděných a dovolily tak nám, lidem, pracovat nejen s texty a obrázky, ale i s informacemi na webu.
Sémantický přístup slibuje i nové formy útoku na zatím neotřesitelnou vyhledávací pozici, kótu č. 1, na níž je v současnosti Google dobře opevněn. Pokud příslušníci sémantického hejna uspějí, zvedne se laťka doposud spíše statisticky zpracovávaného webového obsahu o trochu výš. Prakticky to bude znamenat alespoň to, že chovatelé koček a unixoví administrátoři nebudou dostávat na dotaz "cat" stejné výsledky.
Chvályhodnou snahu sémantiků zatím maří pár maličkostí:
1/ předpokládá se spolupráce autorů webového obsahu a webových aplikací. Ti jsou zatím zaneprázdněni spíše sledováním nových prohlížečů a obcházením jejich nekompatibilit, než aby doplňovali své stránky o nějaké RDFa a mikroformáty a tak nemají čas sledovat...
2/ ...poněkud chaotický vývoj v oblasti.
Protože má sémantický web -- ve fázi zrodu -- problémy sám se sebou, nepřekvapí, že se do něj oškliví hoši ještě ani pořádně neobuli. Ti se samozřejmě chopí svých příležitostí v okamžiku, kdy začne být zřejmé, že se z rance nápadů a standardizačních draftů začíná klubat něco úspěšného (čti: začnou z toho koukat prachy).
Co se stane pak?
Předně si řekněmě, kdo jsou ti zlí. Bystří už tuší, že zlí jsou: spammeři, skriptéři splogů, SEO černokněžníci, doménoví spekulanti, zkrátka všichni weboví příživníci, kteří automaticky generují obsah a zvyšují šum, aniž by přidávali hodnotu. (Aby bylo jasno, existuje jemný, ale podstatný rozdíl mezi obsahem generovaným a obsahem agregovaným.) Tito chlapci se s podrobnostmi sémantického webu doposud neseznámili, ale učiní tak v okamžiku, kdy Joe The Internet User začne místo google.com do adresní řádky prohlížeče psát hakia.com, powerset.com nebo třeba trueknowledge.com.
K čemu tedy dojde, až se objeví opravdu smysluplné sémantické technologie? K ničemu jinému než k pozvolné devalvaci smyslu, k inflaci významu, ke ztrátě sémantiky: Je třeba zařídit, aby se produkt mého klienta dobře rankoval ve výsledcích? Ale prosím, upravíme... jak se to sakra... ontologii, napíšeme plugin do prohlížeče, doplníme standard, rozšíříme vliv, ovládneme trh... však to znáte.
Po jisté době, kdy se věci zdánlivě začnou vyvíjet k lepšímu, dojde -- jakmile se spammeři naučí generovat nebo kupovat význam -- ke kolapsu zbytků použitelného webu. Finito.
A možná také ne.
Možná se zlí chlapci, aniž by o to stáli, dopustí vedlejšího efektu, který by nikdo nečekal. Začnou nevědomky, mimoděk... přidávat hodnotu (no fuj). V honbě za věrnějším a významuplnějším, avšak falešným, obsahem, jenž by úspěšněji mátl budoucí sémantické vyhledávače, dopustí se nechtěně jeho postmoderní tvorby. Na základě existujících textů začnou vystřihováním a opětovným lepením automaticky vytvářet informace, které nám -- světe, div se -- budou k užitku. Nejprve ve stylu tohoto fousatého vtipu, později lépe a stále dokonaleji. Zlé se sémanticky zlepší, zlí si sémanticky polepší.
K setření hranic mezi ošklivými a hodnými hochy dojde pozvolna. Možná už k němu dochází nyní, v intencích Webu 2.0 s jeho sociálně statistickými kritérii "užitečnosti".
Uvědomil jsem si to naplno dnes, kdy mi, poštou ranní, dorazil jeden nečekaný Google Alert. Pokud to ještě neznáte: to je takové diferenční automatické hledání -- zadáte hledanou frázi a ono vám to pak nepravidelně zasílá svodku s novinkami. Kdo to zná, ví, že jde o neocenitelnou službu, jež efektivně zvyšuje počet mailů, který ten den nestihnete vyřídit. A kdo Google Alert nejenom zná, ale i aktivně používá, jistě si všiml, že v alertech za poslední asi půl rok rapidně vzrostl počet splogů, na něž svodky odkazují. Spammeři zkrátka zacílili i na zcela minoritní cílovou skupinu, kterou představují nejrůznější odborníci nebo lidé jako já, tedy podivíni, co si nechávají posílat výsledky hledání nepraktických kombinací klíčových slov, jako např. "multi-objective optimization" nebo "evolutionary strategies".
Zkrátka -- při pohledu na tento spammerský blog se u mne dostavil onen slovutný AHA moment, celé to probíhalo zhruba takto: JE to nade vší pochybnost jen nosič reklamy a ne zápisník nějakého vědce hodný mé pozornosti, takže zavíráme tab... POČKAT... hmm... opravdu? Vždyť ten spammer mi může, při splnění určitých dalších předpokladů, být užitečný -- pokud ovšem bude konzistentně kopírovat seznam literatury ze sborníků, které bych si možná někdy rád prolistoval, pokud je trochu lépe zorganizuje, atd... takže... zlý nebo hodný? Zlý, jasně, že zlý, pokud hodnotíme jeho prvotní motiv. Ale pochybnost dále vzrůstá -- co když jednou bude -- samotnou honbou za významem, jedinečností, atd. svého splogu -- donucen mi opravdu přinést nějakou zajímavou informaci, kterou bych jinak nenašel?
Co když i emailový spam ruku v ruce s mailovými filtry dosáhne onoho kýženého stavu, kdy skrze obrannou bariéru do inboxu proniknou jen opravdu zajímavé, a přesto nevyžádané maily? Co když jednou úmyslně nastavím svůj sémantický spamfiltr tak, že připustím... určité, konkrétně cílené... reklamě... aby mne oslovila? (Ó, jaká ostuda se k těmto myšlenkám, mezi námi intelektuály, vůbec přiznat: no považte, on se nevyhýbá reklamě).
Co když se... tak nějak samo od sebe... vyřeší naše současné dilema, které se projevuje tím, že nestíháme sledovat a vyhledávat všechny významné novinky, zatímco jsme zahlceni naprosto nepodstatnými věcmi, jež se na nás valí ze všech stran?
Co když... Možná. A možná vůbec ne.
Ale pokud ano, kdy se tak stane? Zcela jistě až v době, kdy většinu článků z webu pro nás a za nás bude vyhledávat a předčítat autonomní softwarový agent -- robotická sekretářka -- a my zatím budeme zalezlí, někde v klidu, dokonale soustředeni na vymýšlení Webu 4.0.
---
Pozn.: rozdělení na hodné a zlé chlapce zrcadlí čistě mé osobní preference. Pokud v tomto textu zaměníte dobro za zlo, nedojde ke ztrátě jeho informační hodnoty.
Jedním z buzzwordů poslední doby je tzv. Sémantický web, neboli Web 3.0. Jde o... hnutí... (znáte snad výstižnější slovo?) hodných hochů s chvályhodnou motivací -- zlepšit užitnou hodnotu webu. Stručně řečeno: Vytvořit sémantické standardy a technologie umožňující vznik nových aplikací, které by chápaly význam skutečností na webových stránkách uváděných a dovolily tak nám, lidem, pracovat nejen s texty a obrázky, ale i s informacemi na webu.
Sémantický přístup slibuje i nové formy útoku na zatím neotřesitelnou vyhledávací pozici, kótu č. 1, na níž je v současnosti Google dobře opevněn. Pokud příslušníci sémantického hejna uspějí, zvedne se laťka doposud spíše statisticky zpracovávaného webového obsahu o trochu výš. Prakticky to bude znamenat alespoň to, že chovatelé koček a unixoví administrátoři nebudou dostávat na dotaz "cat" stejné výsledky.
Chvályhodnou snahu sémantiků zatím maří pár maličkostí:
1/ předpokládá se spolupráce autorů webového obsahu a webových aplikací. Ti jsou zatím zaneprázdněni spíše sledováním nových prohlížečů a obcházením jejich nekompatibilit, než aby doplňovali své stránky o nějaké RDFa a mikroformáty a tak nemají čas sledovat...
2/ ...poněkud chaotický vývoj v oblasti.
Protože má sémantický web -- ve fázi zrodu -- problémy sám se sebou, nepřekvapí, že se do něj oškliví hoši ještě ani pořádně neobuli. Ti se samozřejmě chopí svých příležitostí v okamžiku, kdy začne být zřejmé, že se z rance nápadů a standardizačních draftů začíná klubat něco úspěšného (čti: začnou z toho koukat prachy).
Co se stane pak?
Předně si řekněmě, kdo jsou ti zlí. Bystří už tuší, že zlí jsou: spammeři, skriptéři splogů, SEO černokněžníci, doménoví spekulanti, zkrátka všichni weboví příživníci, kteří automaticky generují obsah a zvyšují šum, aniž by přidávali hodnotu. (Aby bylo jasno, existuje jemný, ale podstatný rozdíl mezi obsahem generovaným a obsahem agregovaným.) Tito chlapci se s podrobnostmi sémantického webu doposud neseznámili, ale učiní tak v okamžiku, kdy Joe The Internet User začne místo google.com do adresní řádky prohlížeče psát hakia.com, powerset.com nebo třeba trueknowledge.com.
K čemu tedy dojde, až se objeví opravdu smysluplné sémantické technologie? K ničemu jinému než k pozvolné devalvaci smyslu, k inflaci významu, ke ztrátě sémantiky: Je třeba zařídit, aby se produkt mého klienta dobře rankoval ve výsledcích? Ale prosím, upravíme... jak se to sakra... ontologii, napíšeme plugin do prohlížeče, doplníme standard, rozšíříme vliv, ovládneme trh... však to znáte.
Po jisté době, kdy se věci zdánlivě začnou vyvíjet k lepšímu, dojde -- jakmile se spammeři naučí generovat nebo kupovat význam -- ke kolapsu zbytků použitelného webu. Finito.
A možná také ne.
Možná se zlí chlapci, aniž by o to stáli, dopustí vedlejšího efektu, který by nikdo nečekal. Začnou nevědomky, mimoděk... přidávat hodnotu (no fuj). V honbě za věrnějším a významuplnějším, avšak falešným, obsahem, jenž by úspěšněji mátl budoucí sémantické vyhledávače, dopustí se nechtěně jeho postmoderní tvorby. Na základě existujících textů začnou vystřihováním a opětovným lepením automaticky vytvářet informace, které nám -- světe, div se -- budou k užitku. Nejprve ve stylu tohoto fousatého vtipu, později lépe a stále dokonaleji. Zlé se sémanticky zlepší, zlí si sémanticky polepší.
K setření hranic mezi ošklivými a hodnými hochy dojde pozvolna. Možná už k němu dochází nyní, v intencích Webu 2.0 s jeho sociálně statistickými kritérii "užitečnosti".
Uvědomil jsem si to naplno dnes, kdy mi, poštou ranní, dorazil jeden nečekaný Google Alert. Pokud to ještě neznáte: to je takové diferenční automatické hledání -- zadáte hledanou frázi a ono vám to pak nepravidelně zasílá svodku s novinkami. Kdo to zná, ví, že jde o neocenitelnou službu, jež efektivně zvyšuje počet mailů, který ten den nestihnete vyřídit. A kdo Google Alert nejenom zná, ale i aktivně používá, jistě si všiml, že v alertech za poslední asi půl rok rapidně vzrostl počet splogů, na něž svodky odkazují. Spammeři zkrátka zacílili i na zcela minoritní cílovou skupinu, kterou představují nejrůznější odborníci nebo lidé jako já, tedy podivíni, co si nechávají posílat výsledky hledání nepraktických kombinací klíčových slov, jako např. "multi-objective optimization" nebo "evolutionary strategies".
Zkrátka -- při pohledu na tento spammerský blog se u mne dostavil onen slovutný AHA moment, celé to probíhalo zhruba takto: JE to nade vší pochybnost jen nosič reklamy a ne zápisník nějakého vědce hodný mé pozornosti, takže zavíráme tab... POČKAT... hmm... opravdu? Vždyť ten spammer mi může, při splnění určitých dalších předpokladů, být užitečný -- pokud ovšem bude konzistentně kopírovat seznam literatury ze sborníků, které bych si možná někdy rád prolistoval, pokud je trochu lépe zorganizuje, atd... takže... zlý nebo hodný? Zlý, jasně, že zlý, pokud hodnotíme jeho prvotní motiv. Ale pochybnost dále vzrůstá -- co když jednou bude -- samotnou honbou za významem, jedinečností, atd. svého splogu -- donucen mi opravdu přinést nějakou zajímavou informaci, kterou bych jinak nenašel?
Co když i emailový spam ruku v ruce s mailovými filtry dosáhne onoho kýženého stavu, kdy skrze obrannou bariéru do inboxu proniknou jen opravdu zajímavé, a přesto nevyžádané maily? Co když jednou úmyslně nastavím svůj sémantický spamfiltr tak, že připustím... určité, konkrétně cílené... reklamě... aby mne oslovila? (Ó, jaká ostuda se k těmto myšlenkám, mezi námi intelektuály, vůbec přiznat: no považte, on se nevyhýbá reklamě).
Co když se... tak nějak samo od sebe... vyřeší naše současné dilema, které se projevuje tím, že nestíháme sledovat a vyhledávat všechny významné novinky, zatímco jsme zahlceni naprosto nepodstatnými věcmi, jež se na nás valí ze všech stran?
Co když... Možná. A možná vůbec ne.
Ale pokud ano, kdy se tak stane? Zcela jistě až v době, kdy většinu článků z webu pro nás a za nás bude vyhledávat a předčítat autonomní softwarový agent -- robotická sekretářka -- a my zatím budeme zalezlí, někde v klidu, dokonale soustředeni na vymýšlení Webu 4.0.
---
Pozn.: rozdělení na hodné a zlé chlapce zrcadlí čistě mé osobní preference. Pokud v tomto textu zaměníte dobro za zlo, nedojde ke ztrátě jeho informační hodnoty.
Přihlásit se k odběru:
Příspěvky (Atom)