Přejít k navigační liště

Zdroják » Různé » Postřehy z Google Developer Day 2010

Postřehy z Google Developer Day 2010

Články Různé

V úterý 16. listopadu se v Praze konala konference pro vývojáře používající technlogie Google – Google Developer Day (GDD). Akce zajímavá a inspirativní již jen pro to, jakou má dnes pozici Google mezi ostatními firmami jejichž podnikání se točí okolo internetu. O své postřehy z této akce se s vámi podělí Jirka Kosek.

V žádném případě nečekejte podrobnou reportáž z GDD – s výjimkou úvodní přednášky se další prezentace odvíjely paralelně ve čtyřech sálech, a to nemluvím o doprovodném programu – jeden smrtelník mohl postihnout maximálně kolem 20 % z celého GDD.

Představa 75 minut trvající úvodní keynote mě do začátku trochu děsila a počítal jsem s tím, že místo ní spíš budu pít kafe a vyřizovat e-maily. Během úvodní keynote se vystřídalo několik řečníků, kteří ukázkami doplnili hlavního průvodce keynote Erica Tholomé, takže vše mělo příjemný spád a mé obavy se ukázaly jako liché. Hlavní témata byla tři – HTML5/Chrome, Cloud a Android.

Co mě však dost zarazilo, byly vstupy přednášejících z českých firem. Je jistě velmi oživující, když přednášku kapacit z Google obohatí někdo lokální, kdo ukáže, jak technologii používá. Ale proč tyhle minivstupy byly většinou česky a ne anglicky? Neznám přesná čísla, ale přišlo mi, že celkem hodně účastníků nebylo z česky mluvících zemí a neměli tak šanci rozumět. Přišlo se tak o mnoho zajímavých momentů – jsem třeba zvědavý, co by Jeremy Orlow přednášející o HTML5 řekl na zmínku Davida Grudla (ukazujícího využití některých vlastností HTML5 v Nette) o vložení Javascriptu, který HTML5 funkce vypne, aby to fungovalo. (Možná to řekl David trochu jinak, ale takhle to v jeho krátké Nette kanonádě vyznělo.) Pochopil bych přednášky v češtině, kdyby GDD byl skoro v každé zemi. Ale v Evropě byl jen v Moskvě, Praze a Mnichově. Příště by to chtělo buď překladatele nebo více světáctví a oprostit se od Švejkova jazyka.

Vzhledem k mým zájmům a neschopnosti se klonovat jsem v následujících přednáškách vypustil sekce věnované Androidu a podnikání a pohyboval se mezi Cloud Computingem a Chrome/HTML5.

Native Client

Vzpomínáte si ještě na ActiveX? Tato technologie Microsoftu, která dovolovala ve stránce spouštět binární komponenty bez jakékoliv kontroly nad tím, co dělají, a použitelně fungovala jen ve Windows a Internet Exploreru, již naštěstí skoro vymřela. Nebo ne? Zdá se, že Google zatoužil po vlastní obdobě ActiveX a stvořil Native Client. Technologie umožňuje spouštět nativní kód (tedy přímo strojový kód pro danou platformu, typicky vytvořený např. kompilátorem C++) přímo v prostředí prohlížeče. K dispozici je API pro komunikaci nativního kódu s Javascriptem a zbytkem stránky.

Myšlenka tedy podobná jako u ActiveX. Výhodou oproti ActiveX je lepší bezpečnost – před spuštěním se kód verifikuje a kontroluje se, zda nebude provádět některé nepovolené operace. Alespoň papírově to vypadá, že Native Client bude podporován v několika operačních systémech a na různých procesorových architekturách – to si samozřejmě vyžádá separátní kompilaci pro jednotlivé architektury.

Přemýšlel jsem, proč takovou věc jako Native Client Google dělá a prezentuje na GDD. V dnešní době se postupně skoro pro vše vytvářejí javascriptová API a nové možnosti HTML5 jako třeba 2D canvas a jednou možná i 3D canvas umožní přímo v prohlížeči naprogramovat téměř cokoliv. Pro většinu aplikací bude Javascript v prohlížeči výkonem stačit, zvláště pokud se ještě zapracuje na interpretech, kompilátorech a virtuálních strojích pro Javascript. Výjimkou však budou hry.

