Aufbau und Funktion von einem Ruby Blog Engine

Info: Dieser Blogeintrag wurde von meinem alten Blogging Engine, die ich selbst gebaut hatte, umgezogen. Ich hatte leider nicht die Zeit die Platform fertig zu entwickeln oder neue Features hinzuzufügen. Deshalb lest ihr diesen Artikel nun in Ghost.

"Wie schon hier beschrieben, möchte ich euch den Aufbau und Funktionsweise von "meinem" Blog zu erläutern.

Die Datenbank

Als Datenbank kann ich MongoDB sowohl auch ein neues Produkt die ArangoDB verwenden. Momentan versorgt die MongoDB die Rails Application. Ich werde aber bald alles auf die ArangoDB umstellen. ArangoDB sowie MongoDB sind NoSQL Datenbanken. Meiner Meinung nach ist ArangoDB noch mächtiger und Feature reifer als MongoDB, dies wird auch der Grund sein, warum ich auf ArangoDB wechseln werde. Um ein Rails Projekt schnell und sicher auf die Datenbank zugreifen zu lassen, verwendet man sogenannte Driver oder oft auch ORM (Object Relation Mapper) in meinem Fall verwende ich für MongoDB Mongoid und für ArangoDB Guacamole. Zugegebenerweise könnte Guacamole noch etwas ausgereifter sein. Da ich aber so und so auf die Generatoren von Rails verzichte kann man auch wunderbar mit Guacamole als Driver arbeiten. Der Hauptunterschied zu "normalen" Datenbanken ist, dass diese Dokumenten Orientiert sind und noch auf Tabellen und Indizes setzen. Somit schaut ein BlogPost bei mir in der Datenbank so aus: json { "_id": ObjectId("54ddde604d425002fe040000"), "tags": [ "tag" ], "name": "Hello World!", "content": " TEXT ", "category": "General", "date": new Date("2015-02-13T15:37:49+0100"), "language": "German", "public": true } Sieht definitv logischer und schöner aus wie in einer relationalen Datenbank 😉

Rails Application

Direkt in der Rails Application werden die BlogPosts gelisted und auch ein wenig aufgehübscht und dann in die View gegossen. Das wirklich interessante Teil beginnt eigentlich, wenn man über das Erstellen oder Editieren stolpert. In der Auflistung der Blog Posts sollte man nicht immer den vollen Beitrag sehen, somit sollte der "abgeschnitten" werden. Da die Posts in MarkDown geschrieben werden, ist es schwierig das HTML welches ensteht abzuschneiden und die Tags zu schließen. Desshalb gibt es einen Hidden Tag welcher den Umbruch erzwingt. Syntax HighLighting wird am Client via Javascript umgesetzt. Jedes mal wir das Markdown aus der DB geladen und in HTML umgewandelt. Dies muss leider so sein, da wenn ich einen Post Editieren will wieder das Markdown sehen und nicht das unschöne HTML. Die andere Möglichkeit ist, alles doppelt (einmal in HTML und einmal in MarkDown zu speichern), da aber das Rendern von Markdown recht performant ist kümmert mich das "noch" nicht. Zudem würde ich eher dann auch ein Caching in Rails setzten statt alles doppelt zu speichern.

ToDo's

  • Kommentare beantworten
  • Kommentar Bilder Icons
  • Nav Menu actives Element
  • Listung der Non-Public in Admin/Writer View
  • Tags Suche
  • Kategorien Suche
  • Generelle Suche
  • Tags in Tags darstellen

Further ToDo's

  • Image Host (Rails to cdn.bmalum.com)
  • File Hoster
  • more to be announced"