Vor einigen Wochen musste ich nach einer Lösung für das Problem eines Kunden suchen: Das Setup ist nicht mit der Website gewachsen, was am Ende zu Rankingverlusten führte. Sehr ärgerlich. Aber woran lag es? In erster Linie lag das Problem an der Performance des gewählten Webhostings. Dabei ist es egal welchen Webhoster ich meine. An einem Umzug gab es kein Vorbei. Was aber mit dem Mailhosting machen? Ich selber habe mich bisher immer seht stiefmütterlich mit Mailhosting beschäftigt. Nun war ich gezwungen mir einige Gedanken zu machen.
Nicht erst seit der Github-Übernahme durch Microsoft nutze ich einen privaten Server, um private Repositories und einige Kundenprojekte zu hosten. Schon länger habe ich dafür eine Gitea-Instanz im Einsatz. Wer nämlich nicht zu den großen Anbietern GitHub, Bitbucket oder GitLab möchte, hat die Möglichkeit einen eigenen Server zu betreiben.
In diesem Blogbeitrag möchte ich eine kurze Einführung in die Thematik des Git-Hostings geben, bevor ich das Setup von Gitea in einem docker-Container beschreibe.
Überall Anbieter: Welche Software für privates Git-Hosting?
Sehr bekannt und beliebt ist, ohne jeden Zweifel, GitLab. Fast schon eine Art Pionier in diesem Bereich, war GitLab Vorbild für einige Features der Folgeprojekte. Neben GitLab gibt es aber heute auch noch GitBucket (Server), Gogs und Gitea.
Ich möchte heute auf den Artikel von Thomas Leister hinweisen: Mailserver mit Dovecot, Postfix, MySQL und Rspamd unter Debian 9 Stretch. Ein toller Einstieg in die aktuelle Konfiguration eines Mailservers. Da ich selber vor kurzem meinen Mailserver zu Rspamd migriert habe, hier Rspamd direkt in das Setup aufgenommen wurde, kann ich jedem die Anleitung bzw. Rspamd empfehlen.
Beim tollen Heinlein Support gibt es für Rspamd eine tolle Einführung. Noch immer gibt es keinen englischen oder deutschen Wikipedia-Artikel zum Thema (lediglich einen französischen). Umso attraktiver ist die Dokumentation von Rspamd.
Es wird sicher so einige Plattformbetreiber geben, die ein Problem mit gewissen Nutzern haben. Nutzer die andere Nutzer beschimpfen, den Ablauf stören oder möglichst viel Schaden verursachen möchten. In den meisten Fällen wird, wenn die Betreiber vom Verhalten erfahren, der Nutzer gesperrt. D.h. der Login ist nicht mehr möglich oder die Portalfunktionen stehen nicht mehr zur Verfügung. Die Absicht hinter einem solchen Vorgehen: Die so indentifizierten unliebsamen Nutzer sollen die Konsequenzen spüren und so auf den "richtigen Weg" gebracht werden. Aber was passiert dann? Die Nutzer erstellen sich einen neuen Account und die Probleme beginnen von vorne. Löschen der Zugänge oder deaktivieren gewisser Funktionen ist kein nachhaltiges Instrument die eigene Community zu schützen.
In diesem Post geht es um das Golden-Cage-Pattern, dass hilft die "bösen Nutzer" besser in den Griff zu bekommen.
Vor vielen Jahren war Wordpress toll. Es war eine schlanke, in PHP-geschriebene, Software, dessen Weiterentwicklung stark durch die Community geprägt wurde. Wordpress wurde zu einer Zeit auf den Markt gebracht, in welche die Entwicklung mit PHP nur selten gewissen Paradigmen folgte. Das Pattern der Wahl war damals "dirty". Zumindest aus heutiger Sicht.
Die Nutzer-orientierte Entwicklung führte dazu, dass Wordpress heute sehr viel kann. Vom schlanken (und fixen) Script ist nicht mehr viel erhalten geblieben. Auch wenn die Entwicklung sich langsam in eine bessere Richtung gewandt hat, ist für mich Wordpress heute (2018) noch immer nicht wieder das Script der Stunde, wenn es um die Realisierung von kleinen Seiten, Single-Pages oder Portfolio-Seiten geht.
(Copyright des Bildes siehe Credits)
Ein wesentlicher Standard aktueller PHP-Applikationen ist die Möglichkeit Routes zu definieren. Routes haben damit die Variante abgelöst, die zu Beginn der 2000er Jahre zum PHP-Standarf gehörten: Das anlegen einer Vielzahl von Dateien, auf die der Nutzer Zugriff hat. Ich möchte kurz auf die Möglichkeit der Definition von Routes in Symfony mit Hilfe der Annotation-Methode eingehen.