Kategorien
Design HTML/CSS

CSS- und HTML-Vokabular: Wörterbücher für Anfänger und Vergessliche

Selbst als erfahrener Entwickler hat man nicht, wo man geht und steht, CSS-Vokabular vor Augen. Oder murmelst du etwa kontinuierlich CSS-Syntax vor dich hin? Sollte dem so sein, wundere dich nicht, wenn die Menschen beginnen, dich zu meiden. Hast du in letzter Zeit derlei Anzeichen bemerkt, weißt du ja jetzt, woran es liegen könnte. Schon gut, danke mir nicht.

Möglicherweise hilft dir das Projekt, das ich dir heute vorstellen möchte, den Anschein beginnenden Wahnsinns zu widerlegen. Also, anstelle CSS murmelnd durch die Straßen zu ziehen, bookmarke einfach das kleine Projekt „CSS Vokabular“ und mach den Kopf frei…

CSS Vocabulary: Not More To It
CSS Vokabular: Viel mehr gibt es nicht zu sehen

CSS Vokabular: Wissen, was was ist

Das kleine Helferlein namens CSS Vocabulary, das mit der Hilfe einiger engagierter Zeitgenossen inzwischen nicht nur in englischer, sondern auch in deutscher Sprache, sowie einigen weiteren, verfügbar ist, ist im Grunde komplett selbsterklärend. Es besteht aus nicht mehr als einem einzelnen Quelltext-Beispiel und und einer Sidebar mit Begriffen. Wählst du einen beliebigen Teil des Quelltextes per Klick aus, wird der dazu passende Begriff in der Sidebar farblich hervorgehoben.

Umgekehrt funktioniert es genau so. Klickst du auf einen Begriff in der Sidebar, werden die dazu passenden Code-Teile im Quelltext-Beispiel farblich hervor gehoben. Mehr gibt es nicht zu sehen.

CSS Vocabulary: Code Example
CSS Vocabulary: das Quelltext-Beispiel

Klar, CSS Vocabulary bringt dir nicht wirklich CSS bei. Aber, wenn es dir wenigstens manchmal so geht wie mir, dann wirst du an dir selbst bemerkt haben, dass die genauen Begrifflichkeiten im Kopf nicht immer sicher abrufbar sind. Das ist besonders dann ungünstig, wenn du gerade einen Text über CSS schreibst. Du weißt genau, was du schreiben wolltest, aber wie hieß jetzt dieser verflixte Begriff noch gleich genau? Mir passiert das auch gerne, wenn ich einen Style Guide dokumentiere. Da freue ich mich über eine schnelle unkomplizierte Nachschlagemöglichkeit wie CSS Vocabulary.

CSS Vocabulary: Sidebar
CSS Vocabulary: Sidebar

CSS Vocabulary ist ein Projekt der Finnen Ville Vanninen, Pasi Jokinen und Timo Moilanen, das inzwischen in einem größeren Projekt namens Vocabs aufgegangen ist. Neben CSS findest du auf Vocabs einen in gleicher Weise aufbereiteten Wortschatz für HTML, eben das HTML Vocabulary.

Vocabs kann völlig frei unter einer MIT-Lizenz genutzt werden und ist zuhause bei Workflower.fi. 

(Der Beitrag erschien zuerst im Sommer 2014 und wird seitdem aktuell gehalten. Das letzte Update erfolgte im April 2019.)

Beitragsbild: MikesPhotos auf Pixabay

Kategorien
(Kostenlose) Services Essentials

RhodeCode: Selbstgehostetes Admin-Tool für die Github-Alternative Mercurial

Vor einigen Wochen haben wir bereits GitLab vorgestellt als Alternative zu GitHub als Self-Hosting-Lösung. Für die Versionsverwaltung Mercurial(hg) heißt das entsprechende Pendant RhodeCode. Doch kann RhodeCode wirklich mit der git-Lösung mithalten?

rhodecode-summary-1024x486-w640

Mercurial und Git – Ähnliche Ansätze, ähnliche Zielgruppe, Unterschiede im Detail

