Da bin ich auf die Idee gekommen, ein zweites Fenster zu öffnen, das den Flash-Film beinhaltet und die Verbindung zum Socket-Sever aufrecht erhält. Kommende Daten vom Server werden dann auf die Hauptseite mittels Javascript gesendet bzw. Daten die zum Server geschickt werden, werden mit Javascript zum zweiten Fenster geschickt, dass die Daten dann zum Server sendet. Eine Brücke quasi zwischen Hauptfenster und Perl-Server.

Hauptproblem war die Referenz des zweiten Fensters, also des Brücken-Fensters, nach jedem neuen Seitenaufruf wiederherzustellen; denn ein Browser leidet nach jedem neuen HTTP-Request an chronischem Gedächtnisverlust. Er weiß von gar nichts mehr. Hä, welches zweite Fenster, welche Socketverbindung? Nach jedem neuen Seitenaufruf muss man die Hauptseite daran erinnern, dass eine Brücke existert, die es auch zu benutzen gilt.

Nach längerem Rumprobieren bin ich auf die Idee gekommen zu ermitteln wann die Hauptseite gewechselt wird, um dann noch schnell eine Funktion im Brückenfenster aufzurufen: “Du, ich geh jetzt einen neuen Link laden, schick mir doch die Referenz zu deinem Fenster, wenn ich wieder da bin!”.
Mit der Javascript-Funktion onbeforeunload haut das auch hin: wenn eine Seite verlassen wird, oder besser gesagt kurz vorher, ruft das Hauptfenster die Funktion passWindowRef auf der Brücke auf. Diese versucht dann in einer setInterval-Schleife im Abstand von 100 ms die Referenz an das Hauptfenster zu senden. Daten, die in der Zwischenzeit ankommen aber nicht an das Hauptfenster gesendet werden können, weil es noch nicht vollständig geladen wurde, werden gequeued, also in einem Array zwischengespeichert und dann, wenn alles klar ist, nachgeschickt.
Das funktioniert perfekt, Chat-Unterhaltungen usw. bleiben trotz Seitenwechsel erhalten oder besser gesagt werden einfach wieder aufgebaut in ihrem aktuellen Zustand.

Dann bin ich auf die Idee gekommen mir die ganze Sache mal im Opera anzuschauen. Im Firefox, Chrome ja sogar Internet Explorer funktioniert alles prächtig… Aber dann musste ich feststellen, dass der Opera nicht nur rumzickt, nein er weigert sich total das onbeforeunload-event zu triggern.
Eine Katastrophe für mein ganzes sauer erarbeitetes Konzept. Ein hoffnungsloser Zustand. onbeforeunload wird einfach ignoriert!

Nun gut, dann bin ich auf die Idee gekommen mit window.opera nachzuschauen, ob der Opera benutzt wird, um dann die Referenz-senden Geschichte anders zu lösen. Nämlich bei jedem neuen Seitenaufruf durch einen ajax-request ein kleines php-script aufzurufen, welches an einen unix-Server sendet: “hallo, ich bin jetzt da, richte doch dem Zweitfenster aus, dass ich die Referenz zu ihm brauche!”. Der unix-Server sendet dann an den Haupt-Socket-Server die Nachricht, der dann dem Zweitfenster mitteilt, dass es die Funktion passWindowRef aufruft, die dann die Referenz zum Hauptfenster sendet.
Das nenne ich mal Kommunikation, umständlicher gehts wohl nicht: Aber es funktioniert.
Das schöne am Programmieren ist einfach, dass es, egal was man sich vornimmt, immer eine Lösung gibt, meistens sogar mehrere. Man darf einfach nicht aufgeben.
Ob sich die ganze Sache jetzt gelohnt hat, nur um das iframe loszuwerden? Ich glaube schon.

Kurzum ich bin einfach bei Codeigniter geblieben. Die Dokumentation ist spitze, für Anfänger und OOP-Nullchecker wie mich ist es unkompliziert, und es ist auch wirklich schnell.

