Michael Mahemoff: Vytvářet software se nenaučíte jen čtením knížek (rozhovor)

Michael Mahemoff pracuje v Googlu jako Chrome Developer Advocate. Řadu let píše pro Ajaxian a v roce 2006 napsal knihu Ajax Design Patterns. Je autorem užitečných nástrojů, např. ListOfTweets.com a také vtipného projeku IE6IsOlderThanYourGrandpa.com. Bloguje na Softwareas.com a tweetuje jako @mahemoff.

You can switch to English version.

Píšeš pro Ajaxian už pět let, takže detailně sleduješ dění v tomto oboru. Co považuješ za největší změny ve světě JavaScriptu a AJAXu za posledních pět let?

Byla tu hromada inkrementálních změn, prohlubovalo se například naše chápání JavaScriptu a objevovaly se knihovny a nástroje jako jQuery a Firebug, které vývojářům usnadňovaly život. Dalším přínosem bylo výrazné zlepšení výkonu. Ovšem tu zásadní post-ajaxovou změnu můžete vidět poslední dobou na nových schopnostech prohlížečů, tj. HTML5, CSS3 a příbuzných technologiích jako je třeba geolokace (které pro zjednodušení společně všechny označuji jako "HTML5"). Dříve nebylo možné pracovat s videem nebo pokročilou grafikou bez ohledu na to, jak dobří jste byli v JavaScriptu. Museli jste se uchýlit k používání pluginů, hacků a obezliček, abyste dosáhli schopností vyžadovaných u moderních aplikací. Dnes pro řadu z těchto schopností existují vyhrazená API definovaná jako otevřené standardy. Oproti předchozím technikám jsou obvykle rychlejší, bezpečnější a snazší pro vývojáře.

Michael přednáší na JSConf 2010 (Zdroj: Flickr)

Spolu se softwarovým inženýrstvím jsi studoval také psychologii. Jak jdou tyhle obory dohromady?

V řadě věcí. Tím obvyklým průnikem a fascinujícím tématem byla vždy umělá inteligence. Ovšem v minulých desetiletích se z převážně akademických vod vynořila User Experience a stala se klíčovým podoborem moderního softwarového vývoje. Všimněte si, že recenzenti dnes mezi faktory zařazují i uživatelskou přívětivost; lidé očekávají, že produkty budou intuitivní. Toho lze dosáhnout pouze s pochopením lidské psychologie, což znamená víc, než jen spekulování; psychologie je obor postavený na faktech.

Napsal jsi knihu Ajax Design Pattern, jak ses od blogování a programování dostal k napsání knihy?

Kniha vznikla na základě mého blogpostu na stejné téma. Bylo to krátce po té, co vznikl termín Ajax. Lidé byli nadšení, můj text zabodoval na těch správných webech (Delicious Popular apod.) a z O'Reilly mě požádali, abych o tom napsal knihu. Pokračoval jsem současně v blogování ukázek a v psaní textu knihy na wiki.

Pokud budu někdy psát další knihu, nejspíš se vyhnu používání wiki a budu se víc soustředit na blog, nebo aspoň na wiki s komentáři. Je to lepší, když žádáte o zpětnou vazbu. Lidé se totiž jen zřídka pouští do úprav dlouhých článků, které napsal jeden člověk. (A když už to učiní, jedná se v polovině případů o spam!)

Michael přednáší na JSConf 2010 (Zdroj: Flickr)

Nějakou dobu jsi se věnoval TiddlyWiki. To je poměrně kuriózní projekt. Co se ti na něm líbí? (Pozn.: TiddlyWiki je wiki distribuovaná jako jeden jediný HTML soubor.)

Pracoval jsem s TiddlyWiki v Osmosoftu, což je inovační skupina v BT, kterou vede tvůrce TiddlyWiki Jeremy Ruston. Ovšem o kód TiddlyWiki jsem se zajímal už dřív, když jsem psal Ajax Design Patterns. Rozhodně se nejedná o typický projekt. Rád jsem tehdy žertoval, že jako jeden z mála lidí na světě jsem placen, abych vytvářel webové aplikace běžící na protokolu "file:".

TiddlyWiki je v jádru tvořena jedním jediným souborem, který obsahuje veškerý kód HTML, kaskádové styly i JavaScript. To byla samo o sobě už tehdy inovativní myšlenka, ovšem co ji dělá stále výjimečnou je schopnost uložení aplikace na lokální disk bez použití rozšíření prohlížečů i bez offline storage API z HTML5. Je to možné pomocí Active X v IE, nativního API ve Firefoxu a v ostatních prohlížečích pomocí appletu v druhém souboru. Můžete tak snadno vytvářet perzistentní webové aplikace a dokonce i "guerilové" víceuživatelské aplikace pouhým umístěním HTML na sdílený disk.

