Google | Code-Inside Blog

HowTo: Einstieg in "Cloud-Computing"

15. Jan, 2009 by Robert Mühsig 2 Kommentare

Cloud-Computing hört man heute immer mehr – doch was verbirgt sich dahinter? Welche großen Anbieter gibt es im Bereich des "Anwendungshostings" und was ist für Entwickler interessant?

10 Jahre Google Startseite im Schnelldurchlauf

6. Okt, 2008 by Robert Mühsig 3 Kommentare

Gerade auf dem Blog von Tobias Steinicke gefunden:

Die Daten beruhen auf dem Internet Archiv. Bemerkenswert wie wenig die Seite sich im schnelllebigen Internet verändert hat.

HowTo: Charts mit der Google Charts API erstellen – eine Einführung

22. Jan, 2008 by Robert Mühsig 2 Kommentare

Still und leise hat Google eine weitere API vor einer kleinen Weile veröffentlicht: Die Google Chart API. Was kann man mit dieser anstellen? Hier ein kurzer Überblick.

Wie funktioniert das und was kostet es?

Die Google Chart API ist recht einfach gestrickt:

Eine spezielle URL wird zusammengebaut und Google rendert daraus ein PNG Bild, welches man überall einsetzen kann. Maximal 50.000 Requests pro User (ich nehm an die IP wird geloggt) und pro Tag sind allerdings erlaubt – aber der Service ist sonst kostenlos und erfordert keine Anmeldung (daher der Gedanke mit der IP).
Böswillige Menschen könnten Google natürlich unterstellen, dass der Preis die geschickten Daten sind – Datenschutz olé

Schauen wir uns erstmal an, was die Charts API uns bieten kann, bevor wir zu den fachlichen Teil kommen:

Was für Charts gibt es eigentlich?

Diese 5 Chart Typen sind momentan in der Google Chart API enthalten:

Dabei haben einige Typen noch “Subtypen” enthalten – auf dem Screenshot ist ein kleiner Teil zu sehen.

Sieht nett aus, was muss ich tun?

Die Grundstruktur für die API – URL ist folgende:

http://chart.apis.google.com/chart?<parameter 1>&<parameter 2>&<parameter n>

Die 3 “wichtigen Parameter Typen”:

Chart Größe:
- Parameterstruktur: chx=[height]x[width]
- Beispiel: chs=300×500
- Live: Beispiel
- Hinweis: 1000 Pixel ist das Maximum!
Chart Daten:
- Aufgrund der URL Beschränkung auf ca. 255 Zeichen (müsste hinkommen ) hat Google die Möglichkeit eingebaut, seine Daten zu codiergen, dabei gibt es drei Möglichkeiten, bei den Beispielen sollte immer auf die URL geachtet werden:
  - Simple encoding
    - Parameter: chd=s:[data]
    - Max. 62 Werte
    - Live: Beispiel
  - Text encoding
    - Parameter: chd=t:[data]
    - Max. 1000 Werte
    - Live: Beispiel
  - Extended encoding
    - Parameter: chd=e:[data]
    - Max. 4096 Werte
- Da diese Encodierung meistens programmatisch entstehen soll, hat Google Java Script Snippets bereitgestellt und sammelt zudem in ihrem Google Groups weitere Links zu der Google Chart API.
Chart Type:
- Als dritter wichtiger Parameter dient der Typ der Charts:
- Parameterstruktur: cht=[type]
- Bestimmte Typen haben bestimmte andere Merkmale – Google hat dies bereits gut in einer Tabelle zusammengefasst.

Andere Parametertypen:

Man kann natürlich die Farbe, je nach Typ entsprechend, anpassen:
- Data Set Colors:
  - Parameterstruktur: chco=[hex],[hex],…
- Solid fill
- Linear gradient
- Linear stripes

Labels können ebenfalls gesetzt werden:

Title: chtt=[Title]
Legend: chdl=[Legend1]|[Legend2]|[Legend...]
Pie Charts: chl=[Lenged1]|[Legned2]…
Multiple Axis: chxt=…

Styles können auch definiert werden:

Sieht schick aus – machen wir doch mal ein Beispiele