Mercurial und Git sind zwei Versionsverwaltungen mit ähnlichen Ansätzen, diese Ähnlichkeiten sind auch bei RhodeCode und GitLab sichtbar. Die Features unterscheiden sich nur gering. In RhodeCode lassen sich Repositories anlegen, es gibt Statistiken zu Repos, ein Changelog, Verwaltung der Branches und eine File-Ansicht. Bei einigen Dingen fehlen allerdings noch kleinere Features, dies lässt sich jedoch verschmerzen. Erkennbar ist allerdings, dass man sich doch stark an GitHub ausgerichtet hat. Das wird deutlich an Features wie dem Folgen von Usern oder der Möglichkeit Repositories zu forken (klonen). Der Gemeinschaftsansatz ist hier ausgeprägter als zum Beispiel bei GitLab. Hier soll das Forken aber auch bald möglich sein. Das liegt sicherlich in der Natur von Mercurial, bei welcher das Klonen eine zentrale Rolle spielt.

Interessant ist die Volltextsuche. Alle Repositories zum Beispiel nach Schlüsseln oder anderen wiederkehrenden Informationen durchsuchen zu können, kann für einige Unternehmen interessant sein. Auch die Nutzerverwaltung mit der Zuweisung von Rechten ist wichtig, gerade um Hierarchien in Entwicklungsteams abbilden zu können. Ebenfalls möglich ist der direkte Upload von neuen Dateien in Repositories. Diese lassen sich wiederum direkt in RhodeCode bearbeiten und committen.

Die Installation und Integration ist für Teams, die Python als Entwicklungssprache bevorzugen, denkbar einfach. Mit Hilfe von pip oder easy_install besorgt sich RhodeCode alleine die nötigen Abhängigkeiten. Updates können dann ebenfalls relativ einfach eingespeist werden. Am Besten nutzt man hierfür virtualenv, wie auch in der Dokumentation vorgeschlagen.

Features und Wartbarkeit sind nicht die Probleme, die man bei RhodeCode vorfindet. Das größere Problem liegt in der Übersichtlichkeit des User-Interfaces. Diese ist nämlich kaum vorhanden. Insgesamt wirkt alles sehr überladen und groß. Einen responsiven Ansatz hat man nicht gewählt. Schade, denn gerade im mobilen Bereich wäre ein schönes Frontend der eigenen Projekte doch sehr hilfreich, zum Beispiel wenn man sich von unterwegs den aktuellen Entwicklungsstand ansehen will.

Die Anzahl und der Gedanke der Features sind wirklich großartig. Auch die Performance kann sich durchaus sehen lassen. Wenn das Team jetzt noch an der Oberfläche bastelt, hat RhodeCode auf jeden Fall großes Potential. Nicht verschweigen will ich dabei, dass man die Oberfläche auch selber anpassen kann. Dies liegt durchaus im Bereich des Machbaren und wird zunehmend öfter durchgeführt, gerade in Bezug auf die Integration der Software in die eigene Umgebung.

Wer Mercurial ohnehin bereits zur Versionsverwaltung nutzt, kann problemlos RhodeCode verwenden. Wer bei Github zufrieden ist, erhält auch mit RhodeCode kein zwingendes Wechselargument.

Links zum Beitrag:

  • Feature-List RhodeCode – packages.python.org
  • RhodeCode Projektseite – rhodecode.org
  • RhodeCode Demo – rhodecode.org

(dpe)

Kategorien
(Kostenlose) Services Essentials

GitLab 4.0: Github-Alternative zum Selberhosten

GitLab ist mittlerweile in der Version 4.0 erschienen. Dabei handelt es sich um eine „Git-Management-Software“ für das lokale Netzwerk, die zunächst wie ein GitHub-Klon wirkt, aber mit jeder Version stetig mehr Features bekommt. So wird GitLab mehr und mehr zu einer validen Alternative für GitHub-User, denen es lieber wäre, wenn die Projekte nicht im Weltennetz gepflegt werden müssten. Wer will seine Investition schon einem öffentlichen Service anvertrauen, wenn er es vermeiden kann?

Mit Hilfe von GitLab können Git-Repositories erstellt und verwaltet werden. Ähnlich wie bei GitHub kann dabei der veränderte Code angezeigt und teilweise bearbeitet werden. Eine Syntax-Hervorhebung, Unterschiede zwischen den einzelnen Commits und Darstellungen von Verzweigungen der Branches sind nur einige Features, welche die eigentliche Arbeit mit Git enorm erleichtern.

Gitlab Projektübersicht
Gitlab Projektübersicht

Rege Entwicklungstätigkeit: Neue Features mit jeder GitLab-Version