Aber nun zum eigentlich Thema: gestern habe ich zufällig das Zikula-Framework entdeckt. Ein Framework speziell zum erstellen von Communities. Das ist doch genau das, was ich suche.
Ich habe nicht lange gefackelt und hab mir das Framework runtergeladen. Es gibt wirklich sehr sehr viele Module dafür, von der Profilansicht zur Userverwaltung zum Forum zum Private-Nachrichten-Modul etc. Praktisch alles schon fertig programmiert, eine sofort benutzbare Community.
Man kann auf der Herstellerseite von Zikula einfach auswählen, welche Module, Plugins und Themes man haben will und kann dann ein zusammengestelltes Paket downloaden.

Nachdem ich aber mein zusammengeklicktes Zikula installiert habe, ist mir auch gleich aufgefallen, warum Zikula für micht auf keinen Fall in Frage kommt. Schon auf der Zikula-Page selbst ist mir die Lahmarschigkeit der Seite aufgefallen; und diese ganzen vorgefertigen Module haben ihren Preis: Performance! Ein Seitenaufbau dauert extrem lange, ich schätze mal so um die 2 Sekunden, und das kann einfach nicht sein. Selbst meine technisch komplett veraltete Singlebörse baut eine Seite mit dutzenden Userbildern, und -informationen aus der Datenbank in so 0.2 Sekunden auf. Gut, nur der PHP-Teil, das Rendering der Seite dauert dann vielleicht nochmal 0.3 Sekunden - egal… Zikula kommt leider daher wie ein alter Opa mit Krückstock.

Auch die Module habe ich mir angeschaut und denke mal ich schreibe meine eigenen Libraries und Plugins für Codeigniter, da weiß ich wenigstens woran ich bin und bin flexibel. Die Startseite meiner Codeigniter-Singlebörse (ich habe immerhin schon die Startseite fertig, man kann sich einloggen und es werden Facebook-ähnlich Userupdates aus der Datenbank gefischt, Userpics angezeigt etc.) lädt im Vergleich zu Zikula wie der Blitz.

Ich kann also nur von Zikula abraten, weil die Performance einfach sehr schlecht ist, auch wenn die Idee löblich ist, ein zusammenklickpaares CMS anzubieten (ich hab nicht soooo genau hingesehen, aber was ist an Zikula eigentlich ein Framework?).

Diesmal war es ein PNG-Bild. Ein Farbüberlauf in einem DIV, der in eine hellblaue Farbe führte. Beim Firefox und den anderen Browsern war der Überlauf stufenlos, d.h. man hat das Bild selbst gar nicht gesehen.

Beim IE konnte man einen direkten Schnitt erkennen, das PNG-Bild war hier seltsamerweise dunkler als in den anderen Browsern, und auch dunkler als in Photoshop. Strange?

Es half nur das Bild als JPG abzuspeichern und zu verwenden.

Es ist sicher nicht das beste Framework, aber für die kleine Seite, die ich gemacht habe, ist es ausreichend. Ausserdem ist es gut dokumentiert.

Ich habe für eine Kneipe eine kleine Seite gemacht, eine Visitenkarte im Netz quasi. Ich habe versucht, es idiotensicher zu machen, d.h. ich habe ein miniCMS programmiert, der Admin muss sich nur einloggen und kann direkt auf den Seiten die wichtigsten Sachen ändern, z.B. die Preisliste bearbeiten, neue Kategorien hinzufügen, löschen, Artikel hinzufügen, löschen - ich hab mich dabei ziemlich vom phpmyAdmin inspirieren lassen.
Für das hochladen von Bildern habe ich ein fertiges Java-Applet eingebaut, das die Bilder gleich clientseitig verkleinert und es ermöglicht auch mal 200 Bilder auf einmal hochzuladen. Ausserdem habe ich ein bisschen AJAX eingebaut, sodass man zum Bestätigen von Admin-Lösch-Aktionen nicht die ganze Seite reloaden muss, sondern es poppt ein “Fenster” auf, also ein position:absolute-zIndex-Div und die Datenbankgeschichte wird über xmlhttprequest erledigt.

