Skip to content

Welche Templates nutzt ihr für euer Blog?

Das Auge isst mit”, so heißt es, und für mich gilt das definitiv. Zwar gilt gerade im Web insoweit oft “weniger ist mehr” und fehlende Inhalte lassen sich nicht durch optischen Putz überdecken, aber ich finde, dass ein guter Text durch eine hübsche Verpackung viel gewinnen kann. Sehr angenehm auch, wenn Webseiten im Zeitalter der mobilen Endgeräte “responsive” sind, sich also möglichst gut den jeweils gebotenen Bildschirmdimensionen anpassen und nicht “für eine Auflösung von … optimiert” sind.

Dementsprechend ist die Auswahl an Themes oder Templates für die verschiedenen Blogsysteme groß (Serendipity) oder gar völlig unüberschaubar (Wordpress). Vor der Qual der Wahl stellt sich aber zumindest für diejenigen, die neben einem Blog auch noch eine eigene Website - oder andere Webangebote - betreiben, die Frage, ob - und inwieweit - das Blog in die Struktur des restlichen Webangebots eingepasst und/oder an dessen Design angepasst sein soll. Das erfordert dann nämlich - nicht selten umfangreiche - Anpassungen an den fertigen Themes (hoffentlich nur im CSS) und schränkt möglicherweise die Auswahl dann auch nicht unerheblich ein.

Mich hat das aktuelle Serendipity-Standard-Theme “2k11” überzeugt: responsive, schick, leicht anzupassen (wie man an diesem Blog sieht - wobei “leicht” immer relativ ist).

Welche(s) Template(s) nutzt ihr, für Wordpress oder Serendipity? Passt ihr das Aussehen eures Blogs an eure übrigen Webseiten optisch an oder verzichtet ihr - zur Vermeidung des Aufwands, zur auch optischen Trennung oder aufgrund des angenehmeren Designs - darauf?

Welche Themes könnt ihr empfehlen, oder welche Blogs erscheinen euch optisch oder vom Design her besonders gelungen?

Auf eure Empfehlungen und Erfahrungen bin ich gespannt .

Fußnoten von MultiMarkDown zu Wordpress konvertieren (und zurück)

Wir Juristen lieben Fußnoten … oder verwenden sie jedenfalls mit Vorliebe und in großer Zahl und Länge - eine juristische Arbeit ist nur echt, wenn mindestens ein Drittel, besser die Hälfte der jeweiligen Seite oder mehr von einem Fußnotenapparat in Anspruch genommen wird. :-)

Dieses Feeling will man natürlich auch beim Web-Publishing nicht vermissen; hier kommt Wordpress zu Hilfe, gibt es doch verschiedene Plugins für eine Fußnotenverwaltung, von denen mir bisher footnotes am besten gefällt. Man kann seine Fußnoten einfach im Fließtext an der passenden Stelle ergänzen, entweder in eckigen Klammern: ((...)) oder in Tags wie <fn>...</fn> oder ganz anders. Am einfachsten erscheint mir dabei die erstgenannte Möglichkeit, und da das Plugin umfangreiche Anpassungen auch des CSS direkt in der Konfiguration erlaubt, funktioniert das auch recht gut.

Nun schreibe ich meine Blogbeiträge in der Regel in Markdown, und auch das kann Wordpress natürlich verarbeiten. Was liegt also näher, als Blogbeiträge erst in einem Markdown-Editor vorzubereiten und dann am Ende in Wordpress (oder Serenidpity, natürlich) einzufügen? Umso mehr, als auch Scrivener als ein mögliches Ausgabeformat MultiMarkdown kennt?

Das Problem dabei ist allersings, dass Fußnoten zwar in MultiMarkdown (wenn auch nicht in “purem” Markdown) unterstützt werden, das Format da aber anders aussieht; dort ist nämlich an der Stelle, wo das Fußnotenzeichen im Text stehen soll, nicht etwa - wie bei den Wordpress-Plugins - der gesamte Fußnotentext einzufügen, sondern nur ein Platzhalter in der Form [^x], wobei x für eine beliebige Zeichenfolge steht. Die Fußnoten werden dann - wie im Ausgabeformat ja auch - am Ende des Textes in der Form [^x]: ... eingefügt. Das hat zwar den Nachteil, dass man einen Zähler hochzählen muss und Schwierigkeiten bekommt, wenn man eine Fußnoten “zwischendrin” einfügen will, ist aber besser lesbar - und für die Einfügerei hat man ja Tools wie Scrivener, die das bei der Ausgabe automatisch richtig machen.

Nur: wie bekommt man die Fußnoten im MultiMarkdown-Format dann in Wordpress, oder einen Text aus Wordpress wieder in einem verständlichen Format in den Markdown-Editor? Die ersten beiden Male habe ich das von Hand gemacht … Das geht. Aber es dauert. Und dauert. Und spaßig ist auch anders. Und: wozu gibt es Computer?

Also habe ich nach ein paar Versuchen - und einigen Blicken ins Perl-Kochbuch, das passenderweise ausgerechnet ein Dickhorn-Schaf auf dem Cover hat! - ein kurzes Script zusammengehackt, das erst die vergleichsweise einfache Aufgabe der Konvertierung des Wordpress-Formats ins MultiMarkdown-Format übernommen hat und dann um die Konvertierung in umgekehrter Richtung erweitert wurde, die eigentlich auch gar nicht so richtig komplex ist. Das funktioniert unter Linux wie auch - mit Activestate-Perl - unter Windows und tut seinen Zweck, auch wenn man das Problem sicherlich noch eleganter lösen könnte und es an jeder Fehlerbehandlung (und an Dokumentation bisher auch …) fehlt.

