Versions ist ein grafischer SVN-Client für MacOS X. Eigentlich recht gut, aber wird seit längerem nicht mehr so recht weiterentwickelt. Es gibt so einige DInge, die man mit so einer GUI einfach und intelligenter machen könnte – z.B. Cherry-Picks oder Branch-Merge.
Ich hatte mir vor ca. 2 Jahren auch einmal “Cornerstone” angesehen – sehr gross, sehr ausführlich, sehr unübersichtlich. Das hat sich ggf. auch geändert, aber inzwischen nutze ich die Kombo aus Versions und der Commandline.

Versions wurde jetzt von der Firma SOFA aus Amsterdam übernommen – die waren wohl vorher schon am Projekt beteiligt. Das lässt hoffen.

Eine erste positive Sache gibt es bereits:

You can now use your Versions license key to get a €10 discount on Kaleidoscope! http://www.kaleidoscopeapp.com/buy
(via Twitter)

Das Merge-Tool von Apple ist nicht verkehrt, aber ich verwende seit längerem “DiffMerge” (kostenlos).
Kaleidoscope ist aber schlicht genial – war mir bislang aber im Verhältnis zu teuer. Mit dem 10€-Nachlass, ist es das aber wert (nicht das es das vorher nicht auch schon gewesen wäre, aber ich brauche DIFF-Tools eigentlich nur selten).

Achja: DiffMerge wird nicht verbannt. Die Möglichkeit Ordner zu vergleichen werde ich weiterhin benötigen. Wer es “krasser” braucht, dem sei Araxis Merge empfohlen – für Windows und MacOS X. Kostet aber auch entsprechend und kann Dinge, die ich bei anderen Tools noch nicht gesehen habe (vor allem beim Vergleichen von XML-Files).

BBEdit

Mein Gefühl sagt mir, das es zum Ende des Jahres eine Version 10 geben wird – geben muss.
Ich suche nach wie vor einen Editor, der ein so geniales autocomplete und autoformat besitzt wie das Visual Studio von Microsoft für .NET und Co.
Es gibt nichts vergleichbares für MacOS X  – oder für Linux. Zumindest nichts vergleichbares, bei dem die Unterstützung mindestens PHP, HTML und CSS enthält. Optimal wären dann noch Javascript (inkl. bekannter frameworks wie jQuery), Perl, AS3 und XML.
BBEdit ist beim autocomplete nicht so wirklich toll. Aber ansonsten ein genialer Editor – und ich bin ihn natürlich auch schon sehr, sehr lange gewöhnt.

Zu meinen Untersuchungs-Kandidaten gehören u.a.:

1. Espresso: die Version 1.1.2 ist zwar vielversprechend, aber nicht ausreichend; wenn man sich CSSEdit ansieht, dann ist das genau der Ansatz den ich mir vorstelle…
2. Komodo-IDE: mein letzter Check war die Version 5.2.4 – jetzt gibt es Version 6. Werde ich bei Gelegenheit prüfen. Version 5 war jedenfalls auf meinem MacBook ein bisschen träge (ich hatte mir Komodo-Edit, den kleinen Bruder, näher angesehen und der war schon ziemlich unerträglich träge).

Weitere Programme stehen zwar auch noch auf meiner Liste, fallen aber bislang ganz raus, weil sie entweder nur für HTML funktionieren, oder eben kein gutes autocomplete bieten:

• SEEdit: für PHP ungeeignet – es gibt aber eine deutlich neuere Version, die ich mir bei Gelegenheit ansehen werde
• Taco HTML Edit: nene, wenn man nichtmal das Encoding ordentlich verwalten kann…
• Zend Studio: es gibt jetzt eine beta der Version 8 – Version 7 ist zwar für PHP gut, aber für den Rest unbrauchbar
• Textmate: eigentlich genial, aber es fehlt zuviel – Version 2 könnte das richten, aber bis die kommen wird…
• SubEthaEdit: Cool wg. der Möglichkeit mit gleichzeitig mit mehreren Personen an einem File zu arbeiten, aber
• HyperEdit: schon nicht schlecht, aber wird wohl nicht mehr so aktiv weiter entwickelt und ist einfach nicht ausreichend genug.
• skEdit: hat Zusatzmodule, aber ist insgesamt nicht zufrieden stellend.

