Nachtrag: Vorbereitungen für OS X 10.5 Leopard

Am vergangenen Freitag wurde endlich der Leopard aus seinem Käfig gelassen und fand (laut eigener Aussage von Apple) bereits am ersten Verkaufswochenende bei über 2 Mio. Usern Anklang. Das Upgrade verlief, abgesehen von einigen Problemen mit dem Application Enhancer, vielerorts problemlos und auch die Fachpresse ist sich einig, dass Leopard ein würdiger Nachfolger von Tiger ist.

Neben der aufpolierten Oberfläche und Applikationen wie Time Machine, Spaces und Co. hat sich einiges interessantes und für uns relevantes unter der Haube getan. So spendiert Apple seinen Usern ab OS X 10.5 einen Apache2 (2.2.6), der uns den Umgang mit PHP5 wesentlich vereinfacht. Um das PHP5-Modul zu laden, entfernen wir in der httpd.conf (die mittlerweile in /etc/apache2 zu finden ist) an entsprechender Stelle das Kommentarzeichen

LoadModule php5_module libexec/apache2/libphp5.so

und restarten den Apache wie gehabt über die Kommandozeile

sudo apachectl restart

Sollte man sich für diesen Weg entscheiden, ist allerdings noch ein weiterer Schritt nötig. Bei der Benutzung einer MySQL-Datenbank wird Symfony früher oder später anmeckern, dass es über /var/mysql/mysql.sock keine Verbindung zur Datenbank aufnehmen kann. Dies liegt daran, dass mysql.sock nicht in /var/mysql, sondern in /tmp abgelegt wird. Am einfachsten behebt man dieses Problem mit einem entsprechenden Softlink:

sudo mkdir /var/mysql
sudo ln -s /tmp/mysql.sock /var/mysql/mysql.sock

Damit ist auch Apples jüngste Raubkatze fit für Symfony ;)

Vorbereitungen II - Versionskontrolle mit Subversion

Im Gegensatz zum letzten Teil, könnt ihr diesen Part als optional ansehen. Es ist nicht wirklich nötig für Symfony ein Software-Repository anzulegen, aber wenn ihr - wie ich - zu den Leuten gehört, die gerne mal simultan auf zwei verschiedenen Maschinen entwickeln (z.B. auf dem iMac zu Hause und auf dem MacBook von unterwegs), dann führt eigentlich kein Weg daran vorbei; genauso wenn Ihr in einem Team von mehreren Personen zusammen an einer Applikation schreibt.
Hierbei werden wir auf das OpenSource Projekt Subversion zurückgreifen, ein System zur Versionskontrolle, das von vielen als inoffizieller CVS-Nachfolger angesehen wird, das viele jener Schwächen behebt, mit denen das alte, in Entwicklerkreisen aber sehr beliebte CVS immer noch behaftet ist.

Repositories anlegen und der "Initial Import"

Da wir uns nicht lange mit (langweiligen) lokalen Software-Repositories aufhalten wollen, werden wir in diesem Artikel speziell den Gebrauch von Subversion über den Apache behandeln. Dies hat den Vorteil, dass wir quasi von überall auf unser Repository zurückgreifen können, sofern wir über eine Verbindung zum Internet verfügen.
Benutzer von OS X Leopard dürfen sich übrigens freuen - neben einer Apache2 Installation findet sich übrigens auch Subversion (Version 1.4.4) in den Developer-Tools wieder. Anders als bei Tiger müssen wir also keine zusätzliche Software installieren. Falls Ihr bisher noch nicht auf Leopard geupdatet habt, gibt es diverse Möglichkeiten, Subversion auf Eurem Mac einzurichten. Neben einigen OOTB-Lösungen, beschreibt ein äußert guter und lesenswerter Blog-Artikel auf www.yauh.de den Weg über MacPorts.

Was wir allerdings noch nachträglich machen müssen ist einerseits, die folgende Zeile in der httpd.conf zu suchen

LoadModule dav_module libexec/apache2/mod_dav.so

und darunter die Zeile

LoadModule dav_svn_module libexec/apache2/mod_dav_svn.so

anzufügen. Damit die Änderungen aktiv werden, müssen wir (nach dem Speichern) natürlich noch den Apache neustarten.

Um nun endlich mit unserer Softwareverwaltung loslegen zu können, benötigen wir zunächst mal ein Repository. Dazu erstellen wir ein Verzeichnis repos, bevorzugterweise in einem Bereich, der nicht direkt vom Apache angesprochen werden kann (z.B. in /usr/local). Mittels des Befehls svnadmin verwandeln wir nun das Verzeichnis in ein waschechtes Software-Repository, das unter Versionskontrolle steht. Wollen wir in unserem Repository mehrere Projekte verwalten, macht es Sinn zusätzliche Unterverzeichnisse zu erzeugen. In unserem Beispiel werden wir unser erstes Projekt in prj verwalten.