Beispiel Pie
- Live Beispiel
- Beschreibung:
  - http://chart.apis.google.com/chart?cht=p3& : Chart Type – 3D Pie
  - chd=s:UUKY& : Chart Data in simple Encoding – U (2*) steht für 20, K für 10 und Y für 50 macht insgesamt 100% – siehe die Encoding Tabelle
  - chs=250×100& : Chart Größe in Pixel – 250 * 100 Pixel
  - chl=Hello|World|Code|Inside : Chart Pie Legende, dabei werden die Werte nacheinander auf die Chart Data entsprechend gemappt (Hello=U, World = U, Code = 10, Inside = Y)

Fazit

Das obere Beispiel von mir war recht einfach gestrickt. Wenn man die Google Beispiele auf der API Seite anschaut, wird es doch etwas schwieriger. Leider hat Google nur die Möglichkeit geboten, die Bilder über GET Requests zu erstellen. Daher muss man alles über die komplexen URL Anfragen lösen – sicherlich für kleine Sachen eine gute Lösung, für größere wird es aber leicht anstrengend.

Für einen kostenlosen Dienst und den schicken Typen und den vielen Möglichkeiten, ist es aber doch recht schick gelungen – auch wenn das Datenschutzproblem in “wichtigen” Anwendungen am Ende nicht ganz aus dem Auge verloren werden sollte.

HowTo: YouTube mit C# durchsuchen – Einstieg in die YouTube API / Google Data API

9. Jan, 2008 by Robert Mühsig 6 Kommentare

Vor einige Zeit habe ich bereits in einem meiner Wöchentlichen Rundablagen diesen interessanten Blogeintrag gefunden: Querying Youtube API using C#

Aufbauend auf diesen, habe ich mich selber mit der YouTube API beschäftigt und schreib mal etwas darüber.

Was kann die YouTube API?

Die YouTube API wurde durch die Übernahme durch Google geändert (siehe YouTube Dev) und ist jetzt Teil der GData API. Die YouTube API basiert auf den ATOM XML Format und kann daher auch ohne Anmeldung oder sonstiges in einem normalen Browser betrachtet werden. Wir suchen einfach mal YouTube nach Videos von U2 über die API ab:

http://gdata.youtube.com/feeds/videos?q=u2

(Ergebnis im IE7)

Bietet YouTube / Google sonst noch was?

Da ATOM auch nur XML ist, könnte man jetzt über XmlDocument die Ergebnisse auch selber parsen. Google stellt allerdings für .NET ein SDK bereit, womit man diesen ATOM Feed besser parsen kann: Googles GData .NET Library (einfach das aktuellste nehmen).

Entpackt oder Installiert man das SDK befindet sich in diesem Ordner alle nötigen DLLs: cs\lib\Release

Für die YouTube API gibt es keine gesonderte DLL, sondern wir benötigen diese zwei:

Google.GData.Client.dll
Google.GData.Extensions.dll

Das tolle Test-Such-Konsolen-Programm

Als Demonstration nehm ich einfach ein Konsolenprogramm – auch wenn dies natürlich bei einer Videosuche etwas “unsinnig” ist – es ist am einfachsten

Folgende Namespaces müssen eingebunden werden (und die 2 DLLs von Google und die System.Web DLL müssen mit referenziert werden):

using System.Web;
using Google.GData.Client;
using Google.GData.Extensions;

Wie bereits weiter oben gezeigt, benötigt man für das Suchen auf YouTube diese URL als Ausgangspunkt: http://gdata.youtube.com/feeds/videos?q=[SUCHWORT]

Das entsprechende “[SUCHWORT]” muss natürlich entsprechend noch für den Einsatz in der URL maskiert werden. Hier hab ich eine schöne Übersicht über die URL-maskier Möglichkeiten im .NET Framework gefunden: URL-Maskierung

Über die Klasse “HttpUtility.UrlEncode” bekommen wir den gewünschten maskierten Suchstring – dafür müssen wir auch “System.Web” mit referenzieren.

