MyInnoQBlog

Nach einem ersten Test-Deployment kam es noch zu einigen Fehlern, was relative Linkangaben anging, wenn man die Seite z.B. in einem anderen Verzeichnis ablegt.
Besonders Pfadangaben zu Bildern im Stylesheet machten Probleme. Da aber CSS-Stylesheets nicht dynamisch sind, habe ich erstmal die entsprechenden Angaben herausgenommen und inline in einem Template (application.html.erb) abgelegt. Dort konnte ich dann die entsprechende Dynamic reinbringen.
Das hat mir aber natürlich nicht gefallen, so viele Style-Angaben im Template zu haben, und so habe ich mich auf die Suche nach einer Lösung gemacht und bin auf folgenden Blogeintrag von Josh Susser gestoßen: http://blog.hasmanythrough.com/2007/10/18/simpler-than-dirt-restful-dynamic-css

Nach diesem Rezept bin ich dann quasi vorgegangen, um das Problem zu lösen. Ich musste es nur etwas anpassen, da meine Angaben überall verfügbar sein sollten - also application-wide.
Also habe ich erstmal ein view-template im Verzeichnis /app/views/application/ erstellt mit dem Namen "dynamic_stylesheet.css.erb".
Danach habe ich im Application-Controller (application.rb) folgende Methode implementiert:

def dynamic_stylesheet
    respond_to do |format|
      format.css
    end
end

Einfach eine Methode, die bei Anforderung eines Stylesheet entsprechend reagiert.

Des weiteren war es noch notwendig eine Route in routes.rb hinzuzufügen:

map.connect '/dynamic_stylesheet.:format',
:controller => "application", :action => "dynamic_stylesheet"

So war es dann schon möglich, das Stylesheet mit folgender URL direkt aufzurufen: http://localhost:3000/dynamic_stylesheet.css

Um das Stylesheet in einem view-template noch einzubinden, brauchte ich nur noch folgende Zeile hinzufügen:

<%= stylesheet_link_tag '/dynamic_stylesheet' %>

So sieht dann alles auch wieder schick aus und der Style-Kram ist wieder da, wo er hingehört. War in der Tat "Simpler than dirt"! Thanks to Rails 2.0!

Eine übersichtliche Liste, was Leopard so alles mit sich bringt:

http://trac.macosforge.org/projects/ruby/wiki/WhatsNewInLeopard

(via RubyInside)

Nachdem ich den Apache2 Webserver auf meinen Rechner installiert habe, möchte ich hier kurz meine Arbeitsschritte festhalten.

Zuerst sollte man MacPorts installieren und darüber dann den Apache2. Das geht dann ganz einfach im Terminal:

sudo port install apache2

Dabei ist bei mir allerdings ein Problem aufgetreten: die Bibliothek db44 konnte nicht installiert werden. Wer ähnliche Probleme hat, sollte sich folgendes mal angucken: http://alistairisrael.wordpress.com/2007/09/18/building-db44-using-macports/
Bei mir hat das geholfen.

Jedenfalls sollte der apache2 nun unter /opt/local/apache2 installiert sein. Unter dem bin-Verzeichnis sollte man nun den Webserver aufrufen können:

/opt/local/apache2/bin/apachectl -v

Sollte nun die aktuelle Version angezeigt werden, ist bisher alles richtig gelaufen.

Um den Webserver nun auch über die Systemeinstellungen starten und beenden zu können, müssen noch folgende Sachen erledigt werden:

1. Personal Web Sharing in den Systemeinstellungen beenden

2. ins Verzeichnis /usr/sbin wechseln und folgendes eingeben:

   mv apachectl apachectl-1.3
   

3. folgenden Symlink erstellen

   ln -s /opt/local/apache2/bin/apachectl /usr/sbin/apachectl
   

4. httpd.conf.sample in httpd.conf umbenennen

   mv /opt/local/apache2/conf/httpd.conf.sample /opt/local/apache2/conf/httpd.conf
   

5. diese Datei dann auch bearbeiten und folgende Zeilen einfügen

   PidFile "/private/var/run/httpd.pid"
   

   sowie DocumentRoot und Directory anpassen:

   DocumentRoot "/Library/WebServer/Documents"
   <Directory "/Library/WebServer/Documents">
   