Wer auch vor diesem Konvertierungsproblem steht und wen der noch rohe Zustand des Scripts nicht abschreckt, der kann sich gerne im Git-Repository bedienen.

Struktur im Blog: Kategorien und/oder Tags?

Die meisten Blogsysteme bieten dem Benutzer zwei Möglichkeiten, seine Inhalte zu strukturieren und zu systematisieren: Kategorien und Tags (Schlagworte). Zumindest die Kategorien können dabei regelmäßig eine Gliederung abbilden, d.h. Unterkategorien enthalten. Üblicherweise können einem Eintrag beliebig viele Tags, zumeist aber auch mehrere bzw. beliebig viele Kategorien zugewiesen werden.

Diese Optionen bieten nun eine Vielzahl von möglichen Wegen zur Strukturierung des eigenen Blogs. So kann man gänzlich auf Kategorien verzichten und die Einträge nur verschlagworten, entweder systematisch mit einem begrenzten Vorrat an Schlagworten, die möglichst häufig verwendet werden, oder als “stream of consciousness” die Kernthemen des jeweiligen Beitrags aufnehmen. Das andere Extrem wäre der Verzicht auf Tags zugunsten von Kategorien, mit denen die einzelnen Themen logisch gruppiert werden, wobei grundsätzlich durchaus überlappende Kategorisierungssysteme möglich sind, bei denen jedem Beitrag zwei oder mehr Kategorien - aus unterschiedlichen Taxonomien - zugewiesen werden. Schließlich ergeben sich vermittelnde Möglichkeiten. Die jeweiligen Vorgehensweise hängt dabei neben dem persönlichen Stil sicherlich auch in nicht geringem Maße von Art und Inhalts des Blogs ab.

Wer in seinem Blog bspw. den ganzen Bereich seines persönlichen und beruflichen Lebens sowie verschiedener Hobbys abbildet, wird Kategorien oft schon deshalb benötigen, um die völlig disjunkten Themenbereiche voneinander zu trennen. Finden sich bspw. Einträge zur Freizeit- und Urlaubsgestaltung - die insbesondere von Bekannten, Freunden und Familie gelesen werden - neben Beiträgen zum Geocaching - die andere Geocacher sehr, lebensältere Onkel und Tanten aber nun gar nicht interessieren - und fachlichen Beiträgen zur beruflichen Tätigkeit, bspw. als Systemadministrator oder Entwickler, und damit zusammenhängenden Freizeitprojekten, bietet es sich an, Kategorien wie Privates, Geocaching und Softwareentwicklung einzurichten und die letztgenannte bspw. noch mit den Unterkategorien Releases und Debian zu versehen. So können die Onkel und Tanten die Kategorie Privates abonnieren und die neuesten Fotos der Großnichten bewundern, Geocacher sich ihren Themenkanal suchen und die mehr am Bereich der Entwicklung interessierten Leser sich entscheiden, ob sie alles - die gesamte Kategorie mit allen Unterkategorien - mitbekommen möchten oder nur Ankündigungen neuer Versionen; zudem lassen sich Beiträge zu bestimmten Projekten - hier im Beispiel “Debian” - gesondert abrufen und auf diese Weise in einem Aggregator (”Planet”) zusammenfassen. Feinere Unterteilungen einzelner Bereiche machen das System dann aber bald unübersichtlich; verschachtelte Unterkategorien lassen irgendwann den Wald in lauter Einzelbäumen untergehen. Ist ein Blog hingegen “monothematisch”, können schon Kategorien auch eine feinere Unterteilung ermöglichen. Wer nur über “Software” schreibt, kann bspw. die Unterkategorien aus dem vorigen Beispiel als Hauptkategorien nehmen und sie für Ausnahmefälle noch um eine Kategorie für anderes oder privates ergänzen.

Wer so mit Kategorien arbeitet, wird irgendwann auch einmal vor dem Problem stehen, dass sich verschiedene divergente Sortierkriterien ergeben. Wollte man im obigen Beispiel den Bereich “Software” bspw. noch in “Webapplikationen” und “Shellscripts” oder nach der verwendeten Programmiersprache unterteilen, ergeben sich Überschneidungen zu den schon vorhandenen Kategorien. Hier würden dann sich überlappende Kategorisierungssysteme greifen, in denen Beiträgen bspw. sowohl die Kategorie “Debian” als auch die Kategorie “Webapplikation” zugewiesen werden, oder man delegiert die feinere Unterteilung an Tags. Das gleiche gilt für bestehende Reihen oder Serien, wie bspw. einen wöchentlichen “Linkdump”, der sich möglicherweise auch thematisch einordnen lässt, oder einen regelmäßige Reihe “Best practices”.

Wie arbeitet ihr in euren Blogs? Nutzt ihr Kategorien oder Tags, oder beides? Wie? Habt ihr euch ein ausgefeiltes System ausgedacht, oder ist das alles “dynamisch gewachsen”?

Über Antworten und Kommentare würde ich mich freuen.

Wie macht man heute Webstatistik?