Další cool vlastností je systém pluginů. Zatímco TiddlyWiky ve výchozím stavu slouží jako osobní wiki, můžete z ní snadno vytvořit blog, prezentaci nebo cokoliv jiného. Nahrál jsem screencast popisující, jak během 15 minut vytvořit fórum. Používám k tomu TiddlyWeb, protože se jedná o fórum hostované na serveru, ačkoliv bylo vyvinuto na protokolu "file:".

S Michaelem Mahemoffem se můžete osobně potkat 15. listopadu na hackathonu, den před GDD. (Na akci se navíc uvidíte celý den i se mnou, protože jsem mezi organizátory 8-)

Zajímá vás HTML5? Sestavte vývojářský tým a zkuste za 1 den naprogramovat užitečnou aplikaci. My vám k tomu dáme: prostor, občerstvení, připojení k internetu a podporu několika Googlích vývojářů v průběhu dne.

Serverovou část aplikace můžete vytvořit ve vašem oblíbeném jazyce. Klientská část musí využívat některých možností HTML5.

Pokud HTML5 zatím pořádně neovládáte, nezoufejte, pro přehled si projděte prezentaci na HTML5Rocs. Na místě budou vývojáři z Googlu (včetně Michaela), kteří vám budou celý den k dispozici a poradí vám.

Zaregistrujte se, těšíme se na vás.

Další informace najdete na Facebooku nebo Twitteru.

Hackathon pořádá GUG.cz v partnerství s Google, czu.gug.cz a Provozně ekonomickou fakultou ČZU.

Máš rád hackathony. Co považuješ za největší přínos hackathonů?

Některé hackathony jsem si zamiloval. Vytváření software má jako disciplína své silné i slabé stránky. A tou opravdu silnou stránkou je možnost vytvoření něčeho naprosto úžasného během jednoho jediného dne. Samozřejmě, řada lidí na hackathonech něco až tak dobrého nevytvoří, ale i tak aspoň něco vytváří a tím se hodně naučí.

Hackathony jsou oslavou toho úžasného, co se děje, když začneme den se zárodkem malého nápadu a skončíme ho předvedením hotového díla ostatním. A obsahuje i sociální přínos - navázání nových známostí, možnost pracovat s ostatními a učit se od sebe navzájem. A to v takové míře, jak účastníci chtějí. Někteří radši pracují samostatně - i to je v pořádku.

Navíc vytvářet software se nenaučíte jen čtením knížek nebo posloucháním. Můžeme se dohadovat, proč tomu tak je, ovšem většina vývojářů se shodne na tom, že k pochopení základů si musíte vyhrnout rukávy a pustit se do vlastního kódování. Hackathony jsou k tomu ideální prostředí, je to takové bezpečné místo, kde váš výstup není nijak kritický a máte řadu možností, jak vám může někdo poradit a poskytnout zpětnou vazbu.

Jaký byl ten nejdelší hackathon, kterého ses účastnil?

V BT jsme praktikovali agilní přístup a akce intenzivně probíhaly po tři dny. Snažili jsme se dát dohromady všechny investory projektu a získat pozornost uživatelů, takže jsme s nimi mohli pracovat a žádat je o testování vznikajícího díla. Ujasnili jsme si naše nápady a naplánovali další iteraci.

Nebylo to perfektní. Měl jsem občas pocit, že pro správnou vyváženost potřebujeme víc vývojářů, abychom mohli dělat akce, které se soustředí na tvorbu skutečných projektů a jejich prezentování na konci každého dne.

Někteří říkali, že tohle je způsob, jakým má software vznikat dennodenně - nemá se jednat o občasný velký třesk. Ovšem já myslím, že ve velkých mnohonárodních korporacích jsou akce typu "velký třesk" tím nejlepším realizovatelným způsobem. Většina z těchto akcí měla pro firmu opravdu přínos.

Takže v Osmosoftu jste pořádali firemní hackathony? Proč by měly firmy pořádat své vlastní hackathony?

Ano, byly velice efektivní a nakonec jsme je pořádali asi jednou měsíčně. Mám na to pěkné vzpomínky. Osmosoft měl řadu interních zákazníků a externích partnerů. Ráno jsme se sešli se zákazníkem - obvykle jich přišlo několik. Dohodli jsme se na uživatelských scénářích, jejich prioritách a začli jsme s hackováním. Obvykle tak hodina až dvě sprintu. Začínali jsme v 10 dopoledne a výsledek práce prezentovali v 7 večer. Mezitím byly sprinty, standup meetingy k synchronizování a naplánování dalšího sprintu. Pokud to šlo, po celou dobu jsme checkovali do GitHubu nebo podobného repozitáře a tweetovali jsme o celé akci. V plánu bylo nejen odprezentovat naši práci, ale také veřejně spustit vytvořenou webovou aplikaci (to se však často nepovedlo).

