[Proof of Concept] SharpConnect
Nachdem ich in den letzten Tagen an einem Konzept getüftelt habe, wie man verschiedene webbasierte APIs einfach zugänglich machen könnte, möchte ich nun eine beispielhafte Implementierung vorführen: SharpConnect. (Download DLL) Und das Ziel meiner Wahl ist natürlich Last.FM, was auch sonst. Wohlgemerkt gehe ich hier nicht auf die Umsetzung ein, nur auf die Verwendung.
Es stellt sich zuerst die Frage: Was wollen wir? Ich für meinen Teil würde z.B. gerne wissen, wo und wann Kasabian demnächst Konzerte geben (Nicht, dass die Chance bestünde, das München auf der Liste wäre, aber dennoch…), und somit böte sich der API-Aufruf artist.getEvents zur näheren Betrachtung an: Welche Parameter hat er, wie muss er ausgeführt werden und wie sieht die Antwort aus?
Wir sehen, dass es zwei Parameter gibt (“artist” und “api_key”, beide benötigt) und dass die Antwort ein XML-Dokument ist, dass die Wurzel “lfm” hat, anschließend den Knoten “events” und viele Kindknoten “event”, die die einzelnen Konzerte enthalten. Diese wiederum besitzen Werte für die auftretenden Künstler, den Ort, die Zeit, Ticketverkäufe, etc… Das Beispiel von der API-Seite:
<events artist="Cher" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" total="4">
<event>
<id>599858</id>
<title>Cher</title>
<artists>
<artist>Cher</artist>
<headliner>Cher</headliner>
</artists>
<venue>
<name>The Colosseum at Caesars Palace</name>
<location>
<city>Las Vegas</city>
<country>United States</country>
<street></street>
<postalcode></postalcode>
<geo:point>
<geo:lat>36.2265501474709</geo:lat>
<geo:long>-115.0048828125</geo:long>
</geo:point>
<timezone>PST</timezone>
</location>
<url>http://www.last.fm/venue/8841108</url>
</venue>
<startDate>Sat, 16 Aug 2008</startDate>
<startTime>19:30</startTime>
<description></description>
<image size="small">...</image>
<image size="medium">...</image>
<image size="large">...</image>
<attendance>42</attendance>
<reviews>0</reviews>
<tag>lastfm:event=669027</tag>
<url>http://www.last.fm/event/599858</url>
<website>http://...</website>
<tickets>
<ticket supplier="...">http://...</ticket>
...
</tickets>
</event>
...
</events>
[Concept] Generischer API-Zugriff
Eines der größten Hindernisse beim Zugriff auf die Cloud, also die riesigen Datenmengen, die im Internet schweben, sowie die darauf basierenden Dienste, ist die Tatsache, dass die vielen verfügbaren APIs oftmals grundsätzlich verschieden sind. Dementsprechend ist es schwer, die eigene Arbeit, das eigene Wissen auf unterschiedliche Dienste/WebServices/APIs anzuwenden oder zu recyclen. Man beginnt meist wieder bei Null – und sei es bloß, die bereits fertige Implementierung eines anderen zu verstehen.
Mein Problem begann beim Last.FM-Webservice: wie kann ich dessen Funktion möglichst einfach zugänglich machen, ohne Flexibilität zu verlieren? Ich wollte nicht auf eine bereits bestehende Lösung zurückgreifen, da dort womöglich viel mehr angeboten als letztendlich benötigt wird; genauso sollte keine neue, nur für Last.FM nutzbare Implementierung geschaffen werden, sei sie auch noch so einfach zu verwenden – irgendwann müsste dann doch wieder von vorne begonnen werden… Eine neue Abstraktionsschicht musste her, eine vereinfachte, für den Otto-Normal-Programmierer sinnvolle Minimal-Version von WSDL quasi. Etwas, das leicht zu erlernen und zu verwenden ist, ohne unnötigen Ballast.
Den Rest dieses Beitrags lesen »
nginx = Wow!
Nachdem ich ja diese Woche mit meinem Blog den Hoster gewechselt habe, stand ich vor einem kleinen Problem: der vServer, den ich mir angemietet habe, schien zeitweise extrem instabil, hing manchmal fest und tat gar nichts mehr.
Eine kleine Analyse brachte das Problem zutage: der installierte Apache 2 Server fraß die Resourcen auf, anscheinend beim Versuch, sich mit der MySQL-Datenbank (die ich zwecks einfacher Weiterbetreibung dieses Blogs behalten habe) zu verbinden. Und egal, wo ich an der Konfiguration herumgeschraubt habe, es hat nichts gebracht.
Also bin ich einen anderen Weg gegangen: ein neuer Webserver musste her. Und hierbei fiel mein Auge auf nginx (Engine X). (Homepage) Eine kurze Installation und eine unglaublich einfach zu erledigende Konfiguration später, lief er dann auch schon. Und siehe da: keine Abstürze, keine langen Wartezeiten. Einfach Wow!
Jetzt muss ich nur noch cakePHP zum Laufen bekommen, dann wäre die Welt perfekt… Läuft.
Umzug vollbracht
So, seit eben liegt diese Seite bei meinem neuen Hoster, der synergetic AG. Hat jetzt dann doch eine Woche gedauert, weil ich vergessen hatte, ein Formular an die DeNIC zu schicken. Shame on me…
Aber jetzt sollte wieder alles funktionieren. Wenn nicht, bitte bescheid sagen!
Update: Um das Forum kümmere ich mich morgen.
[Release] LeSharp 1.2.2
Heute habe ich (weil ich einfach vor Ewigkeiten vergessen habe, das zu machen) eine ausgebesserte Version von LeSharp online gestellt. Im Vorgänger hat Pico nicht mehr richtig funktioniert, aber die Tatsache, dass sich darüber niemand aufgeregt hat, nehme ich jetzt einfach mal positiv auf… Wenn weiter Probleme mit LeSharp bestehen, bitte melden!
Download:
https://sourceforge.net/projects/lastsharp/files/lesharp/LeSharp%201.2.2/LeSharp1.2.2.zip/download
Aktuelle Situation: Stress.
Ich möchte diesen Artikel nutzen, um kurz meine aktuelle Situation zu beschreiben und mich im Zuge dessen dafür zu entschuldigen, dass ich diese Seite und meine Projekte im Moment eher ruhen lasse.
Zum einen bin ich letzten Samstag umgezogen (der klassische Studentenweg: von Zuhause weg und in eine 2er-WG) und da jetzt dann doch ziemlich eingebunden. Ich hab noch nichtmal ein Bett… (Lieferzeit: 3 Wochen)
Seit September arbeite ich zudem als Werkstudent bei Telefonica O2 Germany. Die 20h-Woche ist jetzt vielleicht nicht sooo auslastend, aber es summiert sich dann doch.
Zuguterletzt geht dann demnächst auch die Uni wieder los, was mein Pensum dann auf 50h die Woche erhöht. Aber mei, wir sind jung – wenn wir jetzt sowas nicht packen, wann dann?
Jedenfalls werde ich alle offenen Kommentare beantworten, sobald ich Zeit habe. Ebenso wird es dann neue Versionen der einzelnen Programme geben. Danke für’s Verständnis!
Scripe. Oder: Warum eine Scriptsprache auch nur eine Suppe ist.
Es ist wohl aufgefallen, ich erwähne es trotzdem: Seit einiger Zeit arbeite ich an einem Prinzip, dass es jedem Interessierten ermöglichen soll, eine eigene Script- oder Programmiersprache zu entwerfen. Meine theoretischen Überlegungen, so langweilig sie auch manches Mal seien mögen, habe ich in einer Reihe von Artikeln festgehalten; damit ich diese Texte aber auch schreiben konnte, musste ich immer ein kleines Stückchen vorausdenken und einiges an implementierungstechnischer Vorarbeit leisten.
Und heute war ich dann soweit, dass ich eine gar nicht so üble Version vor mir hatte, die ich nun (nicht detailliert, eher angeberischerweise 
) präsentieren will. Vorhang auf für Scripe!
Wie entwickle ich meine eigene Scriptsprache? (Teil 3: Syntax)
Nun, wie weit sind wir bisher? Wir haben einen Lexer, der unsere Eingabe in Einzelteile spaltet, und wir können einfache Ausdrücke in eine verwertbare Form bringen. Was wir bisher noch nicht (bewusst) gemacht haben, ist, einen Ausdruck zu analysieren und zu prüfen, ob er sinnvoll ist oder nur unzusammenhängend aneinandergereihte Token enthält.
Zur Erinnerung: sowohl “1+2+3″ als auch “1+(” wären Zeichenfolgen, die der Lexer akzeptieren und ohne zu meckern zerkleinern würde. Das ist auch in Ordnung so, da die syntaktische Prüfung ohnehin eher Aufgabe des Parsers ist. Aber was genau gilt es denn dabei zu beachten?
“Syntaxfragen”
- Sind genau so viele öffnende wie schließende Klammern vorhanden und passen diese zusammen?
- Stimmt die Zahl der Parameter, mit der eine Funktion aufgerufen wird?
- Stimmen die Parametertypen, mit denen eine Funktion aufgerufen wird? (“+” arbeitet normalerweise nur auf Zahlen, der Punkt z.B. in PHP auf Strings, etc…)
- Befinden sich Operatoren an den richtigen Positionen? (Die Fakultät einer Zahl wird z.B. durch Anhängen eines Ausrufezeichens gekennzeichnet: “3!”)
- Darf eine Funktion geschachtelt vorkommen? (z.B. wäre “echo(echo(1))” eher sinnlos, wenn “echo” die Ausgabefunktion ist)
- Darf eine Funktion/ein Konstrukt in einer untergeordneten Umgebung vorkommen? (Das wäre z.B. der Fall, wenn man Funktionsdefinitionen innerhalb von Funktionsdefinitionen zulässt.)
Neben der Syntax gibt es noch weitere Punkte, die eine Programmier-/Scriptsprache ausmachen. Eine Auflistung findet man z.B. hier.
Wie entwickle ich meine eigene Scriptsprache? (Teil 2: Grundlagen des Parsens)
Einen wichtigen Schritt haben wir an dieser Stelle bereits hinter uns: Der hier beschriebene Lexer verwandelt eine Eingabesequenz wie “1+3*(4-2)” in eine Liste von Tokens mit Typ und Wert:
zahl : 1 operator : + zahl : 3 operator : * open : ( zahl : 4 operator : - zahl : 2 close : )
Damit haben wir eine maschinenlesbare Repräsentation des gewünschten Ausdrucks – allerdings keine Garantie dafür, dass dieser syntaktisch korrekt ist. Ebensowenig kann eine Maschine, die diese Liste nun vorgelegt bekommt, “einfach mal so” den Wert des Ausdrucks berechnen, da ihr Informationen zur Auswertungsreihenfolge fehlen. (Wenn 1+3 zuerst berechnet wird, lautet das Ergebnis 8, wenn 3*(4-2) zuerst berechnet wird, lautet es 7.)
Wir brauchen also eine Darstellung unseres Ausdrucks, die bezüglich der Reihenfolge der Auswertung eindeutig ist und eine Maschine, die diese erstellt – und wie könnte es anders sein: auch dieses Problem wurde bereits einmal gelöst.
Wandeln wir also auf den Spuren von Edsger W. Dijkstra.
Wie entwickle ich meine eigene Scriptsprache? (Teil 1: Der Lexer)
Die Aufgabe, die ich mir hier gestellt habe, eine eigene Script- oder Programmiersprache zu entwickeln, bringt so ihre Probleme mit sich. Wie und wo fange ich an? Ist das nicht zu viel für mich? Und sollte ich nicht auf bereits vorhandene Bibliotheken zurückgreifen, anstatt alles von Grund auf neu zu entwickeln?
Vor allem die letzte Frage kann einem zu schaffen machen. Warum etwas möglicherweise nicht gut funktionierendes entwickeln, wenn es doch überall schon tausendfach durchdachte Lösungen gibt? Immerhin lautet doch eine der obersten Regeln in der Softwareentwicklung:
Don’t reinvent the wheel!
Nun, ich bin Informatikstudent. Ich will wissen, wie die Dinge “unter der Haube” aussehen, ich will lernen. Und wenn alle nur noch auf vorgefertige Bibliotheken zurückgreifen, weiß doch bald keiner mehr, was dem Zauber eigentlich zugrunde liegt… Dementsprechend:
Don’t reinvent the wheel, unless you plan on learning more about wheels!
Diese Anleitung soll jedem helfen, der interessiert daran ist, was im Inneren eines Interpreters oder Compilers eigentlich (ungefähr so) abläuft. Ich selbst habe gerade erst das zweite Semester hinter mir, d.h. allzu theoretisch wird es hier nicht und jeder mit ein wenig logischem Denken und genug Engagement sollte es hinbekommen, meinen Ausführungen zu folgen.
Lasset uns beginnen.