Ich erinnere mich noch, wie ich vor vielen Jahren - rund anderthalb Jahrzehnten - das Interesse an damals von mir zum Download bereitgestellten Dateien gemessen habe: Jeden Monat lud ich mir von meinem Webspaceanbieter die dort generierten Logfiles herunter, ließ auf meinem heimischen Rechner ein Auswertungsprogramm laufen und ergänzte liebevoll die Anzahl der jeweiligen Downloads im vergangenen Monat in Klammern hinter dem Namen der Datei. Anfangs fand ich das total spannend, nach einiger Zeit ziemlich nervig, und später bin ich dann auf ein Zählscript umgestiegen (Umleitung des Dateiabrufs über ein PHP-Script, das eine Datenbank fütterte).

Unabhängig davon ist es natürlich weiterhin interessant, wie intensiv die eigene Website von anderen genutzt wird. Insbesondere die Abrufe und Besuche - für diese Metriken gibt es natürlich vielfältige Definitionen - insgesamt, welche Seiten oder Dateien besonders oft aufgerufen werden, welche Suchbegriffe auf die eigenen Seiten führen (auch wenn Google das leider erschwert hat) und - für jede Seite oder Datei - wo diese verlinkt sind (Referrer-Auswertung). Zu diesem Zweck hat man früher [tm] einfach die Logs des Webservers ausgewertet, bspw. mit Webalizer oder AWStats. Heute - eigentlich schon seit vielen Jahren - liest man stattdessen von Google Analytics und Piwik (und den damit verbundenen Datenschutzproblemen).

Weil ich mit der Zeit gehen will, habe ich mir auch einmal Piwik installiert und nutze es bislang im Logdatei-Auswertungs-Modus. Das hat mich allerdings bislang nicht besonders überzeugt; es dauert teilweise gefühlt ewig, bis eine Auswertung vorliegt, und für mich interessante Statistiken - bpsw. die Referrerstatistik: von wo wurden bestimmte Seiten aufgerufen? - habe ich bislang zumindest nicht gefunden. Vielleicht ist das auch einfach der falsche Weg, mit Piwik umzugehen …

Daher die Frage in die Runde und an die geschätzte Leserschaft: Was benutzt der Blogger oder Webpublizist von heute zur Auswertung der Seitenaufrufe? Eher eine Auswertung der Logfiles? Oder eher einen Livedienst wie Google Anlaytics? Was genau benutzt ihr? Wie sind eure Erfahrungen?

Bonusfrage: Wie haltet ihr es mit Datenschutzerwägungen?

Hilfsweise: Welche Newsgroup, welches Forum ist die oder das richtige für solche Fragen?

Über Antworten und Kommentare würde ich mich freuen.

Generatoren für statische Websites

Ganz früher bestand eine Homepage, bestanden Webseiten allgemein im wesentlichen aus HTML-Dokumenten. Auf dem Weg zum Web 2.0 kamen zunächst CGI-Scripts für bestimmte Anwendungen auf; insbesondere aber mit der Verbreitung von PHP wurden Webseiten deutlich interaktiver. Blogs, Gästebücher, Kontaktformulare wären anders auch kaum vorstellbar. Nicht immer aber ist Interaktivität wirklich erforderlich. Manche eigentlich statische Seite wird nur deshalb dynamisch via PHP - oder auf vergleichbare Weise - erzeugt, weil es so bequem ist, die Erstellung einer Navigation und der Grundstruktur der Seiten zu automatisieren und Änderungen nur an einer Stelle vornehmen zu müssen. Das kann durch Installation eines CMS - oder eines dafür “zweckentfremdeten” Blogs oder Wikis - erfolgen; man kann auch wie ich schlicht die bisherigen HTML-Dokumente durch PHP-Scripts ersetzen, die im wesentlichen nichts anderes tun als vorgefertigte Funktionen für die Generierung des Seitengerüsts und der Navigation aufzurufen und ansonsten praktisch nur aus HTML bestehen. Meistens wäre es aber eigentlich gar nicht erforderlich, die Webseiten für jeden Aufruf neu zu generieren, weil sie sich nicht oder doch nur selten ändern. Ausreichend wäre es vielmehr, die Erstellung der an und für sich statischen Seiten aus Vorlagen - Templates - zu automatisieren und dabei ggf. auch automatisch die nötige Navigation zu erstellen.

Das leisten - in verschiedensten Variationen - static site generators, also Scripts oder Programmpakete, die man mit Schablonen (Templates) und Inhalten füttert und die daraus - ergänzt um eigene Programmschnipsel - die fertige Website erstellen. Vorteilhaft daran ist, dass die Webpräsenz im wesentlichen aus statischen HTML-Seiten bestehen kann, nur dort durch Scripts ergänzt, wo das auch tatsächlich für Interaktivität notwendig ist. Auf dem Webserver wird die Last deutlich verringert, weil nicht für jeden Seitenaufruf ein PHP-Interpreter gestartet werden muss; auch bestehen weniger Angriffsmöglichkeiten, weil kein ausführbarer Code mehr “live” auf dem Webserver laufen muss. Eine gewisse Interaktivität lässt sich auch durch tägliche, halbtägliche oder sogar stündliche Neuerzeugung der Webseiten erreichen; das macht für ein Forum oder auch ein Blog mit Kommentaren sicher wenig Sinn, aber wenn “nur” ein RSS-Feed oder die aktuellsten Tweets eingeblendet werden sollen, reicht das oft aus. Zudem lassen sich bspw. Kommentare auch durch externe Systeme wie Disqus vermittels Javascript einbinden.

