Blockchain als Perspektive

Steven B. Johnson stellt in seinem aktuellen Artikel Beyond the Bitcoin Bubble im Magazin der New York Times Blockchain als Zukunftshoffnung für offene Protokolle dar.

Er beschreibt das Internet in zwei Phasen, die erste ist geprägt von offenen Protokollen und Peer-to-Peer-Verbindungen, die zweite charakterisiert er als Phase von Monopolisten, die alle Daten in ihre eigene Plattform einschließen und sie als Waren verstehen.

Blockchain bietet laut Johnson die Möglichkeit eine neue Phase einzuläuten, in der offene Standards und die Möglichkeit direkter Vernetzung wieder die Hoffnung auf gleichwertigeren Austausch beflügeln. Er lädt dazu ein Blockchain über Bitcoin hinaus zu beachten, und somit das inhärente Potential wahrzunehmen und zu nutzen:

Like the original internet itself, the blockchain is an idea with radical — almost communitarian — possibilities that at the same time has attracted some of the most frivolous and regressive appetites of capitalism. We spent our first years online in a world defined by open protocols and intellectual commons; we spent the second phase in a world increasingly dominated by closed architectures and proprietary databases. We have learned enough from this history to support the hypothesis that open works better than closed, at least where base-layer issues are concerned. But we don’t have an easy route back to the open-protocol era. Some messianic next-generation internet protocol is not likely to emerge out of Department of Defense research, the way the first-generation internet did nearly 50 years ago.

Yes, the blockchain may seem like the very worst of speculative capitalism right now, and yes, it is demonically challenging to understand. But the beautiful thing about open protocols is that they can be steered in surprising new directions by the people who discover and champion them in their infancy. Right now, the only real hope for a revival of the open-protocol ethos lies in the blockchain. Whether it eventually lives up to its egalitarian promise will in large part depend on the people who embrace the platform, who take up the baton, as Juan Benet puts it, from those early online pioneers. If you think the internet is not working in its current incarnation, you can’t change the system through think-pieces and F.C.C. regulations alone. You need new code.

Steven B. Johnson, Beyond the Bitcoin Bubble. New York Times, 16.01.2018.

WordPress Toolbar und vollflächiger Hintergrund

Die WordPress Toolbar ist Segen und Fluch zugleich. Einerseits stellt sie wichtige Funktionen im Frontend zur Verfügung, andererseits bringt sie einigen Ballast mit sich. Zu eben erwähntem Ballast zähle ich die Inline-Styles über die sie sich ihren Raum auf der Seite freihält. Dieser Raum wird über einen margin-top freigehalten, der mir jedoch dann in die Quere kommt, wenn ich einen vollflächigen Hintergrund einsetzen möchte.

Um sowohl die WordPress Toolbar nutzen zu können und mein Layout konsistent zu halten, gehe ich folgendermaßen vor:

Zunächst füge ich in der header.php meines Themes eine ifelse-Kontrollstruktur hinzu. Dafür setze ich zuerst eine Variable mit der ich später dem html-Element eine entsprechende Klasse zuweise. Daraufhin kontrolliere ich ob die WordPress Toolbar angezeigt wird, und weise der Variable einen entsprechenden Wert zu.

<?php
  $wpadminbarClass = '';

  if ( is_admin_bar_showing() ) {
    $wpadminbarClass .= 'wpadminbar';
  } else {
    $wpadminbarClass .= '';
  }
?>

<html dir="ltr" <?php language_attributes(); ?> class="no-js <?php echo $wpadminbarClass; ?>">

Mit dieser Klasse am html-Element habe ich ein Hilfsmittel zur Hand, um die Inline-Styles zu überschreiben. Dazu füge ich dem Stylesheet meines Themes die entsprechenden Zeilen der Inline-Styles hinzu und ersetze die vorgesehenen margin-top durch padding-top.

html.wpadminbar {
  margin-top: 0 !important;
  padding-top: 32px !important;
}

* html.wpadminbar body {
  margin-top: 32px !important;
  padding-top: 0 !important;
}

@media screen and ( max-width: 782px ) {
	html.wpadminbar {
    margin-top: 0 !important;
    padding-top: 46px !important;
  }

	* html.wpadminbar body {
    margin-top: 0 !important;
    padding-top: 46px !important;
  }
}

Welche Möglichkeiten nutzt ihr um sowohl die WordPress Toolbar zu nutzen und Eure Layouts konsistent zu halten?

Spricht Eurer Meinung nach etwas dagegen in den Inline-Styles direkt padding-top statt margin-top zu verwenden?

Ist Dein Mac sicher?

Gestern Abend sah ich einen Tweet von @lemiorhan indem er eine Sicherheitslücke darstellte, über die jede Person sich Zugang zu einem Mac mit High Sierra verschaffen kann. Unter High Sierra ist der root-Benutzer standardmäßig ohne Passwort aktiviert. Da der root-Benutzer systemweit über alle Rechte verfügt, handelt es sich hierbei um eine äußerst kritische Sicherheitslücke.

Mit diesen sieben Schritten kannst Du dem root-Benutzer Deines Macs ein sicheres Passwort zuweisen:

Passwort für den root-Benutzer setzen

  1. Wählen das Menü „Apple“ () > „Systemeinstellungen“, und klicke anschließend auf „Benutzer & Gruppen“ (oder „Accounts“).
  2. Klicke auf das Schlosssymbol, und gib anschließend den Benutzernamen und das Passwort für einen Administratoraccount ein.
  3. Klicke auf „Anmeldeoptionen“.
  4. Klicke im unteren Bereich der Karte neben ›Netzwerkaccount-Server‹ auf „Verbinden“ (oder „Bearbeiten“).
  5. Klicke auf „Verzeichnisdienste öffnen“.
  6. Klicke im Fenster „Verzeichnisdienste“ auf das Schlosssymbol, und gib den Benutzernamen und das Passwort für einen Administratoraccount ein.
  7. Wähle in der Menüleiste der Verzeichnisdienste: „Bearbeiten“ > „root-Benutzer aktivieren“, und gib anschließend das Passwort ein, das Du für den root-Benutzer verwenden möchtest.

Rene Ritchie weist auf imore.com darauf hin, dass der root-Benutzer nicht deaktiviert werden sollte, da dadurch die Sicherheitslücke wieder geöffnet wird.

Wer keine Berührungsängste mit dem Terminal hat, kann das Passwort für den root-Benutzer auch darüber setzen, das geht wesentlich schneller und einfacher:

  1. Terminal öffnen
  2. sudo passwd root eingeben
  3. Die erste Passwort-Abfrage bezieht sich auf den Account mit dem Du angemeldet bist, und dann gibst Du zwei Mal das neu zu setzende Passwort für den root-Benutzer ein

Danke an Sven für den Terminal-Hinweis.

Update 30.11.2017:
Apple hat in der Nacht ein Sicherheitsupdate zur Verfügung gestellt. Falls noch nicht geschehen, aktualisiere am Besten direkt Deinen Mac.

Deployment eines Themes für WordPress

Dieses Wochenende steht unter dem Motto der Vereinfachung von Prozessen. Während ich meine Arbeit schon lange mit Git versioniere, hatte ich für das Deployment bisher noch den umständlichen Weg über den direkten Upload der aktualisierten Dateien gewählt. Dieser Umstand störte mich schon eine Weile, und so war heute Abend die Zeit gekommen auch diesen Prozess zu vereinfachen. Gestern habe ich darüber geschrieben wie ich WordPress mit einer Eingabe im Terminal für die Installation vorbereite, heute soll es nun darum gehen, wie sich Änderungen am Theme ganz einfach mit einem git push in der Produktion anwenden lassen.

Voraussetzungen

  • Etwas Vertrautheit im Umgang mit git
  • Ein Hosting das SSH und git unterstützt

Was haben wir vor?

Für das Deployment des Codes legen wir ein zusätzliches Verzeichnis (Repository) auf dem Server an, auf dem die Seite betrieben wird für die die Änderungen bestimmt sind. Diesem Repository ordnen wir eine Funktion zu, die ausgeführt wird, sobald das Verzeichnis aktualisiert wurde. Nachdem wir diese Schritte durchgeführt haben, kann das Deployment durch ein einfaches git push live master ausgeführt werden.

In diesem Artikel gehe ich davon aus, dass du dein Projekt bereits mit git versionierst, und beschriebe daher nur die Aspekte, die für den Deploy notwendig sind.

Repository vorbereiten

Das Verzeichnis für die Repositories (kurz repos) legen wir im Home-Verzeichnis an. Das Home-Verzeichnis ist nicht das öffentliche Verzeichnis in dem sich die Seite befindet und die über den Browser erreicht wird. Diese Seite ist bei Uberspace gehostet, ich verwende für die Beispiele Pfade wie sie dort üblich sind, das musst du für deinen Hoster anpassen.

Als erstes Legen wir ein Verzeichnis mit dem Namen repos an und wechseln in dieses Verzeichnis:

mkdir repos && cd repos

In unserem eben angelegten Verzeichnis sollen die Repositories angelegt werden. Da Themes und Plugins am Besten in unterschiedlichen Repositories verwaltet werden, gibt uns dieses Vorgehen die Möglichkeit unterschiedliche Projekte direkt mit unserer Seite zu verbinden. Wir bereiten nun das Repository für unser Theme vor und wechseln direkt in das neue Verzeichnis. Da es sich hierbei um ein Bare-Repository handelt, bekommt es gemäß der Konvention die Endung *.git.

mkdir mein-theme.git && cd mein-theme.git

Nachdem die Verzeichnisstruktur korrekt angelegt ist, bereiten wir das Repository dafür vor Inhalte unserer lokalen Entwicklungsumgebung zu empfangen:

git --bare init

Das Repository auf dem Server ist nun vorbereitet und wartet darauf mit Inhalten gefüllt zu werden. Bevor wir die Funktion anlegen über die wir die Änderungen direkt nach Eintreffen auf dem Server in unsere WordPress-Installation übertragen, weise ich noch auf die RAM-Nutzung hin. Bei Uberspace kam es bei der Verwendung von git auf den Servern schon zu Problemen mit der RAM-Auslastung. Im Uberspace-Wiki werden ein paar einfache Einstellungen erwähnt, die ein gutes Zusammenspiel von Server und git gewährleisten.