Wenn jetzt in den Systemeinstellungen Personal Web Sharing wieder aktiviert wird, sollte nun der Apache 2 anstelle des Apache 1.3 gestartet werden und man sollte auch wie gewohnt auf seine Webprojekte über http://localhost/~UserName/ zugreifen können.

Um die in MacOSX Tiger mitgelieferte Version des Webservers wieder zu aktivieren, tut man einfach folgendes:

cd /usr/sbin
mv apachectl apachectl-2
mv apachectl-1.3 apachectl

(Meine PHP-Umgebung musste ich danach auch neu installieren, um kompatibel mit der 2er Version von Apache zu sein. Ich hatte PHP von entropy.ch installiert und das mitgelieferte Modul ist entweder kompatibel mit 1.3 oder mit 2.0.)

Wenn ihr euch schon immer mal gefragt habt (wie ich grade), wie man die Schriftgröße auf Webseiten browserunabhängig und benutzerfreundlich gestaltet, lege ich euch hiermit mal 2 Links ans Herz, die ich für recht nützlich empfunden habe:

1. How to size text using ems
2. Effective Style with em

Ein Argument für die Festlegung der Größe mittels em-tags ist, dass der IE keine Schriften mit Angaben mit px skalieren kann. Soweit ich weiss, wurde das in der 7er-Version behoben. Trotzdem finde ich die beiden Artikel sehr hilfreich und ich weiss jetzt warum in manchen Stylesheets die Schriftgröße (fast) ausschließlich in em angegeben ist.

Ich bin dann jetzt mal wirklich beim Backend gelandet.
Dort angekommen, musste ich mich erstmal darum kümmern, dass die entsprechenden Templates (Edit, Index, New...) erstmal ein anderes Layout bekommen als die Webseite selber.

Zuerst dachte ich, ich könnte einfach Folgendes in den ArticleController schreiben und gut is...:

layout "backend", :except => [:show, :search]

Dem war aber leider nicht so. Denn anstelle, dass show und search weiterhin das Standardlayout verwenden, benutzten sie dann gar keins mehr. So musste ich noch folgende Zeile in den entprechenden Methoden hinzufügen/modifizieren:

format.html { render :layout  => "application" } # show.html.erb

So habe ich explizit festgelegt, welches Layout sie nutzen sollen. Das entspricht zwar nicht Convention over Configuration aber mir is bis jetzt nix besseres eingefallen.

Da ich momentan "Getting Real" lese, dachte ich, mach' ich es wie die Jungs und fange beim UI an. Der folgende Screenshot zeigt einen ersten Entwurf:

Ich habe mit dem Layout für das Hinzufügen neuer Artikel angefangen, da dies erstmal die wichtigste Komponente des ganzen CRUD ist. Außerdem ist das edit-Template dann quasi auch direkt fertig.

Ok, es sieht im Moment sehr schlicht aus. Ich habe grundsätzlich erstmal das Stylesheet, welches mir das scaffolding generiert hat genommen. Ich habe dann nur den Hintergrund der Webseite eingefügt.
Ferner habe ich das Markdown Cheat Sheet von Mr. Markdown himself eingefügt. Ich glaube zwar, dass sich die bisherigen Autoren der Webseite gut mit der Markdownformatierung auskennen, aber wer weiss, wer da sonst noch mit arbeiten wird...Außerdem: sollte man eine Formatierung vergessen haben, kann man eben schnell nachschauen. Genug Platz ist auf jeden Fall da.

Die Eingabeform besteht nur aus den Feldern für Titel und Fliesstext sowie einer Auswahl in welche Kategorien man den Artikel stecken möchte. Das ist erstmal alles was man braucht. Ich habe mich dazu entschieden die optionalen Felder (Kurztitel und Zusammenfassung) per default ausgeblendet zu lassen, um 1. den Blick auf das Wesentliche zu richten und 2. die momentane Situation so ist, dass die wenigsten Artikel einen Kurztitel und/oder Zusammenfassung besitzen.
Alle anderen Felder für einen Artikel werden automatisch generiert. Diese müssen also (erstmal) nicht auf der Maske erscheinen.

Ich denke so kann man erstmal damit arbeiten. Was ich allerdings vielleicht noch einfüge ist ein Header mit dem innoQ-Logo, damit man auch weiss, wo man sich hier befindet.