Das Angebot an solchen Generatoren ist - wie bei Blogs, Wikis, CMS, Bugtrackern usw. - einigermaßen unüberschaubar geworden, wie man einer beliebigen Liste von Static Site Generators entnehmen kann. Gute Erfahrungen habe ich mit nanoc gemacht, mit dem auch der CCCS seine Website generiert; Jekyll wird bspw. bei GitHub genutzt, um dort Webseiten - direkt aus Git heraus - zu generieren. Der einzige Nachteil bei beiden ist ggf., dass sie in Ruby geschrieben sind und daher eigene Scripts und Erweiterungen sinnvollerweise ebenfalls in dieser Sprache zu halten sind. :-)

Das Grundprinzip ist bei allen Generatoren immer dasselbe: Es wird ein Grundgerüst für die Seiten in Form eines oder mehrerer Templates aufgebaut, gerne in HTML 5 und “responsive”, die dabei Platzhalter oder sogar entsprechend fortgeschrittenere Funktionen enthalten. Das Design erfolgt über CSS, wobei auch CSS-Präprozessoren wie LESS oder SASS zur Anwendung kommen können. Die einzelnen Webseiten schließlich können als HTML-Dokumente, aber besser noch in einfacheren Auszeichnungssprachen wie MarkDown, Textile, Asciidoc usw. angelegt werden. Dann gibt es in der Regel noch eine Konfigurationsdatei, aus der sich ergibt, wie die einzelnen Bausteine - Templates, CSS, Seiteninhalte - “bearbeitet” und zusammengefügt werden sollen. Aus diesen Anweisungen und Bausteinen generiert der Site Generator dann statische HTML-Dokumente (oder auch PHP-Scripts, oder Dokumente, die Javascript enthalten, oder …). In der Regel sind dabei eine Vielzahl von Filtern zur Interpretation von Markdown, LESS und Co. bereits enthalten; die eigenen Seiten und Designs lassen sich daher quasi aus einem Baukasten zusammensetzen, zumal als Basis für das Grundgerüst der Seiten auf Systeme wie Bootstrap oder HTML5 Boilerplate zurückgegriffen werden kann, die eigene Schriftarten, Icons und/oder Javascript direkt mitbringen oder zumindest entsprechende Anregungen enthalten. Mit verhältnismäßig wenig Aufwand lassen sich so die eigenen Inhalte hübsch, technisch modern und auf den verschiedensten Geräten vom Smartphone über das Tablet bis zum Laptop oder großen Desktopbildschirm ansehnlich darstellen.

Wenn man möchte, kann man auch die Quelldokumente in einem Versionsverwaltungssystem wie Git verwalten und bei jeder Änderung daraus automatisch eine neue Version der Webseiten erzeugen. Auf diese Weise ist ein Blogbeitrag, aber auch eine neue Seite der eigenen Homepage schnell in Markdown geschrieben, mit einem Vorspann - mit den notwendigen Informationen wie Titel, Autor, Erstellungsdatum, Typ pp., bspw. in YAML - versehen und im Git-Repository gespeichert; daraus erzeugt dann der Generator automatisch die neue Seite und passt - gleichfalls automatisch - alle davon betroffenen anderen Seiten (Inhaltsverzeichnis/Sitemap, Navigation, RSS-Feed, …) an und erzeugt sie, soweit nötig, neu.

Ich finde das sehr praktisch für alle Anwendungsfälle, die keine “Webapplikation” darstellen, sondern im wesentlichen statische Inhalte enthalten, die sich nicht minütlich oder stündlich, sondern eher täglich, wöchentlich oder auch nur alle Jubeljahre einmal ändern. Durchaus lässt sich aber auch ein Blog so betreiben, wenn man denn die interaktiven Elemente wie Kommentare pp. “outsourced”, bspw. an Anbieter wie Disqus. Mit ausreichend Zeit - ja, genau da liegt der Knackpunkt … :-) - plane ich, zumindest einige der von mir betreuten Webseiten in der Zukunft entsprechend umzustellen.

MarkdownPad

Über Markdown habe ich in diesem Blog schon mehrfach geschrieben. Ich nutze diese simple Auszeichnungssprache nicht nur für meine Blogbeiträge, sondern auch für FAQs, die sowohl als einfacher Text - bspw. für Postings im Usenet - als auch als HTML - bspw. im Web - veröffentlicht werden sollen, als Quelle für daraus generierte Webseiten oder bei Anbietern, die gleichfalls auf diese Auszeichnungssprache setzen, wie bspw. Github.

Bislang habe ich Markdown in meinem Standardeditor Sublime Edit 2 verfasst (oder ggf. in Notetab Pro), schließlich handelt es sich letztlich um einfachen Klartext, und den Text dann veröffentlicht und notfalls einmal nachbearbeitet. Wenn ich einmal wirklich eine Vorschau sehen wollte, habe ich einen der im Web vorhandenen Online-Konverter wie Markdown Live Preview benutzt, bei dem man links in ein Fenster seinen Text einfügen kann und der rechts daneben dann live die Umsetzung in HTML darstellt. Wenn man allerdings mit einer langsamen Internetanbindung irgendwo an der Küste sitzt - oder gar offline arbeiten möchte -, ist das kein optimaler Workflow. :-)

Daher bin ich jetzt - nach kurzer Suche über Google - auf den Markdown-Editor MarkdownPad 2 gestoßen, der einem im Prinzip das, was Markdown Live Preview online kann, offline bietet: links der Text in Markdown, rechts daneben das gerenderte HTML. Außerdem gibt es die bereits sattsam aus Web-Editoren wie in Wikis oder Blogs bekannten Buttons, mit denen man das entsprechende Markup generieren kann - eigentlich nicht nötig, weil das schöne an Markdown ja gerade ist, dass man es ganz natürlich tippen kann, aber mal ganz praktisch, wenn man nach einer Schaffenspause mal wieder ein spezielleres Markup vergessen hat und sich den Ausflug zu einer Syntaxübersicht sparen möchte. Außerdem kann man auf einfache Weise das generierte HTML direkt exportieren, wenn man das möchte.