sudo svnadmin create /usr/local/repos/prj

Anschließend werden wir das Repository mit Daten befüllen. In einem Verzeichnis unserer Wahl (z.B. ~/Documents) erstellen wir einen Ordner prj und mit den Unterodnern trunk, branches und tags:

> cd ~/Documents
> mkdir prj
> cd prj
> mkdir trunk branches tags

Diese Unterorder-Struktur ist übrigens nicht zwingend, allerdings ist sie gängige Subversion-Konvention. Mit dem "warum, weshalb und wofür" werden wir uns zu einem späteren Zeitpunkt auseinandersetzen. Für den Moment müsst Ihr mir einfach vertrauen, dass diese Struktur im Umgang mit Subversion definitiv Sinn macht ;)
Die zu verwaltenen Files kopiert ihr anschließend in den trunk-Ordner. Zu Testzwecken werden wir ein einfaches Script namens helloworld.php unter Versionskontrolle stellen

// helloworld.php

<?php

echo "Hello, World!";

?>

Der erste Import geschieht über den Befehl

sudo svn import -m "Initial Import" /Users/stylez/Documents/prj file:///usr/local/repos/prj

Adding /Users/stylez/Documents/prj/trunk
Adding /Users/stylez/Documents/prj/trunk/helloworld.php
Adding /Users/stylez/Documents/prj/branches
Adding /Users/stylez/Documents/prj/tags

Committed revision 1.

Der Parameter -m gibt dabei eine Nachricht (Message) an, die als Vermerk / Notiz im Repository gespeichert wird.

Da unser Apache ja nun Hand in Hand mit unserer Subversion-Versionsverwaltung arbeitet, können wir nun über einen beliebigen Webbrowser mal einen Blick auf unser Repository werfen. Vorher müssen wir allerdings nochmal an die httpd.conf ran, um (mindestens) folgende Direktive hinzuzufügen:

<Location>
DAV svn
SVNPath /usr/local/repos/prj
AuthType Basic
</Location>

Damit ist unser Repository dann unter http://127.0.0.1/svn erreichbar.
Die URI svn ist nicht unbedingt optimal gewählt, wenn man im Hinterkopf behält, dass man in /usr/local/repos mehr Projekte als nur prj verwalten will, aber für den Moment soll uns das nicht weiter stören.
Natürlich können wir unser Repository auch über ein Passwort schützen bzw. es nur für ausgewählt Benutzer zugängig machen. Um dieses Posting allerdings nicht noch weiter in die Länge zu ziehen, verweise ich an dieser Stelle ein zweites Mal auf den entsprechenden Eintrag auf www.yauh.de ;)

Tools und grafische Frontends

Neben der festen Integration in Apples Xcode-Tools, existieren noch diverse andere Frontends und Plugins, um die Arbeit mit Subversion zu erleichtern. Hervorzuheben sind dabei die freie Software svnX, mit der sich auch viele unterschiedliche Repositories gleichzeitig verwalten lassen und die mit einer ansprechenden grafischen Oberfläche aufwartet. Wer es lieber etwas pragmatischer mag, der sollte mal einen Blick auf das SCPlugin werfen. Mit Hilfe dieser kleinen, aber feinen Erweiterung für den Finder ist es möglich SVN-Aktionen über das Kontext-Menü auszuführen. Benutzer der Windows-Software Tortoise werden sich dabei sofort heimisch fühlen.

Vorbereitungen I - PHP5 und MySQL