Hry jsou jednou z mála aplikací, které dokáží počítač normálního uživatele vytížit na plno. Dává proto smysl, že během prezentace byl Native Client použit právě pro spuštění 3D aplikace využívající herní knihovnu Unity. Myslím, že operační systém Chrome OS bude nejdříve mířit do spotřebních zařízení – set-top boxy, tablety, … A byla by škoda, kdyby tato zařízení nešla používat jako herní konzoli. Tak jsem zvědavý, do kolika let tu budeme mít GBox, GPlayStation či jak se ta nová herní konzole Google bude jmenovat. Jiné smysluplné využití Native Client si moc nedovedu představit.

Rozšíření Chrome

Pomocí rozšíření je dnes možné si většinu prohlížečů funkčně vymazlit do požadované podoby. Rozšíření samozřejmě podporuje i Chrome a o tom byla další prezentace v sekci Chrome&HTML5. Většina prohlížečů dnes směřuje k tomu, že rozšíření se píší přímo jako malá webová aplikace využívající Javascript, HTML a CSS. K dispozici je navíc pár dalších API, která zpřístupní informace o prohlížeči a jeho stavu. Je to zcela jistě správný směr, protože to usnadní psaní rozšíření širší skupině vývojářů.

Doufám, že do pár let se psaní rozšíření v Javascriptu, HTML5 a CSS prosadí ve všech prohlížečích. Pak by bylo možné mezi prohlížeči sjednotit API a balíčkování rozšíření a konečně by si uživatelé instalovali rozšíření pro webový prohlížeč, ne jako dneska speciální rozšíření pro Chrome, speciální rozšíření pro Firefox, speciální rozšíření pro IE, speciální rozšíření pro Operu, … Něco podobného jako Widgets. Jestli však Google chce být vůdčí silou takové iniciativy, asi by měl na konfiguraci rozšíření používat nějaký flexibilnější formát než JSON.

HTML5

Přednáška nazvaná „Praktické HTML5“ byla zklamáním pro všechny, co už o HTML5 něco vědí. V programu byla její úroveň označená jako 201 – tedy pro vývojáře, kteří už technologii znají. Kdo se však těšil na ukázky nějakých pokročilejších API vznikajících v souvislosti s HTML5, které dovolují psát offline aplikace, zasílat zprávy, používat obdobu vláken, ukládat lokálně data, …, byl zklamán. Jeremy Orlow toho neukázal o mnoho víc než během keynote. Takže jsme například viděli, jak se v HTML5 pouští video, jak funguje 2D a 3D canvas a že je možné soubor do stránky přetáhnout myší. Čtení dat z gyroskopu a zobrazování textu v neustále vodorovné poloze bylo jistě efektní, nicméně můj ThinkPad tohle uměl už před sedmi lety. Vůbec celá prezentace byla zaměřena hlavně na věci, které jsou vidět a jsou většinou efektní – dočkali jsme se tak i ukázek SVG, CSS, animací a transformací.

Trošku mě dráždilo, že přednášející se moc nesnažil rozlišit, co z prezentovaných věcí je součást návrhu HTML5 a má širokou podporu, co je jen poměrně kontroverzní návrh, který se Google rozhodlo již implementovat a co je věc čistě specifická pro Chrome, resp. jeho jádro WebKit. Nepředpokládám, že by si snad někdo v sále myslel, že objekt window.webkitNotifications je součástí HTML5. Ale u jiných prezentovaných technologií, jako jsou mikrodata, bych si již tak jistý nebyl.

Mohli bychom nad tím samozřejmě mávnout rukou, ale bohužel v historii webu se již několikrát stalo, že se příliš zpropagovala a začala používat nehotová a nedotažená technologie. Výrobci prohlížečů pak takovou technologii kvůli zpětné kompatibilitě musí udržovat, a plýtvají tak zbytečně zdroji, které by šlo napřít mnohem užitečnějším směrem.

Nakonec jsme se však s pár dalšími účastníky GDD shodli na tom, že odklon od „neviditelných technologií“ vzadu k věcem, co se hýbou, jsou barevné a jsou vidět, je vlastně logický. Google hlavně propaguje svoji platformu Chrome a to, co umí – ohánění se HTML5 jen vylepšuje image – používáme přece otevřené a standardizované technologie tak, jak se dnes sluší a patří.

Objemná data v mracích a jednooká vědma

Prezentace „Storage, Big Query, and Prediction APIs“ ukázala nabídku Google pro práci s velkými objemy dat v cloudu. Google Storage je služba, která umožňuje ukládat kusy dat na serverech v cloudu. Data pak lze rychle načítat po celém světě, protože se automaticky replikují do několika datových center. Osobně jako nejdůležitější plus této služby vnímám silnou inspiraci úložištěm Amazon S3 – používá se stejný model a API. Nástroje od Google umějí pracovat s oběma úložišti a časem se tak snad podaří dotáhnout i myšlenku zmíněnou během keynote – z cloudových služeb se stane standardizovaná komodita do té míry, že půjde data i aplikace bezproblémově přesouvat mezi různými poskytovateli těchto služeb.

Problém služeb jako Google Storage a Amazon S3 je v tom, že nabízejí jen primitivní úložiště klíč/hodnota pro vaše kusy dat, které lze případně doplnit o metadata. Ale zdaleka nenabízí komfort a možnosti relačních databází pro dotazování. Jakýmsi kompromisem je tak služba BigQuery. Ta umožňuje definovat schéma dat uložených v Google Storage v jednoduchém CSV formátu a následně s těmito daty pracovat jako s relační tabulkou a provádět nad ní jednoduché SQL dotazy. Lze používat jen omezenou podmnožinu SQL, ale deklarovanou výhodou je možnost pracovat s opravdu velkými objemy dat.

Prediction API je pak pokusem přiblížit umělou inteligenci běžnému vývojáři. Je to jednoduché rozhraní pro strojové učení. V tuto chvíli až příliš jednoduché – samotná funkčnost je velmi primitivní a navíc chování systému nelze upravovat. Prediction API lze použít jen jako jednoduchý klasifikátor nebo regresní model pro textové či číselné hodnoty. Ve zkratce nejprve musíme Googlu poskytnout trénovací data, která ukazují jaké hodnoty výsledků pro jednotlivé vstupy očekáváme. Po této zaučovací fázi pak stačí posílat vzorky dat a zpět dostaneme předpovězenou hodnotu.

Osobně jsem podle názvu rozhraní očekával něco více než funkčnost, která se studentům předmětů strojového učení ukazuje na prvním cvičení. Na druhou stranu je pravda, že vybrat správnou metodu strojového učení není úplně jednoduché a pro jednoduché aplikace jako klasifikace spamu, určení jazyka dokumentu apod. může Prediction API odvést dobrou službu. Jen by mne zajímalo, co vše Google dělá s daty, která přes Prediction API protečou.

Pozdní odpoledne

Hlavně kvůli Jardovi Benglovi jsem se chtěl jít podívat na „Novinky v oblasti Google Geo“, ale přestávková diskuse mne o pár minut zdržela, a to byla chyba. U dveří bylo plno a zrovna jsem neměl náladu volat „postupte si dále do vozu“, když už přednáška začala.

Chtěl jsem si pak spravit chuť a myslel jsem si, že se dozvím něco nového na další „dvěstějedničkové“ přednášce – „Ověřování na celosvětové síti“. Nicméně když i po deseti minutách zůstával přednášející u výkladu principů fungování OpenID, vzdal jsem to a šel jsem na kafe.

JSON-mánie

Nemám nic proti JSONu, pokud se používá tam, kde se to hodí. Nemám nic ani proti RESTovému API, které komunikuje pomocí JSONu, pokud nabízí i XML verzi. Na GDD šlo však snadno nabýt dojmu, že Google se téměř bezhlavě orientuje na JSON a zcela ignoruje stav okolních věcí.

Zapisovat manifest rozšíření pro prohlížeč v JSONu, tak jak to dělá Chrome ( manifest.json), mi přijde ještě tak na hranici. Sice nechápu, proč nepoužívají XML jako konkurence. Ostatně sama rozšíření nejsou tolik odlišná od Widgets a ty mají svůj manifest rovněž v XML. Pro jednoduchý manifest je JSON sice o pár znaků kratší, ale až si tam přidají pár parametrů navíc, už to zdaleka tak přehledné jako XML nebude. Ale budiž, je to jejich volba.