MarkdownPad ist kostenlos; die 15 Dollar teure “Professional”-Version beherrscht u.a. Tabellen in Markdown Extra und den Export in ein PDF. Ich finde das sehr praktisch und werde dieses Tool zukünftig für meine Markdown-Texte verwenden.

Druckertreiber für HP LaserJet 1015 unter Win7/Win8

Mir leistet seit Jahren ein kleiner, aber durchaus feiner HP LaserJet 1015 als Drucker gute Dienste. Er belegt recht wenig Platz, der Papiervorrat ist ausreichend, und man kann auch mal 100 Seiten am Stück drucken - für die heutigen Zwecke, bei denen ab und an mal ein Brief, eine Checkliste, ein Kalender oder ein Kartenausschnitt, vielleicht auch einmal ein Manuskript oder eine Reihe Handouts gedruckt werden sollen, ist das (auch von der Druckgeschwindigkeit) völlig ausreichend und mir - für Schwarzweißdruck - aus mehrerlei Gründen lieber als ein Tintenstrahldrucker, der in Gestalt eines HP OfficeJet Pro 8600 Anfang letzten Jahres auch hier eingezogen ist. Wenn doch einmal größere Druckmengen erforderlich sind, gibt es in der Regel im Büro eine Möglichkeit dafür, oder - oft sogar billiger - im Copyshop.

Problematisch ist aber die Treiberversorgung für neuere Windowsversionen. Für Windows 7 gab es - so weit ich weiß - gar keinen offiziellen Treiber, und die Treiber für Windows 8 und Windows 8.1 sind nur für den Anschluss via USB direkt am entsprechenden Rechner geeignet. Das hilft mir nicht, weil der Drucker am Linuxrechner hängt und von dort via CUPS als Netzwerkdrucker bereitgestellt wird …

Jedesmal also, wenn hier ein neuer Rechner einzieht, stehe ich neu vor dem Problem, einen Druckertreiber für den LaserJet zu installieren, und jedesmal habe ich vergessen, wie ich beim letzten Mal zu einer Lösung gekommen bin - ich erinnere mich nur daran, dass das Stunden gekostet hat, und das tut es dann auch erneut. Und jedesmal ärgere ich mich, dass ich meine Lösung dann nicht hinterher dokumentiert habe.

Daher nun dieser Blogeintrag, in dem für die Nachwelt (und vor allem für meinen nächsten Rechner!) festgehalten sei:

  • Eine Lösung ist die Installation eines anderen Druckertreibers, bspw. für einen LaserJet 3055 - es muss dann aber der PCL-Treiber sein, und das funktioniert nur unter Windows 7 mit PCL 5, nicht aber unter Windows 8 mit PCL 6; PCL-5-Treiber gibt es da nicht mehr.

  • Eine andere Lösung ist es, schlicht einen älteren Treiber auf der Webseite von HP herunterzuladen. Der “host based”-Treiber für Windows Vista funktioniert hier (zwar mit etwas Verzögerung vor dem ersten Ausdruck, ansonsten aber) beanstandungsfrei.

  • Ich habe das Gefühl, bei meinem vorletzten Rechner hätte ich noch eine andere Lösung - offenkundig auch mit einem älteren Treiber - gefunden, aber wenn das so ist, dann erinnere ich mich daran nicht mehr …

Falls zufällig jemand eine noch bessere oder anderweitig konstruktive Idee hat, bin ich im übrigen natürlich ganz Ohr!

Congstar Prepaid

Ich hatte bereits vor einiger Zeit geschildert, dass ich für den drahtlosen Netzzugang im Urlaub und auf Reisen auf einen Huawei E5331 setze, in dem eine Prepaid-Karte von Congstar mit einer aktivierten Tagesflat werkelt. Ganz richtig war mein Bericht jedenfalls zur Tagesflat aber nicht; deren Limit von 200 MB monatlich gilt nämlich nur für Vertragskarten. Bei Prepaid-Karten gibt es stattdessen für die Tagesflat ein tägliches (!) Limit von 25 MB, das ziemlich schnell aufgebraucht ist, worauf dann die Geschwindigkeit auf die üblichen 64 kb/s gedrosselt wird. Dafür ist es - zumindest neuerdings - möglich, jederzeit für weitere 99 Cent ein neues Paket mit 25 MB ungedrosseltem Datenverkehr (gültig für 24 Zeitstunden ab Abruf) zu buchen und sich auch das bereits verbrauchte Volumen anzeigen zu lassen, indem man nämlich einfach - über die entsprechende Datenverbindung - die Webseite datapass.de aufruft. Die zeigt das noch vorhandene und das verbrauchte Volumen an und bietet die Möglichkeit, mit einem Klick Volumen beliebig oft nachzubuchen. Sehr praktisch, wenn man unterwegs “nur mal eben” etwas erledigen will, kein Monatspaket für fünf, zehn oder mehr Euro buchen möchte und das knappe Inklusiv-Volumen von 25 MB nicht ganz ausreicht.

Hat man allerdings - vorhersehbar - etwas größeres vor, bspw. in einem längeren Urlaub, bei dem man bei schlechtem Wetter auch mal arbeiten und surfen möchte (und mit automatisierten Downloads bspw. von Android-Geräten im WLAN leben muss, wenn man vergisst, eben diesen zu deaktivieren), sollte man rechtzeitig (!) vorher statt der Tagesflat eines der größeren Pakete buchen. Die Kündigung der Tagesflat erfolgt nämlich zum Ablauf des Folgetages - und so lange die Tagesflat noch aktiv ist, kann kein anderes Surf-Paket mit Datenvolumen gebucht werden. Auch die Buchung erfolgt dann nicht instantan, sondern braucht etwas Zeit, bis die Bestätigung vorliegt.

Ist die Buchung allerdings gelungen, stehen - je nach Paket - 200 MB, 500 MB, 1 GB oder 3 GB für den mit Buchung beginnenden 30tägigen Abrechnungszeitraum zur Verfügung, und auch hier können beliebig oft für jeweils 5,- € Datenpakete von 200 MB (in den beiden kleineren Paketen) bzw. 500 MB (in den beiden größeren Paketen) auf dem bereits genannten Weg - oder auch per SMS - nachgebucht werden.

Serendipity 2.0-beta3

Rund drei Monate nach dem Release der Beta-Version von Serendipity 2.0 haben sich etliche kleinere und größere Verbesserungen und Fehlerbehebungen angesammelt, so dass die Zeit reif war für eine dritte Beta-Version, die ich mittlerweile - nach einem Probelauf im Testblog und der obligatorischen Sicherheitskopie - auch hier auf Netz - Rettung - Recht einsetze.

Ich bin sehr zufrieden: alles ist noch runder, funktionaler, praktischer geworden, und die in meinem letzten Beitrag aufgezählten kleineren Haken und Ösen sind wohl auch allesamt verschwunden.

Leider war ich in den letzten zwei Monaten nicht mehr in der Lage, täglich die Diskussionen im Forum und den Issue Tracker weiterzuverfolgen oder mich gar selbst einzubringen - man hat es wohl auch an der erneuten relativen Stille hier im Blog bemerkt -, aber ich habe den Eindruck, dass Serendipity 2.0 auf einem sehr guten Weg ist.

Late adopter - bleich wie Papier

Offenkundig gehöre ich nicht (mehr?) zu den Menschen, die allzeit das neueste technische Gadget als allererster haben müssen - im Gegenteil.

Dauerte es schon bei dem Thema Smartphone ungewöhnlich lange, nämlich bis ins Frühjahr 2010, bis ich mich für ein solches erwärmen könnte (obwohl ich schon anderthalb Jahre vorher neidisch beobachtete, wie praktisch so eine Bedienoberfläche mit Touchscreen ist, während ich neben einem Skelett im Wald hockte … - aber das ist eine andere Geschichte), ist der Funke auch bei dem Thema “E-Book-Reader” bisher nicht so recht übergesprungen. Meine Frau nennt schon lange einen Kindle ihr eigen, von Kollegen habe ich mir bereits vor zwei Jahren die Vor- und Nachteile der verschiedenen Modelle erläutern lassen - dennoch konnte ich mich bislang nicht dafür erwärmen, ein gedrucktes Buch gegen ein elektronisches Gerät einzutauschen, obwohl ich schon mehrfach darüber nachgedacht hatte.

Den Anlass zum erneuten Überdenken bot jetzt die Tatsache, dass die beiden letzten Bücher von Karen Rose, die ich noch nicht gelesen hatte, nur als E-Books erschienen sind. Kurzentschlossen habe ich daher Mitte Juli einen Kindle Paperwhite geordert … und bin, mal wieder, durchaus zufrieden. Gerade die Art Bücher, die ich nach dem Lesen ohnehin wieder über BookMooch oder ähnliche Dienste vertauschen würde, kann ich sehr gut auch nur in elektronischer Form lesen. Außerdem hat so ein Gerät echte Vorteile, wenn man im ÖPNV unterwegs ist oder Pausen von 15-45 Minuten außerhalb des Büros zu füllen hat, so dass die Rückfahrt nicht lohnt.

Offenbar macht das Gerät auch durchaus süchtig, oder es geht einfach nur so schnell, “mal eben” in ein Buch hineinzuschauen; jedenfalls habe ich in dem knappen Monat seither immerhin 19 (gut, zumeist kürzere) Bücher rein elektronisch gelesen. Bemerkenswert.

Mobiles Internet - reloaded

Schon vor gut fünf Jahren hatte ich über meine guten Erfahrungen mit einer UMTS-Mobilfunkkarte von Novatel für meinen Laptop berichtet; und diese Karte tut auch noch in meinem aktuellen Laptop unter Windows 7 gute Dienste, denn dessen eingebautes UTMS-Modul hat mich sehr enttäuscht und ist für mich nicht brauchbar.

Inzwischen hat sich die Welt aber natürlich fortentwickelt; und wiederum wurde ich durch Berichte in Blogs auf UMTS-WLAN-Router (wie ich sie bezeichnen möchte - Geräte, die einerseits als WLAN-Accesspoint arbeiten und sich andererseits über eine UMTS-SIM-Karte mit dem Mobilfunknetz verbinden und so für alle Geräte im WLAN eine Internetverbindung bereitstellen) neugierig. Das ist natürlich noch besser, als nur den Laptop selbst online zu bringen, zumal, wenn die UMTS-Abdeckung am Standort des Laptops schlechter ist als anderswo in der (Ferien-)Wohnung.