Bevor wir uns in die Arbeit mit Symfony stürzen können, müssen wir zunächst einige Änderungen an unserem frischen System vornehmen. Zu allererst müssen wir die Apple Developer-Tools installieren (Installations-DVD #1), damit uns solche Tools wie gcc, make etc. über die Kommandozeile zur Verfügung stehen. Für unsere zukünftigen Sessions empfiehlt es sich übrigens das Terminal aus den Dienstprogrammen (cmd+shift+U) ins Dock zu befördern, - wir werden es nämlich noch ziemlich oft brauchen ;)

MacPorts - OpenSource auf dem Mac

Nach der Installation der Developer-Tools benötigen wir die aktuelle Version von MacPorts. MacPorts (ehemals DarwinPorts) ist ein OpenSource Paketmanager, der uns bei der Installation von zukünftigen *nix Tools zur Hand gehen soll. Anders als bei vergleichbaren Paketmanagern wie z.B. apt-get (Debian) oder fink (OS X) sind Ports keine vorkompilierten Binärpakete, sondern eher Makefiles, die Softwarepakete (als Sourcecode) autmatisch aus dem Netz herunterladen, entpacken, patchen, kompilieren, installieren und sich sogar automatisch um eventuelle nicht erfüllte Abhängigkeiten kümmern.

Da sämtliche Software wie gesagt noch komplett kompiliert werden muss, sollte man sich darüber im Klaren sein, dass dieser Vorgang je nach Applikation eine ziemlich lange Zeit in Anspruch nehmen kann. Ein schneller Prozessor ist dabei sicherlich nicht von Nachteil ;) Der Lohn unserer Mühen ist, dass unsere fertige Software anschließend perfekt auf unser System abgestimmt ist. Sämtliche Binaries werden übrigens in /opt/local/bin installiert. Dies hat den Vorteil, dass man so nicht in Konflikt mit der übrigen OS X Software gerät. Aus Gründen der Bequemlichkeit sollte man also am besten die .bash_profile innerhalb des eigenen Home-Verzeichnisses um folgende Zeilen erweitern:

PATH=$PATH:/opt/local/bin
export $PATH

MacPorts in allen Einzelheiten zu besprechen würde definitiv den Rahmen dieses Blogs sprengen. Deswegen verweise ich an dieser Stelle mal auf das wirklich gute Wiki der MacPorts Homepage.

PHP5 und MySQL

Die momentan (September 2007) noch aktuelle OS X Version (Tiger) wird standardmäßig mit einem Apache Webserver Version 1.3 und PHP 4 ausgeliefert. Hier stoßen wir bereits auf unser erstes Problem, denn für den Einsatz von Symfony benötigen wir mindestens PHP 5.x. Natürlich könnten wir uns die aktuelle PHP-Version von der PHP-Homepage herunterladen und kompilieren bzw. alternativ den Weg über MacPorts wählen. Allerdings ist dieser Weg nicht unbedingt der bequemste. Glücklicherweise bietet uns Marc Liyanage von www.entropy.ch ein vorkompiliertes PHP-Binärpaket mit OS X Installer und allen nötigen und nützlichen Erweiterungen.

Die Überprüfung, ob bei der Installation alles nach Wunsch verlaufen ist, erfolgt einerseits über die Kommandozeile (Terminal):

> php -v
PHP 5.2.4 (cli) (built: Aug 31 2007 23:40:28)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies

und andererseits über den Aufruf von <? phpinfo(); ?> innerhalb eines PHP-Scriptes über den Apache-Webserver. Speichert das Script (z.B. als test.php) in ~/Sites und ruft es im Browser über

http://localhost/~<username>/test.php

auf, wobei <username> natürlich durch Euren Username ersetzt werden muss. Solltet Ihr keine Verbindung zum Server herstellen können, wurde der Apache wahrscheinlich noch nicht gestartet. Aktiviert ihn in Systemeinstellungen -> Sharing -> Personal Web Sharing

Die aktuelle MySQL Version erhält man von der MySQL Homepage (ebenfalls als Binärpaket).

MAMP, not least

Als All-in-One Lösung für den vorsichtigen User wäre vielleicht noch MAMP-Paket zu erwähnen, welches gleich mit einer kompletten Apache-, MySQL- und PHP-Umgebung aufwartet, die sich bei Bedarf und ohne große Probleme wieder aus dem System entfernen lässt. Ich selbst habe MAMP noch nicht getestet, aber das, was ich ich so an Feedback zurückbekommen hab, war durch die Bank ziemlich positiv.

Eine Abrechnung mit Vorurteilen

Ein Developer-Blog, das sich um das PHP-Webframework "Symfony" dreht und als Entwicklerplattform auch noch auf OS X setzt. Himmel hilf, ausgerechnet PHP, die schlimmste "Programmiersprache" der Welt, die so buggy und inkonsistent programmiert wurde, dass "echten IT-Profis" das Mittagessen hochkommt, sobald sie nur den Namen hören. Und dann auch noch Apples "Klickibunti" Betriebssystem - was soll das? Wer benutzt denn schon einen Mac, höchstens doch nur Yuppies, Pixelschieber und sonstige Jünger des heiligen Steve Jobs. - ich denke, diese oder ähnliche Vorurteile haben wir alle schon mal gehört oder alternativ auch selbst in die Welt gesetzt.