In der neuesten Version werden nun auch Nutzer-Gruppen unterstützt. Gruppen können Repositories anlegen und so den Mitgliedern der Gruppe automatisch Rechte für die neuen Repositories verleihen; eine Arbeitserleichterung, speziell bei größeren Gruppen. Darüber hinaus bietet GitLab ein kleines Ticket-System (Issues), sowie ein einfaches, aber funktionales Wiki und eine übersichtliche Administration. Über die Oberfläche können außerdem die SSH-Keys der Nutzer eingebunden werden. Auch die Abbildung einer Nutzer-Hierarchie in Git ist möglich. Merge-Requests können zum Beispiel direkt in GitLab bearbeitet werden.

GitLab ist ein sehr schönes Frontend für Git-Nutzer, die schnell eine Übersicht über den Status eines Projektes bekommen wollen. Das Design erinnert stark an die üblichen Bootstrap-Seiten, was jedoch den Vorteil birgt, dass man sich sehr schnell zurecht findet. Das Featureset erschlägt einen nicht unbedingt, bietet aber alles, was man landläufig so benötigt. Für die Arbeit in Projekten und in der agilen Softwareentwicklung ist dies vollkommen ausreichend. Für Dokumentationen kann zum Beispiel das integrierte Wiki genutzt werden.

Gretchen-Frage: GitHub oder GitLab?

Grundsätzlich stellt sich die Frage, ob es Sinn ergibt, den Aufwand für Hosting und Administration der Software zu übernehmen. Daten müssen gespiegelt und zusätzlich Backups erstellt werden. Ist es also nicht besser auf das zuverlässige GitHub zu setzen? Im Endeffekt kommt es auf die eigenen Bedürfnisse an. Wie streng intern müssen meine Daten und meine entwickelte Software behandelt werden? Will ich wirklich, dass meine Investition auf fremden Servern liegt?

Wenn für die Einbindung von GitLab und Git erst noch Expertise eingekauft werden muss, das Team nicht zu groß wird und man extra jemanden mit der Administration beauftragen muss, sollte man wohl eher GitHub nutzen. Einen nennenswerten Kostenvorteil darf man bei keinem der Systeme erwarten.

Gerade für größere Unternehmen kann es sinnvoll sein, auf GitLab zu setzen. Erfahrenen Unix-Administratoren geht die Einbindung und Installation schnell von der Hand, da GitLab auf Rails und Gitolite basiert. Sicherheitskritische Probleme sind bisher eher selten aufgetreten, dürften aber auch kaum eine Rolle spielen, da GitLab in der Regel nur im internen Netz erreichbar sein wird. Der Administrationsaufwand ist eher als gering einzustufen. Updates kommen zwar öfter, sind aber relativ einfach zu applizieren.

Mit jeder Version erschienen bis dato immer wieder neue hilfreiche Features. Auf Anregungen der Community wird ebenfalls schnell reagiert. Da GitLab intuitiv nutzbar ist und leicht, aber zuverlässig administriert werden kann, spricht kaum etwas dagegen, die Github-Alternative zumindest einmal auszuprobieren.

GitLab ist Open-Source, steht unter der liberalen MIT-Lizenz und stellt eine sinnvolle Erweiterung für die eigene Software-Umgebung dar. Wer sich erstmal ein Bild von GitLab machen will, kann sich einen kostenlosen Account auf GitLab.com, der Hostingplattform zu GitLab.org, anlegen. GitLab.com wurde dezidiert zu dem Zweck ins Leben gerufen, den Einstieg in die Nutzung von GitLab zu erleichtern.

Links zum Beitrag:

  • Self hosted Git management software – GitLab.org
  • Eine Fremdhostinglösung steht ebenfalls bereit – GitLab.com

(dpe)

Kategorien
Plugins WordPress

Kollaboratives Schreiben für Teams mit dem brandneuen WordPress-Plugin Post Forking

Ein brandneues Plugin für WordPress bohrt das beliebte CMS zu einer Art GitHub auf. Es erlaubt nämlich das gleichzeitige Arbeiten mehrerer Autoren an einem Beitrag. Auch Personen ohne weitergehende Rechte können über Post Forking in den Workflow einbezogen werden. Das könnte eine Lösung für mehrere recht verbreitete Probleme derer sein, die in einem Redaktions-Workflow tätig sind.

Wired und das GitHub-Experiment

Es begann mit einer Idee der Wired-Redaktion. Dort schreiben mehrere Personen an ein und demselben Beitrag. Zum Alltag gehört, sich gegenseitig zuzurufen: „Geh du mal bitte aus dem Beitrag raus. Ich muss noch was ändern!“ Jeder, der WordPress im Team verwendet, kennt das. Bei Wired entschloss man sich zu einem interessanten Versuch. Man stellte einen Beitrag auf GitHub zum kollaborativen Bearbeiten ein. Der Versuch sollte zeigen, ob GitHubs Konzept des Forking und Merging geeignet ist, den starren WordPress-Editor abzulösen.