Also habe ich mir im Juli vergangenen Jahres vor dem Urlaub einen Huawei E5331 zugelegt, der sich bewährt hat und mit dem ich seitdem sehr zufrieden bin.

Mobilfunk-Datentarife

Ein Mobiltelefon nutze ich - für Telefonie und SMS - seit gut 20 Jahren. Seitdem hat sich vieles geändert, nicht zuletzt an den Tarifen. Lange Zeit war ich Vertragskunde - seit 2000 bei Vodafone - und hatte mir irgendwelche Pakete aufschwatzen lassen, für die ich dann im Monat bis zu 30,- € bezahlt habe (ohne Datenoption, wohlgemerkt!), obwohl ich Wenigtelefonierer bin und das Mobiltelefon v.a. benötige, wenn (und weil) ich erreichbar sein muss und - wenn wirklich nötig - kurze (!) Telefonate zu führen. Vor rund 7 Jahren wurde mir das alles zuviel, und ich bin in einen Prepadi-Tarif gewechselt. Seitdem lade ich im Monat - für Telefonie und SMS - in der Regel weniger als 15,- € auf, und ich vermute, dass der Löwenanteil dieser Kosten auf dienstliche Gespräche entfällt (die ich meinem Arbeitgeber bislang großzügigerweise schenke).

Vor gut 10 Jahren war ich einmal einige Jahre täglicher Fernpendler und habe zudem erstmals einen Laptop genutzt; klar, dass ich irgendwann einmal mein Telefon damit via Kabel oder Bluetooth gekoppelt und dann (per GPRS) Mail und News von unterwegs gecheckt (und teilweise auch gechattet) habe. Auch klar, dass ich - bei zeit- oder volumenbezogener Abrechnung! - einige Zeit lang meine monatlichen Rechnungen dank Kostenexplosion quasi mit einem roten Schleifchen zugeschickt bekam; es fehlte eigentlich nur noch ein Dankesbrief des Vorstands für die Sanierung des Unternehmens. Später bin ich dann sinnvollerweise auf eine entsprechende Karte umgestiegen und habe vor allem einen günstig(er)en Anbieter genutzt. Insbesondere als ich dann vor vier Jahren als “late adopter” mein erstes Smartphone mein Eigen nennen durfte, stellte sich die aber auch die Frage nach einem brauchbaren “Flatrate”-Angebot (bzw. einem Volumentarif mit Freivolumen und nachfolgender Drosselung bei Überschreitung).

"Mobilfunk-Datentarife" vollständig lesen

Kommentare des Blogautors hervorheben

In anderen Blogs fand ich es immer ganz schön, wenn Kommentare des ursprünglichen Autors - des Blogeintrags - optisch hervorgehoben werden. Wer das gleichfalls schick findet, kann das auch mit Serendipity umsetzen.

Voraussetzung ist, dass im verwendeten Theme (oder Template) zum einen entsprechender Smarty-Code vorhanden ist, der auf die Übereinstimmung von “Kommentarautor” und “Blogautor” prüft, und es zum anderen dort entsprechende CSS-Definitionen gibt, die dann zu einer Hervorhebung führen. Ersteres ist im neuen Standardtheme “2k11” der Fall, letzteres nicht.

Wenn die Überprüfung ergibt, dass der Kommentar vom Autor des Beitrags selbst stammt, bekommt der entsprechende <article>-Abschnitt die Klasse serendipity_comment_author_self zugewiesen. Für diese Klasse sind also entsprechende Definitionen vorzunehmen, die dann zu einer optischen Hervorhebung führen. Dazu erstellt - oder ergänzt - man eine entsprechende Datei namens user.css im Verzeichnis des Themes (templates/2k11) entsprechend (deren Nutzung freilich in der Konfiguration des Themes aktiviert sein muss), bspw. so wie hier in diesem Blog:

  1. .serendipity_comment_author_self {
  2.         background: #ff9;
  3.         padding: 0.5em;
  4.         border-radius: 0.75em;
  5. }

Die Überprüfung erfolgt standardmäßig auf Identität der jeweils angegebenen Namen von Kommentar- und Eintragsautor, nicht über die Identität der E-Mail-Adresse. Das lässt sich natürlich ändern, bspw. in der Datei comments_by_author.tpl im Theme-Verzeichnis (templates/2k11). Bei einer Überprüfung auf Identität der E-Mail-Adresse wäre aber zu prüfen, ob nicht etwa ein Spamschutz-Plugin die Ausgabe der E-Mail-Adressen unterdrückt; falls doch, stehen die entsprechenden Daten für Smarty nicht zur Verfügung. Nachdem zumindest in 2k11 ohnehin über das Template selbst die Ausgabe der Mailadressen unterbunden wird, kann man die entsprechende Spamschutz-Konfiguration aber auch getrost deaktivieren.

Im Serendipity-Forum finden sich zu den näheren Einzelheiten u.a. folgende Threads:

Beachten sollte man im übrigen, dass natürlich letztlich jedermann Namen und E-Mail-Adresse des Blogautors für Kommentare verwenden kann …

Dokuwiki als "Multisite"-Installation

DokuWiki ist für mich derzeit und schon länger die generische Antwort auf die Frage nach einem Wiki, nicht nur für Dokumentationszwecke, und auch für die Frage nach einem (simplen) CMS.