Musím zdůraznit dva důležité body. Za prvé, náš postup byl velmi rychlý, což naše zákazníky většinou překvapilo. Důvodem byl náš důraz na znovupoužívání - každý projekt byl nejen příležitostí pro vytvoření nové aplikace, ale současně také vytvoření série komponent, které jsme mohli použít v dalších projektech. Nešlo nám o velké enteprise vize, ale o vytvoření padesátiřádkového pluginu pro TiddlyWiki, který dělal něco užitečného. Mohl to být plugin pro komentáře, grafický editor nebo počítadlo slov.

Za druhé, otevřenost může být v kontextu společnosti tvořící nový produkt překvapující. Mohli jsme si to dovolit protože jsem stavěli framework na bázi pluginů. Osmosoft mohl jako tvůrce open source vytvářet open source komponenty a s tím i aplikaci, která z velké části na těchto komponentách stála. BT si ji mohla upravit pro své vlastní potřeby a stejně tak jakýkoliv jiný podnik (např. naši externí partneři). My jsme byli součástí BT a tak jsme jim nabízeli přímou podporu k úpravě aplikací. Ale ukázali jsme, že open source může i v případě velké společnosti fungovat a předvedli jsme přínosy hackathonů.

Letos na jaře jsi začal pracovat pro Google jako Chrome Developer Advocate. Jak ses k té práci dostal? Byl to tvůj nápad nebo tě Google oslovil?

Byl jsem osloven jednou osobou z Googlu a pak jsem už prošel klasickým přijímacím procesem.

Chrome podporuje rozšíření, podobně jako řada dalších prohlížečů. Ovšem každý prohlížeč obsahuje jinou implementaci. Nemělo by se rozhraní sjednotit, aby bylo možné jednou napsat rozšíření a spouštět je pak všude?

Obvykle se říká write once, run many, což je velkou výhodou samotného vývoje pro web. Stinnou stránkou je, že tím můžete předčasně zabrzdit inovační proces. Takový mechanismus rozšíření Firefoxu umožnil úžasné věci - třeba takový Firebug, ovšem pro běžného vývojáře je těžké v něm začít tvořit - zbyl tu prostor pro další zlepšování, bylo příliš brzo na standardizaci.

Dnes má Chrome pro rozšíření mechanismus, který je webovým vývojářům blízký, Mozilla má JetPack a Safari s Operou také podporují rozšíření. Doufejme, že lidé začnou kreslit Vennovy diagramy a hledat, co mají jednotlivé mechanismy společného. Ovšem jen v případě, že to nezastaví prohlížeče v dalších inovacích. Chrome třeba nedávno nabídl rozšířením možnost přidat se do kontextové nabídky; něco takového by nemělo být blokované standardizačním procesem.

Na kolika Google Developer Days přednášíš?

Přednášet budu na třech evropských GDD (v Mnichově, Moskvě a Praze), na každém budu mít dvě session: Google Chrome Extensions a HTML or Native for Mobile Development. Na té druhé budu společně s Android advokátem Retem Meierem.

Už jsi byl někdy v Praze nebo je to tvoje první návštěva? Na co se nejvíc těšíš?

V Praze jsem zatím ještě nebyl. Nejdůležitější je pro mě GUG akce před GDD. Česká republika má silnou vývojářskou komunitu, těším se na setkání s místními vývojáři a na to, s čím přijdou.

Děkuji za rozhovor

Otázky kladl Martin Hassman, odpovídal Michael Mahemoff.

A pokud vás myšlenka hackathonů zaujala, neváhejte a zaregistujte se na náš hackathon, který pořádáme 15. listopadu v Praze.

Michael Mahemoff: You can't just learn by reading or listening (interview)

Michael Mahemoff works for Google as Chrome Developer Advocate. He has been writing for Ajaxian for many years and wrote Ajax Design Patterns for O'Reilly in 2006. He is the author of useful tools such as ListOfTweets.com and also a funny project, IE6IsOlderThanYourGrandpa.com . He blogs at Softwareas.com and tweets as @mahemoff.

Můžete si přečíst český překlad. There is Czech translation available.

You have been writing for Ajaxian five years already, so you watch this field very closely. What were the most important changes in JavaScript-and-AJAX-World during last five years from your point of view?

