Garten Eden

#linux #programming #android #online #stuff

femto blog system

femto macht seinem Name alle Ehre: Als minimalistisches System erfüllt es all meine und vielleicht auch deine Bedürfnisse an eine Blogging Software: einfach, performant und sicher.
femto will nicht möglichst viel. femto will seine Sache gut machen, ohne zu nerven. Trotzdem/Deswegen kann sich die Feature-Liste sehen lassen:

Features

Noch eine Blog Software, rly?

Aber es gibt doch schon genug! Und warum sollte ich mir die Mühe machen umzusteigen?
Ja, es gibt tatsächlich viele Blogsysteme, aber eben keine, die meinen Ansprüchen (s.o.) gerecht werden konnte, deswegen musste eine neue her. Und warum die Mühe machen? Vielleicht weil sich schon einmal viele von uns die Mühe gemacht haben, das System zu wechseln — und es sich gelohnt hat.

Tacheles. Was bringt es mir wirklich?

Im Endeffekt sollst du von der Zufriedenheit deiner Besucher profitieren. Sind sie gerne auf deinem Blog, kommen sie wahrscheinlich wieder, empfehlen dich vielleicht weiter, verlinken dich. Aber was trägt entscheidend dazu bei, eine positive user experience zu ermöglichen?
Nun, ich empfinde es jedenfalls als positiv, wenn die Seite kurze Ladezeiten hat, gerade wenn ich mobil surfe. Deswegen spart femto an allen (sinnvollen) Stellen Übertragungsvolumen und Rendering-Zeit. JavaScript wird sehr spartanisch und möglichst effizient verwendet; die verwendeten PHP-Funktionen wurden zeit-optimiert und die Datenbankzugriffe auf ein Minimum reduziert (oft nur eine Abfrage pro Seite).
Design ist natürlich Geschmackssache, aber mit der mitgelieferten Standard-CSS-Datei habe ich versucht, eine stilvolle, lesbare, zugängliche Alternative zu dem zu bieten, was man häufig so im Web findet. Responsiveness inklusive (verkleinere doch mal deinen Browser). Ach ja, genauso wie den Rest des offenen Systems kann man das Design natürlich personalisieren oder vollständig ersetzen.
Eher mittelbar, aber sicherlich ganz elementar profitieren Nutzer von einem sicheren System. Einem, bei dem sie wissen, dass selbst im Falle eines Falles keine Rückschlüsse auf ihre Herkunft (IP-Adressen) oder gar ihre Passwörter (Autoren) möglich sind. In der Standardeinstellung speichert femto deshalb nur die ersten 2 Byte einer IP-Adresse und zeigt sie zu keinem Zeitpunkt an. Autorenpasswörter werden sicher gehasht und gesalzen – bei jedem Einloggen neu. Falls möglich, wird zusätzlich die Rechteverwaltung des Datenbanksystems genutzt. Apropos Datenbank: Alle Abfragen sind selbstverständlich weitestgehend vor SQL Injections abgesichert (Stichwort: Prepared Statements).
Einfach, performant, sicher. Quelloffen und anpassbar. Kannst du das von deinem jetzigen System auch sagen?

Okay, Screenshots?

Du siehst dir gerade so eine Art Live-Screenshot an… und der ist sogar klick- und scroll-fähig.

Mehr Infos, bitte

femto blog system wird auf github gehostet. Dort gibt es den Download, eine Dokumentation (im Aufbau) und alles, was man wissen muss:
femto blog system auf github

Wie immer – und diesmal besonders – ist jedwede Art von Feedback und Verbesserungsvorschlägen sehr willkommen!

Kommentare

Dein Kommentar:






Bisher...

 
27.11.2014 10:42 Eduard Dopler sagt:
Hallo Philipp,

natürlich kann man den Spamschutz auf vielerlei Weisen implementieren, auch ohne JS. Ich habe mich für diese Variante entschieden, weil sie relativ simpel und trotzdem noch recht effektiv ist. Eine Captcha-Überprüfung finde ich wegen verschiedener Punkte nicht optimal (oft unleserlich, mehr Bandbreite, oft fremder Code etc.). Es wäre eine serverseitige Generierung und Prüfung möglich; ich habe mich aber für den JS-Ansatz entschieden, eben aus genannten Gründen.
Man darf den Code aber natürlich überall modifizieren ;)
 
27.11.2014 10:37 Philipp sagt:
Kannst du den Spamschutz nicht auch ohne JavaScript implementieren?
 
18.11.2014 22:40 Eduard Dopler sagt:
Wie beschrieben werden ausschließlich Prepared Statements verwendet. Wikipedia sagt dazu: „Mittels Prepared Statements können SQL-Injections effektiv verhindert werden, da das Datenbanksystem die Gültigkeit von Parametern prüft, bevor diese verarbeitet werden.“ Beispiele und eine rudimentäre Erklärung dazu kann man dort auch finden.

Nun ist es jedem selbst überlassen, wie man diesen Sicherheitsmechanismus bewertet. Alle hielten TLS/SSL für „sehr sicher“, dann kam Heartbleed. Das mein ich mit „weitesgehend“.
 
18.11.2014 22:35 Kenny sagt:
"Alle Abfragen sind selbstverständlich weitestgehend vor SQL Injections abgesichert" - Was heißt denn "weitestgehend"? Sind Abfragen gegen SQL-Injections abgesichert oder nicht? Oder einige ja und andere nein?
 
31.10.2014 12:41 Eduard Dopler sagt:
Danke, dein Design gefällt mir auch. Will man es richtig, muss man es wohl selber machen ;-)
 
31.10.2014 12:06 SammysHP sagt:
Richtig so, sieht toll aus! Genauso so habe ich es mit meinem BetaBlog auch gemacht.

de

Moment, lade ältere Artikel...

E-Mail (nicht öffentlich)

Homepage (optional)

Kommentar... (code-Tag erlaubt)