mthie spaces

Posterous schließt - oh, was für eine Neuigkeit. Viel schlimmer: Jetzt kommen die vielen Blogger aus ihren Ecken gekrochen und geben Tipps, was zu tun ist. Die häufigste und auch blödeste Aussage, die ich in den letzten Tagen las: Ihr müsst euer Blog in Zukunft selbst hosten, damit das nicht wieder passiert.

So ein Schwachsinn!

Was genau soll das für einen Vorteil haben? Als nächstes muss man wahrscheinlich lesen, dass nur noch Wordpress empfohlen wird, da es eine total tolle Verbreitung hat.

Die Probleme bei dieser Aussage: Die User haben einfach keine Ahnung, was sie da tun. Nehmen wir doch mal ein paar Beispiele aus der Praxis.

User mietet sich einen Root-Server und installiert (W|L)AMP mit Wordpress

Kann man machen. Wenn man sich damit auskennt. Tun aber viele nicht. Die Kisten laufen dann 2 Jahre ohne Systemupdates und die Leute wundern sich, warum die Kiste von lustigen Scriptkiddies auseinandergenommen wird. Und natürlich wollen in diesem Falle alle Restore, aber Backups hat natürlich wieder niemand gemacht.

User mietet sich Shared- oder Managed-Hosting

Zumindest schiebt man hier die Server-Software-Updates auf den Hoster ab, der das wahrscheinlich automatisiert durchführt. Das ist okay. Jetzt muss sich der User nur noch um seine Blogsoftware kümmern.

Wenn ich allerdings mal 100 Blogs ansurfe, die auf Wordpress basieren, dann stelle ich bei knapp 50% fest, dass diese eine veraltete und wahrscheinlich auch löchrige Version einsetzen. Die meisten Minor-Updates in der Software sind Security-Fixes gemischt mit ein paar Bugfixes, keine Feature-Updates.

Schlimmer noch sind oft die Plugins, die zur Blogsoftware nachträglich installiert werden. Diese Plugins sind oft so löchrig wie Schweizer Käse und niemand hat die Absicht, diese Lücken auch zu fixen. Läuft doch!

Cloud-Anbieter

Der Vorteil bei Cloud-Anbietern ist oft, dass sie Admins haben. Admins wehren sich gerne gegen alles, was ihnen die Server kaputt macht. Aus Gründen.
Hier wird also für die Sicherheit und Geschwindigkeit der Seite gesorgt, auch wenn man mal aus Versehen auf slashdot landet, bleibt das Blog erreichbar. Wenn der Dienst gehackt wurde, gibt es Backups, die zurückgespielt werden und der Bugfix ist automatisch für alle User aktiv.

Der Nachteil: Man kann oft keine Plugins installieren oder eigene Themes bauen. Nun ja, wordpress.com bietet in der Hinsicht seinen VIP-Service an. Ist nicht billig, aber erfahrene Leute bauen Themes und Plugins, die auch über mehr als einen Server skalieren können. Und schon sind alle wieder glücklich. Aber arm. Irgendwas ist ja immer.

Nachdem gestern schon geleaked wurde, dass Acer eine neue Chromebox produziert, kam heute Lenovo um die Ecke und zeigt sein neues Chromebook. Speziell für Schulen. Soweit so gut.

Schauen wir uns doch das Gerät von den Spezifikationen her mal genauer an:

• 11.6’’ (1366x768) display - gute Größe, auch für Kinder
• 1.3 inches - 3.9 lbs / 1.8 kg - keine Ultrabook-Leichtigkeit, aber okay
• Up to 6.5 hours of battery - zum Vergleich: das erste Samsung-Chromebook hatte Akkulaufzeiten von 8-10 Stunden
• Intel® Celeron™ processor - kein High-Level, aber die Schüler sollen ja auch nicht darauf spielen
• 16 GB Solid State Drive - Dann sind die Daten schon mal grob geschützt vor fallengelassenen Laptops
• Dual band Wi-Fi 802.11 a/b/g/n and Ethernet - das Wi-Fi hat sogar eine vergrößerte Reichweite, was bei den vielen schlechten Schul-WLANs wohl besser ist
• HD Camera - gehen wir mal davon aus, dass es dazu dient, dass die Kinder auch mal von daheim mit einer Erkältung mit der Klasse kommunizieren können sollen
• 2x USB 3.0, 1x USB 2.0 - für die Tastatur und eine Maus hätten auch zwei Ports gereicht, die Hausaufgaben kann man über's Internet holen, dafür braucht man keinen USB-Stick
• 1x HDMI Port, 1x VGA Port - VGA und HDMI für Beamer oder einen Monitor zu Hause, ohne dass man wie bei der Chromebox oder dem Chromebook Series 5 und Series 5 550 einen Displayport-Adapter braucht

Bis hierhin soweit okay, aber schauen wir uns das Gerät mal genauer an:

Hier sehen wir auf der linken Seite den VGA-Anschluss, 2 USB-Ports, den Ethernet-Anschluss und den Audio-Anschluss. Rechts sind der SD-Kartenslot, der HDMI-, der USB-2.0- und der Stromanschluss. Gehen wir doch mal davon aus, dass die USB-Anschlüsse wirklich für z.B. die Maus sein sollen, wäre folgendes Szenario denkbar: Maus an den rechten USB-2.0-Port bei Rechtshändern oder für Linkshänder links an einen der beiden USB-3.0-Ports.

Jeder Rechtshänder, der aber mal einen Laptop mit rechtsseitigem Stromanschluss besaß, kennt das Problem, dass sich der Stromanschluss immer mit der Maus verheddert. Wenn jetzt noch am vorderen rechten Ende, also da, wo wirklich die Maus liegt, noch ein HDMI-Kabel angeschlossen wird, hat man keinen Platz mehr, um seine Maus zu positionieren.

Jetzt werden alle Linkshänder jubeln, aber nur, solange sie kein Ethernet-Kabel und/oder VGA-Kabel angeschlossen haben, welches dann im Weg liegt. Dieses Device ist jetzt nicht unbedingt groß, sodass man nicht mal eine Ausweichmöglichkeit für die Maus hat.

Wer jetzt mit der Ausrede kommt, dass man ja eine Tastatur anschliessen kann und dann den Laptop aus der Schusslinie bringt, der hat noch nie eine normale Tastatur an ein Chrome-OS-Gerät geklemmt, denn die Tastenbelegungen der F-Tasten ist komplett anders und es gibt einfach zu viele Leute, die noch auf die Tastatur schauen, wenn sie tippen. Die Chrome-OS-Tastatur, die man im Laden von Samsung angeboten bekommt ist anders als die von Lenovo und somit keine Lösung.

Alles schwierig halt und hätte man besser machen können, aber grundsätzlich finde ich die Idee gut, dass man in den Schulen die Internetgeräte für Schüler und Lehrer bereitstellen möchte, da die User damit nicht viel falsch machen, sich keine Viren einfangen oder irgendwas kaputt spielen können. Einfach ein Gerät zur Benutzung.

Wie François Beaufort auf Google+ geschrieben hat, wird es wohl demnächst ein neues Chrome-OS-Gerät von Acer geben.

Gut: Die Box wird scheinbar einen Intel-Core-i7-Prozessor mit 2,7 GhZ beinhalten, wie das Kernel-Log zeigt und damit reichlich Power für die richtig guten WebGL-Applikationen haben, die sich nicht immer alle auf die GPU auslagern lassen.

Schlecht: Man hat scheinbar eine 465,7-GB-Nicht-SSD-Festplatte eingebaut. Während also meine derzeitige Chromebox mit der eingebauten SSD in ca. 3 Sekunden hochfährt, braucht die neue Chromebox da wahrscheinlich über 10 Sekunden. Vor allem braucht man die Festplatte einfach nicht. Da auf Chrome OS ja nur der Browser und keine weitere Software als entsprechende Extensions laufen, bringt die große interne Festplatte einfach keinen Mehrwert.

Schon beim aktuellen Acer-C7-Chromebook fragte ich mich ernsthaft, warum man eine 320-GB-Festplatte einbaut, aber ich schätze mal, dass die Hersteller da einfach nur Geld sparen wollten, um das Gerät noch wieder ein paar Euros günstiger zu machen und denken da eher nicht an die Leute, die Filme, Musik oder Photos auf der lokalen Festplatte speichern, da es dafür keine "guten" Programme/Funktionen gibt.

Trotz alledem bin ich froh, meinen Arbeitsalltag mit Chrome OS bewältigen zu dürfen. Es funktioniert, es startet schnell und ich kann effizient und schnell arbeiten. Was will man mehr?

Ich schrieb vor ca. 1,5 Jahren, dass ich mich von der App Engine verabschiede. Aber was soll ich sagen: Ich kann nicht ohne sie.

Inzwischen hoste ich viele meiner Arbeiten auf der App Engine und auch endlich wieder Teile dieses Blogs - die Administrationsoberfläche.

Der Grund: Ich hoste weiterhin die fertig generierten Seiten auf Amazons S3 mit der CloudFront als CDN, da es der schnellste Weg ist, um statische Dateien auszuliefern und es gibt halt fast nichts Statischeres als ein Blog.

Also schreibe ich meine Posts auf der App Engine mit meiner kleinen Admin-Oberfläche, die natürlich mit meinen Resourcen keine Kosten verursacht und lasse dann die fertigen Seiten in die S3 generieren. Und schon hab ich wieder mein kleines, aber dummerweise gut skalierendes Blögchen.

Da ich letzte Woche darüber gestolpert bin, wollte ich es zumindest kurz niederschreiben: Ich musste einen Text mit Umlauten aus Usereingaben in einer speziellen Schriftart auf ein Bild positionieren. Da das Projekt auf Googles App Engine laufen sollte, war es natürlich in Python 2.7 geschrieben. Hier als mein erster Test:

from PIL import Image
from PIL import ImageDraw
from PIL import ImageFont