There have been plenty of incremental changes, like our understanding of JavaScript getting more sophisticated and the introduction of libraries and tools like jQuery and Firebug to make life easier for developers. We've also benefited from massive performance improvement. But I think the most disruptive change, post-Ajax, is what we've seen recently with the new capabilities of browsers, i.e., HTML5, CSS3, and related technologies such as Geolocation (all of which I collectively refer to as "HTML5" for the sake of convenience). No matter how fluent we became with JavaScript and the like, it was still not possible to do things like video and rich graphics. To achieve the kind of capabilities modern apps required, we had to resort to browser plugins, hacks, and workarounds. Now with HTML5, we have dedicated APIs for many of these capabilities, defined as open standards. Compared to the previous techniques, they are based on open standards and they are typically faster, more secure, more powerful, and easier for developers to work with.

Michael speaking at JSConf 2010 (from Flicker)

You studied Psychology in addition to Software Engineering. How do these subjects go together?

In many ways. Artificial intelligence has always been the obvious intersection and remains a fascinating topic. But over the past couple of decades, User Experience, has come to the fore and emerged from a rather academic niche into a key sub-discipline of modern software development. You see product reviews now which include User-Friendliness as a factor; people expect products to be intuitive. You can only do that with an appreciation of human psychology, which means more than just speculation; psychology is an evidence-based discipline.

You wrote book Ajax Design Pattern. How you got to writing book from blogging and programming?

The book was the product of a blog post on the same topic, where I got inspired to collect ideas after seeing the Ajax term coined. People got excited, it hit a few of the right sites (Delicious Popular, etc.), and O'Reilly approached me about writing a book. I continued blogging excerpts as well as writing the entire book on a wiki. If I write another book, I would probably avoid the wiki approach and concentrate more effort on the blog, or at least a wiki with comments. It's a better way to solicit community feedback as people will rarely make edits to a long article that is mostly one man's voice. (And when they do, it's spam half the time!)

Michael speaking at JSConf 2010 (from Flicker)

You spent some time working with TiddlyWiki. It is a little bit strange project,isn't it? What do you like on it?

Yes, I worked on TiddlyWiki at Osmosoft, an innovation group inside BT which is run by TiddlyWiki creator, Jeremy Ruston, though I actually pored into the code much earlier, when I was writing Ajax Design Patterns. It's definitely different - I like to joke I'm one of the few people in the world who got paid to make web apps that run off a "file" URI. TiddlyWiki, at its heart, is a Single Page App - it contains all HTML, CSS, and JavaScript in a single file. This alone was innovative when it was first created, but what really makes it stand apart is its ability to save to the local hard drive, without any browser extensions and without using HTML5 offline storage APIs. It's possible using ActiveX on IE, native Mozilla APIs on Firefox, and resorting to a second applet file on other browsers, and it means people can easily build persistent web apps and even make "guerilla" multi-user apps just by sticking an HTML file on a share drive. The other cool thing is the plugin system. While TiddlyWiki is by default a personal wiki, you can quickly turn it into a blog, slideshow, or anything else. I recorded a screencast showing how to build a forum in 15 minutes. It also uses TiddlyWeb, so the forum is actually fully hosted on a server, even though its developed on a file URI.

You can meet Michael Mahemoff on HTML5 hackathon, on 15th November in Prague, register please (Google Translate).

You like hackathons. What do you see as the biggest benefit of hackathons?

Loves me some hackathon. As a discipline, software has strengths and weaknesses, and a major strength is that you can produce something completely awesome in a single day. Or of course, many people won't do exactly that, but they'll still build something and learn a lot in the process. So hackathons are a celebration of this amazing thing we do, where we can start the day with a seed of an idea and end up with a concrete manifestation of the idea. It's going with the flow, fitting in with the nature of software development. There's also a social aspect as well, people making connections, working with each other, learning from each other. And it can be as much or as little as the attendees want - some prefer flying solo, and that's fine too. Something else about software is that you can't just learn by reading or listening. We can debate the reasons, but most developers would agree you can only grasp the concepts by rolling up your sleeves and hacking out real code. Hackathons are an ideal environment to do that, a safe place where the output is not critical and there are plenty of opportunities to get feedback and assistance.

What was the longest hackathon you participated in?

At BT, we had an agile hothouse concept where the events went for three intense days.The idea was to pull together all the project stakeholders and put real users at the centre of attention, so we could work with them and ask them to test our emerging work. We could spike ideas and come out with a plan for the next iteration. It wasn't perfect. I felt like we sometimes needed more coders to get the balance right, in an event that was heavily oriented around building real products and presenting them at the end of each day. Some also argued that it's how software should work every day, not just an occasional big bang, but I think in a complex multinational corporation, such "big bang" events are the best thing realistically. I felt the principle was sound and found most of these events to be good value for the company.