PHP - Eine Sprache wirklich so schlimm wie ihr Ruf..?

Versuchen wir uns doch mal wirklich kritisch mit den o.g. Vorurteilen auseinanderzusetzen. Beginnen wir bei PHP. Entwickelt Mitte der 90er Jahre hat sich PHP bis heute den Ruf als die "beliebteste" bzw. die am häufigsten verwendete Scriptsprache erarbeitet. Die Vorteile liegen auf der Hand: PHP ist leicht zu erlernen und wird auf allen Webservern standardmäßig unterstützt. Binnen weniger Minuten kann man sein erstes PHP-Script schreiben und auf seinem Webspace deployen. Zusätzlich bietet PHP hunderte Bibliotheken z.B. für Datenbankanbindung, XML-Support und sogar Grafik-Generierung.

Jene genannten Vorteile sind gleichzeitig allerdings auch die größten Nachteile von PHP. Dadurch, dass PHP so einfach zu erlernen und benutzen ist, schicken sich viele "Feierabend-Programmierer" an, ihre halbgaren PHP-Projekte im WWW zu veröffentlichen, die teilweise so schlampig programmiert sind, dass man Internet-User davor schützen müsste ihre teilweise sensiblen Daten solchen Seiten anzuvertrauen. Schade nur, dass die Schuld in diesen Fällen meist auf die Programmiersprache geschoben wird und ein PBCAK-Fehler ("Problem Between Chair And Keyboard") nur äußerst selten in Betracht gezogen wird.

Symfony - An Open-Source PHP Web Framework

Nicht zu leugnen ist allerdings, dass PHP schnell gewachsen ist, - vielleicht schon etwas zu schnell. In den Programmbibliotheken finden oftmals mehrere unterschiedlich benannte Funktionen für ein und dasselbe Problem und viele zusammenhängende Funktionen sind verwirrenderweise oft unterschiedlich benannt. Hinzu kommt die objektorientierte Programmierung, die zwar grundlegend seit PHP Version 3 unterstütz wird, obwohl der größte Teil der PHP-Standardbibliothek immer noch prozedural angelegt ist.

An genau diesem Punkt kommt das Webframework Symfony ins Spiel. Symfony wurde von den beiden Franzosen Fabien Potencier und François Zaninotto im Jahr 2005 entwickelt und entstand als Fork von Mojavi3-DEV, einer PHP-Implementierug des MVC-Paradigmas. Symfony kann als der "kleine" PHP-Bruder des beliebten Ruby On Rails Frameworks angesehen werden, da es mit Templates, Routing und Helpers ein ähnliches Konzept untersützt. Als handfestes objektorientiertes MVC-Framework "zwingt" Symfony den geneigten Entwickler in eine relativ strikte Programmierkonvention, - nämlich jene der sauberen Trennung von Darstellung und Code. Durch diese modulare Trennung entsteht "sauberer" Code und das Gesamtprojekt wird wesentlich flexibler und wartbarer.
Diese und viele weiteren Symfony-Features werden wir hier auf diesem Blog zu späterer Zeit noch wesentlich detaillierter durchleuchten.

Aber wieso ausgerechnet OS X als Entwicklerplattform..?

Okay, zugegebenermaßen gehören Macs seit Jahrzehnten zum Standard der Multimedia-Branche, aber sind diese Dinger denn auch für Entwickler interessant? Die Antwort darauf ist ein laut und deutliches "Ja". Viele Leute verkennen, dass unter all den glänzenden Fenstern und Oberflächen ein waschechtes Unix-System schlummert: Der OS X Kern mit dem Namen "Darwin" ist ein OpenSource Unix-Betriebssystem auf der Basis von FreeBSD bzw. 4.4BSD. Dem durchschnittlichen Apple-Benutzer bleibt Darwin allerdings verborgen.



Man kann OS X allerdings auch - wenn man denn will - auf die Vorteile des Darwin-Kerns zurückgreifen: Mit dem Terminal (zu finden in den "Dienstprogrammen") können professionelle Benutzer ebenfalls über eine Kommandozeile in das System eingreifen und auf Wunsch liefert Apple (in seinem Xcode-Package) sämtliche Development-Tools eines *nix Systems (gcc, make etc.) und sogar eine eigene X11-Implementierung. Tools und Applikationen wie z.B. openssh, rsync oder ein Apache-Webserver sind sogar schon per default vorhanden.
Wie man sieht, hat man also eine vollwertige Unix-Umgebung ohne auf den (liebgewonnenen) Apple-Komfort und das hervorragende Multimediasystem verzichten zu müssen.