Ich stand vor der Entscheidung wie ich die Homepage für mein neues Spieleserverprojekt gestalten sollte. Ich schwankte anfangs zwischen einem dynamischen Portal für freie Spiele und selbst geschriebenen statischen HTML-Seiten. Ich habe mich schließlich gegen PHP und Datenbanken entschieden und auf statische Inhalte gesetzt, die zum einen durch Chronicle, einen Blogkompilierer, und zum anderen durch manuell erstelltes XHTML erzeugt werden. Die restlichen Statistiken und Graphen für die einzelnen Spiele werden täglich durch das Auswerten von Logdateien und mit Hilfe von Munin dargestellt.
Die Frage bei so einem Projekt ist: Wie viel Interaktion möchte man eigentlich haben?
Linuxiuvat.de ist keine Clan- oder Gildenseite, sondern lediglich das Erscheinungsbild des virtuellen Servers, auf dem einige freie Spiele laufen. Ich übernehme hier die klassischen Aufgaben als Serveradmin und Macher der Homepage, kann aber natürlich nicht alle Mitglieder eines Clans ersetzen.
Meiner Meinung nach sind Foren oder sogar ein Wiki nur dann sinnvoll, wenn man gleichzeitig eine Community rund um die Spiele aufbauen will, die das Projekt mit Leben füllt. In meinem Fall gibt es nur mich und die Idee irgendwann das Ganze abzuschließen und zum Fazit zu kommen, dass die Möglichkeiten des vServers ausgeschöpft sind. Danach möchte ich nur noch das Bestehende weiterpflegen, selbst eine Runde spielen und zum nächsten Projekt weiterziehen.
Vor diesem Hintergrund und der Tatsache, dass der Spieleserver auch ein praktisches Beispiel ist (es macht vor allem Spaß), wie man mit Freier Software, wenig Ressourcen und auch kostengünstig ein Projekt gestalten kann, wollte ich die Interaktion auf das Notwendige und Sinnvolle beschränken.
Hilfreiche Software
Es gibt sehr viele Möglichkeiten die eigene Homepage zu gestalten. Einige Ideen finden sich z.B. bei Debian und Ubuntu mit
aptitude search '~sweb'
In der Sektion "Web" stecken zahlreiche Content-Management-Systeme, Blogsoftware und Hilfsmittel statische Inhalte zu erschaffen. Eigenes Vorwissen, die verwendete Programmiersprache, Performance und verfügbare Angebote des Webhosters spielen natürlich eine Rolle. Bei einem eigenen VPS kann man aus dem Vollen schöpfen, da es keine technischen Beschränkungen gibt.
Bekannte Content-Management-Systeme
Es gibt hervorragende freie CMS darunter die großen Joomla, Drupal, Typo3, Movable Type und WordPress. Allen ist gemein, dass sie hochentwickelt, stark erweiterbar und vielfältig einsetzbar sind. Vom kleinen Linuxblog bis zur Unternehmenskette mit eigenem Franchise ist alles denkbar. Inhalte und Seitengestaltung sind unabhängig voneinander. Wissen über HTML oder Skriptsprachen ist nützlich jedoch nicht zwingend notwendig. Jeder kann Dank des umfangreichen Backends Inhalte einstellen und verwalten.
- Anforderungen: PHP, MySQL/PostgreSQL
- Vorteile: Dynamische Inhalte, Interaktion mit Benutzern ist einfach, unzählige vorgefertigte Plugins und Themen, große Gemeinschaft, gute Dokumentation, sehr flexibel
- Nachteile: Speicherintensiv, Datenbank und PHP wird benötigt, potentielle Sicherheitslücken, komplexe Bedienung, Einarbeitungszeit notwendig
Eher unbekannte Content-Management-Systeme
Dann gibt es die eher unbekannten CMS, die meist weniger Feature als die großen haben, aber nicht weniger geeignet sind, um kleinere dynamische Projekte zu verwirklichen. Mir fielen insbesondere Zine, PyLucid und TDiary auf, da ich ein wenig mit Zine wegen der Programmierung in Python geliebäugelt habe. PyLucid ist ebenfalls in Python geschrieben und benutzt Django, während TDiary in Ruby verfasst wurde. Hier sind Japanisch- und Englischkenntnisse von Vorteil. Eine weitere interessante Alternative ist WebGUI in Kombination mit Perl und MySQL und DotClear. Leider forderten alle mindestens noch die Installation einer zusätzlichen Datenbank.
- Anforderungen: Python, Ruby, Perl, MySQL/PostgreSQL
- Vorteile: Dynamische Inhalte, einfache Interaktion mit Benutzern, einige zusätzliche Plugins und Themen, flexibel, interessante Programmiersprachen
- Nachteile: Relativ speicherintensiv, Datenbank, Python oder Ruby notwendig, potentielle Sicherheitslücken, weniger umfangreich als die großen CMS
Die Welt der statischen Webseitengeneratoren
Ein Trend unter Techies sind sicherlich Webseitengeneratoren wie Jekyll für Ruby und Hyde für Python, die mit Hilfe von Templates aus Text, Markdown oder HTML die komplette Seitenstruktur einer Webseite unabhängig vom Inhalt erstellen können.
Etwas einfacher aufgebaut, aber nicht weniger effektiv, sind z.B PubTal (Python), WebGen (Ruby) und Blazeblogger.
Mein Favorit, für den ich mich schließlich entschieden habe, war Chronicle, den ich im nächsten Beitrag etwas ausführlicher vorstelle.
Was ist so toll an statischen Blogkompilierern und Webseitengeneratoren?
Ich habe mich für diesen Typ entschieden, weil ich sie für sicher, leichtgewichtig und effizient halte. Natürlich kann man auch Plugins für ein CMS benutzen, die den dynamischen Inhalt in statischen überführen (Stichwort: WP-Super-Cache). Ein Blogkompilierer wie Chronicle macht das von Haus aus. Statische Inhalte werden extrem effizient durch den Webserver ausgeliefert, so dass selbst bei einem mickrigen vServer die Performance selbst unter mittelgroßer Last nicht leiden wird.
Ein normales Projekt benötigt nicht einmal ansatzweise alle Funktionen eines CMS. Hier geht es auch darum realistisch zu bleiben. Weniger ist oft mehr. Außerdem sind diese Generatoren einfach zu bedienen und benötigen weder Datenbank noch eine Skriptsprache um zu funktionieren, was im Regelfall gleichbedeutend ist mit mehr Leistung und geringeren Kosten.
Einen Haken hat die Sache. Interaktion ist ohne zusätzliche Software nicht möglich, woraus ein neues Problem erwächst.
Disqus und Co. sind böse
Wirklich, ist das so? Fakt ist, wenn man auf ausschließlich statische Inhalte setzt, muss man dennoch irgendeine serverseitige Anwendung/Skript installieren, damit Kommentare von Besuchern irgendwie in die Webseite eingebunden werden können. Viele verfallen dann auf externe Dienstleister wie Disqus oder IntenseDebate.
Als Webseitenbetreiber muss man lediglich ein Stück Javascript-Code einbinden und schon werden Kommentare an die Server von Disqus und Co. weitergeleitet und dann auf der eigenen Webseite dargestellt. Disqus macht es wirklich einfach. Keine Spam-Probleme, keine Last auf dem Server, perfekte Integration mit Sozialen Netzwerken. Als Alternative könnten Besucher z.B. eine E-Mail schicken und man bindet dann den Inhalt manuell in die Seite ein, aber hey, wer macht das schon. 😉
Ich bin nicht wirklich der Typ, der hinter jedem erfolgreichen Internetunternehmen den nächsten faschistischen Weltbeherrscher vermutet. Man sollte sich aber schon die Frage stellen, ob man für jede Webseite die Kontrolle über seine Daten an eine externe Stelle abgegeben muss oder nicht. Diese Bedenken hat Jeremy Scheff auf den Punkt gebracht.
Ich persönlich denke, dass man Interaktion und Kontrolle über die Daten auch anders haben kann und das auch nutzen sollte. Im Falle von Chronicle war das z.B. das einfache Einbinden einer einzigen CGI-Datei. Andererseits vielleicht sollten wir einfach an einem wirklich quelloffenen und freien Disqus arbeiten!
Fazit
Die Wahl der Software hängt entscheidend von den eigenen Ansprüchen ab. Wem Geschwindigkeit und Sicherheit wichtig ist, sollte statische Inhalte veröffentlichen, die bevorzugt mit einem Blogkompilierer oder Webseitengenerator erzeugt werden oder auf die händische Methode zurückgreifen. Für mein kleines Projekt werde ich diesen Weg auf jeden Fall weitergehen.
cooler Artikel, Daumen hoch!
Nicht zu vergessen ist acrylamid, ein relativ junger, aber äußerst einfacher und effektiver Blog- und Homepagecompiler. Ich bin selbst sehr zufrieden damit, und etwas an der Entwicklung beteiligt.
Bzgl. Disqus bin ich vollkommen deiner Meinung. Ich wäre auch für Mail, am besten noch in Verbindung noch mit GPG, sodass jeder Beitrag korrekt signiert sein mus 🙂 Möglich wäre es durchaus, wenn man Zugriff auf einen Mailserver hat, dessen Mails man automatisch weiterverarbeiten kann, oder die Mail lokal abruft und regelmäßig pusht.
Oh nein, nicht doch XHTML! HTML5 steht in den Startlöchern und ist in eigentlich allen Browsern verfügbar. Nimm das bitte.
Achso, die Farbe der Links auf der Seite ist schrecklich. Ich kann gar nix lesen. Und allgemein wäre ein bisschen mehr Kontrast schön.
Es gibt auch XHTML 5: https://en.wikipedia.org/wiki/HTML5#XHTML5
Der Unterschied besteht praktisch darin, dass es in HTML 5 ein paar „unsaubere“ Konstrukte gibt, die in XHTML 5 nicht erlaubt sind. Wenn man die nicht braucht, besser die striktere Variante XHTML verwenden.
Eine Gegenüberstellung von verschiedenen Markup-Standards wäre sicherlich einen Extraartikel wert, obwohl ich denke, dass sich damit schon einige Leute mit beschäftigt haben. Für mein Projekt genügt mir zur Zeit XHTML Strict 1.0, sollte es damit jemals Probleme geben denke ich über HTML5 nach.
Das ist die Originalfarbe von Debian. Die ist sogar offiziell dokumentiert und so festgelegt. Mir gefällt sie auf dunklem Hintergrund. Ja, das mit dem geringen Kontrast ist so gewollt. Welche Farben/Werte schlägst du vor?
Pyblosxom ist in der Hinsicht auch erwähnenswert.
Was ich nicht so ganz verstehe? In welcher Welt spielt die Geschwindigkeit auf der Server-Seite wirklich eine Rolle. Ist völlig egal, wie schnell das ist, es sei denn du hast 100.000nde Seitenaufrufe täglich. Der Löwenanteil findet auf dem Client statt.
Anmerkung zu Disqus, man kann die Daten leicht syncronisieren.
Ich habe es in diesem Artikel nicht noch einmal extra erwähnt, aber ich besitze einen XEN-virtualisierten vServer mit 256 MB RAM. Hier spielt jeder CPU-Zyklus und jedes bisschen RAM eine Rolle, vor allem da ich die Leistung für die Spieleserver und nicht für den Webserver verwenden möchte.
Bei Anwendungen, die auf PHP+MySQL basieren findet alles serverseitig statt, wohingegen bei statischen Seiten keine Skripte bei einer Anfrage ausgewertet müssen und der Webserver sofort die Daten ausliefert. Vor diesem Hintergrund denke ich schon, dass gerade für kleinere Projekte aber auch allgemein statische Seiten einen immensen Geschwindigkeitsvorteil haben.
Kann man in Chronicle denn den Code vor der Erstellung per Hand manipulieren? Bei Thingamablog z.B. kann man einfach die DTD verändern und hat praktisch HTML5. 😀 Soweit ich weiß ist HTML5 ja weitestgehend abwärtskompatibel! Ich wusste gar nicht das es diese Dinger noch gibt….egal, früher habe ich mal NOF Essentials eingesetzt und ich fand Thingamablog sehr geil, als ehr nich weiterentwickelt wurde. Vielleicht probiere ich mal wieder einen Blogkompilierer aus, mobiles Bloggen mache ich eh nicht und fette Systeme wie WP oder S9Y machen auf Freehostern einfach keinen Spaß (da darf man auch nichts erwarten, wenn man schon 4free haben will^^).
Übrigens kann ich Disqus & Intensedebate aus den gleichen Gründen gar nicht ab. Disqus nötigt zusätzlich jeden Blogger mit irgendetwas, ob OpenID oder Facebook seine Identität zu bestätigen. Kann ich gar nicht ab, ich will auch mal etwas posten dürfen ohne meine OpenID oder mein FB-Profil der Öffentlichkeit zu präsentieren.
@Marco: WP kann auch mal 64-128 MB RAM fressen wenn man einige Plugins drauf hat. Auf unserem uralten Schulserver macht das Probleme und auch einige Freehoster quittieren solche dicken CMS mit ewig langen Ladezeiten (bei denen sollte man ja eh auf schlanke Scripts achten, allein aus Rücksicht auf andere User). Da macht das sehr viel Sinn. Und es gibt ja auch Länder wo die Internetverbindungen noch viel schilmmer sind als in D. Zu guter Letzt ist sowas auch ideal für TOR, Freenet und I2P. Nicht umsonst gibt es für Freenet und I2P extra modifizierte Blogkompilierer (auf Thingamablog-Basis glaube ich…).
@sebix: Benötigt acrylamid Python auf dem Webspace? Das Tool vergleicht sich ja mit Pyblosxom, und dieses braucht ja immerhin ein Python-Script auf dem Webspace, nix mit rein statisch. 😀 Kann Python überhaupt statisch sein? Es ist ja eine Script-Sprache wie PHP, oder? 😕
Ach ja: Thingamacomment sollte nach ein paar Anpassungen auch mit anderen Blog-Kompilierern funktionieren. Damit kann man ein statisches System und Kommentare erweitern, es benötigt aber PHP. 😉
@Georg: Nein, natürlich nicht! Die Website wird vollständig lokal (mit einem python-Programm) generiert und dann hochgeladen. Das wars. (Eignet sich deshalb auch für Github-Pages)
Die Templates sind vollständig anpassbar und mit eigenen Filtern lässt sich eigene Magie hinzufügen, was sehr hilfreich ist.
Von den 2 bisher existenten Blogs lassen sich jeweils auch die Sourcen ansehen (auch die, die zum generieren nötig sind, beötigen allerdings die aktuellste git-version)
Mein Blog, die Quelldateien, und die zum Generieren (Hieran sieht man die Eleganz des Systems).
Die Sources von posativs Blog sind auch auf github.
@ Georg
Du kannst die Themen bei Chronicle natürlich vor dem Erstellen des Blogs abändern. Es sind nicht wirklich viele Dateien, in die man reinschauen muss. Mit etwas HTML und CSS lässt sich da sicherlich optisch noch einiges rausholen, wenn man die Standardthemen nicht mag.
@sebix, apo: Danke für eure Infos! Nach Thingamablog habe ich diese Tools etwas aus den Augen verloren, ich wusste gar nicht, das es auch noch weitere gibt. Jetzt werde ich mir mal Chronicle, acrylamid & Blazeblogger anschauen und mal gucken, wo ich am einfachsten und saubersten eine Kommentarfunktion implementieren kann. Das wird dann mein nächstes Blog-Sys. 😀
Dein Design ist übrigens sehr schick, sebix. 🙂 Gibt es dieses public bzw. darf ich es einfach von Github ziehen und mit Vermerk auf deinen Blog benutzen?
Falls euch das Thema interessiert, könnt ihr euch auch mal pplog oder pritlog-light anschauen. Die beiden Tools basieren jeweils nur auf einem Script (Perl bzw. PHP) und lagern die Beiträge in Textdateien ab. Ist zwar nicht richtig statisch, dafür kann man damit aber auch online Texte schreiben. ,-)
@Georg: Vielen dank! Skaliert auch wunderbar auf kleinen Auflösungen, sollte ich mal was drüber schreiben. Falls du es gleich testen willst: http://www.benjaminkeen.com/misc/bricss/
Natürlich darfst du dir das Design abschauen, ich hab aber auch nichts dagegen, wenn du es personalisierst 😉 Meins baute auf posativs auf, merkt mal im direkten Vergleich auch noch etwas (Außer dass seins nicht skaliert *g).
Danke. Leider kann ich kein CSS, aber ich kann das ja als Anlass nehmen ums es zu lernen und dann eine Sidebar an dein Theme dranzubauen *g
An die Skalierbarkeit von einem Theme habe ich noch nie gedacht, ist ja super wenn man auf dem Smartphone einfach das gleiche Theme in klein darstellen kann wie auf dem PC. Da mussich mir auch mal Gedanken drüber machen wenn es mal wieder an eine Webseite geht. 😀
Pyblosxom ist zwar primär als dynamisches Blog gedacht, aber unterstützt auch das Kompilieren in eine komplett statische Website, und Acrylamid wurde stark durch dieses Projekt inspiriert.
Im Gegensatz zu Pybosxom hat Acrylamid ein paar mehr Features, was besonders das statische Blogging angeht (man kann es sich leisten, kostspielige Typography-Feinheiten oder Silbentrennung, Syntax-Highlighting statisch zu rendern). Das Interface ist auch freundlicher 😉
Ein ziemlich junges Projekt als statischer websitekompilierer:
Jas CMS
Danke, da bin ich mal gespannt. 🙂