So in Osmosoft there were hackathons inside the company? Why should companies try out their own hackathons?

Yes, they were incredibly effective and we ended up running them about one a month, as Osmosoft had a wide range of internal customers and external partners. Fond memories! We'd meet the customer in the morning, usually several of them present. We'd agree on user stories and prioritise them, and then we'd get hacking. Typically an hour or two per sprint, running from 10am and presenting our work at 7pm. Between sprints, a standup meeting to sync up and plan the next sprint. Ideally, we'd be checking into GitHub or similar repo the whole time, and tweeting the event. The ultimate plan was to not only present our work, but also host the resulting web app publicly by end of play (not that it always happened in practice).

There are two important points here. Firstly, we could move very quickly, in a way that often surprised our customer. The reason was our emphasis on reuse - every new project was an opportunity to build not just a new app, but a series of components that could be used on other projects. Not grand enterprisey whitepaper visions, but a 50-line TiddlyWiki plugin that actually does something useful, today. It could be a comments plugin, a graphical editor, or a word counter. Secondly, the openness may be striking in the context of a company building new products. We could do this because we were building a plugin-based framework. Osmosoft, as an open source provider, would make the open source components and an app which is mostly just a composition of those components. BT could then come along and customise it to their own needs, just as any other enterprise (such as our external partners) could pick it up and use it too. Of course, in practice, we were part of BT and we would offer them direct support in customising and deploying the apps. But we showed open source can work for a big company, and we showed the benefits of a hackathon.

You started working for Google in spring this year as a Chrome Developer Advocate. How do you got this job? Was it your idea or have you been asked by Google?

I was invited to apply for the role by someone in Google and I then went through a standard interview process.

Chrome has support for extensions as many other browsers today. But every browser has different implementation. Doesn't make sense to create some cross-browser interface for browser extensions? To make possible for developers to write extension once and run everywhere?

The obvious upside is write once, run many; which is a huge benefit of web development in general. The downside is the risk of stifling innovation too early. While Firefox's extension mechanism has led to wonderful things like Firebug, it's also been difficult for everyday web developers to jump into and left opportunities for improvement, so it was too early to standardise on something like that. Now that Chrome has an extension framework that's easy for web developers to pick up and use, and Mozilla has JetPack, and Safari and Opera also have extension mechanisms, hopefully people will start to draw Venn diagrams and work out where we have common ground. But only if it doesn't stop browsers from continuing to innovate in this area. Chrome has recently introduced the ability for extension commands to appear in the context menu; that's one example of the kind of ongoing improvement that shouldn't be hindered by a standardisation process.

How many GDD do you visit this year as a speaker?

I will speak at the three European GDDs (Munich, Moscow, Prague), in two sessions at each: Google Chrome Extensions and HTML or Native for Mobile Development. The latter will be me alongside Android advocate Reto Meier, so it should be a lot of fun.

Have you ever been to Prague or is it your first visit? What are you most looking for?

I've not been to Prague, but looking forward to it. The best thing for me will be the pre-GDD GTUG event. Czech Republic clearly has a strong web development community, so I'm looking forward to meeting the local developers and seeing what they come up with.

Martin Hassman was interviewing Michael Mahemoff before his visit to Prague.

If you want to meet Michael at hackathon on 15th November, please register.

Jak funguje geolokace ve Firefoxu - detailní (až vyčerpávající) popis

Často narážím na otázky týkající se geolokace ve webových prohlížečích. Lidé jsou někdy zmateni jejími výsledky. Např. přemýšlí, proč jim jeden počítač vrací jiné údaje než jejich druhý počítač v té samé místnosti apod.

Vysvětlím podrobně, jak funguje geolokace ve Firefoxu. Snad si pak dokážete na vaše otázky odpovědět. Budu se zabývat pouze Firefoxem - ostatní prohlížeče jsem zatím podrobně nezkoumal, ale část zmíněného může být jistě aplikována i na ně.

Pokud chcete komplexní pohled na problematiku, podívejte se na mou přednášku S geolokací by se neztratili ani Jeníček a Mařenka.

Začněme s javascriptovým kódem pro geolokaci

Použít geolokaci na webové stránce je celkem snadné. Stačí na to volání jedné funkce, a sice: navigator.geolocation.getCurrentPosition (viz připravovaný standard W3C).

A pro vyzkoušení: plný funkční příklad (všimněte si panelu hned nahoře, který musíte potvrdit).

Takhle to vypadá snadné. Pojďme se ale podívat, co přesně se odehraje od doby, kdy povolíte vašemu prohlížeči zjištění polohy až do získání výsledných souřadnic. Sami byste si pak měli být schopni odpovědět na otázky typu proč někdy Firefox vrátí polohu přesně (s rozptylem 150 metrů) a jindy ulítne a má rozptyl mnoha kilometrů.