Das Test Program bietet einfach eine Eingabemöglichkeit und gibt die 20 ersten Suchtreffer wieder, hier der komplette Quellcode:

        static void Main(string[] args)
        {
            Console.WriteLine("Suchwort:");
            string searchTerm = Console.ReadLine(); 

            string uriSearchTerm = HttpUtility.UrlEncode(searchTerm);
            string url = "http://gdata.youtube.com/feeds/videos?q=" + uriSearchTerm; 

            Console.WriteLine("Connection to YouTube - Searching: " + searchTerm); 

            FeedQuery query = new FeedQuery("");
            Service service = new Service("youtube", "sample");
            query.Uri = new Uri(url);
            query.StartIndex = 0;
            query.NumberToRetrieve = 20;
            AtomFeed resultFeed = service.Query(query); 

            foreach (AtomEntry entry in resultFeed.Entries)
            {
                Console.WriteLine("Title: " + entry.Title.Text);
                Console.WriteLine("Link: " + entry.AlternateUri.Content);
                Console.WriteLine("Tags:");
                foreach (AtomCategory cat in entry.Categories)
                {
                    Console.Write(cat.Term + ", ");
                }
                Console.WriteLine();
            } 

            Console.ReadLine();
        }

Kurz erklärt:

Der Suchstring wird über UrlEncode maskiert.
“FeedQuery” ist eine spezielle Google.GData Klasse, mit welchem man ATOM Feeds leichter abrufen kann.
Bei “Service service = new Service(”youtube”, “sample”)” muss der “Servicename” und der “Applicationname” übergeben werden, obwohl dies wohl keinerlei Bedeutung hat.
Bei “service.Query(query)” wird die Suchanfrage abgeschickt (max. Suchergebnisse sind wohl 20 Einträge pro Request) und als Ergebnis kommt ein “AtomFeed”.
Dieser “AtomFeed” wird pro Entity entsprechend ausgegeben.
Die für YouTube interessante “watch” Adresse, versteckt sich in entry.AlternAteUri.Content – z.B. http://www.youtube.com/watch?v=w-TssRlmmBE für einen U2 Song

Resultat für die Suchanfrage für “Die Ärzte”:

Der Sourcecode wurde nur wenig vom originalen abgeändert.

Was macht man nun damit?

Das ganze bringt momentan in der Konsolenanwendung relativ wenig – in einer Windows.Forms Anwendung und mit dem “WebBrowser” in dem das Flashfile abgespielt werden kann, ist das schon brauchbarer (oder in einer ASP.NET Anwendung)

Leider gibt es wohl keine Möglichkeit (jedenfalls nicht mit dieser API – weiß einer einen anderen Weg?) das Flash von außen zu steuern. Das heisst, das man das embedded HTML (wie es bei YouTube üblich ist) immer mit einbauen muss – dafür kann man z.B. gut das “WebBrowser” Control nehmen.

Das Demoprojekt runterlade

Runterladen könnt ihr das Demoprojekt natürlich auch – ich hab es diesmal mit dem Visual Studio 2008 (die Express Edition kann jeder sich kostenlos runterladen) erstellt – falls jemand nur Visual Studio 2005 zur Hand hat und den Code benutzen möchte, steht dem nichts im Wege – einfach die CS Datei öffnen. In dem Demoprojekt wird kein .NET 3.5 benötigt – ich wollte nur mal rumexperimentieren.

[Download Democode]

Links:

Microsoft Virtual Earth vs. Google Maps (und eine andere Alternative) aus Entwickler- und Anwendersicht

30. Dez, 2007 by Robert Mühsig 3 Kommentare

Google hat mit seinem Kartendienst in diesem Jahr sehr viel bewegt – viele Mashups nutzen Google Maps und wenn man mal kurz eine Adresse nachschlagen will, nutzen viele Google Maps. Microsofts Virtual Earth fristet eher ein Schattendasein. Ob dies berechtigt ist oder nicht, möchte ich einfach mal an einigen Gesichtspunkten zeigen, welche für den normalen Anwender wichtig sind und auch für einen Entwickler.

Startseite – der erste Blick zählt

Da der berühmte erste Blick entscheident ist, vergleichen wir einfach mal den Aufbau beim betreten der beiden Kartendienste:

Virtual Earth:

Das Design ist an andere Windows Live Dienste angepasst und erstrahlt in einem bläulichen Ton.
Auf der linken Seite gibts ein Teil für die Eigenwerbung. Ansonsten ist es recht aufgeräumt.

Die Karte ansich ist in einem beigen Ton gehalten und – der hässlichste Punkt an Virtual Earth: In englisch! Wann bitte fixt Microsoft mal diesen Bug? Ich hätte gern die Städtenamen und Ländernamen in deutsch.

Die Eingabemaske:

Vorangewählt ist hier der Punkt “Unternehmen” mit der man z.B. Pizza in Dresden suchen kann. Den Punkt “Unternehmen” zu nenne halte ich persönlich für nicht wirklich gelungen und diesen Punkt auch noch vorauszuwählen finde ich auch nicht wirklich praktisch. Ich denke, die meisten Leute wollen wissen, wo ein Ort ist.

Allgemein ist das vielleicht auch keine so gute Idee von Microsoft gewesen, die Suchmaske so an der Seite zu verstecken – eine Position mehr in der Mitte wäre sicherlich “cleverer”.

Google Maps:

Google Maps erstrahlt im Google Style mit schlichtem Design.
Auf der linken Seite ist hier ebenfalls etwas Blabla zu finden.

Die Karte ist in freundlicheren Weiß und Blau gehalten und es steht auch “Deutschland” und “München” und nicht “Germany” und “Munich” da.

Die Eingabemaske:

Google üblich sehr schlicht und trotzdem sehr gut. Hier ist diesmal “Karte durchsuchen” vorangewählt.

Ergebnis:

Google Maps ist etwas “durchdachter” und die Karte wirkt freundlicher. Hier punktet Google.

Suchresultate

Was findet welche Suchmaschine besser? Hier mal ein einfacher Test:

Virtual Earth

Die Suchanfragen an Virtual Earth muss wirklich sehr genau sein, ein “Riesaer Straße 5 Dresden” versteht er nicht, erst nachdem man ein Komma vor Dresden macht, erkennt er es.
Die Suchanfragen sollten genau so eingegeben werden:
Straßenname (optional), PLZ oder Ort.

Gebe ich jetzt “Dresden, Riesaer Straße 5″ ein, schlägt mir VE folgende Sachen vor:

Über den Sinn und Unsinn kann man hier streiten.

Google Maps

Es ist egal, wie ich “Riesaer Straße 5, Dresden” schreibe – ob mit Komma oder Dresden vor der “Riesaer Straße” – ich komme immer am Ziel an.

Ergebnis:

Da VE hier schwächen zeigt, punktet auch hier wieder Google.
(ich hab noch andere Tests der gleichen Art gemacht und das Ergebnis war ca. immer das gleiche)

Kartenqualität

Die Straßenangaben etc. werden bei beiden wahrscheinlich ähnlich gut sein, vielleicht bei Microsoft durch die Jahrelange Erfahrung mit MapPoint sogar noch ein Fünkchen besser, aber wie gut sind denn die Sateillitenaufnahmen?

Virtual Earth:

Beispiel 1: Dresden

Näher ran geht es leider nicht.

Beispiel 2: Berlin

Wie in Dresden, geht es auch hier nicht näher ran.

Beispiel 3: München

Selbes “Problem” auch in München.

Google Maps:

Beispiel 1: Dresden

Man kann sehr weit ranzoomen, bis man einzelne Passanten erkennt.

Beispiel 2: Berlin

Ebenfalls sehr gut.

Beispiel 3: München

Ergebnis:

Google liefert hier eindeutig bei den Beispielen das bessere Bild ab – auf dem Land hat Google zwar auch hin und wieder seine Schwächen (und vom “Alter” des Bildes nicht gesprochen), aber trotzdem besser als Virtual Earth.

Sonstige Funktionen

Virtual Earth:

Routenplaner:
Der Routenplaner verweisst auf eine alte MSN Seite und sieht sehr bescheiden aus:

“Bird´s Eye”:
Diese Funktion hat nur Microsoft und finde ich persönlich eine sehr gute Idee. Es zeigt einige Städte in einer Vogelperspektive und wurden von einem Flugzeug aufgenommen. Die Bilder sind daher auch deutlich besser als Satellitenaufnahmen:

3D:
Die 3D Funktionalität gibts als Browser Addon (für den IE, FF weiß ich jetzt nicht). Leider ging bei mir die Installation immer wieder schief, sodass ich es aufgab. Zudem finde ich es generell eine ungünstige Idee, sowas in den ohnehin bereits überladenen IE mit reinzuimplementieren.

Google Maps:

Routenplaner:
Der Routenplaner greift auf die selben Kartendaten zu und ist auch sonst sehr praktisch.

Google Earth:
Das Desktopprogramm von Google bietet einige nette Features (z.B. 3D) die über die Fähigkeiten von der Online Variante geht.

Ergebnis:
Der Routenplaner von Google ist eindeutig schicker, aber die Bird´s Eye Funktionalität ist in Virtual Earth sehr schön. Durch Google Earth hat Google ein nettes Desktop Programm entwickelt, welches noch einige nette Spielerein mitbringt – hier Punkte VE für die Bird´s Eye Funktionalität und Google für die anderen beiden Punkte.

APIs – Der Stoff für die Entwickler

Virtual Earth:

Microsoft hat ein interaktives SDK für VE hier bereitgestellt:
The Virtual Earth Interactive SDK

Die API gibt sonst auch sehr viel her, das Kernproblem liegt aber in den Suchalgoryhtmen von Virtual Earth bzw. dessen schlechtem Bildmaterial.
Ich habe mich bei diesem HowTo mit Virtual Earth beschäftigt.

Das Gute an Virtual Earth: Es fällt keine Registrierung an.

Hier 3 Blogempfehlungen von mir zum Thema Virtual Earth:

Auf der MSDN gibt es auch noch ein Webcast zum Thema Virtual Earth:

Windows Live (Teil 4-4) – Entwickeln mit Virtual Earth

Google Maps:

Google stellt unter seiner Code Seite die Maps API vor. Die Dokumentation ist sehr gut gemacht und wird ständig erweitert. Google selbst liefert noch einige Tutorials und Artikel. Im Internet gibt es zudem sehr viele Informationen über die Google Maps API, ich selber habe in einem kleinen HowTo über die Grundvoraussetzungen geschrieben.
Google Maps verlangt eine Registrierung und ab 50.000 Geocoding Requests wird Google wohl eine Email schreiben

Fazit

Google Maps ist bei Bildqualität und Suchergebnissen klar besser als Virtual Earth. Ich als etwas Microsoft behafteter Entwickler gebe den Microsoft Pendaten meisten noch eher eine Chance als der “normale” Benutzer, aber bei Virtual Earth fehlt noch einiges. Das die Karte etwas “altbacken” aussieht, ist nur ein kleiner Punkt. Am meisten stört mich, dass immer noch “Germany” drüber steht und nicht “Deutschland” – den Suchalgorythmus muss Microsoft auch noch stark verbessern.

Von der API her sind beide gut einsetzbar. Wenn man Virtual Earth profesionell Einsetzen möchte, denke ich jedoch, dass Microsoft sehr schnell reagieren kann, weil es ihnen einfach an guten Referenzen in Europa / Deutschland fehlt. Über meine Arbeit habe ich jedenfalls bisher einen guten Eindruck von Microsoft bekommen, wenn es darum ging, Virtual Earth irgendwo einzusetzen.

Wenn Microsoft jetzt noch die Bildqualität, Suchergebnisqualität und allgemein am Design feilt, wird es vielleicht auch für den normalen Benutzer interessant – die Bird´s Eye Funktion ist auf alle Fälle sehr schick.
Google Maps und dessen API ist sehr beliebt, sodass man viele gute Quellen findet und Google mit Qualität überzeugt.

Was soll man nun nehmen?

Wer gern im Microsoft Umfeld rumspielt, der wird wahrscheinlich mal Virtual Earth probieren. Bei privaten Projekten sollte man das nehmen, was am meisten Spaß macht.
Im professionellen Umfeld sollte man nach den Preisen fragen und abwägen, was günstiger ist – auch in Hinblick auf Support von Google oder Microsoft.

Alternativen