Programmieren ist eher mein Ding, im Webdesign selbst bin ich noch eine ziemlich Niete. Aber ich habe mich mal im Netz umgeschaut und mich inspirieren lassen. Ich glaube mit dem Webdesign verhält es sich ähnlich wie mit anderen kreativen Hobbies: erst kopiert man, schaut ab, bevor man seinen eigenen Stil findet.

Hier mal die Seite Kneipenseite.

Weil ich grad dabei war, habe ich gleich noch eine andere Seite mit Codeigniter gemacht, vom Design her ist sie der Kneipenseite sehr ähnlich.

Da habe ich wieder so eine geniale Idee gehabt, die beim zweiten mal darüber nachdenken doch wieder Müll war. Man kann mittles Flash ein Bild malen und es an eine Email-Adresse schicken. Die Seite soll eigentlich für Kinder sein, für Kinder, die z.B. Eltern oder Freunden, Onkeln etc., die gerade nicht da sind, Bilder malen und schicken wollen. Das geniale ist natürlich, dass Kinder, die Bilder malen so um die 6 Jahre alt sind, oder noch jünger… Und ich weiß ja nicht, ob die schon in der Lage sind, Emailadressen einzutippen.

Die Seite ist auch noch auf Englisch, weil ich mir erhofft habe so mehr Besucher zu bekommen, die dann zufälligerweise mal auf die Adsense-Links klicken. Mein Englisch ist ziemlich beschissen ist mir aufgefallen ;).

Aber es war ganz interessiert mit amfphp ein Bild von Flash an den PHP-Server zu schicken und dort per Email abzuschicken. Dazu wird das gemalte Bild in Flash zu einem PNG-Bild encoded, in ein Bytearray konvertiert und dann an mit amfphp an eine PHP-Funktion geschickt.

paint-a-picture.net

Da ich mich zur Zeit mit Webdesign beschäftige, ist es höchste Zeit mal diesen hässlichen Blog ein bisschen aufzupeppen, der sieht wirklich scheusslich aus.

Meine Singlebörse müsste auch mal aufgeräumt werden, argh. Die neuen Seiten sehen schon etwas besser aus, lange nicht wirklich geil, aber im Vergleich. Ausserdem habe ich sie mit W3C validiert und null Fehler und darf jetzt diese XHTML1.0 Buttons auf meine Seiten kleben hihi!

Meine Singlebörse hat ja so um du 140 Fehler, au Weia. Ich müsste sie eigentlich direkt neu schreiben. Muss mir noch ein passendes Framework suchen, ein CMS wäre auch nicht verkehrt, aber irgendwie würde ich mir mein eigenens zusammenbasteln.

Naja, kommt Zeit kommt Rat. Und jetzt kommt auch der Sommer.

EDIT 26.06.2010:
Habe nun meine Singlesbörse komplett neu geschrieben mit Codeigniter. Momentan liegt sie zwar noch auf dem localhost aber bald lade ich sie hoch. Ich habe so 2,5 Monate gebraucht um alles neu zu schreiben.
Es ist ein gutes Gefühl seine “eigene” Seite programmiert zu haben, entstanden ist Bayernculture nämlich aus einem phpBB-Forum.

Das jetzige Bayernculture ist einfach scheußlich, freue mich schon, wenn ich die Seiten austauschen kann.

Codeigniter ist geil!

Was das heisst? Die IP-Adresse stammt von meinem lokalen PC, also der, der bei mir zuhause steht.
Faszinierend. Wie kommt der Google-Spider nur dazu bei mir zuhause aufzutauchen? Einem Link kann er ja nicht gefolgt sein. Wie bahnt sich so ein Spider seinen Weg? Wie hat der nur meinen PC gefunden, ich meine Bayernculture kennt er ja, aber nicht DAS Bayernculture auf meinem Localhost!

Seltsam seltsam!

EDIT: Dieser Artikel ist bereits nach 2 MINUTEN gespidert worden! Habe gerade selbst geschaut zum Thema “Google spidert Localhost” - und siehe da: mein gerade geschriebener Artikel. *lol*