Deployment Funktion anlegen

In der Shell befinden wir uns noch im eben angelegten Repository mein-thema.git, und in diesem Repository legen wir auch die Deployment-Funktion an. Um die Änderungen anzuwenden verwenden wir den servierseitigen Hook post-receive, der beginnt wenn der erste Prozess abgeschlossen ist und mit den erhaltenen Informationen einen anderen Dienst aktualisieren kann.

vi hooks/post-receive

Die Datei post-receive öffnet sich nun im visuellen Editor der Shell. Den Bearbeitungsmodus aktivierst du mit i, worauf sich die eigentliche Funktion einfügen lässt. Bitte achte darauf, dass du den Pfad zum Theme auf das du die Änderungen anwenden möchtest für deine Gegebenheiten anpasst:

#!/bin/sh
GIT_WORK_TREE=/var/www/virtual/user/wp-content/themes/mein-theme git checkout -f

Den Bearbeitungsmodus des visuellen Editors verlässt du mit esc, danach gibst du :wq ein um die Änderungen zu speichern und den Editor zu verlassen.

Die eben angelegte Funktion muss ausführbar sein, weshalb wir ihre Rechte entsprechend setzen:

chmod +x hooks/post-receive

Wir haben nun unser Repository auf dem Server angelegt und vorbereitet, die Funktion um die eingecheckten Änderungen auf die Produktion anzuwenden haben wir ebenfalls erstellt. Dem Deploy steht nichts mehr im Wege.

Remote hinzufügen

Im Terminal öffnen wir ein neues Tab und wechseln in das Verzeichnis unseres Themes. Dort sehen wir zunächst nach mit welchem entfernten Repository wir bereits verbunden sind:

git remote -v

Hier wird dir sehr wahrscheinlich dein Repository bei GitHub oder BitBucket ausgegeben. Unsere Entwicklungsumgebung verbinden wir nun noch mit dem Repository das wir eben auf unserem Server angelegt haben:

git remote add live ssh://user@server.net/home/user/repos/mein-theme.git/

Mit git remote -v kannst du nun noch schnell überprüfen ob deine Eingabe geklappt hat und dein live-Repository ebenfalls verbunden ist.

Deployment, oder Änderungen anwenden

Nun haben wir alles vorbereitet um Änderungen an unserem Theme in der Entwicklungsumgebung ganz einfach auf das Theme in der Produktion anzuwenden. Diesen Vorgang nennt man Deployment, und dieser besteht nun nicht mehr in der händischen Auswahl und Übertragung der geänderten Dateien, sondern wird durch einen einfachen git push angestossen:

git push live master

Fazit

Ich habe mich dazu entschieden das Deployment nicht über einen Dienst zu machen, da ich keine Lust hatte meine Zugangsdaten irgendwo einzutragen. Mit dieser Methode melde ich mich mit einem SSH-Schlüssel auf dem Server an. Die Verknüpfung meines Rechners und dem Server über den erwähnten SSH-Schlüssel war bereits angelegt, und ist – soweit ich das beurteilen kann – ziemlich sicher.

Die Möglichkeiten Änderungen an einem Theme genauso einfach in der Produktion anzuwenden und nicht mehr nach den geänderten Dateien suchen zu müssen und diese in das korrekte Verzeichnis auf dem Server zu kopieren gefiel mir so gut, dass ich direkt zwei Änderungen durchführte.

Verwendete Quellen:

WordPress herunterladen und installieren

Als ich kürzlich wieder einmal WordPress installieren musste, wollte ich nicht den gewohnten Weg – aktuelle Version über die Webseite herunterladen, entpacken, in den entsprechenden Ordner kopieren und schließlich installieren – gehen, sondern machte mich auf die Suche nach einer direkteren Möglichkeit.

WordPress herunterladen

Bevor ich die aktuelle Version von WordPress herunterlade, wechsle ich mit dem Terminal in den Ordner, in dem ich WordPress installieren möchte. Das funktioniert sowohl per SSH auf einem Server, als auch direkt auf dem Rechner. Im korrekten Ordner angekommen nutze ich curl um das Paket herunterzuladen:

curl -O https://de.wordpress.org/latest-de_DE.tar.gz

Nachdem der Ladevorgang abgeschlossen ist befindet sich das komprimierte Paket in meinem Ordner, und muss entpackt werden. Zum entpacken verwenden wir den Tape Archiver (kurz tar), dem wir die Optionen -xzf übergeben. -x legt fest, dass die Dateien aus einem Archiv extrahiert werden. Mit -f werden die Daten der ausgegebenen Datei gelesen, und -z dekomprimiert das gzip-Archiv. Da ich WordPress direkt im Zielordner, und nicht in einem Unterordner, installieren möchte, gebe ich noch die Option --strip-components=1 mit, was dazu führt, dass die erste Verzeichnisebene weggelassen wird:

tar -xzf latest-de_DE.tar.gz --strip-components=1

Nun befindet sich WordPress an der gewünschten Stelle und ist bereit installiert zu werden. Bevor ich dies jedoch mache, lösche ich noch das komprimierte Paket:

rm -f latest-de_DE.tar.gz

Der Zielordner enthält nun alle notwendigen Dateien um darüber WordPress zu installieren.