Ovšem k zcela fatálnímu nepochopení došlo na konci prezentace Prediction API. Toto rozhraní je dostupné přes REST a všechny ukázky používaly JSON. Ptal jsem se, zda lze komunikovat i přes XML. Přednášející se nechápavě ptal, proč by mělo existovat i XML API, když na tak jednoduchou věc JSON přece stačí. Nebyl prostor, takže odpovím zde. Protože během posledních deseti let se investovaly obrovské prostředky do toho, aby mnoho veřejných i vnitropodnikových služeb a rozhraní bylo dostupných v XML. Všichni na to mají odladěné nástroje, takže proč by něco měli měnit jen proto, že Google je líný napsat 20 řádek kódu a mít i XML variantu API. Nebo Google čeká, že je tak velký, že se mu ostatní přizpůsobí? To už jsme tu jednou měli – ne, děkuji nechci.

onUnload

Organizačně nelze GDD nic moc vytknout, byla to povedená akce. Nicméně z obsahového hlediska jsem očekával trochu více – přece jen je vidět, že Google se zaměřuje na stále širší masu vývojářů a uživatelů jeho technologií, takže logicky i jednotlivé prezentace nejdou tak do hloubky jako v předchozích letech. Nicméně pro ty, co nemají čas instantně sledovat nové technologie Google, je GDD velice příjemnou a efektivní jednodenní nalévárnou.

Pokud jste na GDD nebyli, nemusíte zoufat, záznamy přednášek jsou již na na YouTube. Jenom si tam nedáte ty výborné lívance, co byly na konec.

Komentáře

Subscribe
Upozornit na
guest
31 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
BoB2176

Kdyby všichni přemýšleli stylem „takhle to fungovalo vždycky, takže proč děláte změnu“, tak by lidstvo nikam nepokročilo. Chcete používat Prediction API? OK, můžete, komunikujeme RESTFul a JSON. Nechcete? Nemusíte…

pribinacik

Nerozumiem uplne autorovemu zapaleniu pre XML, komunikacia cez XML je ciste plytvanie. Snad nebudeme pouziva do konca sveta XML, pretoze si napisal a odladil nejake nastroje… a este podotknem, ze aj JSON sa da samozrejme zobrazit prehladne, rovnako ako XML sa da dat cele do jedneho riadku, takze ten argument, ze je to neprehladne neberiem.

Radek

Přehlednost asi není úplně to, oč tu běží. Dokonce ani to, jestli se přenáší o pár bajtů víc. U služby, která bude pracovat pravděpodobně s většími objemy dat je celkem jedno, jestli ta data obalíte několika tagy, nebo je jen ozávorkujete. Autor ale v článku zmiňuje jiné důvody, které stojí za zamyšlení – např. integrace s existujícími systémy, knihovnami a nástroji.

BoB2176

Právě s velkými objemy dat je úspornější notace výhodou. Je celkem rozdíl, jestli se například 100 MiB hrubých dat posílá jako 200 MiB zakódováno v JSON nebo jako 500 MiB zakódováno pomocí XML (čísla jsou vymyšlená, jde jen o princip).
Kdyby služba poskytovala rozhraní SOAP, tak použiju SOAP. Když poskytuje RESTful+JSON, tak použiju RESTful+JSON.
Jak jsem psal výše – nechci, nemusím…

BoB2176

V tom úplně teoreticky nejhorším případě XML bude maximálně 2x větší než JSON.

S tím si dovolím nesouhlasit. Rozdíl může být výrazně vyšší.
JSON 33B:
[{"data":"tes­t"},{"data":"tes­t"}]

XML 104B:
<?xml version="1.0"?><a­rray><object><da­ta>test</data></ob­ject><object><da­ta>test</data></ob­ject></array>

Čím menší je „jednotka dat“, tím je výraznější úspora JSONu proti XML.

BoB2176