Ok, ich bin dann doch erstmal wieder beim Frontend gelandet. Irgendwie mag ich es nicht, wenn Dinge so halbfertig sind, besonders wenn es nur "Kleinigkeiten" sind. Und so habe mich dran gemacht, die bisher schon implementierte Suche (mittels acts_as_ferret plugin), anstatt mit POST, mit GET und somit REST-konform umzusetzen.

Für die Sache musste ich dann ein extra Route in routes.rb eintragen und schon funktionierte es! :-) Naja, ok...ein bisschen nachdenken musste ich schon vorher. Aber ich denke das Ergebnis, sprich der in der Adresszeile übergebene String, macht Sinn und man kann anhand der URL verstehen, was abgeht:

Ich habe mich bei der Benennung des Suchparameters für die lange Version ("query=") entschieden, da man so besser nachvollziehen kann, was gemeint ist. Die Kurzfassung ("q=" z.B. bei Google) ist einfach nicht so sprechend. Und zusätzlich ist der Quellcode auch verständlicher. Ferner habe ich den title-tag der Ergebnisseite angepasst, so dass der Titel nun auch besagt, dass man gesucht hat und wonach man gesucht hat. Somit lässt sich die Seite dann auch bequem bookmarken.

Das Frontend für die innoQ-Webseite ist nun fertig (kleinere Änderungen vorbehalten). Es waren noch ein paar Detailsverbesserungen notwendig, so. z.B. das richtige Highlighten (uuuuhhhh) der Unternavigation. Des weiteren wurde die Datenbankstruktur nochmal komplett neu aufgesetzt und so ist z.B. auch ein Feld "short_title" - für einen optionalen Kurztitel eines Artikels - hinzugekommen. Ferner wurde der Missstand entfernt, dass bei einigen Artikeln der Titel nochmal im Text selber stand und bei manchen nicht. Jetzt steht nirgendwo mehr der Titel im eigentlichen Fließtext und somit sind die beiden Dinge sauber getrennt.

Für das ganze Daten-hin-und-her-Geschiebe in der Datenbank habe ich wieder rake-Tasks benutzt, was auch wieder hervoragend funktioniert hat. Dort habe ich wieder ordentlich mit Regulären Ausdrücken gearbeitet und muss sagen, dass ich die Dinger mitlerweile doch sehr lieb gewonnen habe.

Als nächses werde ich mich dann dem Backend widmen und wohl eine GUI zum erstellen und bearbeiten von Artikeln coden.

"IMHO ist lesbarer Code wesentlich besser, vor allem, was die Wartbarkeit angeht. Und wenn man dafür die doppelte Anzahl Codezeilen benötigt..."

Das habe ich in einem Post vor einiger Zeit geschrieben, und bekomme nun eine kleine Bestätigung von jemandem, der mehr Erfahrung hat. Koz vom Rails Core Team schreibt auf therailsway.com:

"While the refactored version may have more lines of code, but don’t let that scare you. It’s far more important for code to be human readable than incredibly concise."

Genau meine Meinung! Ob ich mich selber immer daran halte steht auf einem anderen Blatt... ;-) Ich finde in dem kurzen Post ist ein sehr schönes Beispiel angegeben. Solchen Code mag ich.

Der Link: http://www.therailsway.com/2007/10/4/many-skinny-methods

Da auch die Suche der innoq-Webseite neu gecoded werden muss, habe ich mich da auch nach einer Lösung umgesehen und bin auf das Plugin acts_as_ferret gestoßen.

Auch zu diesem Plugin gab's ein Tutorial von railsenvy.com. Und zwar hier: http://www.railsenvy.com/2007/2/19/acts-as-ferret-tutorial

Und es ist in der Tat so einfach, wie es in diesem Tutorial beschrieben ist. Coole Sache.

Es gibt ein erstes Preview-Release von Rails 2.0!

Um dieses zu Installieren gibt es folgende Möglichkeiten:

gem install rails --source http://gems.rubyonrails.org

Oder, um es nur in einem Rails-Projekt auszuprobieren:

rake rails:freeze:edge TAG=rel_2-0-0_PR

In dem Post erläutert DHH einige neue Features von Rails 2.0. Sicherlich lesenswert: http://weblog.rubyonrails.com/2007/9/30/rails-2-0-0-preview-release

Grab it:

;-)