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: es lässt sich viel eher für den äußeren Test des Codes einsetzen (wie erfährt der Nutzer die Rails-Anwendung), während man mit Rspec viel eher unter der Bühne arbeitet (also systemnah, direkt einzelne Komponenten unabhängig voneinander testen).

Während ich also mit Cucumber als Allererstes beschreibe, was ich mit der Anwendung machen will, überprüfe ich dann mit Rspec die Arbeitsweise der Modelle, Controller und Helper (Views müssten theoretisch ja gar nicht mehr mit Rspec noch einmal durchexerziert werden, da ich dies ja bereits mit Cucumber erledigt habe; Tests sollte man aber vielleicht trotzdem schreiben).

Wie ihr seht, geht also schon viel Zeit am Anfang flöten, die hoffentlich hintendran aber dann wegfällt. Es heisst ja wohl ohnehin, dass bei der Entwicklung einer Software mehr Zeit ins Testen als in die Code-Basis selbst gesteckt wird. Mit den oben genannten Paradigmen verlegt man aber das Testing bereits an den Anfang und spart sich somit Zeit am Ende.

Warum? Wie ebenfalls oben schon erwähnt, werden ja die Tests nicht erst im Nachhinein geschrieben, sondern dienen als Baubeschreibung. Außerdem verleitet das sicherlich auch nicht dazu, die sonst nachgegliederten Tests an die Anwendung anzupassen (man kann sich beim Entwickeln bestimmt so einiges schön reden ;o). Siehe hierzu auch das Grey-Box-Testing [→].

Rails, Routing und Dynamik

Mein größtes Problem an Rails ist das Routingmodel. Es muss zwingend für jeden Controller eine festgeschriebene Route definiert werden.

Routen selbst sind natürlich keinesfalls statisch, immerhin gibt es beim Rails-Routing unzählige Möglichkeiten, die seltsamsten Routen zu definieren.

Seit Rails3 versucht man uns ja nun auch das RESTful Routing mit Resourcen schmackhaft zu machen, aber ich mag keine Anwendungen, die an jeder nur denkbaren Stelle stur dem REST-Prinzip folgen, die URLs sehen damit teilweise unheimlich hässlich aus. Auch wenn heutzutage ohnehin gern mit URL-Shortener gearbeitet wird, mag ich auch in der eigentlichen Webanwendung eine gewisse URL-Ästhetik.

Am Beispiel eines Blogs, gerade mit WordPress, ein sehr einleuchtendes Beispiel: Kaum einer mag die Form /?page=1, die Variante /meine-seite-ueber-muell liest sich dagegen viel angenehmer, auch die Permalinkstruktur für die Blogposts, die man z. B. datumsbasiert untersortieren lässt scheint viel angenehmer als nur /?post=2342.

Jetzt kann WordPress aber was ganz Tolles: die Permalinkstruktur lässt sich nach der Installation des Blogs beliebig anpassen, zur “Laufzeit” will ich hier nicht sagen, da ja auf den meisten Servern wohl kaum die PHP-Anwendung persistent vor sich hindümpelt. Bei Rails dagegen ist dieses Modell des dynamischen Permalinkings gar nicht direkt möglich, da hier die Applikation im Regelfall einmal geladen wird und dann im Speicher auf seine Arbeit wartet, es ist ein eigener, ständig laufender Webdienst, der nur meist mit Apache oder nginx an die Welt extra angebunden wird (kaum einer wird wohl eine Standalone-Lösung nutzen, wenngleich dies durchaus möglich ist).

Zudem hab ich mit Rails das Problem, dass nur Controller dann angesprochen werden können, wenn sie via routes.rb festgehalten worden sind. Ein Ein- und Aushängen zur Laufzeit ist somit nicht möglich. Selbst das Ansprechen durch einen anderen Controller quittiert Rails nur mit der Meldung, dass für jenen Controller mit der betroffenen Action eben keine Route definiert sei.

Und das ist echt blöd so!

Ich wollte ursprünglich nur eine Art Catch-All-Route definieren, die an den ApplicationController gebunden ist, und dieser sollte dann in einer Router-Action dann dynamisch verzweigen. Und woher sollten die Routen kommen? Klar, einige essentielle wären zwar vordefiniert (beispielsweise sowas wie /admin), aber die meisten sollten eben aus der Datenbank kommen.

Der Spaß wäre gewesen, sowohl Controller in einer laufenden Anwendung mit einer Aktivierungsfunktion auszustatten bzw. wäre dadurch ein Plugin-System möglich, was ebenfalls darauf abzielt, nicht im Code rumfuschen zu müssen. Jedoch kann ich diese Idee wohl vorerst komplett verwerfen.

Seitenblicke

Das Padrino-Framework (welches auf dem Microframework Sinatra beruht) habe ich mir am Wochenende ebenfalls kurz angeschaut. Hier ist ein alternativer und sehr interessanter Ansatz drin: man kann in Padrino mehrere Apps kreieren, die dann in verschiedene Basis-Routen eingehangen werden (also /app1, /app2, /app3 …). Die Versuchung war recht groß, zumal viele Dinge in Padrino ähnlich aufgebaut sind wie in Rails.

Aber ich werde nun erst einmal eisern am Rails-Framework lernen und gelegentlich einige Gehversuche mit Padrino erledigen. Padrino hat noch einen entscheidenen Vorteil: wenn man sich schon alle Modelle definiert hat, kann man wunderbar eine /admin-Subapplikation einrichten, mit der man dann schon die Daten verwalten kann (ein Seeding könnte damit entfallen). Sozusagen ein rohes Admin-Interface, welches man sicherlich später durchaus auch für die Endanwendung umgestalten kann, aber vornehmlich auch zum Entwickeln und Testen gut geeignet ist. So etwas fehlt im Rails-Kern noch.

Eventuell werde ich mal testen, ob es funktioniert, die Rails-Modelle in eine Padrino-App zu symlinken und ich dort nur die Admin-App installiere und nutze (eben nur zum Testen, nicht für den Produktiveinsatz).

Da ich bei beiden Frameworks nämlich Mongoid als ORM nutzen kann, sind die Modelle also ohnehin recht weit weg vom Framework abstrahiert. Solange man also keinen Framework-typischen Code einschleust, sind Modelle schön portierbar.

Alle Theorie ist grau, darum werde ich einfach weiter probieren und studieren.

Der alte, noch unfertige Dampfkessel ist zwar etwas beschädigt, aber wird trotzdem als Grundlage für den neuen gelten.

Oder anders ausgedrückt: Ich schmelze Teile davon wieder ein und schmiede mir andere daraus.

Bis bald — dann mit neuen Erfahrungen!

asaaki on blogcraft, 2010. | Kaputter Dampfkessel und Entwicklungsparadigmen (Permalink) | Keine Kommentare bisher | Add to del.icio.us
Post tags: bdd, behavior driven development, cms, cucumber, entwicklung, pressure, pressure cms, rails, REST, RESTful, route, routing, rspec, ruby, tdd, test driven development, tests

LOL-SEO / SEO-LOL – Spaß mit Suchmaschinenoptimierung!

1. SEO ist nicht schwer …
2. Mit nummerierten Texten ist SEO sogar leicht …
3. Und mit Farbe wird SEO super easy!
4. Die eigene Seite ist die beste Referenz der eigenen SEO-Tätigkeit.
5. Okay, lange Rede, gar kein Sinn — lest und -besser noch- schaut, worum es geht.
6. Zu Punkt 4 in Bezug auf Punkt 5 siehe diese Seite, mit der sich ganz schnell und leicht Geld im Internet verdienen lässt.

Ein Kurzartikel der fiktiven Kategorie “Spaß mit SEO!”

asaaki on blogcraft, 2009. | LOL-SEO (Permalink) | 4 Kommentare | Add to del.icio.us
Post tags: LOL-SEO, seo, SEO-LOL, SEO-Volk, Volks-SEO, VolksSEO

So kann man, wie ich gestern selbst erfahren habe, z. B. die Suchmaschinen-Robots unfreiwillig komplett aussperren.

Was habe ich dabei gelernt: Man kann keine Regeln erfassen, die das besuchen von Links mit Ankern (…/#anker-im-text) einschränkt. Denn das explizite Einschließen des “#” ist nicht möglich, da es für die robots.txt als Kommentarzeichen gilt. 

Warum wollte ich überhaupt Dokumenten-Anker ausschließen? Damit das Folgen von ohnehin meist nur redundanten Links wie “Weiterlesen”, “Read more” etc.  weiter minimiert wird. So ein Crawler einer Suchmaschine kann allein erheblichen Traffic verursachen (bzw. bei PHP-basierten Seiten mit Datenbank auch noch eine Menge Nutzlast auf CPU und RAM). Für den Index spielt es sehr wahrscheinlich kaum eine Rolle, da nur selten Links mit Ankern zu finden sind.

Bei Blogs steht der erste Link ja direkt als Überschrift, der eventuell zweite zum gleichen Inhalt ist dann oftmals mit einem #more-Anker versehen. Intelligente Spiders sollten hier sehen, dass es sich um ein und dieselbe Zielseite mit identischem Inhalt handelt.

Wie ich ja oben andeutete, war dies ein Versuch. Und mit einem für mich aufschlussreichen Ergebnis, aber eben mit dem, worauf ich fokussiert war.

Also zum Merken nochmals:

Eine Regel in der Form

Disallow: /*#more

niemals benutzen!!! Der Bot liest nämlich nur:

Disallow: /*

und ist damit gleichbedeutend wie “Alle Unterseiten sind gesperrt für dich!” (Der Stern wäre hierbei optional, unterstreicht die Regel aber umso deutlicher).

Wer seine Seite in den Google Webmaster Tools [⇒] eingetragen hat, kann dort auch ganz leicht überprüfen, ob die robots.txt korrekt funktioniert. Sicher mag es auch noch andere Dienstleister geben, habe aber gestern keinen so auf die Schnelle gefunden.

asaaki on blogcraft, 2009. | Sperrschrift für Automaten (Permalink) | Ein Kommentar | Add to del.icio.us
Post tags: allow, crawler, disallow, robots, robots.txt, sperren, spider, suchmaschine

Die Lösung: meine WordPress NoFollowFree Edition!

Was bedeutet denn nun dieses nofollow-Zeugs?

Vor nicht allzu langer Zeit hat sich Google (und wohl auch ein paar andere Suchmaschinen-Betreiber) gedacht, dass der Link-Spam auf vielen Webseiten einfach störend ist und den Suchindex verschmutzt. Damit Seitenbetreiber ein Werkzeug haben, um — gerade gegenüber Google — klarzustellen, welche Links zur weiteren Verfolgung wichtig sind und welche nicht, wurde das Linkattribut rel=”nofollow” eingeführt. So wird dem Suchrobot, der eine Seite besucht und analysiert, gezeigt, dass bestimmte Links auf der Seite einfach keinen Wert haben und diesen nicht weiter nachgegangen werden soll/muss.

Dies sollte hilfreich sein, damit z. B. Blogbetreiber nicht jeden Link vorher anschauen muss. Denn Kommentar-Spammer haben dies gerne ausgenutzt, um massenhaft unseriöse Links zu verbreiten und damit ihre Projekte oder Dienstleistungen populärer zu machen. Denn Google bewertet eine Zielseite eben sehr stark daran, wie viele eingehende Links diese hat.

Ein prominentes Beispiel aus einer anderen Ecke ist die Wikipedia: dort werden im großen Stil viele externe Links mit dem nofollow-Attribut entwertet. Dies ist dort aber auch gewünscht, um die Kontrolle etwas minimieren zu können.

Viele Blogger mit einem WordPress-System dagegen wissen gar nicht, dass auch ihr Blog “unhöflich” gegenüber den Kommentatoren ist. Die angegebene Webadresse wie auch eventuelle Links im Kommentartext werden ebenfalls von Hause aus entwertet. Dabei ist aber das Verlinken in der Blogosphäre ein Hauptelement. Und wer etwas Positives beigetragen hat, sollte eigentlich auch mit einem Link gewürdigt werden. Hierdurch steigt ja auch die jeweilige Popularität im Suchindex.

Diese eingebaute Entwertungsmaschinerie in WordPress ist heutzutage auch gar nicht mehr wirklich nötig, denn gegen Spam gibt es mittlerweile sehr gute Plugins und Helfer. Der Generalverdacht als Spammer kann nun ruhig fallen gelassen werden.

Deswegen wurden bereits einige Plugins geschrieben, die den nofollow-Mechanismus in WordPress aushebeln. Meine Meinung dazu ist aber, dass dies alles Krücken sind. WordPress sollte von sich aus wenigstens die Wahlmöglichkeit lassen; bisher ist diese Funktion leider so noch nicht umgesetzt worden.

Und hier greife ich ein — zumindest so lange, wie die WordPress-Entwickler selbst noch nichts unternommen haben.

Ab sofort werde ich für jede veröffentlichte Version von WordPress ab der Nummer 2.7.1 eine NoFollowFree-Edition erstellen und zum Download anbieten!

Alle weiteren Infos hierzu findet ihr auf der Seite WordPress NoFollowFree Edition (siehe auch Sidebar auf der Startseite).

Ältere Versionen möchte ich nicht mehr unterstützen, da alte Versionen eben auch fehleranfälliger sind und ich an jeden appellieren möchte, seine Blogsoftware aktuell und sicher zu halten.

Ich wünsche mir auch, dass dieses Projekt regen Zuspruch findet. Lange Zeit habe ich nur von den Früchten anderer gekostet, doch ich möchte gern wieder etwas an die Gemeinde zurückgeben.

Die von mir zur Verfügung gestellten WordPress-Pakete sind bis auf die Modifikationen völlig original belassen und erhalten keine Footprints/Backlinks zu diesen Blog. Ich möchte es euch überlassen, ob ihr mich erwähnen und verlinken wollt.

Dennoch bitte ich euch um ein wenig Fairness. Falls ihr z. B. selbst die Pakete zum Download anbieten wollt, dann sagt mir bitte Bescheid und verlinkt mich als Urheber der NoFollowFree-Edition. So kann ich euch auch als zusätzliche Download-Quellen mit aufnehmen. Ich danke euch!

asaaki on blogcraft, 2009. | WordPress und NoFollow – ein NoGo! (Permalink) | 11 Kommentare | Add to del.icio.us
Post tags: download, neu, nofollow, nofollowfree, wordpress

Verändere NIE einfach so in den Einstellungen die Permalink-Struktur. Gerade aus der Sicht von Suchmaschinen ergeben sich hier gewaltige Nachteile, aber auch bestehende Querverlinkungen und externe Links gehen damit kaputt und verloren.

Abhilfe schaffen hier z. B. bei WordPress die Redirection- bzw. Permalink-Plugins. Mit einigen muss viel manuell korrigiert werden, andere versuchen automatisch die alten Permalinks zu den neuen umzubiegen. Da bei mir die automatisierten Mechanismen meist nicht so glücken wollen, habe ich auf das Plugin mit Handarbeit gesetzt^[01]: Redirection von Urbangiraffe.

Es mag für den Anfänger kompliziert anmuten, aber an die Veränderungen von Permalink-Strukturen sollten sich ohnehin nur Erfahrene wagen, sonst ist auch mal gern das ganze Blog futsch! Für den Kenner tun sich mit diesem Plugin natürlich unendliche Weiten auf, man hat hier fast die gleiche Freiheit wie beim direkten Bearbeiten der RewriteRules in der .htaccess — nur komfortabler und alles direkt aus dem WordPress heraus.

Mein Fazit: Sehr praktisch!

Merke: Überlege dir schon von Anfang an, welche Permalink-Struktur du in deinem Blog haben willst; es erspart dir im Nachinein viel Ärger. Linktipp für eine mögliche und gute Struktur: beim toscho gab es vor nicht allzu langer Zeit einen interessanten Artikel zur “besten URL-Struktur”.

Wie ich zu diesem Artikel kam? Weil ich jetzt einfach einmal meine Haus-interne Permalink-Struktur auf Vordermann gebracht habe. Und obwohl schon einiges bei Google und Co. indexiert ist, habe ich da zu Beginn wenig Angst, dass da was Schlimmes passiert. Im Laufe der kommenden Stunden werde ich sämtliche alten URLs auf das neue Regelwerk umgebogen haben und meistens sind die Suchmaschinen auch recht gnädig und biegen ihren Index zurecht. Manchmal.

Was macht ihr, wenn die URL-Struktur verändert werden soll? Welche Plugins kommen bei euch zum Einsatz? Oder fragt ihr euch, wozu überhaupt der ganze Kram gut sein soll?

asaaki on blogcraft, 2009. | Strukturwandel (Permalink) | Ein Kommentar | Add to del.icio.us
Post tags: .htaccess, permalink, redirection, rewrite, url