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.
Posts mit dem Label google werden angezeigt. Alle Posts anzeigen
Posts mit dem Label google werden angezeigt. Alle Posts anzeigen
Donnerstag, 31. Mai 2007
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.
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