In einem Schritt

Im einleitenden Satz schrieb ich davon, dass ich nach einer direkten Möglichkeit suchte. Während ich die gefundene Möglichkeit hier aufschrieb führte ich selbstverständlich die einzelnen Schritte nochmals aus, und stieß dabei auf weitere Verbesserungen. Da es möglich ist einzelne Befehle im Terminal direkt nacheinander ausführen zu lassen (Piping), kann das oben beschriebene durch eine Eingabe erzielt werden:

curl https://de.wordpress.org/latest-de_DE.tar.gz | tar -xzf - --strip-components=1

WordPress installieren

Die Installation lässt sich ganz einfach im Browser abschließen. Dazu gebe ich die Adresse der zu installierenden Webseite ein, daraufhin fragt WordPress nach den Angaben zur Datenbank, nachdem diese übermittelt sind, kann ich einen Benutzer anlegen und die Installation abschließen.

Fazit

Meiner Ansicht nach liegt der Vorteil dieser Methode darin, dass alle erforderlichen Dateien per Terminal geladen werden und die Installation schließlich im Browser abgeschlossen wird, dadurch geht sie schneller und ich kann mich früher an das machen, was ich mit der Installation vor habe.

Verwendete Quellen

Prototyping mit CSS Grid Layout

CSS Grid Layout, Pug, auto-fill, dense, minmax()

Die Möglichkeiten Layouts im Browser darzustellen kommen mit CSS Grid Layout in eine neue Phase. CSS Grid Layout ermöglicht die schnelle Umsetzung von Layouts, und eignet sich auf Grund seiner Flexibilität besonders gut für die Erstellung von Prototypen. Schnelligkeit und Flexibilität sind vor Allem darin begründet, dass die Layout-Entscheidung über das Elternelement erfolgt und sich die Kindelemente nach diesen Vorgaben richten. Auf diese Weise lassen sich unterschiedliche Szenarien unmittelbar testen.

Durch die Unterstützung in allen aktuellen Browsern lässt sich CSS Grid Layout, im Sinne des progressive Enhancement, auch in der Produktion einsetzen, an dieser Stelle soll es aber nur um die Entwicklung von Prototypen gehen.

Der Prototyp soll folgende Anforderung erfüllen: Ein Raster von Kacheln, deren genaue Anzahl unbekannt ist. Jede vierte Kachel soll zwei Spalten breit sein, während die übrigen nur eine Spalte einnehmen.

Um diese Anforderung zu erfüllen bekommt das Elternelement folgende Anweisung:

.grid-parent {
  display: grid;
  grid-auto-flow: dense;
  grid-gap: $spacing;
  grid-template-columns: repeat(auto-fill, minmax($mintrack, 1fr));
}

Zunächst wird die Darstellung als Raster festgelegt. Da die Anzahl der Kacheln nicht bekannt ist, definiere ich über die Eigenschaft grid-template-columns ein Raster, das durchgängige Spalten hat, wofür auto-fill sorgt, und lege eine minimale und maximale Spaltenbreite fest. Die minimale Spaltenbreite lege ich in der Variable $mintrack fest, was mir auch die Möglichkeit gibt diesen Wert zu einem späteren Zeitpunkt in einer Media-Query zu verwenden. Die Eigenschaft grid-auto-flow legt fest wie die Kindelemente im Raster positioniert werden. Der Wert dense sorgt dafür, dass Lücken die durch größere Elemente entstehen gefüllt werden, was dazu führen kann, dass die Reihenfolge verändert wird.

Die Anzahl der Spalten die jede vierte Kachel einnehmen soll, lege ich direkt auf dem Kindelement fest:

.grid-child:nth-of-type(4n) {
  grid-column: auto / span 2;
}

Um die Anzahl der Kacheln schnell modifizieren zu können, verwende ich die auf JavaScript basierende Template Engine Pug zur Erzeugung des Markups. Mit dem folgenden Code wird das Elternelement mit 17 Kindelementen erzeugt. Die Kindelemente haben einen Titel der die Position des Elements beinhaltet und einen kurzen Text.

section.grid-parent
  while n < 17
    .grid-child
      h1.title Tile #{n++}
      p.copy= copy

Zur Darstellung des Vorgehens habe ich in den Code hier nur in Auszügen wiedergegeben. Den vollständigen Code, die kompilierte Ansicht und die Möglichkeit den Code zu verändern, findest Du in diesem CodePen.

Im Bildschirmfoto ist das Raster zu sehen. Diese äußerst hilfreiche Funktion der Entwickler-Tools in Firefox nutze ich regelmäßig um das definierte Raster zu überprüfen.

Die Anregung zur Lösung der gestellten Anforderung stammt aus dem hervorragenden Buch The New CSS Layout von Rachel Andrew. Die, wie gestern bekannt gegeben wurde, die neue Chefredakteurin des Smashing Magazine ist.

Reaktionen sichtbar machen