Ich habe heute ein bisschen damit herumgespielt und bin mit dem Ergebnis echt zufrieden. Jetzt kann ich endlich ein cooles Space-Spiel programmieren, oder es zumindest versuchen.

Entweder werde ich ein festes Universum erzeugen, und das Ergebnis in einer Datenbank speichern… So um die 1000 verschiedene Planeten mit zufallsgenerierten Namen, oder es wird immer bei jedem Spielbeginn ein neues Universum erstellt. Wie auch immer, Ideen habe ich, nur mit der Umsetzung hapert es meistens (ich träume von einer Art Galactic Civilziations 2 Spiel, mit Multiplayer. Mal sehen was ich wirklich daraus mache.)

Aber seht euch einfach mal das Sternensystem an. BTW ich bin kein Grafiker, mich interessiert eher dieses Zufalls-Zeugs. (Ruhig öfter mal den Browser aktualisieren für andere Ergebnisse.)

Perlin Nose, aha noch ein paar Keywords einbaue, SEO Haha!

Perlin Noise und Flash AS3 Actionscript, zufallsgeneriertes Sternensystem.

Achso ja der Link, den hätt ich ja fast vergessen…

Häng zuviel vorm PC!

Perlin Noise Demo

Bye bye!

Ach ja, klickt ruhig auf die Planeten um das Surface zu sehen. Sieht zwar nicht besonders aus aber die Möglichkeiten sind faszinierend (Stichwort Tilemap).

Mit Perl ist viel mehr möglich als „nur“ dynamische Webseiten zu erstellen, auch auf die Socket-API von C lässt sich darauf zugreifen und in Verbindung mit Flash als Client lassen sich damit Chats und sogar Multiplayer-Spiele realisieren. Was ist ein Socket? Um es kurz zu machen: ein Socket ist eine Schnittstelle in einem Netzwerk, die es ermöglicht Daten beinahe in Echtzeit zu übertragen. Dabei fungiert ein Perl-Script als zentraler Server, lauscht auf Verbindungen und eingehende Daten, parst die Daten und sendet sie bei Bedarf weiter an andere Computer, die auch mit dem Perl-Server verbunden sind.
Zum Vergleich: ein Apache-Webserver macht eigentlich das selbe. Er lauscht auf sogenannte HTTP-Requests, die wir senden, wenn wir einen Link anklicken. Der Webserver parst die Daten und liefert uns die gewollte Seite aus. Der vorteilhafte Unterschied zwischen einem Apache-Webserver und einem Perl-Socket-Server liegt aber darin, dass es nicht ganze HTML-Seiten sind, die über die Leitungen fließen, sondern schlanke Strings.

Kleines Beispiel: Wir klicken einen Button in Flash an, auf dem steht: Zeig mir die Server-Zeit.
Flash sendet durch einen (TCP-)Socket den String „[aktion:serverzeit]\0“ an den Perl-Socket-Server. Das „\0“ fügt der Flash-Player übrigens automatisch hinzu, um damit das Ende des Strings zu signalisieren.
Der Perl-Server parst den String und findet heraus: aha, ich soll die Serverzeit ausliefern. Als Antwort schickt er nun den String „[serverzeit:12:32:54]\0“.
Es sei an dieser Stelle auch gleich erwähnt, dass die XMLSocket-Klasse nicht zwingend Strings im XML-Format verlangt. Und das ist auch gut so, denn ein
„serverzeit“ im vergleich zu „[aktion:serverzeit]“ ist ganz klar bandbreitenschonender, weil man einfach viel weniger Daten senden muss. Natürlich hätte ich auch „{aktion}{serverzeit}“ schreiben können oder auch „[a][s]“ oder gar „[s]“. Welches Protokoll man auch verwendet, solange man es selbst versteht und solange es logisch ist, passt alles.

Perl, der Meister der Regular-Expressions. Damit wird es sehr einfach, die Daten zu parsen.

$flashDaten =~ /\[aktion:(\w+)\]/;
my $aktion = $1;

if ($aktion eq „serverzeit“) {
my ($sec,$min,$hour) = localtime(time);
my $anwort = „[serverzeit:$hour:$min:$sec]\0“;
sende_zurück($antwort);
}