Ich installiere DokuWiki dabei (wie die meisten Webapplikationen) nicht als Debian-Paket, sondern direkt vom Erzeuger; zum einen, weil ich gerne eine aktuelle Version habe, zum anderen, weil ich dann (wie bei anderen Webseiten) frei entscheiden kann, wo die Dateien liegen sollen - und das ist in der Regel nicht dort, wo Debian sie ablegen würde, insbesondere, wenn es mehr als einen Nutzer mit Webseiten geben soll - und nicht zuletzt, weil das trivial funktioniert. Das führt dazu, dass ich Updates von Hand durchführen muss, und das kann dann schon etwas nervig werden, wenn es mehrere Hosts und mehrere Wikis betrifft.

Daher überlege ich schon länger, wie ich - zumindest bei Installationen auf demselben Host - den Aufwand (und, natürlich, auch den Platzverbrauch) minimieren kann. Die offenkundige Lösung ist eine “Farm”- oder “Multisite”-Installation, bei der der Code nur einmal vorhanden ist, aber jedes Wiki seine eigenen Konfiguration und natürlich seinen eigenen Speicherplatz für Inhalte hat. DokuWiki unterstützt das prinzipiell, aber die nächste Frage ist ja immer, wie gut das auch tatsächlich funktioniert: stabil, flexibel und vor allem ohne krude Hacks.

Nachdem ich mich diese Woche damit beschäftigt habe, kann ich sagen: es funktioniert gut. Die Flexibilität bleibt erhalten, Hacks braucht man nicht, weil die aktuellen DokuWiki-Versionen eine “Multisite”-Installation unterstützen, und stabil wirkt es bisher auch.

Der offensichtliche Vorteil liegt darin, dass man für beliebig viele Wikis nur einmal den Code für das Wiki selbst - und den für Plugins und Templates - installieren, updaten und pflegen muss. Der offensichtliche Nachteil liegt darin, dass alle Plugins und Templates im “Master”-Wiki installiert werden müssen und in den einzelnen Wikis nicht nachinstalliert werden können, und dass sich alle Wikis in Unterverzeichnissen unter einem “Stammverzeichnis” befinden müssen, deren Namen identisch mit der URL des Wikis sind.

"Dokuwiki als "Multisite"-Installation" vollständig lesen

Blogs und Editoren

Wer ein Blog betreibt, kennt vermutlich die Frage danach, welcher Editor für die Einträge am sinnvollsten verwendet werden sollte.

Meine erste Blogengine, sunlog, bot meiner Erinnerung nach bloß ein Eingabefeld, in das man entweder HTML eingeben oder darauf setzen konnte, dass der ansonsten nicht weiter bearbeitete Text schon irgendwie ausgegeben werden würde.

Nach dem Umstieg auf Serendipity habe ich auch erst einmal den Standard-Editor verwendet, wozu braucht man schließlich WYSIWYG, wenn man HTML beherrscht? Das war auf die Dauer dann aber doch eher anstrengend: um jeden Absatz herum <p>...</p> schreiben, Hervorhebungen korrekt mit <strong>...</strong> einbauen, Links von Hand setzen … Das macht keinen wirklichen Spaß. Und der Einbau von Bildern ist von Hand auch eher eine Strafe als ein Vergnügen.

Also bin ich später auf den WYSIWYG-Editor von Serendipity gewechselt; ich glaube, ich habe sogar nacheinander verschiedene solche benutzt. So richtig zufrieden war ich damit aber auch nicht; das daraus generierte HTML erschien teilweise suboptimal, zwischendurch hatte das Gerät aufgrund irgendeiner (vermutlich von mir irrtümlich getroffenen) Einstellung die Neigung, alle Texte per <font>-Tag mit weißem Hintergrund zu hinterlegen und Spielereien dieser Art mehr. Außerdem war es so mit nicht unerheblichem Aufwand verbunden, Einträge in einem Texteditor vorzubereiten und später per copy & paste ins Blog zu übernehmen, bedurfte es dann doch eines zweiten Schrittes, in dem Formatierungen und Links hinzugefügt wurden, wie auch lx4r in einem vergleichbaren Blogbeitrag berichtet. Wenn ich stattdessen direkt im Editor schrieb, ereilte mich gerne ein Missgeschick wie “langen Blogeintrag geschrieben, abgeschickt, mittlerweile aber ausgeloggt” (worauf Serendipity den Beitrag üblicherweise hungrig verspeist und man ihn neu schreiben darf) oder, noch schlimmer, ich komme an eine Tastenkombination, die eine Browseraktion auslöst und dann den Browser den Text verschlucken lässt. Gut, dagegen hilft Lazarus, aber der wahre Jakob ist das trotzdem nicht, ganz abgesehen davon, dass man eben so nicht sinnvoll offline arbeiten (oder auch nur die Annehmlichkeiten eines guten Texteditors nutzen) kann.

Mit dem Relaunch des Blogs habe ich auch dafür eine Lösung gefunden: ich verwende den simplen Standardeditor von Serenditpity zusammen mit dem Markdown-Plugin. Wieder eine für mich sehr hilfreiche Anwendung von Markdown. Jetzt kann ich flüssig Texte schreiben, sie ggf. per copy & paste ins Blog übernehmen und muss mich nie wieder um seltsame Formatierungen kümmern. Passt. Das ist ein Workflow, der Spaß macht.

(Um zu verhindern, dass ältere Einträge durch das Markdown-Plugin zerhackt werden, kann man dieses Plugin für die älteren Einträge - jeweils einzeln pro Eintrag - deaktivieren. Jedenfalls dann, wenn man das Plugin “erweiterte Eigenschaften für Artikel” [serendipity_event_entryproperties] installiert hat. :-))

tweetbackcheck