Nach dem Web 1.0 (mehr oder weniger statische Internetseiten) und dem Web 2.0 ("das Mitmachnetz") wird es Zeit für das Web 3.0, zumindest für die ersten Vorboten. Ich stelle einfach mal zusammen, was sich da so an Ideen findet.
Zunächst ist da das räumliche Web (spatial web). Mit Google Earth, Maps, aber auch mit rein virtuellen Räumen wie Second Life, World of Warcraft finden sich hier schon einige Systeme, die einen Vorgeschmack darauf bieten, was die Zukunft im Web - und außerhalb des Webs - bieten wird: Die Vermengung virtueller und realer Räume. Wir leben im "First Life" und sind daran gebunden, dass bestimmte Dinge an bestimmten Orten stattfinden: Wohnen, Arbeiten, Urlaub. Gerade bei der Urlaubsplanung ist Google Earth für viele schon ein echtes Werkzeug geworden. Und dann taggt man einfach seiner Bilder mit Geodaten (aufgenommen mit dem GPS-Empfänger) und schon kann man nachverfolgen, was wo war. Genauso kann man auch alles andere geotaggen - damit finden sich auch schon neben Google weitere Firmen, die Karten mit Bildmaterial und Tags verheiraten wollen.
Second Life war sicher zuerst ein Hype und ist jetzt mehr oder weniger uninteressant geworden, die Idee wird aber das räumliche Web beeinflussen: In 2D im Netz zu surfen ist mehr oder weniger unbefriedigend: Wir leben in einer dreidimensionalen Welt. Online-Shops werden in Zukunft die Waren dreidimensional präsentieren (manche faken das ja schon mit Quicktime VR), auf der letzten CeBIT gabe es 3D-Fernseher zu sehen - zusammen mit IPTV und Overlay-Ads eine tolle Vermarktungsquelle: Einfach den laufenden Film an der Stelle anhalten, wo der Hauptdarsteller diese tollen Klamotten anhat, draufklicken und direkt in den Shop kommen. Dort die Klamotten auf das eigene 3D-Modell ziehen... naja, das ist dann vielleicht Web 5.0 - oder so.
Der zweite Kandidat für's Web 3.0 ist das mobile Web. Immer schon verkündet glaube ich daran, dass der mobilen Kommunikation und insbesondere dem mobilen Webzugang die Zukunft gehört. Gerade zusammen mit dem räumlichen Web kann man sich so toll wirklich nützliche Anwendungen überlegen: Wo ist das nächste gute Restaurant: natürlich nach Web 2.0-Maßstäben von Nutzern empfohlen. Das interessiert mich selten dann, wenn ich wirklich am Rechner sitze. Die Kneipen und Restaurants in meiner Nähe kenne ich. Nein, meistens interessiert mich das, wenn ich unterwegs bin. Also schnell auf meiner PSP per öffentlichem W-Lan auf qype.
Für mich als alten KIler (KI = Künstliche Intelligenz) ist die dritte Zukunftslinie natürlich die spannenste: das semantische Netz. Dabei werden Web-Inhalte nicht einfach nur "konsumierbar" für Menschen produziert, sondern so, dass der Rechner auch etwas damit anfangen kann. Genauer: Ein sogenannter Inferenzmechanismus. Ok, zu tief für hier und jetzt, ein Beispiel muss her. Freebase baut auf der Basis von Wikipedia-Artikeln ein semantisches Wiki auf: Zu Städten steht da nicht nur jeweils ein netter Artikel. Jeder Artikel ist potentiell auch mit einem oder mehreren Typen zugeordnet (die man natürlich frei anlegen darf). Städte sind beispielsweise von folgenden Typen: Location (klar, Städte liegen irgendwo auf der Welt, siehe oben), City (Städte haben ganz besondere Eigenschaften, z.B. eine Einwohnerzahl zu einem bestimmten Zeitpunkt), gegebenenfalls noch ein paar mehr.
Eine Stadt liegt in einem Staat - und jetzt wird es interessant. Wo bei Wikipedia die Links alle gleich sind, da sind die Links bei Freebase auch typisiert. Es gibt also einen Linktyp "is contained" (ist enthalten). Eine Stadt ist enthalten in einem Staat. Eine Staat wiederum ist über den gleichen Linktyp enthalten in einem Staatenbund. Und Linktypen können wieder Eigenschaften haben. Zum Beispiel können sie transitiv sein. Hamburg ist beispielsweise in Deutschland, Deutschland in der EU. Also (!) liegt Hamburg auch in der EU. Und genau das ist der Clou. Kein Mensch muss das in irgendeinem Artikel explizit angeben, trotzdem kann man die Information direkt aus Freebase herausbekommen. Mit einer Anfrage bekommt man so beispielsweise alle Millionenstädte in Europa.
Ganz so einfach ist es leider nicht - die Anfragesprache ist eine Wissenschaft für sich. Klar, es geht. Aber schön wäre doch, wenn man irgendwie eine natürlichsprachliche Anfrage in diese komische Syntax automatisch überführen könnte. Das ist jetzt aber wieder Web 4.0.
Sonntag, 30. September 2007
Donnerstag, 31. Mai 2007
Google Developer Day (Hamburg) - mein Fazit
So, der Tag ist rum, die Sessions sind gelaufen, ich habe die neuen Building Blocks (Schlagwort des Tages) gesehen. Es ist Zeit für mein Fazit - und das ist sehr positiv.
Die Location ist gut - ohne Zweifel. Dann die nächste positive Überraschung: Die Organisation ist fantastisch, das WiFi funktioniert einfach, es geht mit Essen los. Und auch das Essen ist sehr gut. Dann gleich die erste negative Überraschung. Die Übertragung der Keynotes aus London hätte man sich einfach sparen können: Die Qualität des Videostreams ist nun mal nicht erste Sahne, die Inhalte sind kaum besser. Hatte ich ja schon geschrieben.
Der Rest des Tages ist eitel Sonnenschein: Die Referenten sind gut, kompetent, witzig. Die Sessions und Workshops hätten, das habe ich mehrfach gehört, anspruchsvoller sein können. Aber ich weiß, dass es eeeecht schwierig ist, das richtige Niveau zu finden. Und ich glaube, dass es schon wirklich gut geklappt hat.
Über die einzelnen Sessions hatte ich schon gebloggt. Das möchte ich hier nicht noch mal tun. Insgesamt fand ich sie alle von Inhalt und Form sehr unterschiedlich und sehr gut.
Zum Ende noch mal - das Essen war gut (keine Ahnung, ob das Filet vom Mittag oder die Spieße vom Abend besser waren, aber für mich als Schleckermaul war die Creme brulee der Hit).
Also, auf ein Neues. Ich freue mich schon auf den nächsten Google Developer Day. Dann sehen wir uns hier wieder unter dem Tag GDD08.
Die Location ist gut - ohne Zweifel. Dann die nächste positive Überraschung: Die Organisation ist fantastisch, das WiFi funktioniert einfach, es geht mit Essen los. Und auch das Essen ist sehr gut. Dann gleich die erste negative Überraschung. Die Übertragung der Keynotes aus London hätte man sich einfach sparen können: Die Qualität des Videostreams ist nun mal nicht erste Sahne, die Inhalte sind kaum besser. Hatte ich ja schon geschrieben.
Der Rest des Tages ist eitel Sonnenschein: Die Referenten sind gut, kompetent, witzig. Die Sessions und Workshops hätten, das habe ich mehrfach gehört, anspruchsvoller sein können. Aber ich weiß, dass es eeeecht schwierig ist, das richtige Niveau zu finden. Und ich glaube, dass es schon wirklich gut geklappt hat.
Über die einzelnen Sessions hatte ich schon gebloggt. Das möchte ich hier nicht noch mal tun. Insgesamt fand ich sie alle von Inhalt und Form sehr unterschiedlich und sehr gut.
Zum Ende noch mal - das Essen war gut (keine Ahnung, ob das Filet vom Mittag oder die Spieße vom Abend besser waren, aber für mich als Schleckermaul war die Creme brulee der Hit).
Also, auf ein Neues. Ich freue mich schon auf den nächsten Google Developer Day. Dann sehen wir uns hier wieder unter dem Tag GDD08.
Wrap up
Beim Wrap-up hat Andreas Gebhard über Deepa Mehta geredet. Ok, Semantische Netze sind nicht neu, aber wenn er bei Google reden darf, dann muss es ja cool sein. Gedacht, getan: Gegoogelt nach DeepaMehta, gefunden (www.deepamehta.de), ausprobiert und angeschmiert: "The DeepaMehta server at www.deepamehta.de:7557 isn't running" :(
argh...
Doch die falsche Session gewählt. Im Maps Workshop gab's - ich glaube für erfolgreiche Implementierungen - eine 3D Maus. 3D Maus ! Cool. Groovy. Und ich war nicht dabei.
Earth, KML und firstlife.com
Gerade bei Joachim in der Earth- und KML-Session gewesen. War sehr interessant, allerdings war ich etwas zu spät und deswegen schon wieder steckdosenlos. Deswegen nicht live, sondern hinterher gebloggt: Was man mit KML, Maps und Earth so machen kann ist schon jetzt beeindruckend. Wenn man mal in die Zukunft blicken mag - Earth ist ja so alt noch nicht - gibt es schon noch einige Punkte. Network Links, also die Möglichkeit, Geodaten dynamisch nachzuladen, sind jetzt der Anfang. Meine Frage nach Dynamic-KML, also KML mit JavaScript, das im Browser (aka Earth) ausgeführt wird, führt naturgegebenermaßen nicht zu einer befriedigenden Antwort. Joachims veröffentlichte Meinung dazu ist, dass Earth eher schlanker werden soll und eher in den Browser integriert wird als dass es mit noch mehr Funktionalität angereichert wird.
So, jetzt werden hier um mich herum schon die Stuhlreihen abgebaut, damit die Party gleich steigen kann.
So, jetzt werden hier um mich herum schon die Stuhlreihen abgebaut, damit die Party gleich steigen kann.
Peeks aus der GData Session
Frank Mantek redet hier über GData - die Google API zum Zugriff auf diverse Services, z.B. Calendar, Blogger, Picasaweb etc. Nach dem Überblick über das optimistic locking per Versionierung und Authentication. Es gibt diverse Client Libraries - in Java mit Support von Google, in Ruby und - dadahh - LISP ist es eine contributed lib, also von irgendwem. Aber es gibt sie.
Ok, jetzt redet Frank gerade über die verschiedenen Zielsysteme. Kommt mir gerade eine Geschäftsidee? Hm, nein, nicht hier und nicht jetzt - und wenn, dann blogge ich das hier nicht ;) Ansonsten sind die Übersichten eher öde. Aber gut, was will man auch über eine API alleine sagen? Das hat Frank schon ganz am Anfang der Session gesagt.
Aus der Liste der Beispiele ragt der "Phixr Online Photo Editor" raus. Muss ich mal ausprobieren. Schön zu sehen, dass Google mit REST gute Erfahrung gemacht hat und dafür das Atom-Protokoll in der dort vorgesehenen Weise erweitert hat. Der klare Vorteil von REST ist - wer hät's gedacht - die Einfachheit. SOAP ist - gerade in der vollen Ausbaustufe - die ideale Möglichkeit, sich in den Fuß zu schießen. Kleiner Exkurs: Unser über https (Client Zertifikat, Server Zertifikat) und WebService Security gesicherter Service hat jedenfalls ordentlich weh getan. Spaß ist was anderes.
Schön zu sehen ist die Folie "Care for your Developers": Protocol Centric & Language Agnostic; Open your Code; Give Fair Warnings of Changes; Meet your Developers. Stimmt. Das letzte macht Google ja heute und das machen sie gut.
Ok, jetzt redet Frank gerade über die verschiedenen Zielsysteme. Kommt mir gerade eine Geschäftsidee? Hm, nein, nicht hier und nicht jetzt - und wenn, dann blogge ich das hier nicht ;) Ansonsten sind die Übersichten eher öde. Aber gut, was will man auch über eine API alleine sagen? Das hat Frank schon ganz am Anfang der Session gesagt.
Aus der Liste der Beispiele ragt der "Phixr Online Photo Editor" raus. Muss ich mal ausprobieren. Schön zu sehen, dass Google mit REST gute Erfahrung gemacht hat und dafür das Atom-Protokoll in der dort vorgesehenen Weise erweitert hat. Der klare Vorteil von REST ist - wer hät's gedacht - die Einfachheit. SOAP ist - gerade in der vollen Ausbaustufe - die ideale Möglichkeit, sich in den Fuß zu schießen. Kleiner Exkurs: Unser über https (Client Zertifikat, Server Zertifikat) und WebService Security gesicherter Service hat jedenfalls ordentlich weh getan. Spaß ist was anderes.
Schön zu sehen ist die Folie "Care for your Developers": Protocol Centric & Language Agnostic; Open your Code; Give Fair Warnings of Changes; Meet your Developers. Stimmt. Das letzte macht Google ja heute und das machen sie gut.
Von Maplets zu Gadgets
Again... Nachdem ich gerade schon von Maplets gehört habe, höre ich mir jetzt Douwe Osinga an, der über Gadgets redet.
Erst mal: Was sind Gadgets - naja, kleine html/script-Snipplets, die man auf seiner eigenen Homepage, auf iGoogle, im Dashboard, in der Sidebar oder eben irgendwo laufen lassen kann. Sogar im IBM WebSphere Portal ;) Ob Stephan Uhrenbacher das Qype Gadget schon am Start hat? Ich sehe jedenfalls nur die Qype*Vibes hier.
Ein Gadget kann man mit User Preferences (auch hidden) konfigurieren. Dabei gibt es allerlei vorgefertigte Elemente (checkboxes, lists) etc. Dazu kommt dann noch der html- und script-Block im Content und mit beidem zusammen kann man auf dem Gadget Scratchpad in kürzester Zeit sein erstes Gadget bauen. Douwe geht schnell durch so ein paar Sachen durch, die man in seinem Gadget gerne haben möchte: Maps, Google Analytics, Remote Content (z.B. RSS/Atom feeds).
Das ganze ist nicht so hands-on wie die Google Maps API Session von Steffen Meschkat gerade eben, aber auch ganz interessant. Oder vielleicht zu hands-on: Wenn das scratchpad erst mal voll mit JavaScript-Code ist, dann ist das doch ein bisschen viel auf einmal. Aber immerhin: Douwe macht das launig.
Schön ist der Hinweis, dass es in Europa wohl nicht so wichtig ist, die Bedeutung von Internationalisierung zu betonen. Amerika, kannst Du uns hören? Hm, wohl nicht... ;) Auf jeden Fall: Es gibt message bundles, in denen man die Texte ablegen kann. Kennen wir ja aus Java. Hier ist es halt in XML.
Gadgets können auch states speichern. Dazu kann man ein Preference-Item als "hidden" markieren und darin den Zustand speichern. Gadgets können auch externe Ressourcen cachen - die werden dann einfach auf die Google-Server repliziert.
Die Punkte: "Add to Google Button", "Promote your Gadget" etc. überspringen wir mal. Top Gadget Authros findet man jedenfalls unter http://www.google.com/ig/authors. Der Preis für das beste Gadget (hier auf dem Developer Day) ausgelobt ist ein Mittagessen mit Douwe. Hm. Will ich das? Douwe selbst preist an, dass man es für sich selbst machen sollte, "because it's cool".
Mal sehen, wann ich mein erstes Gadget schreibe. Wenn, dann mach ich das wohl zuerst mal, weil ich's für mein Dashboard mag. Ups, gerade noch was nettes gesehen, als ich einen Link für diesen Eintrag gesucht habe: Der Google Mashup Editor. Muss ich nachher mal einen Blick drauf werfen oder sehen, wen ich dazu ausquetschen kann.
Erst mal: Was sind Gadgets - naja, kleine html/script-Snipplets, die man auf seiner eigenen Homepage, auf iGoogle, im Dashboard, in der Sidebar oder eben irgendwo laufen lassen kann. Sogar im IBM WebSphere Portal ;) Ob Stephan Uhrenbacher das Qype Gadget schon am Start hat? Ich sehe jedenfalls nur die Qype*Vibes hier.
Ein Gadget kann man mit User Preferences (auch hidden) konfigurieren. Dabei gibt es allerlei vorgefertigte Elemente (checkboxes, lists) etc. Dazu kommt dann noch der html- und script-Block im Content und mit beidem zusammen kann man auf dem Gadget Scratchpad in kürzester Zeit sein erstes Gadget bauen. Douwe geht schnell durch so ein paar Sachen durch, die man in seinem Gadget gerne haben möchte: Maps, Google Analytics, Remote Content (z.B. RSS/Atom feeds).
Das ganze ist nicht so hands-on wie die Google Maps API Session von Steffen Meschkat gerade eben, aber auch ganz interessant. Oder vielleicht zu hands-on: Wenn das scratchpad erst mal voll mit JavaScript-Code ist, dann ist das doch ein bisschen viel auf einmal. Aber immerhin: Douwe macht das launig.
Schön ist der Hinweis, dass es in Europa wohl nicht so wichtig ist, die Bedeutung von Internationalisierung zu betonen. Amerika, kannst Du uns hören? Hm, wohl nicht... ;) Auf jeden Fall: Es gibt message bundles, in denen man die Texte ablegen kann. Kennen wir ja aus Java. Hier ist es halt in XML.
Gadgets können auch states speichern. Dazu kann man ein Preference-Item als "hidden" markieren und darin den Zustand speichern. Gadgets können auch externe Ressourcen cachen - die werden dann einfach auf die Google-Server repliziert.
Die Punkte: "Add to Google Button", "Promote your Gadget" etc. überspringen wir mal. Top Gadget Authros findet man jedenfalls unter http://www.google.com/ig/authors. Der Preis für das beste Gadget (hier auf dem Developer Day) ausgelobt ist ein Mittagessen mit Douwe. Hm. Will ich das? Douwe selbst preist an, dass man es für sich selbst machen sollte, "because it's cool".
Mal sehen, wann ich mein erstes Gadget schreibe. Wenn, dann mach ich das wohl zuerst mal, weil ich's für mein Dashboard mag. Ups, gerade noch was nettes gesehen, als ich einen Link für diesen Eintrag gesucht habe: Der Google Mashup Editor. Muss ich nachher mal einen Blick drauf werfen oder sehen, wen ich dazu ausquetschen kann.
Google Maps API
Jetzt bin ich in der Google Maps API Session. Steffen Meschkat erzählt uns hier was über die alten und neuen Features in Maps. Zu den neuen gehören u.a. AdSense für Maps.
Schick, die Slides sind in HTML (gut gemacht), dadurch kann Steffen direkt Maps-Element vorführen. Noch ist es einfach, er fängt mit einem "Hello World!" an, indem er in erst mal (gaaanz kurz) zeigt, wie er einen Text in eine Bubble steckt.
Schön: Er geht gleich auf essentielle Fragen ein, die sich direkt an diesem einfachen Beispiel stellen: Wie kann ich einen (von vielen) Markern nach vorne holen? Antwort: Gar nicht. Der Marker ist eigentlich nur ein Punkt. Der Marker steht eigentlich senkrecht auf der Karte, in der 2.5-D Darstellung werden nördlichere durch südlichere Marker überdeckt.
Schick auch die Folie mit dem integrierten Editor: Steffen hat sich eine kleine JavaScript-Konsole in die Map geklebt, mit der er hier direkt in der Session Beispiele laufen lassen kann.
Und wieder was gelernt: Es gibt "Implementierungs-Artefakte". Hier "draggable". Erst macht man einen Marker "draggable: true", danach muss man ihn noch mit "enableDragging()" wirklich drag&drop-bar machen.
Weiter zu ascynchronous continuation: hier gibt man bei einer Serveranfrage die Funktion mit, die die Antwort verarbeitet. Der Grund dafür: JavaScript läuft im Browser in einem einzigen Thread - warten auf die Antwort ist also nicht drin.
Hach, wie mag ich es, LISP zu können. Funktionen hin- und herzuschubsen ist doch das normalste der Welt ;)
Witziger Einwurf am Rande: KML ist von Computer-Grafikern. Klar, Koordinaten sind x, y. Maps ist von Geographen, in der API sind Koordinaten also latitude, longitude. Schön, dass beides irgendwie verständlich ist, zusammen aber irgendwie gemurkst wirkt.
Hach, nochmal. Ich mag LISP - jetzt erklärt Steffen hier erst mal Closures. Gähn ;)
Spannend: Jetzt erklärt Steffen gerade, wie die Maps Entwickler die Sicherheitsmechanismen von JavaScript "ausgehebelt" haben. Ich fass mal kurz zusammen: Es wird ein JSNOP script aufgerufen, das selbst ein callback enthält.
Auch spannend: Peformance. Erstens läuft die Browser UI und das javascript in einem einzigen Thread. Zweitens sind DOM Operationen langsam.
Aus Performance-Gründen werden über den GMarkerManager nur die Marker wirklich in den DOM-Tree eingefügt, die auch (in dem Ausschnitt, in dem Zoom-Level) zu sehen sind.
Man sollte außerdem lange Sequenzen in Blöcke unterteilen, weil ... ups, hier bricht die Erklärung einfach ab. Schade.
Über die DrivinDirectionsAPI kann man sich, beispielsweise in einer seperaten Pane innerhalb des Maps-divs, Routeninformationen anzeigen lassen.
Und weiter im Text. Maplets sind die Basis für weitere Mesh-ups. Zur Zeit liegt das auf http://maps.google.com/preview. Zusammengeworfen werden da die Google Gadgets API (iframe mit html und javascript, remote data Zugriff, Speicherung von Benutzer-Präfs) und Google Maps API (overlays, event-listener).
Jetzt läuft uns leider die Zeit davon, wir gehen trotzdem noch mal schnell in den Code, d.h. in das XML-File, in dem das Maplet definiert wird. In den Modul-Präfss gibt es in den Inhalt steht dann der html und script-Content, der im Maplet-iframe landet. Sieht eigentlich einfach aus. Mal sehen, ob sich das in der realen Welt auch so darstellt. Interessant ist auch das Herstellen von Sicherheit einerseits (Verhinderung von Cross-Side-Scripting, XSS) und das Umgehen von Sicherheitsmechanismen andererseits (Kommunikation zwischen Script-Teilen von maps.google.com und gmodules.com).
Damit genug von hier, auf zur nächsten Session. Aber festzuhalten: Gute Session.
Schick, die Slides sind in HTML (gut gemacht), dadurch kann Steffen direkt Maps-Element vorführen. Noch ist es einfach, er fängt mit einem "Hello World!" an, indem er in erst mal (gaaanz kurz) zeigt, wie er einen Text in eine Bubble steckt.
Schön: Er geht gleich auf essentielle Fragen ein, die sich direkt an diesem einfachen Beispiel stellen: Wie kann ich einen (von vielen) Markern nach vorne holen? Antwort: Gar nicht. Der Marker ist eigentlich nur ein Punkt. Der Marker steht eigentlich senkrecht auf der Karte, in der 2.5-D Darstellung werden nördlichere durch südlichere Marker überdeckt.
Schick auch die Folie mit dem integrierten Editor: Steffen hat sich eine kleine JavaScript-Konsole in die Map geklebt, mit der er hier direkt in der Session Beispiele laufen lassen kann.
Und wieder was gelernt: Es gibt "Implementierungs-Artefakte". Hier "draggable". Erst macht man einen Marker "draggable: true", danach muss man ihn noch mit "enableDragging()" wirklich drag&drop-bar machen.
Weiter zu ascynchronous continuation: hier gibt man bei einer Serveranfrage die Funktion mit, die die Antwort verarbeitet. Der Grund dafür: JavaScript läuft im Browser in einem einzigen Thread - warten auf die Antwort ist also nicht drin.
Hach, wie mag ich es, LISP zu können. Funktionen hin- und herzuschubsen ist doch das normalste der Welt ;)
Witziger Einwurf am Rande: KML ist von Computer-Grafikern. Klar, Koordinaten sind x, y. Maps ist von Geographen, in der API sind Koordinaten also latitude, longitude. Schön, dass beides irgendwie verständlich ist, zusammen aber irgendwie gemurkst wirkt.
Hach, nochmal. Ich mag LISP - jetzt erklärt Steffen hier erst mal Closures. Gähn ;)
Spannend: Jetzt erklärt Steffen gerade, wie die Maps Entwickler die Sicherheitsmechanismen von JavaScript "ausgehebelt" haben. Ich fass mal kurz zusammen: Es wird ein JSNOP script aufgerufen, das selbst ein callback enthält.
Auch spannend: Peformance. Erstens läuft die Browser UI und das javascript in einem einzigen Thread. Zweitens sind DOM Operationen langsam.
Aus Performance-Gründen werden über den GMarkerManager nur die Marker wirklich in den DOM-Tree eingefügt, die auch (in dem Ausschnitt, in dem Zoom-Level) zu sehen sind.
Man sollte außerdem lange Sequenzen in Blöcke unterteilen, weil ... ups, hier bricht die Erklärung einfach ab. Schade.
Über die DrivinDirectionsAPI kann man sich, beispielsweise in einer seperaten Pane innerhalb des Maps-divs, Routeninformationen anzeigen lassen.
Und weiter im Text. Maplets sind die Basis für weitere Mesh-ups. Zur Zeit liegt das auf http://maps.google.com/preview. Zusammengeworfen werden da die Google Gadgets API (iframe mit html und javascript, remote data Zugriff, Speicherung von Benutzer-Präfs) und Google Maps API (overlays, event-listener).
Jetzt läuft uns leider die Zeit davon, wir gehen trotzdem noch mal schnell in den Code, d.h. in das XML-File, in dem das Maplet definiert wird. In den Modul-Präfss gibt es in
Damit genug von hier, auf zur nächsten Session. Aber festzuhalten: Gute Session.
Wrap up der Keynote in 7 Minuten ;)
Ha, nicht aufgepasst, stattdessen gebloggt etc. und - richtig gemacht: Joachim gibt gerade die
Zusammenfassung der Londoner Keynotes - verdichtet, besser, mit anderen Schwerpunkten, z.B. deutlich mehr Gears. Schön.
Zusammenfassung der Londoner Keynotes - verdichtet, besser, mit anderen Schwerpunkten, z.B. deutlich mehr Gears. Schön.
Nachricht von der Keynote
Hier bin ich - beim Google Developer Day. Nach dem leckeren Essen ("Essen ist wichtig bei Google", Karl Krainer) hatte ich schon die ersten netten Kontakte - mit den Jungs von atoolo.com oder mit Patrick und Joachim von Google.
Jetzt sitze ich hier zwischen den beiden einzigen Frauen im Auditorium der Keynote (eine davon ist meine Frau :) ). Die deutsche Keynote war schon sehr nett und kann es fast mit dem Essen aufnehmen. Stephan Uhrenbacher stellt seine Company Qype vor - Early Adaptor von Maps. Die Vorstellung der Speaker von heute ist noch ganz kurzweilig, danach hat die Veranstaltung schon den ersten Tiefpunkt... Chris DiBona erzählt sehr langweilig in eher schlechter Videoübertragung öde Dinge über diverse Entwicklungen bei Google. Das ganze gleicht einem Rundumschlag durch den Buzzword-Dschungle mit diversen Plattitüden dazwischen.
Überhaupt ist die Übertragung aus London nicht soooo faszinierend. Vielleicht schnacke ich doch ein bisschen mit meinen Nachbarinnen und freue mich auf die Live-Sessions nachher.
Jetzt sitze ich hier zwischen den beiden einzigen Frauen im Auditorium der Keynote (eine davon ist meine Frau :) ). Die deutsche Keynote war schon sehr nett und kann es fast mit dem Essen aufnehmen. Stephan Uhrenbacher stellt seine Company Qype vor - Early Adaptor von Maps. Die Vorstellung der Speaker von heute ist noch ganz kurzweilig, danach hat die Veranstaltung schon den ersten Tiefpunkt... Chris DiBona erzählt sehr langweilig in eher schlechter Videoübertragung öde Dinge über diverse Entwicklungen bei Google. Das ganze gleicht einem Rundumschlag durch den Buzzword-Dschungle mit diversen Plattitüden dazwischen.
Überhaupt ist die Übertragung aus London nicht soooo faszinierend. Vielleicht schnacke ich doch ein bisschen mit meinen Nachbarinnen und freue mich auf die Live-Sessions nachher.
Freitag, 25. Mai 2007
Google Developer Day
Moin, moin!
Nächste Woche ist Google Developer Day in Hamburg - und ich bin dabei. Man darf gespannt sein.
Meine persönlichen Favoriten sind ja die Gadget-Themen. Mal sehen, wann ich mein erstes eigenes Gadget schreibe. Bisher war ich ja auf mehr auf Web-Applikationen aus. Generell ist das glaube ich auch einfach eine gute Gelegenheit, neue (nette, interessante) Leute kennen zu lernen und auch alte Bekannte wieder zu sehen.
Noch bleiben viele Fragen offen: Wer hält die Talks? Kann man in der Kürze der Zeit wirklich tiefschürfendes erfahren? Gibt's Sofas für die Teepause? Wer hat gesagt, dass es immer Kaffepause heißen muss?
Lookin' forward :)
Chris
Nächste Woche ist Google Developer Day in Hamburg - und ich bin dabei. Man darf gespannt sein.
Meine persönlichen Favoriten sind ja die Gadget-Themen. Mal sehen, wann ich mein erstes eigenes Gadget schreibe. Bisher war ich ja auf mehr auf Web-Applikationen aus. Generell ist das glaube ich auch einfach eine gute Gelegenheit, neue (nette, interessante) Leute kennen zu lernen und auch alte Bekannte wieder zu sehen.
Noch bleiben viele Fragen offen: Wer hält die Talks? Kann man in der Kürze der Zeit wirklich tiefschürfendes erfahren? Gibt's Sofas für die Teepause? Wer hat gesagt, dass es immer Kaffepause heißen muss?
Lookin' forward :)
Chris
Abonnieren
Posts (Atom)
Posts