Ok, ich glaube man hat mich verstanden: Sockets dienen hauptsächlich dazu möglichst kleine Daten möglichst schnell zu senden/empfangen, und bieten damit die Möglichkeit viele Clients gleichzeitig zu bedienen. Man stelle sich einen Chat vor auf dem sich gerade hunderte User unterhalten. Die Nachrichten müssen so schnell wie möglich weitergeleitet werden, um überhaupt einen Chat möglich zu machen. Es reicht nicht, die Nachrichten in einer Datenbank zu speichern und alle paar Sekunden mittels eines HTTP-Requests die Seite zu aktualisieren. Es gibt zwar solche Chats, z.B. mit PHP, MySQL und Javascript (für automatische HTTP-Requests) realisiert – aber die taugen doch nicht wirklich was; und zwingen mit steigender Useranzahl selbst die stärksten Server in die Knie.

Ein ganz nützliches Perl-Modul, mit dem die Arbeit mit Sockets zum Kinderspiel wird, ist das POE-Modul. POE heisst Perl Object Environment, es ist objektorientiert und dadurch ist die Syntax auch leicht verständlich.

Was ist POE? POE ist ein Framework, welches es wie ein Betriebssystem erlaubt, mehrere Prozesse in einem Perl-Skript gleichzeitig laufen zu lassen, über sogenannte Sessions. Es lassen sich damit wunderbare Programme schreiben, in denen verschiedene Sessions sich um verschiedene Aufgaben kümmern. Da es für viele Bereiche – vor allem im Netzwerk-Bereich – vorgefertigte POE-Module gibt, schreibt sich ein Socket-Server damit fast schon von alleine. Die Hauptarbeit überlassen wir einfach POE und können uns direkt um die lustigen Sachen kümmern wie die Logik unseres Servers, Datenparsen usw.

Ladet euch das POE-Framework von CPAN herunter und installiert es. Falls ihr keinen eigenen Server habt sondern einen Webspace ohne Root-Zugang, kein Problem. Erstellt einfach einen Ordner auf dem Webspace, ladet dort das POE-Modul hoch und inkludiert es anstatt einfach nur:

use POE;

mit…

use lib „dein/absoluter/pfad/zum/POE-Ordner/lib“;
use POE;

Nun aber endlich mal zu einem Beispiel. Ich zeige euch einen kompletten Perl-Socket-Server, der eigentlich zwei Server beinhaltet: der eigentliche Hauptserver kümmert sich um den Flash-Film, der andere Server - nennen wir ihn Policy-File-Server - kümmert sich um die Auslieferung einer virtuellen XML-Datei, dem sogenannten Policy-File. Policy-File, was ist das?
Nun ja, machen wir es kurz: Adobe verlangt aus Sicherheitsgründen die Auslieferung eines virtuellen Policy-Files, quasi eine Datei in der geschrieben steht, dass der Flash-Film dazu berechtigt ist auf bestimmte Ports des Servers zugreifen zu dürfen.
Diese Datei liegt in unserem Perl-Skript in einem String und wartet nur darauf, in die große weite Welt verschickt zu werden. Sie sieht, bei mir zumindest, so aus:

my $xml = ‘‘;

Wie man sieht, steht darin geschrieben, dass localhost auf den Flash-Film zugreifen darf, und der Flash-Film auf den Server auf Port 5006.

Auf Port 5005 lauscht ein zweiter Server, also eine zweite POE-Session, die sich um nichts anderes kümmert als auf eine Verbindung und einen String „ \0“.
Schickt ein Flash-Film – oder wer auch immer – solch einen String, bekommt er als Antwort die $xml-Datei.

Ladet euch einfach die Quelltexte für den Actionscript-Client und den Perl-Server herunter. Schaut euch mal die Datei testServer.pl an.