Der Austausch über Blogartikel steht für mich schon immer im Mittelpunkt. In den Artikeln werden Ideen, Gedanken und Erfahrungen beschrieben, diese stehen jedoch nicht nur für sich selbst, sondern werden von den Reaktionen der Leserinnen und Leser ergänzt. Anfangs wurde engagiert kommentiert. Durch Twitter und Facebook fand schließlich der Austausch meist auf den entsprechenden Plattformen statt, und beschränkte sich in vielen Fällen auf den Ausdruck des Gefallens. Viele Kommentarspalten blieben leer, und die Artikel wirkten leblos. Die Reaktionen darauf war im Blog selbst nicht sichtbar. Social-Buttons mit ihren Tracking-Skripten stellten für mich keine Lösung dieses Problems dar. Den Austausch über die Inhalte verwandeln sie in Zahlen, die Qualität desselben bleibt jedoch weiterhin verborgen. Einen Mehrwert für das Blog und dessen Community stellen sie nicht dar, sondern dienen vor allem den Plattformen als Datenlieferanten.

Bereits vor einigen Jahren erfuhr ich von der IndieWeb-Bewegung, die vernetzte Inhalte sichtbar machen wollte, den Zugriff auf die eigenen Daten betonte und an vielen Stellen interessante Projekte hervorbrachte. In diesem Zusammenhang las ich bei Jeremy Keith über Webmentions.

Die Annahme über zu wenig Wissen und Zeit zu verfügen um mich selbst an die Implementation von Webmentions zu machen, führte dazu diesen Bereich ruhen zu lassen, und schließlich nichts dergleichen zu unternehmen. Erst als ich im Nachklang der Smashing Conference in Freiburg den Artikel »Implementing Webmentions« von Drew McLellan las, fasste ich den Entschluss die Reaktionen auf Inhalte in Blogs endlich wieder sichtbar zu machen.

Da ich gerade an ein paar Projekten arbeite die auf WordPress basieren und ich meine eigenen Blogs ebenfalls damit betreibe, widme ich mich an dieser Stelle der Implemantation von Webmention in mit WordPress betriebene und selbst gehostete Blogs.

Was ist zu tun?

Um Webmention mit WordPress zu benutzen sind vier Schritte nötig.

  1. Installation des Webmention-Plugins
  2. Installation des Plugins für Semantic-Linkbacks
  3. Social-Media-Profile via Bridgy mit dem Blog verbinden
  4. Das eigene Comment-Template anpassen

Das Webmention-Plugin

Das Webmention-Plugins von Matthias Pfefferle erweitert die Diskussion-Einstellung eines WordPress-Blogs, und legt die Grundlage dafür, dass ein Blog Webmentions senden und empfangen kann.

Nachdem das Plugin heruntergeladen, installiert und aktiviert ist stehen unter Einstellungen > Diskussion ein paar weitere Einstellungen zur Verfügung. Achte auch darauf, dass die allererste Einstellung »Versuche, jedes in Beiträgen verlinkte Weblog zu benachrichtigen« ausgewählt ist.

Unter Webmention Settings befinden sich vier Checkboxen und eine Auswahl mit deren Hilfe sich das Verhalten der Webmentions einstellen lassen.

Das Plugin für Semantic-Linkbacks

Das Plugin für Semantic-Linkbacks bietet die Möglichkeit die empfangenen Webmentions je nach Typ unterschiedlich zu behandeln. Es weist den empfangenen Erwähnungen einen entsprechenden Typ – beispielsweise Like, Repost oder Mention – zu, der als Filter und für die Styles zur Verfügung steht.

Eine Übersicht der Einstellungen bringt dieses Plugin nicht mit, es verrichtet seine Dienste sobald es aktiviert ist. Im IndieWeb-Wiki erfährst Du etwas über die Möglichkeiten die zugewiesenen Typen in Deinem Theme zu verwenden. Wie ich die Typen verwende beschreibe ich etwas später in diesem Artikel.

Update 15.10.2017:
Seit Version 3.5.0 unterstützt dieses Plugin die Darstellung von Likes, Mentions und Reposts in eigenen Listen. Dadurch wurde die Anpassung meines Comment-Template obsolet.

Brücken bauen

Der Dienst Bridgy baut die Brücken zwischen Deinen Social-Media-Profilen und Deinem Blog. Er überwacht die verbundenen Social-Media-Profile und sendet Erwähnungen ans Blog. Deine Social-Media-Profile müssen öffentlich sein und die URL Deines Blogs muss dort hinterlegt sein. Wichtig ist auch, dass die Post öffentlich sind, nur so können sie von Bridgy ausgelesen werden.

Auf brid.gy wählst Du also die Social-Media-Kanäle aus über die Du Erwähnungen empfangen möchtest. Sobald Du Bridgy den Zugriff auf Deine Profile gestattet hast, beginnt es damit alle 30 Minuten nachzusehen ob es dort eine Erwähnung Deines Blogs gibt. Wird es fündig sendet es die Erwähnung als Kommentar an Dein Blog.

Das Comments-Template

Um die Erwähnungen zu Bündeln habe ich mein Comments-Template und das Stylesheet etwas angepasst. Zur Anpassung meines Comment-Templates habe ich mich an diesem Code von Michael Bishop orientiert. Mein aktuelles Comments-Template kannst Du in diesem Gist ansehen.