A abych dal trochu „větší“ čísla. Obdobný příklad jako výše, data jsou vždy číslo 0,1,2,…,255,0,1 – celkem 1MiB hrubých dat.
Hrubá data: 1 048 576 B
JSON: 13 265 495 B
XML: 34 237 050 B – tj. 2,58násobek JSONu

Po ZIPu
Hrubá data: 4 503 B
JSON: 155 880 B
XML: 388 670 B – tj. 2,49násobek JSONu

pssp

<a><o data=’test’/><o data=’test’/>

39 znakov. Zalezi len na tom ako si to zapisete.

pssp

redakcny system mi odstrihol < / a > (bez medzier) na konci

Pavel Kroh

Je ovšem otázka jestli má to XML vypadat právě takhle, pokud zrovna nepřenášíte obecné serializované objekty (což asi typická API nedělají) tak se v XML použije lépe čitelný a kontrolovatelný sémantický zápis. Na druhé straně totiž zrovna nemusí být javascript… ne každá novinka ja automaticky „pokrok“.

imploder

Taky jsem to nepochopil. Co je na JSONu tak špatného? Je to taky standardní formát, podobně jako XML. A je úspornější a v javascriptu se nemusí parsovat.

imploder

To mi nepřipadá jako zásadní problém. JSON parser existuje skoro pro každý jazyk a v případě potřeby se to dá na XML převést. Ale je vždycky dobré mít na výběr. Asi se jim to prostě nechce dělat a myslí si, že to takhle stačí. Přitom by si v Googlu IMHO mohli vyrobit obecné API, které by jako vstup přijímalo JSON i XML (bez toho, aby ty 2 verze vytvářeli každou zvlášť).

Martin Soušek

Na různé vývojářské konference chodím už nějaký ten pátek a Googlí představení Chrome s HTML5 mi silně připomnělo jakýsi zapomenutý Microsoft Day (či jak se to tehdy jmenovalo), kde představili bombu!

Dynamic HTML v Internet Exploreru 4! Všem nám spadla čelist, když jsme tehdy viděli ukázky. Například šlo javascriptem hýbat s absolutně pozicovanými elementy! Nebo měnit jejich barvu a velikost. Neuvěřitelné!

Je mi špatně z toho, jak se historie opakuje a jak potřebujeme super moderní žravé počítače, abychom získali stejné výsledky, jaké už jsme měli před 20 lety mimo prohlížeč. Přitom vývojářské nástroje pro RIA v HTML5 velká nula a pokud ji uděláme rovnou v GWT, tak už můžeme použít rovnou Flex. Pro uživatele je to stejně jedno.

Jirka Vejrazka

To bylo tenkrat v Edenu, ze? Taky si vzpominam, jak jsem si musel sbirat celist ze zeme :) Ach ta historie, my co ci pamatujeme jak panacek Java poprve zamaval v Netscape 2.0… :)

backup

to, ze se historie opakuje je bezne v lidske spolecnosti. Dobre je to videt na architekture. Slohy jako, empir, rokoko, seceese a podobne take jen prihazovaly jiny dekor na stavajici stavby. Lide jsou povrchni a chteli to.

Az kdyz vyvoj dosel tak daleko, ze existovaly technicke moznosti – sklo, ocel beton, tak prisel novy styl – konstruktivismus s novou kvalitou.

Tedy zadny duvod ke skepsi, vse bezi ve znamych kolejich.

tomáš j. kouba

Dobrý den,

představa, že svět se zefektivňuje a zlepšuje je podle mého názoru naivní. V podstatě na tom nikdo nemá moc velký zájem.

jirina bohdalova

no jo kluku, ty uz ale nemas davno lamat stranky…to maj delat maly kluci v html5, ty jim mas sefovat, moudre pokyvovat hlavou nad jejich nadsenim pro technolgie a po ranni porade jet na golf

Štěpán Bechynský

Co se týče ukládání velkých objemů dat, tak Jirka zapomněl na Windows Azure Storage. Zde můžete ukládat nestrukturovaná data (podpora CDN) nebo strukturovaná data v noSQL databázi nebo vytvářet frontu zpráv. Kromě toho je k dispozici Azure SQL.

koubel