Ganz kurz, was der Hauptserver macht: Er lauscht auf Verbindungen, akzeptiert diese, schreibt die Verbindungen oder besser gesagt die Referenzen dazu in das Array @connections, sendet eingehende Daten an die Verbindungen (im Array @connections, ausser an den Sender), löscht beendete Verbindungen wieder aus @connections (das ist wichtig, damit der Server nicht versucht Daten an bereits beendete Verbindungen zu senden – was zu einem sehr unschönen Programmabbruch führen würde). Daten parsen tut er nicht, aber falls er das tun soll, könnte es etwa so aussehen wie schon oben erwähnt, mit Regular Expressions:

$buff =~ /\[aktion:(\w+)\]/;
my $aktion = $1;

if ($aktion eq „serverzeit“) {
my ($sec,$min,$hour) = localtime(time);
my $anwort = „[serverzeit:$hour:$min:$sec]\0“;
$outbuffer{$client} .= $antwort;
$kernel->select_write($client, „event_write“);
}

Nun zum Flash-Teil. Wir erstellen nun einen Flash-Film, der einfach ein blaues Viereck zeigt. Dieses Viereck lässt sich verschieben, und wenn man es verschoben hat, sendet es die neuen Koordinaten des Vierecks an die anderen Flash-Filme, die noch mit dem Server verbunden sind. Die anderen Flash-Filme platzieren das Viereck dann an der neuen Position.

Ich zeige erstmal den Actionscript-Code. Es ist übrigens möglich den Code via der freien Flex-SDK
zu kompilieren, falls man kein Flash besitzt. Und das schöne an der Flex-SDK ist – außer dass sie nichts kostet – dass man sie auch unter Linux einsetzen kann. Da POE unter Windows nur zu Versuchszwecken taugt (POE verursacht zumindest beim strawberry-Perl unter Windows nach kurzer Zeit eine CPU-Auslastung von 100%) ist das natürlich sehr praktisch.
Falls ihr an der Flex-SDK interessiert seit, benutzt Google, ist leicht zu finden.

Erstellt in Flash einen neuen Film, speichert ihn und gebt in den Eigenschaften als Dokumentklasse TestSocket an. Mit TestSocket ist die Datei TestSocket.as gemeint, die ihr zusammen mit dem neuen Flash-Film in den selben Ordner kopiert. Oder kopiert die AS-Datei in den bin-Ordner der Flex-SDK und kompiliert den Code mittles Eingabeaufforderung bzw. Terminal dort mit mxmlc TestSocket.as. Danach bindet ihr die SWF-Datei in eine HTML-Seite ein und ladet diese zusammen mit der SWF-Datei auf euren Webspace bzw. xampp bzw. /var/www/ oder wo auch immer ihr eure Webseiten liegen habt hoch.

Startet nun den Server mittels Terminal oder Eingabeaufforderung und ruft über den Browser die HTML-Seite mit dem Flash Film auf. Wenn alles geklappt hat, macht weitere Fenster oder Tabs auf und verschiebt das Viereck. Es müsste nun auf allen anderen Seiten ebenfalls verschoben worden sein.

Ach ja, ein besonderes Schmankerl für die eigene Webseite ist es natürlich einen unsichtbaren Flash-Film laufen zu lassen, der eine Socket-Verbindung herstellt. So ist ein Datenaustausch auch ohne Seitenreload möglich. Dabei kann man Javascript als Brücke verwenden, um so empfangene Daten direkt im Browser auszugeben bzw. anzuzeigen. Man stelle sich einfach vor, dass ein User namens „Hans“ dem User mit der Uid 12 eine Nachricht schreibt, ganz normal über die Webseite. Nun wird eine Funktion in Javascript aufgerufen, die dem Flash-Film sagt, er soll eine Nachricht an den Server schicken, z.B. „[post][12][Hans]“. Der Server parst diesen String und findet heraus: aha, ich soll dem User 12 Bescheid sagen, dass er soeben Post von Hans bekommen hat. Der Server schickt an den Socket des Users 12 den String „[post][Hans]“.
Nun erscheint am rechten unteren Bildschirmrand des Postempfängers – der ja noch nichts von seinem Glück weiß, weil er die Seite noch nicht aktualisiert hat – eine kleine schicke Box, in der steht: „Sie haben Post von Hans!“. Posteingang-Benachrichtigung ohne Seitenreload beinahe in Echtzeit, realisiert mit einem TCP-Socket.