Likes und Reposts sammle ich in einer Liste und verlinke lediglich die Profilbilder mit den jeweiligen Accounts. Danach gebe ich eine Liste der Kommentare aus – in dieser Liste erscheinen bei mir Antworten von Twitter, Kommentare von Facebook und die klassischen Kommentare. In einer Liste unter den Kommentare gebe ich Erwähnungen des Artikels in anderen Blogs aus.

Verbesserungen

Bei meinen ersten Schritten mit Webmention sehe ich Verbesserungspotential in den folgenden Punkten:

  • Links auf den Namen der Autor_inn_en korrigieren
  • Baumstruktur der Kommentare darstellen
  • Profilbilder optimieren und auf den eigenen Server speichern
  • Den Callback der manuellen Webmention-Eingabe optimieren

Ich freue mich von Euch zu hören wenn Ihr Ideen habt wie einer dieser Punkte gelöst werden kann, aber auch wenn Euch noch weitere Verbesserungen einfallen.

Benson Coffee

Den Kaffee von Benjamin Pozsgai wählte eine internationale Jury zum besten des Wettbewerbs und machte ihn zum Deutschen Röstmeister. Als solcher vertritt er Deutschland diesen Winter bei der Weltmeisterschaft in China.

Um auch bei der Weltmeisterschaft die Kaffees optimal zu rösten, bereitet er sich gerade gründlich vor. In den geplanten Trainingseinheiten wird er sorgfältig ausgewählte Kaffees rösten, und dabei auf die Besonderheiten der Bohnen achten um das Beste aus ihnen herauszuholen.

Benjamin Pozsgai hat ein Konzept erarbeitet, das vielen Kaffeeinteressierten die Möglichkeit gibt Teil der Vorbereitungen auf die Weltmeisterschaft zu werden: Das Benson Coffee Abo. Für das Abo wird nach jeder Trainingseinheit die beste Röstung ausgewählt und an die Abonnenten verschickt. Wer auf hochwertige Kaffees steht hat mit diesem Abo die Möglichkeit fünf ganz besondere Kaffees zu bekommen, und sollte sich diese Gelegenheit nicht entgehen lassen.

Bildschirmfoto der Webseite von Benson Coffee – Benjamin Pozsgai

Ich hatte die Möglichkeit für Benson Coffee meine Begeisterung für Kaffee und Webdesign zu verbinden. Auf diesem Weg entstand eine Webseite die über die Vorbereitungen zur Weltmeisterschaft informiert und über die das Kaffeabo bezogen werden kann.

Wer sich das Abo nochmals von Benjamin Pozsgai erklären lassen möchte kann das mit diesem Video tun:

Projektbeteiligung

Die Corporate Identity für Benson Coffee wurde von Marc Böttler entwickelt.

Meine Aufgabe bestand darin das Konzept der Webseite auszuarbeiten. Die Corporate Identity auf ein Interface Design zu übertragen und schließlich die Webseite mit integriertem Webshop und Blog umzusetzen.

Die Vorteile von SVG nutzen

Skalierbare Vektor Grafiken (SVG) bevorzuge ich schon seit längerem zur Darstellung von Logos und Icons in Webseiten. Sie bringen eine ganze Reihe von Vorteilen mit, die ich nicht mehr missen möchte.

Die Hauptvorteile von SVG werden direkt in ihrem Namen ausgedrückt. Es handelt sich dabei um Vektorgrafiken die verlustlos skalieren und auf allen Ausgabegeräten gestochen scharf dargestellt werden. Da es sich bei SVG um Vektorgrafiken auf Codebasis handelt, lassen sie sich sehr gut optimieren und versionieren, können mit CSS und JavaScript angesprochen werden, verstehen Media-Queries und sind darüberhinaus noch für den barrierearmen Einsatz geeignet.

Laut caniuse.com können etwas mehr als 97% der Browser SVG darstellen. Deshalb ist in vielen Anwendungsbereichen – beispielsweise wenn sie als Icon einen Text ergänzen – kein Ersatz erforderlich. Da ich SVG auch für Logos einsetze, muss sichergestellt sein dass die Grafik immer erscheint.

Um alle Vorteile von SVG nutzen zu können, müssen diese direkt im HTML eingebunden werden. Um darüber hinaus noch den Zwischenspeicher der Browser nutzen zu können, lade ich sie als erstes Element im body und binde sie über use an den entsprechenden Stellen der Webseite ein.

Die Vorteile von SVG nutzen

Um zu demonstrieren wie SVG meiner Ansicht nach optimal genutzt werden habe ich eine kleine Liste mit Links zu meinen Social-Media-Profilen erstellt. Vielleicht ist jetzt ein guter Zeitpunkt die Demo und den Code in einem neuen Tab zu öffnen. Die Links zum jeweiligen Profil werden durch das Logo der Plattform dargestellt. Um die Serveranfragen so gering wie möglich zu halten, fasse ich alle Logos in einer Datei (Spritesheet/Sprite) zusammen.

Das SVG-Sprite sieht folgendermaßen aus:

<svg xmlns="http://www.w3.org/2000/svg" display="none" height="0" width="0">
  <symbol id="twitter" viewBox="0 0 512 512">
    <path fill="currentColor" d="m456 133c-14 7-31 11-47 13 17-10 30-27 37-46-15 10-34 16-52 20-61-62-157-7-141 75-68-3-129-35-169-85-22 37-11 86 26 109-13 0-26-4-37-9 0 39 28 72 65 80-12 3-25 4-37 2 10 33 41 57 77 57-42 30-77 38-122 34 170 111 378-32 359-208 16-11 30-25 41-42z"/>
  </symbol>
  <symbol id="instagram" viewBox="0 0 512 512">
    <path fill="currentColor" d="m256 152c-52-1-100 43-103 95a103 103 0 0 0 200 43 104 104 0 0 0 -97-138zm0 169c-40 2-74-40-65-79 7-40 54-65 91-48 36 14 52 63 31 95a66 66 0 0 1 -57 32zm131-171c1 20-27 31-41 16-14-14-3-41 17-40 13 0 24 11 24 24z"/>
    <path fill="currentColor" d="m424 89c-25-27-64-35-100-33-54 0-109-1-164 1-43 2-85 31-98 73-10 32-5 66-6 98 0 42-1 84 1 126 3 46 37 87 81 98 30 7 62 3 92 4 42 0 83 1 124-1 44-3 85-33 96-76 9-32 5-64 6-97 0-41 1-83-1-125-2-25-13-50-31-68zm-3 250c1 35-23 70-57 77-28 5-56 2-83 3-40-1-80 1-120-1-32-2-61-26-66-58-4-28-1-57-2-86 1-38-1-76 1-114 2-32 26-60 58-65 29-4 59-1 88-2 38 0 76-1 113 1 33 2 62 29 66 62 3 30 1 61 2 92z"/>
  </symbol>
  <symbol id="facebook" viewBox="0 0 512 512">
    <path fill="currentColor" d="m287 456v-182h61l9-72h-70v-45c0-21 6-35 35-35h38v-63c-7-1-29-3-55-3-54 0-91 33-91 94v52h-62v72h62v182z"/>
  </symbol>
</svg>

Das jeweilige Logo befindet sich innerhalb eines symbol welches mit der entsprechenden ID versehen ist und über die viewBox die Zeichenfläche vorgibt innerhalb der die Pfadangaben gedeutet werden. Wird dieses Sprite als erstes Element im body eingefügt, lässt sich das jeweilige Symbol mit den folgenden Zeilen einbinden:

<svg class="social-icon">
  <use xlink:href="#twitter"></use>
</svg>

Ich binde das Sprite im body ein, da alle Version des Internet Explorer und ältere WebKit-Browser extern eingebundenen SVG nicht unterstützen. Das symbol lässt sich direkt über seine ID ansprechen, und muss nicht wie in CSS durch die Position angesteuert werden.

Bevor ich das Sprite einbinde, überprüfe ich ob der Browser in der Lage ist direkt eingebundene SVG darzustellen:

var supportsSvg = function() {
    var div = document.createElement("div");
    div.innerHTML = "<svg/>";
    return (div.firstChild && div.firstChild.namespaceURI) === "http://www.w3.org/2000/svg";
};

Um das Sprite per Ajax zum body hinzuzufügen übernehme ich die Funktion von Chris Coyer:

function getSVG() {
    var ajax = new XMLHttpRequest();
    ajax.open("GET", "./assets/images/sprite.svg", true);
    ajax.responseType = "document";
    ajax.onload = function() {
        document.body.insertBefore(ajax.responseXML.documentElement, document.body.childNodes[0]);
    };
    ajax.send();
};

Kann der Browser mit direkt eingebundenen SVG umgehen, passe ich die Klasse entsprechend an und füge ich das Sprite mittels Ajax als erstes Element zum body hinzu:

if (supportsSvg()) {
    document.documentElement.className += " svg";
    getSVG();
} else {
    document.documentElement.className += " no-svg";
};

Das Sprite ist nun eingebunden, und die Symbole erscheinen an den gewünschten Stellen. Die Links zu den Profilen habe ich wie buttons gestaltet und möchte die Hintergrundfarbe und die Farbe des Icons kontrollieren. Dazu verwende ich folgende CSS-Deklarationen:

a .social-icon,
a:visited .social-icon {
  background-color: rgb(51, 51, 51);
  border-radius: 15%;
  color: rgb(255, 255, 255);
  display: block;
  height: 2.75rem;
  padding: 0.1875rem;
  width: 2.75rem;
  transition: background-color 0.3s ease-out,
    color 0.3s ease-out;
}

a:hover .social-icon,
a:focus .social-icon {
  background-color: rgb(0, 153, 0);
  color: rgb(250, 250, 250);
}

Momentan sind die Links sowohl von funktionierendem JavaScript und der SVG-Unterstützung des Browsers abhängig. Für den Fall, dass entweder das eine oder das andere nicht zur Verfügung steht benötige ich einen Ersatz. Als Ersatz biete ich ein PNG-Sprite an welches ich als Hintergrundbild lade und über die Position des Hintergrunds jeweils das entsprechende Icon anzeige. Dieses Sprite enthält dieselben Icons auf transparentem Hintergrund. Da ich dem html die entsprechenden Klassen mitgebe könnte ich den Ersatz folgendermaßen einbinden:

.no-js .social-icon,
.no-svg .social-icon {
  background-image: url("./assets/images/sprite.png");
  background-repeat: no-repeat;
}