Eine Alternative die ich mir noch nicht angeschaut habe, ist Yahoo Maps. Eine interessantere Alternative ist jedoch Map24. Map24 bietet ebenfalls ein SDK an. Es gibt einmal eine AJAX API, einmal pur als Webservice, für C++ oder Java etc.
Map24 bietet zwar keine Satellitenkarten, allerdings sind diese in einigen Fällen auch nicht nötig.

Map24 SDK erlaubt z.B. multiples Routen, das man z.B. 5 Routen gleichzeitig auf der Karte angezeigt bekommt. Auch hat es noch einige weitere Straßeninformationen gespeichert, z.B. kann man angeben, ob die Strecke für ein LKW oder PKW berechnet werden soll – da spielen z.B. Brückenhöhen eine Rolle.
Map24 ist daher eine interessante Alternative wenn es um Flottenmanagement geht. (das dies wahrscheinlich auch mit Microsofts Virtual Earth oder Google Maps geht, möchte ich nicht bezweifeln, allerdings steht es erstmal nicht in der API drin). Eine Information noch zu Map24: Wenn man dies einsetzt, hat man am Ende meist ein Java-Applett, anstatt normalen HTML / AJAX wie bei MS oder Google.

Neuer Anfang… neues HowTo

13. Mai, 2007 by Robert Mühsig Kein Kommentar

Nachdem es in der letzten Zeit etwas stressiger bei mir und meinen Kollegen war, gibt es nun wieder einen neuen, kleinen HowTo Eintrag. Es geht diesmal um die Google Maps API.

Näheres gibts hier zu bestaunen:
HowTo: Google Maps API (Grundvoraussetzungen)

HowTo: Google Maps API (Grundvoraussetzungen)

13. Mai, 2007 by Robert Mühsig 3 Kommentare

Die wohl berühmteste Mashup API ist die Google Maps API. Wie der Name schon erahnen lässt, geht es um den Kartendienst von Google.

Grundsätzlich ist der Dienst kostenlos, allerdings ist ein genauerer Blick in die Nutzungsbedingungen nicht verkehrt. Wichtigster Punkt ist wahrscheinlich erstmal die Beschränkung auf 50.000 Aufrufe pro Tag um bestimmte Standorte zu lokalisieren.
Wenn dies überschritten ist, sollte man sich mit Google auseinander setzen. Leider ist die Informationspolitik seitens Google nur unvollständig.

Wichtigste Einschränkungen:
- 50.000 Georequests per Day
- keine Routingfunktion

Die normale Routingfunktion, wie man sie aus Google Maps kennt, ist noch nicht für alle offen. Es gibt aber Spekulationen, das dies wohl bald nachgereicht werden soll.

Grundsätzliche Funktionsweise:
Google Maps ist im Grunde eine Javascript Bibliothek mit der Google Maps Oberfläche. Die Technik dahinter basiert auf AJAX. Die eingebundene Google Maps Karte kann mit der umfassenden Bibliothek ”bearbeitet” und in der Darstellung verändert werden.

Da es im Prinzip nur ein eingebundenes Javascript ist, läuft es auf jedem Webserver und in allen unterstützen Browsern. Keine weiteren Plugins sind nötig.

Um den Dienst zu nutzen, muss man sich unter dieser Adresse registrieren. Man benötigt dazu ein Google Konto, was aber ebenfalls kostenlos ist.
In der Registrierung für den Google Map Key muss man seine URL eingeben unter der später die Website erreichbar ist. Da man natürlich nicht immer auf dem Live-System entwickelt, hab ich mir selber (weil ich viele Keys wieder vergessen habe) für die “localhost” Adresse mehrere Keys generiert. Da unter ASP.NET der Webserver auf einen anderen Port läuft, musste ich auch für den jeweiligen Port einen eigenen Key anlegen.
Wie man sieht, kann man im Prinzip so viele Keys wie man möchte anlegen.

Um mal zu sehen, wie man relativ einfach die Google Map einbinden kann, hat Google dieses Tool zur Verfügung gestellt: Map Search Wizard.

Dies wars erstmal wieder zu den Grundvoraussetzung. Mehr ist für den einfachen Gebrauch erstmal nicht relevant. In späteren HowTos wird dann näher auf die eigentliche API eingegangen.