Man fand heraus, dass dem nicht so ist, was aber im Wesentlichen daran lag, dass GitHub schlicht ein Versionskontrollsystem für Software- und sonstige Entwicklungsprojekte ist und insofern eine gehörige Portion an Wissen aus diesen Bereichen voraussetzt. Wissen, das Redakteure in der Regel nicht haben und das sie neben der GitHub-Nutzung auch nicht präsent zu haben bräuchten. GitHub für Redakteure wäre also im Grunde interessant gewesen, aber nicht in der Inkarnation des real existierenden GitHub.

Octocat, GitHubs Maskottchen (Bildquelle: GitHub)

Post Forking: Benjamin Balter entwickelt den Wired-Ansatz fort

Der Open Source Entwickler Benjamin Balter griff Wireds Experiment auf und warf weitere Anwendungsfälle in den Raum. Er fand insgesamt drei:

  • das kollaborative Editieren mehrerer Autoren am selben Beitrag (also Wireds Fall)
  • das Speichern von Änderungen an bereits publizierten Beiträgen durch den Autor (der in der Regel keine Schreibrechte mehr hat, wenn ein Beitrag endgültig veröffentlicht ist) und die Bearbeitung dieser Änderungen durch berechtigte Personen
  • die Schaffung von Bearbeitungsmöglichkeiten für Personen, die ansonsten keinerlei Rechte im CMS haben, etwa normale Leserinnen und Leser (ähnlich zum Pull Request System auf GitHub). Das könnte immer dann interessant sein, wenn man über jemanden schreibt und ihm im Vorfeld sehr einfach die Möglichkeit geben will, sich zu den Inhalten zu äußern. So eine Vorgehensweise ist etwa bei Interviews oder bezahlten Beiträgen üblich.

WordPress Plugin Post Forking: So arbeitet es

Balter übertrug die GitHub-Vorgehensweise auf WordPress und schuf mit Post Forking ein Plugin für den redaktionellen Workflow. Will demnach ein Autor ohne das Recht edit_post einen Beitrag editieren, so erstellt das Plugin einen Fork, also eine weitere Version dieses Beitrags. Diese Version kann der Autor frei editieren und am Ende wie gewohnt speichern und zur Überprüfung vorzulegen. Auf diese Weise gelangt der Beitrag erneut in die Moderation und liegt unter „Pending Review“ im Backend für die Überprüfung bereit. Hierhin gelangen stets diejenigen Beiträge, die von Autoren ohne das Recht publish_post erstellt werden. Man erkennt bereits, dass Balter sich hier eng an den etablierten Standards orientiert, so dass die Verwendung der neuen Funktionalität im Grunde keinen Einarbeitungsaufwand auf der Seite der Autoren nach sich zieht.

Auch der übergeordnete Redakteur findet sich sofort zurecht, denn die nachträglichen Änderungen führen lediglich dazu, dass er den Beitrag erneut vorgelegt bekommt. Er hat nun zu entscheiden, ob er die Änderungen zulassen will. Ist dem so, führt er die neue Version mit der alten Version endgültig zusammen (Merging), wobei ihm vom System etwa bestehende Konflikte und Lösungsmöglichkeiten unterbreitet werden. Erreicht wird diese intelligente Vorgehensweise unter Verwendung der relativ neuen Custom Post Types in Verbindung mit der Revisionshistorie.

Post Forking Version 0.1: Early Adopters vor

Bei der Realisierung des WordPress-Plugins erhielt Balter tatkräftige Unterstützung von den beiden bekannten Plugin-Entwicklern Aaron Jorbin und Daniel Bachhuber. Der letztgenannte Entwickler arbeitet im Hauptberuf für Automattic. Es könnte also gut sein, dass die Funktionalität des Post Forking in der Zukunft eine Chance auf Core-Integration hat. Das Plugin liegt in Version 0.1 vor, was zwar experimentell wirkt, aber eher eine Form von Understatement ist, bedenkt man die bereits recht fortgeschrittene Funktionalität, die Post Forking bereits jetzt bietet.

Seit dem 30.09.2012, also seit einer knappen Woche kann Post Forking im Repository herunter geladen werden, was bislang erst 128 Personen taten. Werden Sie der Nächste sein? Ich rate dazu!

Links zum Beitrag: