Und weil das Wetter so schön ist, gibt es heute noch zwei neue Links, als da wären:
That´s all, folks.
Cori hat die Muse geküsst: weil sie ihr Ansehen nach dem verlorenen EN-Titel bei den Pyranas steigern will, ist sie nun der Meinung viele, aberwitzige Husarenstücke reißen zu müssen, um den Stamm beeindrucken zu können und so wieder an Renommee zu gewinnen.
Die Grundidee ist dabei ganz simpel ein Angriff Kasras. Das ist schon eine leicht größenwahnsinnige Idee für ein Panthermädchen wenn es denn auf Gor wäre, besonders noch wo die Pyranas schon mal vor einem Jahr etwas ähnliches probierten und das damals mächtig in die Hose ging, ganz einfach weil ab einem gewissen Punkt die Bewohner Kasras nicht mehr mitspielen wenn es ihnen zu – shocking! – zu unrealistisch wird.
Aber aus Schaden wird man klug, und diesmal will man also nun sich beim Übersetzen auf die Insel Hilfe holen in Form der Black Shark Piraten. Aha, aha, aha… abgesehen davon, dass auch das ziemlich sicher wieder wie das Hornberger Schießen enden würde, weil man in Kasra wenn es um die Weltherrschaft durch Panther geht doch leicht andere Ideen hat als manche Panther selber, wie man bei Georg auch nachlesen kann, behaupte ich einfach mal dass ein Erscheinen beider Gruppen zusammen die Wahrscheinlichkeit auf Kasra eines reibungslosen Spiels drastisch ins Bodenlose senken würde.
Wie auch immer – die Pyranas wollten also die Black Sharks anheuern und begaben sich dazu auf deren Sim. Da flogen dann zuerst ein paar Pfeile und die Neukajira der Pyranas entpuppte sich als gut getarnter Terminator, der todesverachtend mit einer Steinschleuder trotz mehrfachen Verbots munter auf die Piraten schoss. So endete es mit Kennel für die Pyranas und es kam nicht zu dem Deal. Nun hat Cori die „Gorness“ der Sharks benotet, weil das RP nicht so ganz nach Wunsch gelaufen ist und die revanchieren sich nun fröhlich auf dieselbe Weise bei ihr in den Kommentaren.
Das ist mal wieder ganz, ganz großes Popcornkino, was da abläuft…
Tante Edith: hier noch die Sichtweise der Sharks.
Weil mir ein wenig langweilig gewesen ist und ich mal schauen wollte, was man noch so alles aus WordPress heraus holen kann, habe ich mit dem Blogdesign heute massiv gespielt. Das Ergebnis ist kurz und gut, dass das Basistemplate weiterhin „Weaver II Basic“ ist, allerdings mit anderen Grundeinstellungen, ich mag einfach Weiß als Hintergrund für Schrift nun einmal lieber als irgendwelche komischen Grautöne.
Auch wurde die Avatargrösse in den Kommentaren verdoppelt und als grundlegende Schrift für den Fließtext habe ich hier nun Vollkorn von Friedrich Althausen in Verwendung, ganz einfach weil mir diese Schriftart im Moment sehr gut gefällt. Es gibt ja schon lange die Möglichkeit, sein Design mittels Webfonts aufzupeppen und bei Google eine nette Auswahl ans kostenlos verfügbaren Schriftarten, also wieso sollte man diese nicht mal nutzen?
Google Web Fonts nennt sich das Verzeichnis, wo man zwischen 501 Schriftarten bisher auswählen kann, und das werden sicherlich noch mehr werden. Man kann diese bequem per Javascript oder CSS in sein Template einbinden – fertig.
Öfter mal was Neues, die Profile mancher Avatare in Gor auf Deutsch sind dazu ein nicht enden wollender Quell der Inspiration. Aber der Reihe nach…
Das hier ist ein QR-Code. Kennt ihr vielleicht nicht, aber habt ihr sicherlich bewußt oder unbewußt dutzendfach gesehen, da diese Codes gerade massiv in Mode sind. QR steht dabei für Quick Response, also schnelle Antwort in etwa. Ein QR-Code ist ein zweidimensionaler Barcode, der besonders schnell (sic!) und einfach von Codescannern jedweder Art eingelesen werden kann. Und was benutzt der moderne Datennomade heutzutage, um solche Codes einzuscannen? Richtig: sein Smartphone! Es gibt Zillionen an Barcode-Apps und die Anzahl der Nutzungsmöglichkeiten gehen ins schier Unendliche (nur die meisten Werbeheinis nutzen sie extrem phantasielos).
Ein QR-Code hat dazu auch eine gewisse Redundanz eingebaut, also wenn Bereiche des Codes fehlen kann man ihn dennoch dekodieren. Feine Sache, und wer welche selber erzeugen will, der kann das z.B. hier tun oder direkt bei Google.
Damit die Botschaft eines QR-Codes einen auch erreicht, braucht es neben dem Generator des QR-Codes beim Absender an sich auch beim Empfänger zuerst einmal das Wissen, was ein QR-Code ist und wie man ihn zu lesen hat sowie die Software und notwendige Gerätschaft, genau das zu tun. Der Rest sieht einfach nur einen Haufen komisch angeordneter Quadrate, nicht mehr, nicht weniger. Mein Avatarbild in Slinfo.de war einige Zeit lang auch so ein QR-Code mit meinen wichtigsten Kontaktdaten gewesen, das noch nebenbei.
Nun hat also ein Avatar aus GaD, ich nenne ihn mal der Einfachheit halber X (und nein, damit beginnt der Avatarname nicht noch kommt das im Avatarnamen vor) in seinem Profil anstelle eines Bildes seines Avatars einen QR-Code eingestellt, der es in sich hat. Den Inhalt muss ich hier nicht weiter verlinken, es handelt sich dabei um derbste, persönliche Beleidigungen („du bist erbärmlich“ und dergleichen mehr), die an genau eine Person gerichtet sind.
Das ist natürlich geschickt gemacht – wer einen QR-Code nicht kennt oder den Inhalt nicht zu lesen weiß, sieht es nicht – wer aber einen Barcodescanner hat, der kann es lesen, das macht die Sache aber keinen Deut besser.
Übrigens: mein QR-Code hier ist ein Zitat von Artur Schopenhauer. Viel Spaß beim Dekodieren!
Im Moment grübele ich gerade darüber nach, ob ich den Blog hier statifizieren soll oder eben nicht. Die grundlegende Idee dahinter ist einfach: eine statische Seite wird direkt vom Webserver Apache hier ausgeliefert und kostet keine weitere Rechenzeit, da sie nicht zuerst durch die diversen weiteren Schichten hier wie PHP und MySQL genudelt werden muss. Auch ist so etwas, weil eben statisch, viel weniger anfällig für Sicherheitslöcher als die hier von mir verwendete Blogengine WordPress.
Gut, das sind Überlegungen die die meisten der hier verlinkten Blogger nicht haben werden, ganz einfach weil sie ihre Blogs bei Blogging-Providern betreiben und nicht auf einem eigenen Server. Das hier ist aber mein eigener Server und daher sieht es eben bei mir ein wenig anders aus.
Nun ist es so, dass WordPress an und für sich mehrere Vorteile hat: es ist etabliert und gibt Zillionen an frei verfügbaren Themes, die man verwenden und als Child Theme anpassen kann sowieso abermals Zillionen an Plugins, mit denen man die Funktionalität von WordPress beliebig erweitern kann. Auch wird das Skript selber von Automattic Inc. regelmäßig gepflegt, sollten Sicherheitslöcher entdeckt werden, gibt es schnell und zuverlässig Sicherheitspatches, die zudem im Backend extrem einfach eingespielt werden können. Dasselbe trifft für die Plugins zu.
Nur: die Sicherheit bei PHP ist immer so eine Sache, im Prinzip ist PHP inzwischen historisch ein derart chaotisch gewachsener Haufen Scheiße, dass man in PHP geschriebene Skripte eigentlich niemals wirklich sicher bekommen kann, einfach weil PHP selber extrem unsicher und anfällig für Angriffe aller Art ist. Das bei der existierenden Codebasis noch in den Griff zu bekommen ist völlig illusorisch, dumm nur aber, dass die Mehrzahl aller inzwischen im Web verwandten Skripte auf PHP basieren – wie z.B. vBulletin, das u.a. Slinfo als Forensoftware nutzt, WordPress, phpBB, Drupal, Typo3, Joomla und vieles, vieles mehr.
Dazu kommt bei WordPress auch, dass die Kernfunktionen einigermaßen sicher sind, weil Automattic Inc. dahinter steckt, dasselbe aber nicht unbedingt für die Plugins gelten muss. Die Codequalität der Plugins wird beträchtlich schwanken und auch die Zeit die es braucht, bis einer der Autoren dort ggf. Sicherheitslücken schließt.
Also macht das alles in allem den Betrieb eines solchen Blogs eben zu einem ständigen Glücksspiel, man weiß eben nie, ob es nicht doch irgendwo eine Lücke gibt und der Einfallsvektoren gibt es sicher viele, vermutlich viel zu viele.
Andererseits funktioniert WordPress eben aus dem Browser heraus einfach und sehr gut, die Grundfunktionalität stimmt und auch den Rest mit dem langsameren Rendern der Seiten im Vergleich zu statischen Seiten bekommt man durch Einsatz von geeigneten Caches gut in den Griff. Hier in dem Blog setze ich dazu W3TC ein, das ist die dickste und kompletteste Cachelösung überhaupt, und das macht sich mehr als deutlich in der Geschwindigkeit des Blogs hier bemerkbar. W3TC speichert unter anderem einmal gerenderte Seiten als Dateien auf dem Server ab und das nächste Mal, wenn jemand dieselbe Seite ohne Änderung anfordert, liefert W3TC diese Seite direkt aus dem Cache und fertig – das ist fast so gut von der Geschwindigkeit wie bei statischen Seiten, aber dennoch einen Tick langsamer, da es einen gewissen Verwaltungsoverhead dazu braucht. Andererseits aber ist diese Geschwindigkeitsdifferenz wohl so gering, dass man sie kaum merkt und es sich nicht lohnt, alles hier statisch zu machen.
Dem steht nun die Möglichkeit gegenüber, die Seiten hier komplett in ein statisches System wie Jekyll (geschrieben in Ruby) oder Hyde (geschrieben in Python) zu übernehmen, es gibt derer Systeme noch viele weitere, ebenfalls Zillionen. Solch ein System läuft dann normal zweigeteilt, es gibt einen Redaktionsserver (vulgo der PC zuhause), auf dem man seine Seiten schreibt und dann den Seitengenerator anwirft. Der Redaktionsserver lädt dann die Änderungen an den statischen Seiten per FTP oder sonst was auf den Webserver hoch – und das wars dann gewesen.
Das klingt zuerst einmal nach einer schönen und flotten Sache, und das ist es auch – nur steckt der Teufel dabei im Detail, genauer in den Kommentaren: denn wenn man dann auf seinem Webserver nur einen Haufen statischer Seiten liegen hat, der aber als Blog dienen soll, wie bitte soll das mit statischen Seiten dann noch gehen? Die Mehrheit der Leute, die ihr Blog statifizieren, behelfen sich damit, dass sie die Kommentare an einen externen Anbieter namens Disqus auslagern. Der lädt per Javascript entsprechende Felder für Kommentare nach und das läuft dann alles über seine Serverinfrastruktur, die Basisfunktionalität ist zudem kostenlos – und reicht für die Mehrheit allemal aus. Man kriegt per Plugin die Kommentare aus WordPress spielend einfach nach Disqus exportiert und hat sie dann dort drüben zur Verfügung, eine Sache denken sich Viele und machen das auch so.
Das klingt wie eine schöne Sache, nur: ich persönlich habe meine Daten und damit auch meine Kommentare hier unter eigener Kontrolle und keine Lust, sie einem Anbieter in den USA zu verfrühstücken, von dem ich nicht weiß was er damit wirklich anstellt und wie lange es ihn noch gibt. Spätestens dann, wenn er einmal seinen Dienst einstellen würde, müsste man sich nach einer anderen Möglichkeit umtun. Andere Möglichkeit bedeutet dabei entweder einen anderen Anbieter nutzen oder diese Funktionalität selber nachbauen.
Das hat jemand bereits nach Vorbild von Disqus gemacht und eine Webapplikation namens Juvia geschrieben, die in Ruby on Rails realisiert worden ist. Nur: das wäre für mich den Teufel mit dem Beelzebub austreiben, denn ich werfe doch nicht den einen Mist – PHP – raus um mir einen noch größeren Mist, nämlich Ruby on Rails ins Haus zu holen. Da kann ich das dann auch gleich schön sein lassen, oder schauen, ob es nicht vielleicht wo doch noch eine alternative Lösung zu Juvia gibt.
Auch ist bei einer Statifizierung natürlich wichtig, dass die URL-Pfade danach dieselben sein werden, ganz einfach damit die Suchmaschinen nicht ins Himmelblau verweisen und die diversen Sachen wie eingebettete Videos und Bildergallerien noch irgendwie sinnvoll funktionieren. Das wäre dann aber die Kür nach der Pflicht bei der Statifizierung.
Alles in allem ist das alles für mich so oder so recht unbefriedigend, und solange ich keine für mich zufriedenstellende Möglichkeit sehe, das Blog hier in seiner Mächtigkeit wirklich so zu statifizieren, dass ich alles selber betreiben kann, tut eben nach wie vor WordPress erst einmal weiter hier treudoof seinen Dienst. Vielleicht baue ich mir einfach mal lokal mit einem Static Site Generator meiner Wahl lokal einen Working Prototype und spiele dann mit dem ein wenig herum, schaden kann es jedenfalls nicht.