Der Zwiebelflüsterer

Meine regelmässigen Wanderungen durch allerlei Seiten lies sich heute kurzfristig mit einem weiteren, regelmässigen Hobby verbinden: dem suchen nach Projektmanagementtools. Über den Django-Blogaggregator kam ich heute per Zufall (:)) auf die Seiten von Silver Stripe Software, welche mit SilverCatalyst ein recht beeindruckendes Produkt im Bereich agiles Projektmanagement bereitstellen.

Das “beeindruckend” begrenzt sich leider jedoch nur auf die recht innovative Benutzerführung, die sehr einfach aber klar strukturiert gestaltet ist. Auch das SCRUM Grundprinzipien teilweise mit umgesetzt wurden bzw. das man bereitgestellte Werzeuge dafür nutzen kann (Tasks als User-Stories  und damit ganze Iterationen abbilden) find ich toll.

Sowie die Art der Bereitstellung von Reporten über Aufgaben, Iterationen und allgemein den Status von Projekten, find ich klasse. Das ganze noch in Python geschrieben, macht die ganze Sache auch recht fix.

Aber leider liegen in den aufgezählten, tollen Funktionen auch die Probleme. Denn mehr als ein paar rudimentäre Reportings, Tasks, Iterations und allgemeines Projekt- und Usermanagement gibt es nicht. Weder Abrechnungskalkulationen noch ein Ticketsystem sind enthalten. Damit kann man leben, jedoch nicht zu dem angebotenen Preis der Lizenzen, die man ab mehr als 3 beteiligten Personen benötigt.

Kurz und gut: das Django Book.

Das tolle hieran ist, das die recht ausgeprägte Django-Community noch vor dem erscheinen des Buches, online ihre Meinung zu Kapiteln und jeden einzelnen Absatz abgeben konnte. Und die Meinungen wurde sogar in den meisten fällen beachtet. Find ich toll. Sollten sich O’Reill, Galileo und wie sie alle heisen vielleicht mal auf die Stirn schreiben, dann würde eventuell weniger Tischstützen produziert werden

Großes Fressgelage am 18. und 19. August 2007! Es wird gesoffen, es wird gefressen und es wird getratscht. Das alles natürlich auf hohem, fachlichem Niveau!

Der Met steht schon bereit und ist schön warm!

Ich bin ja ein kleiner Freier, und die Medien sind meine Huren. Das ist wie früher das Fernsehen, ich saug alle Informationen auf wie ein Schwamm. Nicht nur die recht dünnflüssigen Sachen aus der Glotze oder diverse Newssites, sondern auch alles andere: Blogs, tech.-News, Foren, etc.

Und dank den Zeiten von RSS und Atom-Feeds geht das ja noch einfacher, schneller und zeitverbrennender. Nun gut, hab ich mir gesagt: mach doch mal was aus diesem nutzlosen Hobby. Also habe ich mir heut im Rahmen von Onionforge den Zwiebelkurier gebastelt.

Dieser zeigt nun die gebündelten Informationen diverser RSS-Anbiedenter Seiten. Zwar noch recht lose, unketagoriert, etc. Aber trotzdem schon ein angenehmeres durchstöbern von Nachrichten.

Back to the roots, back to the Newspaper!

Ein Teufelsding. Hatten wir doch letztens erst den Auftrag für ein fast fertiggestelltes Projekt eine auf latin1 basierende MySQL Datenbank auf Unicode umzustellen. Dies allein ist ja schon ein ziemlicher Kraftaufwand:

1. Dump der Originaldatenbank erstellen
2. Im Dump alle Latin1 Einträge auf UTF8 umstellen / ersetzen
3. Im Kopf des Dumps folgendes hinzufügen, falls es noch nicht vorhanden ist:
   1. /*!40101 SET NAMES utf8 */;
      Dieses hübsche Zeile soll lediglich dafür sorgen, das MySQL die nachfolgenden INSERT-Kommandos möglichst UTF8-kompatibel ausführt
4. Neue Datenbank erstellen, für die die Connection-Collation, das MySQL-Charset sowie dieBasis-DB-Collation auf utf8_general_ci gesetzt ist. Utf8_general_ci wird von MySQL scheinbar utf8_unicode_ci gegenüber bevorzugt und als Standard für Unicode erfasst.
5. Dump in die neue Datenbank importieren
6. … ANT-Skripte eignen sich hier hervorragend!

Wenn man sich nun die neu ersellte Datenbank anschaut, sollten alle Tabellen und Spalteneigenschaften auf utf8_general_ci gesetzt sein. Die enthaltenen Datenbestände sollten auch im richtigen Format liegen.

Jedoch, das juckt das PHP / MySQL Pärchen nicht sonderlich. Die Collations können alle auf Unicode (UTF8) gesetzt sein, die HTML-Header auch. Und trotzdem werden zerschossene Sonderzeichen geliefert. Das könnte einen wahnsinnig machen. Tut es auch. U.a. mich und meinem Kollegen.

Nachdem wir also ein halbes dutzend Versuche und Prototypen zum konvertieren der Daten geschrieben hatten, gingen wir dem Übel an die Wurzel: MySQL.

In der Tat eine faszinierende Sache. MySQL bietet eine Menge Schnittpunkte, um Collations und Charsets zu setzen. Die der Datenbank/Tabellen sind nur ein kleiner Auszug. Dazu kommen dann so tolle Sachen wie:

• CHARSET für den Client ( character_set_client=x )
• CHARSET für zu lieferende Query-Ergebnisse ( character_set_results=x )
• CHARSET für die MySQL / Client – Verbindung ( character_set_connection=x )

All das auf latin1, da wird man doch gaga auf der Suche nach den Problemen bei der enkodierung.

Man könnte nun die entsprechenden Flags in der my.cnf von MySQL abändern. Das funktioniert sogar … für Konsolenzugriffe. PHP spielt da aber nicht mit, da es scheinbar einen feuchten foorz auf die Einstellungen in der my.cnf gibt.

Eine Möglichkeit funktioniert dann jedoch. Und zwar jene, die jedem PHP-Frickler .. eh, ‘schuldigung … PHP-Entwickler bekannt vorkommen müsste: die frickellösung. Anstatt direkt an der Wurzel des Problems arbeiten zu können, sollte man nach jedem MySQL-Connect ( mysql_connect () ) folgendes Query absetzen:

”SET CHARACTER SET utf8”

Ein vormaliges auswählen einer bestimmten Datenbank ist dafür nicht nötig.

Das penetriert die PHP / MySQL Kombination dann auch zu genau dem, was die Einstellungen in der my.cnf schon sagen: Die Daten aus einem Query UTF8-konform an den Client auszuliefern. Und das klappt. So einfach, und des klappt ….