Sehr vorteilhaft ist es natürlich diesen unsichtbaren Flash-Film in einer Hauptseite laufen zu lassen, in der die eigentlichen Webseiten in einem iframe dargestellt werden. Warum? Weil sonst bei jedem neuen Seitenaufruf die Verbindung unterbrochen und dann wieder hergestellt wird.

Es gibt übrigens eine Javascript-Klasse, die diese Brücke herstellt, gebt mal in einer Suchmaschine „JSXML Bridge Javascript Flash“ ein. Diese Klasse arbeitet mit der ExternalInterface-Klasse von Flash.

Zuguterletzt noch zwei Punkte:
1.Warum muss ich jeden String, den ich vom Perl-Socket-Server an einen Flash-Client schicke mit einem „\0“ beenden? Weil Flash sonst ewig auf das Ende der Nachricht warten würde.
2.Kann jedes Programm, dass Socketverbindungen möglich macht, von jedem anderen Menschen dazu benutzt werden meine auf Port 5005 und 5006 lauschenden Server mit Nachrichten geradezu zu überfluten? Und ob. Stichwort Flooding. Leider können die Server nicht erkennen, ob Daten von einem Flash-Film, einem C++-Programm, einem anderen Perl-Skript oder von sonstwo geschickt werden. Hier ist es wirklich sehr wichtig, sich sichheitstechnisch abzusichern, will man nicht von seinem Webhoster gesperrt werden. Ich z.B. habe es so realisiert, dass nachdem sich ein User in meine Webseite eingeloggt hat seine IP-Adresse über einen UNIX-Socket an das POE-Skript gesendet wird; diese IP-Adresse wird für ein paar Sekunden erlaubt, d.h. Nur IP-Adressen werden gestattet, die praktisch „von oben“ ein okay bekommen haben, und das nur für ein paar Sekunden. Jede andere IP-Adresse wird gar nicht erst reingelassen bzw. sofort wieder rausgeworfen. „Tut mir leid, sie stehen nicht auf der Gästeliste!“. Ausserdem muss der Client auch seine Session-ID mitschicken, und es wird geprüft, ob diese in der Datenbank unter den eingeloggten Usern steht. Wenn nicht, auf Wiedersehen.

Okay, und das ist auch das Stichwort für mich, ich muss weg. Ich hoffe ich konnte dem einen oder anderen einen groben Einblick in die Welt der Sockets bieten und wünsche euch viel Spaß beim Erstellen von coolen Flash-Perl-Applikationen.

Das ging alles so schnell, dass es mir nicht gelang kritisch zu handeln. Sie hatte mir einfach die Konsumentenpistole an die Brust gesetzt und mir mit 20 Euro weniger gedroht; sie hat für mich die Entscheidung getroffen, es wäre doch blöd nein zu sagen, und ich ließ mich davon beeindrucken.
Klar, ich war ja auch noch im Halbschlaf und vielleicht bin ich einfach schwach. Jedenfalls hat sie mich überrumpelt.

So, nach dem „Gespräch“ bin ich mir dann wie ein Stück Vieh vorgekommen. Ein Stück Vieh in einer Herde, die heute alle noch gebrandmarkt werden müssen.

Leistungsgesellschaft. Der Mensch an sich zählt nichts. Er ist ein Objekt. Ein ohne weiteres austauschbares Objekt in einem kapitalistischen Projekt.

Klar, das wäre ja an sich nicht schlimm, denn jeder hat sein Privatleben. Aber in mein Privatleben wurde wieder einmal telefonisch eingebrochen und es wurde versucht mich zu überreden, mich zu überzeugen, mich zu manipulieren. Diesmal mit Erfolg.

Jetzt wo ich wach bin und wo ich über die Sache so nachdenke fällt mir ein ich hätte auch ganz anders reagieren können. „Schicken sie mir einen Brief“ hätte ich sagen können und einfach auflegen. Oder ich hätte mich von ihrer 20 Euro Masche nicht beeindrucken lassen sollen und einfach ein zweites mal NEIN sagen. Aber ich bin nur ein dummer Konsument in einer habgierigen Welt, sie wollen dich aussaugen!