Native client má určitě využití i jinde než na hry, např. na různá vědecké vizualizační aplikace a obecně všude tam, kde je nějaká složitá Cčková zobrazovací/po­čítací knihovna. Není pak nutné zbytečně ji portovat do pomalého javascriptu, ale použije se native client. Podobnou věc má myslím i Flash platforma. Množství takových C/C++ knihoven bude určitě nemalé.

andrejk

na to je java s appletmi, na to nepotrebujete mat na severi skompilovane binarky v nativnom kode pre vsetkych stoosemdesiat roznych platforiem.

koubel

Pokud máte nějakou legacy složitou Cčkovou knihovnu na nějaké operace, které souvisí s vizualizací, tak je vám celá java na prd a její použití všechno jen zkomplikuje. Prostě si tu knihovnu přes native client použijete v browseru a máte hotovo.

Na nové věci to má smysl skutečně asi jen u těch her na všechno ostatní javascript, s javou jděte na klientské straně webu do háje, to je jasný trend dneška.

Martin Soušek

No s javou do háje. To bych tak netvrdil.

Android (neboli i Google TV) je vlastně Java. GWT (třeba rozhraní AdWords) je vlastně Java. Jen to jako Java na první pohled nevypadá, protože Sun zmolochovatěl a umřel. Ale Java jako jazyk žije.

shMoula

Diky za shrnuti, jak koukam, absolvoval jsem vicemene stejne prednasky s naprosto stejnymi pocity :-). Co se tyka JSONu – nepouziva se proto, ze je jednoduse pristupny (a hlavne jednoduse a rychle „parsovatelny“) v javascriptu? Jasne, ze do xml se investovaly nemale penize, ale prece je normalni, ze se veci stavaji obsolete (tim neminim, ze by se melo xml hned a okamzite zahodit a pouzivat pouze JSON, ale proste mi tato notace pro nektere veci prijde jednodussi a logictejsi).

shMoula

Asi bych mel nejprve cist diskuze, koukam, ze v tom nejsem sam :-)

backup

vim ze je autor specialista na XML a proto zna vsechny mozne nastroje a udelatka, jak XML zvladat. Bohuzel a v tom ma autor pravdu, nedokaze se klonovat a proto se nachazeji v praxi jini specialiste nez autor a tito lide nepohnuli XML ani o milimetr dal.

Znam dobre situaci v nakladatelskem sektoru a vim, jek se tam s tim lide trapi. V kazdem takovem vetsim nakladatelstvi maji nejakou vlastni XML normu, podle ktere to bude ‚v budoucnu‘ vsechno jednotne fungovat, ale skutecnost je takova, ze vsichni maji na stole MS-Word a to je ten standard.

Radek

MS Word už ale dnes ukládá dokumenty v XML :-)

iki

… jsou výborný nápad a tímto směrem se ubírají kromě chrome i opera 11 beta, safari 5 a firefoxí jetpack.

Navíc možná svitne i standardizaci mezi prohlížeči:
http://news.cnet.com/8301-30685_3-20019579-264.html

Michal Augustýn

Huh, on měl David Grudl vstup během keynote? Jsem nějak nezaznamenal :)
Jinak pěkné shrnutí a s celkovým dojmem musím souhlasit – informační entropie byla poněkud nižší :-)

Kepi

Ač jsem byl kdysi velkým obdivovatelem XML, napadlo mě díky čtení tohoto článku, že minimálně za mě se sluší poděkovat i Google za to, že podporuje rozumné formáty jako JSON.

I když souhlasím, že je mnohem lepší, poskytnout pro API více možností a kromě JSONu přidat i XML, vstávají mi vlasy hrůzou když zaslechnu, že v manifestu rozšíření by bylo lepší použít XML.

XML je jazyk pro stroj, nikdy pro člověka (ač jsem tomu kdysi věřil). Jako programátor jsem nadšený, že se objevilo něco tak jednoduchého jako je JSON a že se konečně nemusím orientovat v takovém balastu (i když třeba yaml je pro konfiguráky ještě hezčí, i když ne tak flexibilní).

Jednoduše dle mě je ideální používat vhodné formáty pro vhodné příležitosti a XML se bohužel snažilo dostat úplně všude. Pro stroje ano, pro lidi ne…

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.