Krok 1. Zjištění geolokačních údajů

Pokud má prohlížeč určit vaši polohu, musí shromáždit údaje potřebné ke geolokaci. Takových údajů je několik. Co je dostupné snad vždy, je vaše IP adresa (resp. veřejná IP brány přes kterou se připojujete k internetu). Srovnáním IP adresy s příslušnou databází je možné odhadnout vaši polohu. Jedná se o geolokační údaj s nejhorší přesností (rozptyl jednotky, desítky, někdy i stovky kilometrů - má pražská IP adresa je lokalizována do centra Prahy s rozptylem 140 km).

Ale lepší něco než nic. S IP adresou téměř vždy určíte správně zemi uživatele, v lepším případě i město, ve kterém se uživatel nachází. (Má to své mouchy. Pokud je např. uživatel z města A připojen k internetu přes VPN v městě B, pak je tímto způsobem jako jeho poloha určeno město B.) Jelikož jakákoliv metoda je lepší než geolokace pomocí IP adresy, použije se IP adresa jen v případě, kdy nic jiného není k dispozici. Jinak se ignoruje.

Má váš počítač Wi-Fi? Pak může být vaše poloha určena mnohem přesněji. Je-li Wi-Fi na vašem počítači zapnutá, načte Firefox všechny přípojné body, které právě vidíte (jejich jména, MAC adresy a sílu signálu) a použije jich k geolokaci (využívá se k tomu celosvětová databáze Wi-Fi přípojných bodů).

Tím možnosti desktopového Firefoxu končí. U mobilních prohlížečů navíc připadá v úvahu ještě využití BTS ve vašem okolí (to funguje na stejném principu jako u Wi-Fi s tím rozdílem, že signál BTS dosáhne dál, tudíž geolokace pomocí BTS bude méně přesná než geolokace pomocí Wi-Fi). A konečně tu je možnost využití GPS zabudované v telefonu.

My počítáme s desktopovým Firefoxem, tudíž známe jen IP adresu a Wi-Fi v okolí.

Krok 2. Dotazujeme se geolokační služby Googlu

Naznačil jsem, že samotná znalost IP adresy ani Wi-Fi bodů nestačí, je potřeba je porovnat s databází, která obsahuje polohu všech (resp. ne všech, ale dostatečného množství) IP adres a Wi-Fi bodů.

Firefox k tomu používá databázi Googlu. (Takových databází je řada, ale Google má asi jednu z největších = nejlepších.) Google sestavil Geolocation API Network Protocol, pomocí kterého může Firefox (nebo i vaše vlastní aplikace, jak si ještě ukážeme) s jeho databází komunikovat.

V about:prefs předvolbách Firefoxu najdete klíč geo.wifi.uri s hodnotou https://www.google.com/loc/json.

To je URL, se kterou Firefox komunikuje pomocí Geolocation API Network Protocolu. Jak taková komunikace vypadá?

Řekněme, že můj počítač "vidí" jednu Wi-Fi s názvem "default" a adresou "00-0e-2e-7d-7d-0e". Požadavek vypadá takto:

{
 "version": "1.1.0",
 "wifi_towers": [
  {
   "mac_address": "00-0e-2e-7d-7d-0e",
   "signal_strength": -49,
   "ssid": "default"
  }
 ]
}

Všimněte si, že protokol kromě hlavičky s číslem verze obsahuje pouze údaje o daném Wi-Fi bodu, nikde v něm nefiguruje údaj o vaší IP adrese. Tu nepotřebuje. Google k tomu použije IP adresu, ze které mu požadavek dorazí.

Pozn.: Pokud byste chtěli komunikaci mezi Googlem a prohlížečem odposlouchávat a máte problém s HTTPS, můžete změnit hodnotu geo.wifi.uri na http://www.google.com/loc/json (všimněte si změny protokolu z HTTPS na HTTP). Pro pouhé zalogování dat, která Firefox odeslal geolokačním protokolem, se mi osvědčila služba http://www.postbin.org/ nastavte geo.wifi.uri na vygenerovaný postbin a sledujte, co Firefox odesílá. (Po otestování vraťte geo.wifi.uri na původní hodnotu.)

K soukromí: Geolokační požadavky neobsahují cookies. To z důvodu ochrany soukromí. Můžete být právě ke Googlu přihlášeni, ale Firefox cookies přihlášeného uživatele na adresu https://www.google.com/loc/json prostě nepošle. Asi namítnete, že kdyby Google opravdu chtěl, může si propojit identitu uživatele pomocí IP adresy a sledovat jej tak. To jistě může.