Hat jemand weitere Vorschläge?
Wenn BareBones mit BBEdit nicht bald (im nächsten Jahr) in die Gänge kommt, dann würde ich auch auf ein andere OS wechseln…

Seit der beta2 wurden keine funktionalen Bestandteile mehr verändert. Lediglich die Dokumentation (vor allem zum Upgrade von einer vorhergehenden Version) wurde deutlich erweitert bzw. verbessert.

Nachdem ich das Ticketsystem mehr oder weniger 3 Jahre lang gar nicht angeschaut habe, war in den letzten eineinhalb Monaten richtig viel los. Das Upgrade war auch lange überfällig und betrifft vor allem den eMail-Parser und den eMail-Versand.
Die Migration auf UTF-8 war hier ein wichtiger Schritt um die nächsten Versionen “etwas freier” von Ballast gestalten zu können. Wir haben auch bereits mit den Planungen der V2 begonnen – eine Fertigstellung ist natürlich noch nicht absehbar (2011 klingt jedenfalls ganz gut). Hier wird der Schwerpunkt auf ein vollkommen neues Interface gelegt (einfacher, übersichtlicher und natürlich viel besseres HTML).

Ein paar Funktionen und Optimierungen werden wir in der V1.7 sicher noch in diesem Jahr unterbringen. Dem Download liegt auch eine entsprechende FEATURE_REQUESTS.txt bei, die den aktuellen Planungsstand widerspiegelt.

Es wird auch weiterhin auf Bibliotheken Dritter gesetzt – und diesmal auch beim Mailversand:

• mimeDecode aus dem PEAR-Projekt
• PHPMailer Version 5.1 (in einer gepatchten Version)
• HTML Purifier zur Darstellung von HTML-eMails

Des weiteren gelten folgende Systemvoraussetzungen:

• lokaler MTA (z.B. postfix)
• Apache2 mit mod_rewrite und idealerweise mit SSL-Support
• PHP5
• MySQL 5.x.x
• Commandlinetools: zip, unzip, tar, gzip, mysqldump, find, ls, rm, pstotext, antiword

Download der aktuellen Version unter https://www.deam.org/tree/

Im Dezember letzten Jahres habe ich dann mal einen Feature-Request-Aufruf gestartet, der einiges an Bedarf angezeigt hat.

Nachdem ich jetzt auch noch ein paar Bugmeldungen bekommen habe (vor allem was Mailversand, Maildarstellung und Download-Permissions angeht), habe ich mich jetzt mal aufgerafft und hart an der neuen Version gearbeitet.
Bitte nicht falsch verstehen: Das was wir gerade Testen ist nur eine kleine Erweiterung um die aktuelle Funktionstüchtigkeit “am Leben” zu erhalten. Es ist noch nicht die Art Überarbeitung die mir wirklich vorschwebt. D.h. es gibt praktisch keine neuen Funktionen, sondern lediglich zahlreiche Fehlerkorrekturen und Optimierungen.

Das schlimmste an der 1er-Version von treE ist der HTML-Aufbau – quasi noch aus der Steinzeit. Wenn man bedenkt, das ich die ersten Bestandteile schon 2000 geschrieben habe, ist es eigentlich ein Wundern, das es nur so schlecht aussieht ;)

Sofern die Tests erfolgreich verlaufen, sollte treE 1.7.0 noch vor dem 10. August erscheinen.

[update, 09.08.2010]

Die Aktualisierung auf Version 1.7.0 ist zwar weit gekommen, allerdings nicht weit genug um ein “echtes Release” daraus zu machen.
Vor allem die Upgrade-Prozedur von Version 1.5 ist noch nicht final getestet.
Daher habe ich mich jetzt entschlossen eine beta-Version herauszugeben und die Finalisierung dann im September nach meinem Urlaub anzugehen.

