Archive for the ‘non-rails’ Category

Ajax-Push mit “Apuq”: Mein Vortrag auf dem Barcamp Ruhr 2

Sonntag, März 29th, 2009

Heute habe ich auf dem Barcamp Ruhr 2 meinen ersten Vortrag gehalten. Es ging um eine Ajax-Push-Lösung (ich habe es Apuq genannt- Ajax PUsh Queue). Apuq ist ein Ruby-Server der eine Schnittstelle zum Browser und zur Webanwendung bereit stellt und Ajax-Requests des Browsers entgegennimmt.

Ich werde dazu später nochmal die Folien online stellen (und vielleicht die Demo)- Sinn der Sache ist der, dem Browser mit minimaler Verzögerung (< 1s) Nachrichten schicken zu können, die dort per Javascript verarbeitet werden (z.B. für einen Chat).

Ich schreibe diesen Artikel eher als Anlaufstelle für die Zuhörer. Ich habe ja viel Feedback über ähnliche und andere Lösungen für das Ajax-Push-Problem bekommen (Dank an @captainhagbard, @sippndipp u.a. die ich nicht mehr tracken konnte [korrigiert mich, wenn die Namen falsch waren]) Ich werde weiter an “Apuq” arbeiten (da ich es auch beruflich benötige). Am vielversprechendsten schien mir da der Hinweis von @moeffju, eine webbasierte Jabber-Lösung einzusetzen. Mehr als die entsprechenden Keywords notieren konnte ich aber in der Richtung noch nicht.

Wenn ihr euch für die weitere Entwicklung des Projekts interessiert dann verfolgt doch einfach die Kommentare zu diesem Artikel. Ich werde dort Updates posten, wenn es Neuigkeiten zur Entwicklung gibt.

Mehr Seiten im Google-Index durch schnellere Antwortzeiten

Mittwoch, März 11th, 2009

PJ Hyett von GitHub hat in seinem Blog eine Einsicht offenbart, die äußerst SEO-Relevant ist:

Sinkt die Antwortzeit des Webservers, crawlt GoogleBot mehr Seiten.

Diese Entdeckung machte PJ nachdem er am Caching der Seite gebastelt hatte und damit die Ladezeiten erheblich reduzieren konnte. Er veröffentlicht auch gleich einen Screenshot aus den Google Webmaster Tools- dort ist deutlich zu erkennen, dass mit gleichzeitigem Sinken der Antwortzeit (rote Linie) die Anzahl der gecrawlten Seiten (blau) ansteigt.

githubcrawling

Nunja, GoogleBot wird wohl kaum eine single threaded Anwendung sein die auf die Antwort des Webservers warten muss und somit die Anzahl der gecrawlten Seiten proportional zur Antwortzeit sinkt. Vielleicht ist dieser Mechanismus auch ganz selbstlos und soll verhindern, dass der Crawler zuviel Last auf dem Webserver erzeugt?

Wie dem auch sei, es ist ein weiterer guter Grund in einer ruhigen Minute die Antwortzeiten von Spekunauten.de ein bisschen aufzupeppen.

P.S.: Ja, ich habe in diesem Posting wahllos Keywords markiert um zu sehen was Google damit anstellt.

Skriptsprachen einbinden in C#

Freitag, Mai 2nd, 2008

Für einen guten Kunden erstelle ich eine Art Datamining-Software, mit der neue Suchvorschriften ausprobiert werden sollen. Bisher habe ich den algorithmischen Teil dieser Vorschriften direkt in C# programmiert, die meisten Parameter konnten aber über eine GUI verändert werden.

Um noch flexibler zu sein, wollte ich eine GUI erstellen, mit der man Ablaufdiagramme entwerfen kann. Dann fiel mir das Scripting-Framework von Java 6, über das ich vor einer Weile gelesen hatte, wieder ein. Ich war damals sehr beeindruckt von den Möglichkeiten die sich da eröffneten und wollte das immer mal ausprobieren.

Eine Skriptsprache ist nicht schwer zu lernen und ermöglicht es schneller, einen Algorithmus in das Programm zu übertragen als mit einem grafischen Ablaufdiagramm.

Schlug nun die große Stunde des Java 6 Scripting-Frameworks? Nein, denn leider war ein großer Teil der Anwendung schon in C# implementiert. Und .NET ist nicht Java. Es gibt sicher Lösungen, um Java und .NET zu verbinden, aber warum so kompliziert wenn es auch einfacher geht?

Die Skriptsprache Lua

Nach kurzem googlen fand ich ein Tutorial zum Einbinden von Lua in C#. Lua lässt sich in viele verschiedene Sprachen einbinden und wird häufig in Computerspielen zum Steuern des Spielablaufs verwendet.

Die Benutzung in .NET ist äußerst einfach (Wermutstropfen: Es werden drei zusätzliche DLLs benötigt).

Benutzung

Benötigt wird LuaInterface, eine .NET-Bindung für Lua. Achtung, die aktuellste Version (2.0.1) habe ich mit nicht zum laufen bekommen, da dort die Datei luanet.dll fehlt- es geht aber Problemlos mit LuaInterface-1.5.3. Aus diesem Archiv müssen die drei .dll-Dateien aus dem Verzeichnis “built” das Projektverzeichnis der C#-Anwendung entpackt werden. (Die Dateien müssen auch im Verzeichnis des Executables liegen oder in einem durch PATH erreichbaren Verzeichnis). Anschließend in Visual Studio eine Referenz auf LuaInterface.dll setzen- fertig. (hier gibt es eine bebilderte Anleitung dazu).

Von .NET nach Lua und zurück

Um Lua zu benutzen, erzeugt man einfach eine Instanz der Klasse Lua. Diese stellt die Methode DoString bereit, welche Lua-Code innerhalb des übergebenen Strings ausführt.

Die Instanz dieser Klasse kann auch als Hash verwendet werden, wobei die Hash-Keys Namen der Variablen im Lua-Kontext darstellen. Das Lua-Objekt stellt ferner noch die Methode RegisterFunction bereit, mit der eine C#-Methode in Lua bereitgestellt werden kann! Auf diese Weise kann man dem Skriptprogrammierer eine Domain-Specific Language zur Verfügung stellen, wie es auch für Rails Integration-Tests empfohlen wird (ok, dieses Thema ist nur entfernt verwandt).

Ich möchte jetzt nicht weiter auf Details zu Lua und C# eingehen, da dies nicht Thema dieses Blogs ist (das verlinkte Tutorial ist außerdem ausführlicher als ich es hier darstellen könnte). Weil ich aber so positiv überrascht von der einfachen Handhabung des Lua-Interpreters war, wollte ich euch diese Erfahrung nicht vorenthalten :-)