Na druhou stranu odfiltrováním cookies udělal Google, co bylo jednoduše možné. Vaši IP adresu už odfiltrovat nemůže (pokud bychom do toho nezapojili nějakou třetí stranu, která by prováděla anonymizaci IP adresy, a této straně bychom bezvýhradně věřili...).

Uživateli je ovšem přidělen identifikátor, který si prohlížeč po nějakou dobu drží. Google tak může sledovat pohyb konkrétního uživatele, byť tento uživatel není reprezentován svým cookies (tj. svým googlím účtem, tj. svou identitou), ale náhodně vygenerovaným identifikátorem. Předpokládám, že toto sledování Google využívá pro budování a opravování své celosvětové databáze Wi-Fi bodů a BTS (při geolokaci se totiž jednak určuje vaše poloha, ovšem současně se tak i buduje databáze u Googlu - nádherné inženýrské vyřešení úlohy).

Souhrn: Při geolokaci tedy k jisté rozumné ochraně soukromí dochází, byť je to teoreticky ze strany Googlu překonatelné (kdyby chtěl, tak si vás najde a basta!).

Krok 3. Jak Google určí polohu

Skončili jsme odesláním požadavku na URL https://www.google.com/loc/json.

Google odpoví takto:

{"location":
{
 "latitude":50.1001961,
 "longitude":14.4228038,
 "accuracy":150.0
},
access_token":"2:Ta5Y_rSUZbO4rpJD:_FXkzUcxD1OWG-YM"
}

Výsledek si můžeme zobrazit na mapě. Návštěvníci pražských Ruby srazů a Posledních sobot jistě poznali, že se jedná o známý podnik zvaný Fraktál.

Položka access_token je onem zmíněný identifikátor, který vám Google tímto přidělil a kterým budou označeny další požadavky Firefoxu o geolokaci.

Všimněte si, že pomocí Wi-Fi lze zaměřit opravdu přesně. Stačila jediná Wi-Fi a získali jsme naši polohu s rozptylem 150 metrů!!! Tak to skutečně je. Stejnou zkušenost jsem učinil na řade dalších míst ať již v Praze, Plzni nebo Brně. Geolokace pomocí Wi-Fi je neuvěřitelně přesná.

Ve Fraktálu je ve skutečnosti 3-5 Wi-Fi bodů. V požadavku budou Googlu zaslány všechny, ale jemu stačí jediná z nich (je jedno která).

Výjimky: I v městech existují místa, která nemá Google zaměřena přesně. Na výjimky ale narazíte zřídka a nemívají dlouhého trvání. Databáze Google je samoopravující.

Sledoval jsem několik špatně zaměřených bodů a za několik týdnů až měsíců se jejich poloha upřesnila. Podobně tomu je, když se nějaký Wi-Fi bod přemístí (když se někdo přestěhuje do jiného města vezme si s sebou Wi-Fi router), i v takovém případě, se poloha časem ustálí na novém místě.

(Pozorný čtenář právě objevil možnost, jak snadno vysledovat, kam se odstěhovali jeho sousedé. Pokud s sebou vzali Wi-Fi router, je možné po čase určit jejich nové bydliště s přesností na 150 metrů. A to prakticky v kterékoliv civilizované části Zeměkoule!!!)

V případě, že si pořídíte nový Wi-Fi router, pak se za několik týdnů až měsíců také do databáze dostane. (Pokud přemýšlíte jak, pročtěte si, co znamená wardriving či warwalking.)

Je váš Wi-Fi router v databázi Googlu?

To snadno zjistíte. Připravil jsem k tomu jednoduchý nástroj (jedná se jednoduchou aplikaci, která se přímo dotazuje geolokační databáze Googlu). Stačí, když do textového pole zadáte MAC adresu vaší Wi-Fi ve formátu, který používá geolokační protokol, např. takto:

{"version":"1.1.0","wifi_towers":
[{"mac_address":"00-0e-2e-7d-7d-0e"}]}

a odešlete.

V 90% případů získáte vaši přesnou polohu (na 150m). Pokud ovšem získáte tento obrázek, tak jste jeden z mála případů, které v databázi Googlu nejsou. Pak Google použije IP adresu (jelikož moje aplikace hostuje u Googlu má IP adresu lokalizovanou do jakéhosi městečka v Americe).

Pokud máte nový Wi-Fi router, který Google ještě nezná, nebo pokud jste ze samoty, kterou Google databáze ještě nezná, schválně sledujte, jak dlouho bude trvat, než se v databázi objevíte.

Teď byste měli vědět o průběhu geolokace vše. Nebo ne? Ujasněme si ještě pár faktů.