Die 1.7.0beta2 kann also heruntergeladen werden.
Rückmeldungen an kmb@deam.org sind herzlich willkommen.

Interessanter ist es einige andere Aspekte der Umsetzung zu beleuchten. Nur zur Erinnerung: wir sind noch nicht fertig und es gibt noch eine grosse Menge an Bestandteilen, die optimierungsbedürftig sind.
Ich werden über die nächsten Wochen in loser Folge über einige der “Frontend-Aspekte” schreiben. Vor allem auch über das “Warum” einzelner Entscheidungen.

Die Schwerpunkte bisher waren:

1. Ladezeit: Alles kombinieren und komprimieren.
2. Verteilung: Statische Bestandteile nicht via www.hausverbrauch.de, sondern via Amazon-S3
3. ein Markup: Die mobile Version unterscheidet sich im HTML-Markup nicht von der Desktop-Version
4. kein IE6: naja – eigentlich mehr nach dem Motto “CSS3 anstatt Workarounds“

Ladezeit

Die Startseite von https://www.hausverbrauch.de/ löst aktuell 6 Requests aus und hat knapp 120kb an Datenmenge zu transferieren.
Das ist zugegebenermassen noch immer zu viel. Das reine HTML in gepackter Form schlägt mit nur 2,4kb zu Buche und das Logo erreicht fast 16kb.

Der Löwenanteil ist das “combo.min.gz.js” mit fast 92kb.
Dieses Javascript-Bundle ist noch wenig optimiert. Es enthält diese Einzelpakete:

• jquery-1.4.2.min.js
• jquery.cookie-1.0.min.js
• jquery-ui-1.8.custom.min.js
• jquery.bgiframe-2.1.1.min.js
• jquery.passStrengthener-0.9.1.min.js
• jquery.tooltip-1.3.min.js
• jquery.scrollTo-1.4.0.min.js
• jquery.flot.min.js
• jquery.flot.selection.min.js
• functions.min.js

Den verhältnismässig größten Anteil übernimmt jQuery-UI. Wir verwenden nicht alle UI-Funktionen, dennoch ist das ganze Paket enthalten. Das wollen wir im Laufe der Beta-Phase noch korrigieren. Aktuell gehe ich davon aus, das wir für “combo.min.gz.js” im gepackten Zustand etwa 50kb erreichen können.

Ausserdem enthält “combo.min.gz.js” auch Scripte die in der mobilen Version nicht zum Tragen kommen. Hier werden wir noch überlegen inwieweit eine getrennte Auslieferung hier vielleicht noch Vorteile bringen kann.

Randbemerkung:
Es wird landläufig empfohlen Javascript-Files nicht im <head>, sondern am Ende des <body> zu platzieren, da ein JS-Download im <head> “blocking” ist. Das ist allerdings nicht ganz unproblematisch und bedeutet auch, das bestimmte Funktionen noch nicht nutzbar sind. Man muss hier im Grunde dann sehr stark mit DOM-Operationen arbeiten und das ist zumindest bei IE7 und IE8 nicht wirklich spassig (jedenfalls nicht, wenn man einen betagten WIndows-Rechner im Einsatz hat).

Zum Kombinieren und Komprimieren verwende ich ein einfaches Shell-Script. Hier ein beispielhafter Codeauszug:

#!/bin/bash
echo '** kombiniere alle js-files'
cat htdocs/static/libraries/jquery-1.4.2.min.js > htdocs/static/libraries/combo.min.js
cat htdocs/static/libraries/jquery.cookie-1.0.min.js >> htdocs/static/libraries/combo.min.js
cat htdocs/static/libraries/jquery-ui-1.8.custom.min.js >> htdocs/static/libraries/combo.min.js
cat htdocs/static/libraries/functions.min.js >> htdocs/static/libraries/combo.min.js