.no-js .social--twitter .social-icon,
.no-svg .social--twitter .social-icon {
  background-position: 0 0;
}

.no-js .social--instagram .social-icon,
.no-svg .social--instagram .social-icon {
  background-position: -3.125rem 0;
}

.no-js .social--facebook .social-icon,
.no-svg .social--facebook .social-icon {
  background-position: -6.25rem 0;
}

Da ich die Klasse no-js meinem Template mitgebe, führt diese Methode dazu, dass die Browser bei jedem Aufruf auch das PNG-Sprite laden, da mein Script die Klasse no-js erst dann mit js ersetzt wenn das DOM geladen ist. Ich möchte allerdings nur das Sprite laden welches auch tatsächlich verwendet wird.

Um den doppelten Download des Sprites zu umgehen entferne ich den Selektor .no-js .social-icon aus meinem Stylesheet, und füge ihn innerhalb eines noscript dem head meines Templates hinzu.

<noscript>
    <style>
        /* TODO: keep sprite in sync with .no-svg .social-icon */
        .no-js .social-icon {
            background-image: url("./assets/images/sprite.png");
        }
    </style>
</noscript>

Wichtig ist, dass die Sprite-Referenz jederzeit synchron ist. Um dies nicht zu vergessen versehe ich die entsprechenden Stelle mit einem Kommentar. Solange sich Name und Ort des Sprites nicht ändern dürfte es an dieser Stelle jedoch zu keinem Problem kommen.

Die Vorteile von SVG lassen sich meiner Ansicht nach auf diese Weise ideal nutzen. Auch wenn die Funktionalität eines PNG-Sprites nicht exakt einem SVG-Sprite entspricht, bleibt der Wiedererkennungswert erhalten, und die notwendigen Informationen stehen allen Nutzer_inn_en der Webseite zur Verfügung.

Verwendete Ressourcen:

Alles auf einen Blick

Meine Hilfsmittel

Meine Hilfsmittel

Konzept

Um meine Ideen und Gedanken zu konkretisieren helfen mir Stifte, Papier und Schere. Daher befinden sich in meiner unmittelbaren Nähe immer ein paar Stifte, etwas Papier (lose und gebunden) und eine Schere. Meistens greife ich bei der Erstellung eines Konzepts zu meinem iPad und erstelle mit Paper Skizzen des Interfaces und der Interaktionen. Diese Skizzen lassen sich später leicht in andere Programme übertragen.

Schreiben

Kein Konzept und keine Zeile Code entsteht ohne einen guten Editor. Seit einer Weile schreibe ich meinen gesamten Code mit Atom, dem Editor von Github. Neben einigen hilfreichen Erweiterungen bringt Atom auch eine übersichtliche Hervorhebung der Änderungen zur letzten eingecheckten Version mit.

Die meisten Texte schreibe ich in Markdown und verwende dafür iA Writer. Ich habe diesen Editor seit der ersten Version auf allen meinen Geräten und habe mittels iCloud-Synchronisierung die Möglichkeit in den unterschiedlichsten Situationen daran weiter zu arbeiten. Selbst meine Aufgabenliste verwalte ich mit iA Writer.

Grafik

Während früher Photoshop eine wichtige Rolle bei der Entstehung eines grafischen Interfaces spielte, ist bei mir heute wesentlich öfter Sketch oder Illustrator geöffnet. Bei Illustrator gefallen mir vor Allem die Entwicklungen im Zusammenhang mit der Bearbeitung und Ausgabe von SVGs.

Lokale Prozesse

Ich entwickle komplett lokal, weshalb ein stabiler lokaler Server nicht fehlen darf. Dafür steht mir MAMP Pro zur Seite. Durch die Verwendung von Sass und Coffee Script benötige ich CodeKit, das mir den Code kompiliert, komprimiert und das gesamte Projekt schließlich in einem Build-Ordner zur Verfügung stellt. Die Browser-Synchronisierung nach jedem Speichervorgang möchte ich nicht mehr missen.

Zur Komprimierung von Bildern, die nicht innerhalb eines CodeKit-Projektes liegen, verwende ich ImageOptim, und freue mich über diese einfache Möglichkeit grafisch zuverlässige Bildkompression auf dem Rechner zu haben.

Veröffentlichung

Zur Versionierung der Projekte an denen ich arbeite verwendete ich bis vor Kurzem ausschließlich Tower. Seitdem ich das Buch ›Git for Humans‹ von David Demaree gelesen habe, verstehe ich Git besser, und ziehe in den meisten Fällen das Terminal vor. Ich habe sowohl bei GitHub als auch bei BitBucket diverse Verzeichnisse.

Meine eigenen Seiten liegen seit einiger Zeit bei Uberspace. Mit den Servern dort kommuniziere ich entweder mit dem Terminal per SSH oder via SFTP mit Transmit.

Zur Verwaltung von MySQL-Datenbanken verwende ich Sequel Pro. Gerade für den Import und Export von größeren Datenbanken ist diese App unverzichtbar.

Zeiterfassung

Meine Arbeitszeit erfasse ich mit Timings. Rechnungen und Angebote erstelle ich auf der Basis der erfassten Zeiten mit Numbers.