Wenn ich im linken DIV keinen italic Text benutze, sondern einen normalen, fetten oder was auch immer:

Ich würde mal sagen, das ist eine saubere Leistung. Immerhin stammen die Bilder hier von Internet Explorer Version 8.0, und der italic Bug trat schon in Version 5.0 auf. Wirklich, eine Glanzleistung.

Aber mal ehrlich, sowas kann doch gar nicht sein… Man kann doch nicht wirklich peinliche Fehler wie diesen hier über 4 Versionen lang ignorieren.

Der Fehler tritt dadurch auf, dass der Internet Explorer zu dämlich ist, die richtige Breite des DIV Containers zu berechnen, auch wenn diese explizit angegeben ist, sobald sich darin italic geschriebener Text befindet.
Für Layouts bei denen es pixelgenau zugeht, kann ein italic Text also eine Katastrophe heraufbeschwören.

Ich mein, seht euch mal die Bilder an…

Ich habe ja nichts dagegen, dass der Internet Explorer keinen Spaß versteht und bei der kleinsten Unstimmigkeit im Quellcode einen Fehler ausspuckt oder die Seite erst gar nicht anzeigt: kann man sogar was lernen dabei. Aber solche Bugs wie dieser Italic Bug, sowas muss doch nicht wirklich sein. Immer und immer wieder sorgt dieser unglaublich nervige Browser für Unbehagen.

Wir haben also zwei unterschiedliche Texte, die in Hinblick auf das relevante Keyword jedoch völlig gleich sind.

Der erste Text wird über diesen Artikel über diesen Link: deiramantis für die Suchmaschinen erreichbar sein.

Der zweite Text wird über diesen Artikel über diesen Link: deiramantis für die Suchmaschinen erreichbar sein.

Die Linktexte sind also die gleichen, die Dateinamen - und somit die URL sind aber verschieden. Beim ersten Text ist das Keyword in der Url vorhanden; beim zweiten nicht. Ob es nun eine Rolle spielt, dass der Link zu Text eins eher vorkommt, also die Suchmaschine eher darauf stößt als auf den zweiten Text, lasse ich jetzt mal ausser Acht.

Als Titel und Description werde ich einfach die ersten 5 Pseudo-Wörter des jeweiligen Textes bzw. die ersten 12 Wörter des jeweiligen Textes verwenden. So sind auch Titel und Description unique, obwohl sie eigentlich suchmaschinentechnisch gesehen äquivalent sind. Wichtig ist ja nur das Keyword.

Die Ergebnisse werde ich dann in ein paar Wochen hier posten.

Ach, jetzt habe ich doch glatt vergessen suchmaschinenfreundlich zu schreiben. Also müssen natürlich noch ein paar Keywords rein. HALLO OUT THERE! Hier geht es um das Thema: Keywords in der Url - ein praktischer Test.

Ich tippe mal stark darauf, dass der Text mit dem Keyword Dateinamen das Rennen macht.

UPDATE: Inzwischen wurde die Seite test007.html in den Index aufgenommen, wenn man im index-cache nachsieht sogar schon am 16.02.2009, also einen Tag nach Veröffentlichung dieses Artikels.
Die andere Seite mit dem Keyword im Dateinamen ist allerdings noch nicht aufgetaucht. Das muss man jetzt nicht verstehen, denke ich mal. Heute ist der 24.02.

UPDATE2: 27. Februar.
Die zweite Seite deiramantis.html wurde nun auch in den Index aufgenommen. Momentan belegt sie noch den zweiten Platz. Mal sehen, ob sich das noch ändert.

Momentan sieht es so aus: KLICK ME!

UPDATE 1. April 2009

Ähm, ja, lasst euch vom Datum (1.April) nicht täuschen. Ich haber gerade bei Google nachgeschaut und hab gesehen, dass sich der deiramantis.html Artikel jetzt doch durchgesetzt hat. Also das Keyword in der URL scheint doch besser bewertet zu werden.