Wi-Fi je základ

Pokud máte v jedné místnosti dva počítače a jeden z nich má zapnutou Wi-Fi, tak ten s Wi-Fi by vás měl lokalizovat naprosto přesně (na oněch 150m). Zkuste si to na maps.google.com (modré tlačítko vlevo nahoře) nebo na mé javascriptové ukázce na začátku článku. Počítač bez Wi-Fi naopak zcela ulítne a hodí vás nejspíš někam do středu nejbližšího velkého města. Můžete si to vyzkoušet i na tom samém počítači se zapnutou a vypnutou Wi-Fi (někdy je nutné mezitím restartovat Firefox, aby se změna projevila).

Co když Googlu pošlu nekonzistentní data?

I to jsem během svých experimentů zkoušel 8-) Ve standardním požadavku Firefox zasílá seznam Wi-Fi bodů z okolí, Google si najde v databázi jejich polohy a následně z nich stanoví polohu uživatele (pravděpodobně jako střed bodů všech Wi-Fi připojení - v tuto chvíli ignoruje velikost signálu a bere v úvahu pouze polohu bodů).

Co když by dostal požadavek, který by obsahoval současně Wi-Fi body z Prahy i Brna? Co udělá? Hloupý není. Ví, že tak velký signál Wi-Fi nemá. Rozhodne se dle jednotlivých bodů. Pokud mu v požadavku zašlu jeden bod z Prahy a jeden z Brna, nemá dle čeho se chytit a Wi-Fi ke geolokaci nepoužije (stále mu zbývá IP adresa, po které může sáhnout).

Pokud bych zaslal 1 bod z Prahy a 2 body z Brna, pak bude bod z Prahy považován za chybný a Google použije ke geolokaci ony dva Brněnské body (stejnou logikou to funguje i při vyšším počtu bodů).

Všimněte si, že jsme si právě ukázali mechanismus, jaký by Google mohl používat k samoopravování své databáze. Pokud se totiž i se svým Wi-Fi routerem přestěhuji z Prahy do Brna, tak nastane přesně ona výše zmíněná situace. Spustím si geolokaci a můj počítač pravděpodobně uvidí několik brněnských Wi-Fi bodů a jeden (můj) pražský. Pokud by se takový dotaz opakoval dostatečně často, mohl by být můj pražský router považován za přestěhovaný do Brna a jeho poloha v DB by se zaktualizovala.

Jsou to dohady, Google veřejně nespecifikoval, jak přesně svou databázi udržuje. Což asi nikdy neudělá, protože jinak bychom ho mohli správně zvolenými požadavky dokonale zblbnout a celou databázi mu rozházet.

Závěr

To jde ode mě vše. Čím víc jsem tenhle mechanismus zkoumal, tím víc se mi líbilo, jak je navržen. A na závěr mám malou prosbu. Pokud jste někdo zkoumal, jak funguje geolokace v dalším prohlížečích, dejte mi vědět (stačí mi i informace, zda používají také databázi Googlu nebo jinou).

Na úplný závěr děkuji Davidu Majdovi, Pavlu Cvrčkovi a Marušce Grafové, kteří mě byli nápomocni při testování geolokace v Praze a dalších městech.

Google mapy s mikroformáty a další

Nedávno jsem se zmínil o mikroformátech, v tomto postu přidám několik zajímavých odkazů.

Pro ty, kterým není jasné, jak by mohl sémantický web s mikroformáty fungovat, tu máme jedno video ukazující používání mikroformátů na Google mapách ve Firefoxu s rozšířením Operator.



Mikroformáty se již dostávají i do vědních oborů, jak je vidět z webu bioformats.org, který představuje mikroformáty pro použití v oblasti biologie a molekulární genetiky.

Pokud chcete mikroformáty z jejich HTML podoby zkonvertovat do XML nebo JSON, vyzkoušejte Optimus.

Chcete vytvořit na vašem webu denní plán za pomoci mikroformátů? Použijte Conference Schedule Creator, ve kterém zadáte jednotlivé události a získáte vygenerovaný HTML kód pro vložení do vašich stránek.

Nelze upřít, že se mikroformáty pomalu stávají buzzwordem, podobně jako se jím stal AJAX nebo Web2.0. Na webu Australian IT tak kupříkladu v pravém sloupci můžete najít mikroformáty hned vedle Microsoftu:

Sign up for a daily update of the biggest stories in IT. From Microsoft to Microformats, you'll be on top of all the latest in IT news five days a week.

A protože mikroformáty jsou o sémantickém webu, je dobré si ukázat, jak i takový sémantický web ve skutečnosti vypadá 8-)