img = Image.open('background.png')
font = ImageFont.truetype('indieflower.ttf', 18)
image_text = u"àäöüß"
drawer = ImageDraw.Draw(img)
drawer.text((0, 0), image_text, fill=(0, 0, 0), font=font)
img.save('myimage.png')

Dies produziert direkt einen Fehler:

UnicodeEncodeError: 'ascii' codec can't encode character u'\xe0' in
position 0: ordinal not in range(128)

Problem: Die Schriftart ist nicht Unicode-fähig. Allerdings waren ja im Design in genau dieser Schriftart auch Umlaute und Sonderzeichen drin, also muss der Font das ja irgendwie unterstützen.

Die Lösung: Das Windows-Standard-Encoding windows-1252:

image_text = u"àäöüß".encode('windows-1252')

Und schon war nahezu jede Schriftart mit jedem Text möglich und hat mich ca. eine halbe Stunde Research gekostet.

Ach herrje, es gibt wieder eine Sau, die durch's Dorf getrieben wird: "Nun ist es soweit: Abmahnung wegen Vorschaubildern bei Facebooks Teilen-Funktion"

Nun laufen alle Leute los und behaupten: "Ihr müsst ab sofort alle Links ohne Vorschaubild posten!" Aus meiner Sicht ist das der total falsche Ansatz, aber darüber dürfen sich die Anwälte Gedanken machen.

Ich hab dazu auch bei Nina Diercks kurz mal Rede und Antwort gestanden, was man da technisch machen kann und will das hier nochmal kurz näher erläutern, wie das eigentlich geht, wenn ich einen Artikel verlinke.

1. Ich poste den Link zur externen Seite bei Facebook (das Nachfolgende kann auch auf Google+ angewandt werden)
2. Facebook schaut in seinem Cache, ob es die Seite in den letzten 24-48 Stunden schon mal gesehen hat und nimmt die Informationen für die Darstellung - wenn keine Informationen gefunden wurden
3. Facebook lädt den Quelltext der Page herunter, die da verlinkt wird (kann es das nicht, wird auch nix ausgewertet) und schaut, ob es OpenGraph-Informationen findet (dazu gleich mehr) - wenn keine Informationen gefunden wurden
4. Facebook schaut im Quelltext nach HTML <img>-Tags für die Bilder sowie den ersten textlichen Inhaltspassagen und einem <title>-Tag für den Namen der Seite und benutzt diese (gibt es keine Informationen, wird nur noch die Link-URL angezeigt)

Hat Facebook jetzt diese Daten geladen (anders lädt ein Browser die Daten ja auch nicht), werden diese Inhalte zwischengespeichert, damit die Website, die von 100.000 Leuten verlinkt wird, nicht an der Überlast nur durch die Facebook-Anfragen stirbt.

Diese oben genannten OpenGraph-Informationen kann jetzt ein Webseitenbetreiber, der nicht möchte, dass die Vorschaubilder auf Facebook gezeigt werden benutzen, um sich simpel davor zu schützen. Hier mal ein kleines Beispiel, womit ich auch für diese Seite das Vorschaubild verhindere:
<meta property="og:image" content="http://www.example.com/images/blank.gif">

Was habe ich hier gemacht? Ich habe ein Meta-Tag zur Seite hinzugefügt. Diese werden dem normalen User im Browser nicht angezeigt, aber eben für Crawler verwendet, um die Informationen semantisch zu beschreiben.
Dieser hier dargestellte Schnipsel sagt also: Das Bild für OpenGraph-Abfragen hol dir von http://www.example.com/images/blank.gif. Hier kann man jetzt eine URL angeben, die nicht existiert, denn sobald Facebook einen 404-Fehler (Seite nicht gefunden) zurückbekommt, wird das Bild nicht angezeigt. Hier sollte man jetzt nicht unbedingt mein Beispiel nehmen, da die example.com keinen 404-Fehler zurückwirft. Es handelt sich um ein Beispiel. Auch sollte man die unzählichen 404-Fehler nur auf seiner eigenen Domain produzieren und keine fremden URLs benutzen, da dies zu Mehrlast auf fremden Servern führt.

Noch besser wäre es natürlich, wenn man, wenn schon kein Vorschaubild des Inhalts genommen werden soll, hier zumindest ein Logo der Website einbindet. Dann generiert man trotzdem Klicks auf die eigene Website durch die ansprechendere Darstellung. Was soll eine Website, wenn man keine Besucher darauf haben möchte? Und ein guter, beschreibender Text sollte auch dabei sein, was man sich auf der OpenGraph-Website genauer anschauen kann, wie man was machen muss.

Für die meisten Blogsysteme gibt es schon fertige Plugins, die dies bereits abdecken.

Was ich persönlich ganz gut fänd, wäre, wenn Facebook die robots.txt benutzen würde, um Verzeichnisse, die nicht indexiert werden dürfen, genauso auch für die Bilder zu verwenden, wie es Google & Co. als Suchmaschinen tun. Nur kann ich aus Administratorsicht auch widerum verstehen, wenn Facebook den Mehraufwand an Traffic und Rechenzeit nicht investieren will.