Server - Freude und Frust

Eine kleine Aufgabe, mit der ich mich zur Zeit beschäftige, ist der Upload ohne FTP bei einem Online-Projekt. Genauer gesagt: es geht um hochaufgelöste Bilder, die teilweise bis zu 100 MB pro Bild haben können. Eine Upload-Größe, die auf Shared-Hosting-Servern in der Konfiguration praktisch nicht angeboten wird. Zu FTP muss man sagen, dass es etliche User gibt, die davon noch nichts gehört haben oder diesen Begriff überhaupt kennen – die Alltagsrealität. Zweiter Lösungsansatz wäre einen “managed” oder “dedicated” Server anzumieten. Hier beginnt bereits die Kostenfrage, die Verlässlichkeit des Anbieters und zudem hat sich herausgestellt, dass dies dennoch noch lange nicht heißt, dass damit auch die Möglichkeit besteht, in der php.ini und Co. das Limit auf diese Höhe zu setzen.

Der weitere Gedanken-Ansatz war, einfach bei einem der Online-Anbieter, die das Übertragen von großen Datenmengen anbieten, einen “Pro”-Account zu kaufen… aber ganz ehrlich, bei einem Freizeit-Projekt monatlich 50-100 Euro zu zahlen, ist einfach zuviel des Guten. Zudem handelt es sich um einen Dritt-Anbieter, die oft schwer zu durchschauen sind, es geht auch ein wenig um Datensicherheit – und um Professionalität.

Nächster Ansatz – ein kleiner Home-Server, der nicht viel können muss, außer den strukturierten Upload von großen Bild-Daten. IP-Adresse & Übertragungsgeschwindigkeit ist hier kein Problem, die Datenmenge ebenfalls nicht und die 24 Stunden-Verfügbarkeit ebenfalls nicht wirklich. Denn praktischerweise werden hochgeladene Daten vom Server per Auto-Sync sogleich in regelmäßigen Intervallen auf andere Computer übertragen. Sollte der Server das Leben aushauchen, dann gehen maximal ein paar wenige Bilder verloren. So weit so gut – ein Server mit Apache, PHP und MySQL ist in 5 Minuten eingerichtet…. aber es trägt einen bitterer Beigeschmack in sich.

Es müssen wiedermal Ports geöffnet werden und wer sich damit schon mal beschäftigt hat, PHP und MySQL-Datenbanken bzw. einen Server abzusichern gegenüber Cracker-Kiddies sowie der dunklen Macht von Bot/Spam-Netzwerken, der weiß, dass es sich beim sauberen Arbeiten um keine 5 Minuten-Geschichte handelt. Wenn man dann Postings liest wie “Alles nach Plan gemacht, alle Sicherheitseinstellungen, die empfohlen wurden, dies und jenes, minimalste Eigen-Konfigurationen: dennoch – nach 4 Tagen war er gecrackt” dann beruhigt einem das nicht wirklich. Ein eigener Server ist etwas herrliches, man ist sein eigener Herr und Meister und in diesem Fall muss man sich auch nicht allzu groß Gedanken um Ausfallssicherheit und Datenspiegelung machen, kleine Ausfälle lassen sich leicht überbrücken, aber sich verwundbar ins weltweite Netz einzuhängen, ist nicht unbedingt optimal. Das gilt ebenso für einen angemieten “Root-Server” ohne tiefgreifende Kenntnisse. Somit stehen nicht ausreichende Kenntnisse in Bezug auf eine sehr verlässliche, hohe Absicherung des Servers oder die zu hohen Kosten bei einem Provider/Upload-Anbieter bisher im Weg.

Statisches Portfolio

Na bitte, auch das geschafft. Gerade mal ~1 Stunde hat es gestern gedauert, um aus dem alten Wordpress-basierendem Portfolio ein auf Webby basierendes zu “bauen”. Mh, das tut gut. Abgesehen davon, dass am Server gleich wieder sehr viel Datenmüll weg ist und somit wirklich nur noch das online ist, was es bedarf um die Seite im Browser mit Inhalt anzuzeigen, ist auch die Ladezeit der Seite gleich schneller geworden. Aber ich werde nochmal einige der jetzt noch skalierten Bilder verkleinern, dann sollte es noch ein klein weniger schneller laden. Außerdem konnte ich bei der Gelegenheit einige Fehler bei der Darstellung in unterschiedlichen Browsern beheben, einzig eine Hinweismeldung bei deaktiviertem Javascript fehlt noch.

Bei der FTP-Sicherung der alten Seite zeigte sich so nebenbei, dass Wordpress – mit allen Plugins und Themes sowie der Backend-Funktion – aus mehr als 1700~ Dateien bestand. Eigentlich verrückt und der falsche Weg für so eine Seite wie meine. Entspannt kann ich also nun auch wieder die Mails abrufen, ohne diverse Hinweise abzufangen, dass sich das eine oder andere Spam-Kommentar durch die Filter gemogelt hatte. So gehört sich das – neues Jahr 2010 und saubere Seiten ohne größe Updates oder diverse Sicherheitsbedürfnisse. Es wird ein ruhiges, entspanntes Jahr in meinem Online-Leben… gut so!

Ade Wordpress, willkommen Ruby!

Das neue Jahr ist erst wenige Stunden alt und eines der ersten Mails, die mich begrüßten, war prompt ein Spam-Eintrag in Form eines Kommentars bei meinem Portfolio. Nun gut, wozu den Umstand eines neuen Jahres feiern, wenn man nicht auch neue Schritte setzen möchte? Wozu brauche ich überhaupt dort Wordpress? Eine statische Seite, die online dynamisch betrieben wird, kann man nicht unbedingt als sehr sinnvoll bezeichnen. Damit – ade verhasstes und geliebtes Wordpress und willkommen Webby.

Ich hatte mich eigentlich lange davor gescheut wegen des befürchteten Aufwandes, aber die Realität ist nun doch anders – ich sitze gerade erst mal 10~15 Minuten hier und fülle das neue, statische Portfolio bereits wieder mit den alten Inhalten. Das Anpassen des Templates und der zugehörigen Files sowie der Aufbau der einzelnen Einträge waren völlig problemlos und ich fühle schon jetzt den frischen, klaren Wind von sauberen Code. Eingesetzt wird via ERB mein neuer Favorite HAML für den visuellen Aufbau und Textile für die Textgestaltung. Angenehm und nach einer kurzen Umstellung kann man sich gar nicht mehr vorstellen, anders zu arbeiten… es hat fast etwas Natürliches. Naja, der geneigte Leser darf sich natürlich fragen, ob ich ein klein wenig übergeschnappt bin, aber schieben wir das einfach mal auf den nicht vorhandene Rausch der letzten Silvesternacht. :)

Die “Live”-Autobuild-Funktion von Webby unterstützt beim Seitenbau und ermöglicht jederzeit die Preview im Browser, damit sieht man Fehler sofort und kann gleich nachbessern. Der Einsatz einer simplen Markup-Sprache und die Vorschau im Browser vermitteln einem witzigerweise das Gefühl eines WYSIWYG-Editors. Ich kann mir vorstellen, dass nun jemand die Frage stellen könnte, warum bei so einer Seite überhaupt mit einem Tool arbeiten, anstatt gleich mit einem Texteditor einfach die HTML-Seite zu erstellen. Naja… weil’s Spass macht, weil die Seite damit skalierbar bleibt, falls ich mal weitere Unterseiten möchte, und weil es dreimal einfacher ist

%h2 Das ist eine Überschrift
%p Das ist ein Text-Block

zu schreiben als mit der üblichen HTML-Syntax. Somit habe ich gewissermaßen eine dynamische Seiten-Erstellung, jedoch mit einem statischen Ergebnis. Noch einige Anpassungen und alte Inhalte übertragen und die Seite geht heute Abend wieder neu online… ohne Wordpress. Herrlich! :)

Statische Webseite mit Ruby

Nun gut, jetzt bin ich alle durch. Nanoc, Webgen, Rassmalog und Staticmatic. Alle haben aber irgendwelche Eigenheiten, die mich ein wenig stören, liegt aber vermutlich auch einfach nur daran, dass ich mir momentan nicht die Zeit gönne für allzu lange Experimente. Nachdem ich hier mit Jekyll die ideale statische Blog-Lösung gefunden habe, bin ich nun auf der Suche nach einer Variante für mein Portfolio. Dabei geht es jedoch nur um einige, wenige HTML-Seiten, die man vermutlich per Hand und Templates ohne Probleme wesentlich schneller hinbekommt, aber ein klein wenig Spass darf ja doch sein – vor allem will ich bei der Erstellung von Texten auf Textile zurückgreifen.

Hängen geblieben bin ich beim letzten Kandidaten meiner Selektion – bei Webby. Viele sind der Meinung, dass Staticmatic oder Nanoc besser sind, aber da traue ich mir kein Urteil zu. Bei der Konkurrenz muss man in einem Fall zum Beispiel extra immer auch eine zusätzliche Info-Datei pro Seite anlegen – zuviel des Guten. Das Video oben zeigt wunderschön, wie schnell und problemlos man in wenigen Minuten mit Webby eine Webseite (auf)baut. Die Autobuild-Funktion, die automatisch die Veränderungen an der Seite live übernimmt, macht es besonders schmackhaft. Damit ist nun – zumindest voraussichtlich – der Background meiner zukünftigen Portfolio-Seite geklärt. Andere Tipps oder Lösungen sind aber natürlich immer gerne willkommen!

Statischer Webseiten-Generator

Wer sich mal ein wenig umschaut entdeckt einen Haufen diverser statischer Site-Generatoren in Ruby, Python und sonstigen Sprachen. Neben der Blog-Engine Jekyll gäbe es da so klingende Namen wie Nanoc, Staticmatic, Webby und noch viele mehr… Ausgenommen dem hier verwendetem Jekyll kann ich mich mit den anderen nicht ganz anfreunden, Nanoc ist da noch am ehesten in der Auswahl. Ich hätte nämlich gerne neben dem statischen Blog auf eine idente Art und Weise eine statische “normale” Webseite laufen, zB. für ein Portfolio oder dergleichen – allerdings nach meinen Spielregeln und mit dem selben Hintergrund wie dieses Blog hier. Im Idealfall sollte der Aufbau wie folgt möglich sein:

+ html
+ images
+ config
	- meta.saf
	- navigation.saf
+ templates
	- front.saf
	- subsite.saf
	- style.sass
+ pages
	- index.textile
	- about.textile
	- work.textile
	- contact.textile
	...

Der Aufbau einer Seite ist recht ident zu dem Blog hier:

---
layout: front
title: Mein Portfolio
link: Startseite 
meta: 
---
content_1:
h1. Willkommen auf meiner Seite
Hier findet man bla bla

content_2: 
h3. Freunde
Einige Links

Ich denke der Grundgedanke ist damit recht klar. In den pages-Folder speichert man einfach die einzelnen Inhaltsseiten ab, soviele man eben braucht, in diesem Fall auf Textile basierend. Als Wunschgedanke wäre es zudem nett, wenn man in einer Seite auch Content-Bereiche festlegen kann. Aus den Einzelseiten und anhand des link wird auch das Menü automatisch erstellt. Da reicht es, wenn es in Form einer einfachen Listen-Definition in einer Datei landet, mittels CSS kann man sich dann austoben. Zusammengefügt wird alles in Templates mittels einfacher Platzhalter, welche man komplett über ein Stylesheet gestalten kann oder auch direkt in der Template-Datei selber. Prinzipiell würde es dann diese Platzhalter geben:

	saf.title
	saf.meta
	sass.style
		saf.navigation
		saf.content_1
		saf.content_2
		...

Zur Erklärung – die Bezeichnung saf ist eine erfundene Dateiendung bzw. Benennung um hier neutral zu bleiben. Die Platzhalter lassen sich ausbauen und selber definieren. Eigentlich sollte das Teil nichts anderes machen, als nur die Platzhalter aus den Einzel-Seiten mit dessen Inhalten ersetzen, Textile dabei verstehen, alles zusammenfügen und als HTML-Seiten ausspucken. Jetzt wird es einige geben, die aufschreien “Moment mal, das ist doch eh wie all diese Generatoren”! Tja, einen der exakt so einfach und schlicht funktioniert habe ich leider nicht gefunden, aber ich habe auch noch nicht alle durch. Kennt jemand einen Generator, der genau diesen Zweck erfüllt? Selber programmieren müsste man können, aber ob ich Ruby und Co. noch packe… vermutlich nicht. Mist.