Kurzmeldung:Weitere Informationen rund um das Pressure CMS könnt ihr nun via codecraft.io erfahren. Das wird ab sofort mein Entwickler-Tagebuch.Die Beiträge werden dabei sowohl in englisch aus auch deutsch geschrieben -- also nicht jeder Artikel, aber beide Sprachen werden dort auftauchen. Hauptsächlich wird's wohl Englisch sein, damit ich mehr Publikum erreiche.

Ich habe mich ein bisschen verfahren mit dem Projekt Pressure. Nein, ich habe nicht aufgegeben, aber ich habe mich in einigen Dingen in der Entwicklung etwas ungünstig entschieden.Das Ende vom Lied ist, dass ich teilweise das CMS neu schreibe. Als Grundlage für die neue Code-Basis dient mir nun ein ziemlich gut vorausgestattetes Rails-Template. Ich habe schon zwar davon gelesen, aber diesmal auch selbst ausprobiert, ein neues Projekt anhand eines Templates zu generieren kann viele Dinge von Anfang an erleichtern, sofern das Template mit den gewünschten Einstellungen daherkommt.Was ich noch festgestellt habe:Test Driven Development (TDD) [→] und Behavior Driven Development (BDD) [en:→] sind tolle Sachen, erfordern aber auch Einarbeitung und Gewöhnung. Die Vorteile sind ja unbestritten, man erstellt Code, der zuvor geschriebene Tests durchläuft, da diese ja die Ausgangsbasis für den Code stellen. Auch beim verhaltensbasierten Entwickeln steht die zu erreichende Funktionalität am Anfang inklusive einiger Test-Szenarien, die der Code ebenfalls durchlaufen muss.In der Rails-Entwicklergemeinde sind wohl die Gems Cucumber (BDD) und Rspec (TDD) für beide Entwicklungsarten die bevorzugte Wahl.Für mich haben diese beiden Paradigmen aber auch einen kleinen bitteren Nebengeschmack: die ersten Erfolge stellen sich nun wesentlich später ein, da man zuvor mit viel Schreib-Overhead beladen wird. Denn: die Features und Szenarien wie auch die Tests müssen ja erst geschrieben werden. Und dann stellt sich mir die Frage, ob ich eher auf Cucumber oder Rspec setzen soll, denn beides zugleich frisst dann doch zuviel Zeit. Wobei ich ohnehin schon auf eine kleine Fußangel bei Cucumber gestoßen bin: ...

Zwischendurch ein kleiner Beitrag zu Pressure.Und zwar will ich auf das Projektmanagment hinweisen, welches auch von außen einsehbar ist, nämlich unter http://redmine.dinarrr.com/projects/pressure. Statt das weit verbreitete Trac habe ich mich für Redmine entschieden, da es selbst auch eine Ruby/Rails-Anwendung ist. Es sieht zudem etwas schöner aus und lässt sich recht gut administrieren. Ein auch für mich wichtiges Feature ist ebenfalls implementiert: Durch Commits in ein zentrales git-Repository kann ich auch Ticket-Statūs ändern lassen (habe dafür einen separaten Ticket-Status generiert, der sich passenderweise "Commit-Lösung" nennt); das hat den Vorteil, auch Tickets damit abzuhandeln, ohne gleich ins redmine gehen und das entsprechende Ticket manuell bearbeiten zu müssen.Unsaubererweise lasse ich redmine in deutsch laufen, während ich das Projekt selbst in englischer Sprache verwalte, daher müsste ich mein redmine eigentlich auch wieder auf Englisch einstellen.Auch eine passende Domain für Pressure selbst habe ich registriert, die Entscheidung fiel auf pressure-cms.com, da pressure.TLD für den meisten Ländern oder den CNO-Bereich bereits vergeben war bzw. einige Topleveldomains einfach zu teuer sind.Übrigens kann man sich auf der Projektseite bereits ein kleines Bild davon machen, was schon alles passiert ist. Ticket-Anregung nehme ich gern entgegen (z. B. hier in den Kommentaren oder als Mail an pressure-dev ÄT dinarr PUNKT com), einen Reporter-Account spendiere ich nur jenen, die ein ernsthaftes Interesse an Pressure haben (damit ist es dann möglich, mir direkt auf der Projektseite Tickets zu schreiben).Es gibt zwar auch ein zentrales git-Repository, aber aktuell belasse ich es privat (sprich: niemand außer mir kann sich den ...

Entwicklung eines "gigantischen Schienentagebuches"Was ich mit den Überschriften sagen will? Ganz einfach, ich widme mich aktuell einem in Entwicklung befindlichen Blogsystems auf Basis Ruby on Rails und MongoDB. Da ich gerade keine Böcke auf PHP, Wordpress(-Plugins/-Themes) und dem Metabloggen habe, programmiere ich in meiner derzeitigen Lieblingsprogrammiersprache Ruby. Dabei nutze ich das ebenso beliebte Applikations-Framework Ruby on Rails (kurz: Rails oder RoR).

Der eine oder andere Besucher wird festgestellt haben, dass in letzter Zeit hier viel über Wordpress, Plugins und dergleichen gebloggt wurde.Das liegt daran, dass ich aktuell sehr in der Plugin-Entwicklung involviert bin, neben Statpress SEOlution und dem kleinen WP PermaLauts (welches nur sporadisch gepflegt und aktualisiert wird) möchte ich noch weitere -- eigene! -- Ideen voranbringen. Zum Beispiel möchte ich so etwas wie ein Greylist-Plugin für Kommentare schreiben, da mir das reine Erlauben oder Verbieten allein nicht reicht. Im Hinblick auf die nofollow-Problematik in Blogs überlegte ich, was es denn noch gäbe, um vielleicht sinnvolle Kommentare dennoch zu erlauben und den Link des Autors oder Links in dem Kommentar effektiv zu "entwerten" bzw. so umzugestalten, dass eine Suchmaschine merkt, dass der entsprechende Link zwar erlaubt ist, aber die Wertigkeit vom Blogbetreiber nicht im gleichen Maße gegeben ist, wie vielleicht vom Kommentator beabsichtigt.Was ich damit meine? Die nervigen SEO-Blogger, die der Meinung sind, auf nofollow-freien Blogs sich breit machen zu müssen. Da nofollow allein auch kein Allheilmittel mehr darstellt, kam mir der Gedanke, einen anderen Weg zu beschreiten. Wenn der Kommentar dennoch konstruktiv erscheint und damit positiv moderiert werden könnte, sollen wenigstens die Links nicht im Vordergrund stehen. Es gab da schon in der Vergangenheit so einige Lösungen, die aber teilweise manuellen Eingriff z. B. in das Wordpress-Theme erforderten. Und hierbei wurde dann auch wieder generalisiert und jeder Kommentar war betroffen. Daher also eine Greylist, wo diejenigen Kommentatoren zu finden sind, die zwar etwas spammig erscheinen, aber wenigstens vernünftige ...