echo 'gzip-Version'
gzip -9 < htdocs/static/libraries/combo.min.js > htdocs/static/libraries/combo.min.gz.js

Die Dateiendung hat seinen Sinn:
Entweder hat man einen Apache mit mod_headers und kann dann eine solche Konfiguration einsetzen:

<FilesMatch "(.gz.js|.gz.css)$">
        Header add "Content-Encoding" "gzip"
</FilesMatch>

Oder man verwendet Amazon-S3 und setzt den “Content-Encoding”-Header beim Upload der Datei auf “gzip”.

Achja: Das Minify machen wir derzeit mit dem yuicompressor-2.4.2.jar. Das hat mehr oder weniger historische Gründe. Ich werde mir bei Gelegenheit noch Alternativen ansehen.

Da treE kein kommerzielles Projekt ist – jedenfalls nicht im Kern, können wir natürlich nicht so sehr viel Arbeit hineinstecken. Ausserdem sind wir gerade auch noch mit ganz anderen Projekten gut zugedeckt ;-)
Das Projekt ist aber alles andere als tot. Es ist mehr so eine Art Winterschlaf.

Es gibt aktuell zwei Überlegungen:

1. von “vorne” anfangen und eine richtige Version 2.0 starten
2. den Bestand “aufmotzen” und eine Version 1.6 herausbringen

Beides hat Vor- und Nachteile. Einen kompletten Rewrite wird es wohl sowieso nicht geben. Aber an bestimmten Stellen wäre er mind. sinnvoll – und spätestens wenn man über UTF-8 nachdenkt (und das mache ich sehr intensiv), ist es praktisch unabdingbar.

Daher will ich dieses Blog nutzen um erst einmal ein paar weitere feature-requests zu sammeln. Hier einmal ein Auszug aus der aktuellen FR-Liste:

• UTF-8
• RELATED-Funktion um Tickets ohne zu mergen in “eine Kette” hängen zu können.
• neue, sematisch ausgerichtete Suche inkl. einer besseren Tag-Verwaltung
• LOCK-Mechanismen für bestimmte Aktionen
• UNDO für bestimmte Aktionen
• mobile-interface
• SMARTY und generell bereinigtes HTML/ CSS

… gerne in den Kommentaren zu ergänzen :-)

Im Juli 2005 ging die erste Version der kloster-ensdorf.de online. Bis zum Ende des Jahres 2005 wurden noch diverse Erweiterungen vorgenommen und dann gab es im Grunde ein lange Pause für uns – die Seite lief einfach gut und das ist in meinen Augen ein wichtiges Ergebnis.
Bereits 2008 wurde mit Jürgen Zach über eine optische und funktionale Änderung nachgedacht. Im März diesen Jahres fand dann unser Kick-Off statt.

Die optische Gestaltung wurde diesmal nicht von uns gemacht, sondern von Michael Brandel (grafikbuero-brandel.de). Den Hauptteil der Abstimmung und der Umsetzung in HTML hat meine Kollegin Stefanie Graf übernommen. Dabei war unser Fokus auf zwei Bereichen:

1. nicht alles neu schreiben, was nicht unbedingt sein muss
2. sich – wo nur möglich – von dem Ballast des HTML-Table-Aufbaus trennen

Bei all den Wünschen und unseren Ansprüchen hat sich gezeigt, das Punkt (1) nicht so wirklich gut einzuhalten war – es ist wie mit den guten Vorsätzen zum Jahreswechsel ;-)
Punkt (2) haben wir zu 90% erreicht. Auf der öffentlichen Seite würde ich sogar von 95% sprechen.

Wir haben nicht so viele sichtbar neue Funktionen integriert (RSS-Feed für die Newsmeldungen, Pressespiegel, Galerie aufgepeppt, …), sondern mehr “unter der Haube” gearbeitet. Ganz “nebenbei” wurden u.a. folgende Änderungen durchgeführt:

• Umstellung von ISO auf UTF-8
• Suche mit einer sphinx-Konstruktion mit sematischem Charakter
• bessere HTML-Auszeichnung (label-Tag, title-Attribute, li, etc.)
• verbesserter Mailversand

Der Schwerpunkt lag also ganz eindeutig in der Optik und der Überarbeitung der inhaltlichen Struktur.
Es wird noch einige Iterationen der www.kloster-ensdorf.de geben. Einige davon wird der Besucher dann noch merken, aber die meisten beziehen sich dann doch darauf die Arbeitsprozesse für die Administratoren des Klosters zu vereinfachen. In jedem Fall hoffen wir das die neue Seite gut ankommt.

Achja: Wir verwenden unser eigenes framework. Kein bloat-code wie Typo3 oder Drupal. Nicht das ich ein Problem mit Typo3 und Konsorten habe, aber nur weil man “damit alles machen kann” muss man es ja nicht gleich blind einsetzen. Ich persönlich bin immer noch nicht davon überzeugt das solch generische Werkzeuge (und dazu gehört für mich auch CackePHP) für jeden Einsatz geeignet sind. Meine Erfahrung bislang: Je größer das framework, je größer die Hardware. Und bei den Mittelstandsprojekten an denen ich bislang beteiligt war, gab es immer irgendwo eine Budget-Grenze (für Hardware)…

Was mich dabei genau stört ist exakt was dieser Poster schreibt:

Wenn ich als Parameter einen Hash erwarte, dann prüfe ich doch, ob
ein Hash vorliegt (Länge, erlaubte Zeichen) und mache nur dann
weiter, wenn alle Kriterien erfüllt sind.

Niemand ist perfekt, aber bei einer SW die soweit verbreitet ist, sollte man doch annehmen, das ein bisschen mehr über Sanitizer und Co. nachgedacht wird.

Ich habe über die letzten Jahre ein recht brauchbares framework entwickelt. Ein kleines framework, das den jeweiligen Nutzungsumständen immer gut anzupassen war. Inzwischen ist das Entwickeln aber deutlich komplexer geworden, d.h. es müssen mehrere Leute gleichzeitig arbeiten können. Dabei hat mein framework ein paar Limitierungen – nicht zuletzt in der Dokumentation. Es bedeutet doch relativ hohen Aufwand Dritte einzuführen, mit denen man zum ersten Mal zusammen arbeitet.

Aus diesem Grund habe ich mich entschieden einen neuen Weg zu gehen, oder ihn zumindest zu suchen. Mitte August 2008 hatte ich endlich ein paar Stunden Zeit mit CakePHP zu beginnen. Von allen MVC-ausgerichteten frameworks erscheint mit CakePHP bislang als das am besten “verfügbare” (dazu später noch mehr). Allerdigs bin ich mir zum jetzigen Stand noch nicht sicher, wie viel effektiver ich damit arbeiten kann.

Über die nächsten Wochen bis voraussichtlich Mitte November werde ich versuchen mich in CakePHP einzuarbeiten und mir entsprechendes Handwerkszeug zurecht zu legen. Einen guten Teil davon werde ich in diesem Blog veröffentlichen – in deutsch.

Es gibt eine Menge Quellen, aber im deutschsprachigen Raum ist es etwas mager. Ausserdemist das Thema der richtigen Vorgehensweise (“hänge ich das jetzt ins Model oder mach ich ein Behavior draus?”) auch in der englischen Google-Group nicht immer hinreichend gut zu klären.

Meine Aufgabenstellung ist eine Adressverwaltung, die ich vor mehr als 10 Jahren in PHP geschrieben habe und die immer noch im Einsatz ist. Beim letzten Switch von PHP4 auf PHP5 hat sich bei dieser Verwaltung gezeigt, dass es doch ein kleinwenig zuviel Anpassungen bedingte. Das Projekt ist aber überschaubar genug, um sich nicht an planungstechnischen Details aufhalten zu müssen, aber komplex genug um sich mit CakePHP intensiver beschäftigen zu müssen.