Da mir unter OS X noch ein guter grafischer SVN-Client fehlt bin ich momentan viel auf der Kommado-Zeile unterwegs. Drei Tipps, die das Leben einfacher machen:
Subversion benutzt zwar intern überall Unicode, aber wenn man es aus dem Terminal aufruft kann es zu Problemen mit Umlauten in Commit-Messages kommen. Einfach folgendes in die .profile schreiben:
alias svn='env LC_CTYPE=de_DE.UTF-8 /usr/local/bin/svn'
damit ist nur Subversion auf UTF-8 umgestellt, macht man das nämlich global gibt es überall unschöne Effekte im Terminal.
Auch wenn mir das CLI grundsätzlich nichts ausmacht, eine grafische Visualisierung der Diffs ist mir schon lieber. Apple liefert mit den DeveloperTools das ganz brauchbare FileMerge mit, das sehr schön die Unterschiede von zwei Revisionen einer Datei anzeigen kann (die Merge-Funktionalität geht glaube ich in Subversion nicht mit externen Tools ). Man muss einen kleinen Wrapper schreiben um es über Subversion benutzen zu können:
#!/bin/sh exec /usr/bin/opendiff $6 $7
Einfach als diff.sh irgendwo ablegen, ausführbar machen und dann in ~/.subversion/config als diff-cmd eintragen. Wenn man als Editor die Kommandozeilen-Tools von SubEthaEdit, Textmate oder BBEdit einträgt kann man auch die Commit-Messages bequem über einen grafischen Editor eingeben.
Und falls man mal eine falsche Commit-Message angegeben hat, kann man die auch nachträglich ändern. Dafür muss man im Repository-Verzeichnis das hooks/pre-revprop-change Template umbenennen und ausführbar machen. Danach kann man mit:
svn propedit --revprop -rSOME_REVISION_NUMBER svn:log
die Log-Message ändern.
Es muss cool sein für Amazon zu arbeiten, wenn man sieht was die für Konferenzen für ihre Entwickler orgranieren. Großartiges Lineup von Joel Spolsky, George Dyson und Rael Dornfest bis Guido van Rossum und vielen mehr.
Erstaunlich umfangreiche Mitschriften gibts im Amazon Web Services Blog, noch schöner wären natürlich MP3s, aber dann hätte es ja fast keinen Reiz mehr bei Amazon zu arbeiten.
Da ich gerade ein Bestellformular basteln muss, hab ich mich mal nach dem ultimativen Formmailer umgesehen. Eigentlich ja ein sehr simples Script, aber ich wollte PHP, sicher (Empfänger-Adresse nicht als Post-Variable) und gutes Templating. Also keine 5 Seiten ans eigene Design anpassen nur um ‘Vielen Dank für ihre Bestellung’ und Fehlerseiten zu bekommen.
Nachdem ich in den Myriaden von grottigen PHP-Scripts der Script-Archive die Nadel im Heuhaufen nicht gefunden habe und relativ schnell auf das HTML_Quickform-Package von PEAR aufmerksam geworden bin, habe ich meinen Formmailer halt selbst gebastelt.
HTML_Quickform ist eigentlich kein Formmailer sondern ein Sammlung von Klassen um Formulare zu generieren. Also mit
$form->addElement('text', 'email', 'E-Mail: ');
bekommt man ein Input-Feld für die Email. Viel genialer sind allerdings die Rules. Mit denen kann man angeben, ob ein Feld required ist, eine bestimmte Länge hat, eine Regex matcht oder eine eine gültige Email-Adresse ist:
$form->addRule('email', 'Bitte eine gültige Email-Adresse angeben',
'email', '', 'client');
Damit bekommt man Formular-Validierung quasi geschenkt und hat keine Ausrede mehr :) Die Validierung geschieht wahlweise per Javascript oder Serverseitig.
Das ganze Package ist sehr gut konfigurierbar, ich musste nie den Source-Code anpassen und habe alles realisieren können was ich wollte. Man kann auch Smarty als Template-Engine benutzen, was in meinem Fall aber etwas Overkill wäre. Da die Standard-Ausgabe des Formulars Tabellen benutzt (kann ich mit leben) hat man hier aber einen guten Einstiegspunkt.
Um jetzt wieder zum Formmailer zurückzukommen um den es ja eigentlich ging — schließlich habe ich bisher nur ein Formular: Die Formular-Daten sind bei erfolgreicher Validierung mit einer process-Prozedur verarbeitbar und mithilfe des Mail-Packages von PEAR hab sogar ich es geschaft, die Daten per Mail zu verschicken. Die Daten in eine Datenbank zu schreiben wäre aber genau so gut möglich.
Alles in Allem eine sehr gute Entscheidung. Ich muss mich nie mehr nach Formmailern umsehen, mein Formular wird sogar validiert und alles wird in einer einzigen PHP-Datei gemacht, d.h. ich kann alles inline anzeigen und muss nicht mehrere Dateien ans Design anpassen.
Es gibt zwei sehr gute Tutorials, die einem den Einstieg erleichtern:
Die Dokumentation ist sehr umfangreich und eine Präsentation des Autors gibt weitere Einblicke.
Unter OS X Subversion für die lokale Nutzung zu installieren, d.h. ohne Apache/WebDAV-Unterstützung ist eigentlich ganz einfach, wenn man weiß wie es geht :)
1. Subversion
Man nehme das von Martin Ott freundlicherweise zusammengestellte Package und installiere es. Zack, schon hat man Subversion installiert, das war einfach :)
2. Repository einrichten
Um seine Projekte zu verwalten muss man erstmal ein Repository einrichten, in dem alles gespeichert wird. Ich hab meins in den Library-Ordner gepackt, wo ist aber eigentlich egal. Dazu öffne man ein Terminal:
svnadmin create ~/Library/Subversion
3. Projekt importieren
Für die lokale Arbeit reicht ein einziges Repository locker aus, deswegen jetzt die Projekte einfach als Unterordner importieren
svn import MyProject file:///Users/flo/Library/Subversion/MyProject --message="initial import"
(eine Zeile) wobei MyProject der Ordner ist in dem das Projekt liegt. Den Pfad zum Repository sollte man natürlich anpassen. Wichtig ist das zusätzliche MyProject im Repository-Pfad, sonst wird kein Unterverzeichnis für das Projekt erstellt.
4. Working Copy
Wir haben das Projekt bis jetzt nur “eingecheckt”, um damit arbeiten zu können muss es erst wieder “ausgecheckt” werden. Dazu einfach einen neuen Ordner erstellen und im Terminal in dem Ordner
svn checkout file:///Users/flo/Library/Subversion/MyProject/ .
Der Punkt am Ende sorgt dafür, dass die Dateien in den aktuellen Ordner kommen. Wenn man ihn weglässt wird einfach ein Unterordner MyProject erstellt, in dem dann die Dateien sind.
5. Los gehts
In dem ausgecheckten Verzeichnis kann man jetzt arbeiten und die Änderungen per Commit wieder ins Repository spielen. Mehr Informationen gibts im Handbuch. Wer keine Lust auf die Kommandozeile hat benutzt einfach:
6. SvnX
Etwas komfortabler, vorallem wenn man sich ältere Versionen anschauen möchte und nicht für jedes Commit ins Terminal wechseln will, ist SvnX,, ein Cocoa-Programm für Subversion.
Nach der Installation richtet man einfach ein Repository mit dem Pfad ein und erstellt einen Eintrag im Working-Copies-Fenster für den Ordner den wir gerade ausgecheckt haben. Mit einem Doppelklick auf den Repository-Eintrag kann man sich die Versionen und Logs anschauen, ein Doppelklick auf die Working Copy erzeugt ein Fenster für Updates und Commits. Funktioniert ganz ordentlich.
Zusätzliche Links:
Schöner Artikel von Russell Beattie und seine Beziehung zu Perl: Dr. Scriptlove (Or How I Learned to Stop Worrying and Love Perl)
Auch wenn ich noch nie richtig versucht habe Perl zu erlernen ist es einfach eine Sprache die ich nicht anfassen will, nicht mein Stil könnte man sagen. Genauso wie ich festgestellt habe das mein Gehirn nicht ohne weiteres rekursive Lösungen produzieren kann (was mich auch von funktionalen Sprachen fernhält *g*), schreckt mich Perl ab.
Trotzdem habe ich ne Menge Respekt vor der Sprache. (Der Titel dieses Eintrages ist deshalb etwas irreführend, denn ich bin absolut kein Flamewar-Typ und solche Disussionen sind mir sehr zu wider).
Der Kommentar von Douglas trifft es denke ich am besten:
One of the things that you will eventually grasp about Perl is the conciseness of the syntax and how that sparseness is reused over and over again. This forces one to really, really fully grok each and every syntactic construct. I find this that most difficult but ultimately rewarding things about Perl. Not much there but what is there is immensely powerful.
Jetzt habe ich endlich rausgefunden warum in WordPress Vergleiche so merkwürdig programmiert werden:
if ('jazz' == $music)
Damit gibts nen Parse-Error in PHP wenn man mal ein Gleichheitszeichen vergisst anstatt der sonstigen unbemerkten Ausführung des Statements.
Sieht aber trotzdem abartig aus.
Wirklicher guter und lesenswerter Artikel (und deshalb nicht nur in den Quicklinks, obwohl die natürlich auch alle gut und lesenswert sind *g*):
Jordan Hubbard, FreeBSD Co-Founder, ehemaliges Core Team Mitglied und jetzt bei Apple verantwortlich für die UNIX personality von Mac OS X, schreibt über den Einsatz von von OpenSource Software: Open Source to the Core
Open source is not just a way of getting free code; it is both a social order and an entire engineering discipline in its own right, with informal “rules of the road” that must be respected if you are to be at all successful there.
Mit kompetener Zusammenfassung über Lizenzen und was es sonst noch zu beachten gilt vor und nachdem man OpenSource in eigenen Produkten verwendet:
Engineers can be surprisingly averse to adopting comparatively finished products rather than developing their own from scratch, even when the latter option constitutes significantly more work
Gerade vor dem Hintergrund, Apple würde von der OS Community nur nehmen und nichts zurückgeben (was so nicht richtig ist) sehr interessant.
Juchu, jetzt kanns ja los gehen. Habe mit dem Lernen von Cocoa und dem Schreiben eines absoluten Killer-Apps nur auf dieses Buch gewartet: Cocoa Programming for Mac OS X. Genauer gesagt habe ich auf die überarbeitete Second Edition dieses Standard-Buches für alle Cocoa-Programmierer gewartet. Jetzt ist es endlich da, mit aktualisierten APIs, XCode und Panther-Screenshots.
Wie gesagt, jetzt kanns losgehen … moment, ich exmatrikuliere mich nur mal schnell ;-)
Verdammt, beschäftige dich niemals mit Python wenn du danach wieder Java machen musst!
Dieses ganze rumgecaste um nen Container für verschiedene Objekte zu benutzen nervt ja dermaßen. Die neue Java Version mit verbesserten Generics (die vermutlich gar keine sind) ist noch nicht da und ich bin mir jetzt sicher, Latent Typing is the way to go
This eventually meandered (alcohol was involved) into a much larger topic: What the hell is going on with independent development & the Mac?
Jemineh, ein extrem längliches und verworrenes Pamphlet über die Apple und die Developer oder so ähnlich. Habs zwar durchgelesen, aber so richtig schlau bin ich ich nicht geworden was denn eigentlich die Hauptaussage sein soll.
Ganz interessant fand ich die geschichtliche Abhandlung über Apple und die Verbindung zu den Developern, die wohl nie sonderlich gut gewesen ist. Soll sich aber, das ist auch mein Eindruck, aktuell verbessert haben.
Es geht auch um das Henne-Ei Problem: Zu wenig Market-Share -> zu wenige Developer mit Killer-Apps -> noch weniger Marketshare (oder so ähnlich *g*).
Was ich spannend am Mac finde, ist das es trotz des relativ kleinen Nutzerkreises unglaublich viele kreative und innovative Software für den Mac gibt. Man muss sich nur mal so was wie NoteBook und NoteTaker angucken, es gibt nichts vergleichbares für den PC. Oder Launchbar und Konsorten. Ich kann noch nichtmal einen vernünftigen Outliner, vergleichbar mit OmniOutliner, finden.
Eine interessantes Statement aber: Obwohl Cocoa von Apple als Rapid Application Devlopment Framework gehypt wird, ist Apple fast die einzige Firma, die größere Programme in Cocoa auf dem Markt hat.
Außerdem ist mir mal wieder bewusst geworden, dass es gefährlich ist nur in der Blogosphäre zu leben. Denn da bekommt man ja den Eindruck alle switchen zum Mac und kaufen sich ein Power- oder iBook. Über die Realität hab ich nicht den kompletten Überblick, trotzdem denke ich dass die Gedanken zu Apples Marketshare in dem Pamphlet eher plain wrong sind ;-)