Suicide Climber...
Aus der Kategorie "Neulich in der Kletterhalle" heute ein ganz genialer Beitrag. Montag abend - die Halle ist voll wie immer, plötzlich zeichnet sich im Getoße ein sich-ausweitender Platz überraschender Ruhe ab. Sofort fragt man sich: "Was ist passiert?".
Die Antwort fällt dieses Mal etwas überraschender aus: ein Kletterer hat es doch tatsächlich geschafft, eine gesamte Route im 6. Grad zu klettern, korrekt eingebunden, jede Sicherung eingehängt, aber ohne jemanden, der ihn gesichert hätte. Also nochmal zum Mitschreiben: Der Kerl "hängt" oben an der Decke, das Seil liegt am Boden, aber keiner, der ihn sichert.
So - und jetzt? Nun ja - ein anderer Kletterer sieht es zufällig, rennt hin und nimmt ihn in die Sicherung. Aber das eben nicht an der zweiten Exe oder sowas, sondern als der Kerl oben an der Decke hängt. Die Frage lautet freilich: "Wie konnte das passieren?". Nun da gibt es wohl mehrere Gründe:
1. Ein Partnercheck kann garantiert vor dem Klettern nicht stattgefunden haben.
2. Eine Absprache zwischen Kletterer und Sicherer fand während der gesamten Route offensichtlich nicht statt.
3. Die Halle war vermutlich einen Tick zu voll. Und zwar so voll, dass ein Kletterer, wenn er nach unten schaut wohl den Eindruck haben musste, einer der 100 Leute, die da am Einstieg seiner Route standen wird ihn schon heben.
4. Der Kletterer litt an völliger geistiger Umnachtung und sein Kletterpartner hatte wohl besseres zu tun, als sich um ihn zu kümmern. Man fand ihn einige Minuten später einen "Privatkletterkurs" abhaltend mit anderen Personen beschäftigt.
Und die Moral von der Geschicht - jepp, jetzt darf sich jeder selber mal an die Nase fassen! Schon mal losgeklettert, ohne zu warten, bis der Sichernde das Seil im Sicherungsgerät hat? Ich schon! Die schlimmste Folge blieb aus, aber die Vorstellung an diesem Montag Abend war schon beeindruckend!
Schon mal vor dem Klettern keinen Partnercheck gemacht? Joa - ich auch schon. Der hätte das mit Sicherheit verhindert. Man könnte also fast schon sagen, der Partnercheck beim Klettern ist so wichtig, wie das Einbinden und das Sichern selber, weil alles miteinander letzten Endes dazu beiträgt, dass keiner stirbt.
Die letzte Frage: Wann ist eine Kletterhalle so voll, dass man sagen muss, ein sicheres Klettern ist nicht mehr möglich? Und kann - im Falle des Falles, dass halt doch mal etwas passiert - am Ende nicht doch jemand dazu zur Verantwortung gezogen werden, weil JEDER sieht, dass es so nicht geht, aber keiner was dagegen tut?
Für mich ist und bleibt es eine Frage der Zeit, bis durch solche Vorfälle mal ein Kletterer in einer Kiste die Halle verlässt. Traurig, aber wahr.
"So Ahmed - as a climber, I suppose you have a certain kind of specialty?" - "Yes - I'm a SUICIDE CLIMBER!"
Typo3 Umlautprobleme dank Tidy...
Folgendes Problem: Eine Webseite, die seit 2 Jahren läuft hat plötzlich Umlautprobleme. Statt eines Leerzeichens tauchen die gefürchteten schwarzen Rauten mit dem Fragezeichen auf.
Nach langer Suche in Typo3 folgende Ursache: Im Installationstool war TIDY aktiviert. Damit werden wohl unter anderem html entities nach Umlauten transformiert. Tidy war aber nicht auf UTF-8 konfiguriert, so dass jedes HTML Entity im HTML Code nach ISO konvertiert wurde. Diese Konvertierung wurde auch nicht durch irgendwelche TS Einstellungen beeinflusst.
Beispiel: & n b s p; wird zu a0 konvertiert
Vielleicht hilft dieser Eintrag mal jemandem, der ein ähnliches Problem hat...
Leichtgewichtiges ORM für Typo3
In den vergangenen Wochen habe ich mich bei der punkt.de (mal wieder) mit der Persistierung von Objekten in Datenbanken beschäftigt. Ziel dabei war und ist es, ein leichtgewichtiges ORM für Typo3 zu schreiben, welches den komfortablen Zugriff auf Datenbankzeilen erlaubt.
Nach den schlechten Erfahrungen mit Doctrine und dessen Speicherverbrauch war das oberste Ziel, die eigentlichen Datenobjekte möglichst schlank zu halten und so viel Logik wie möglich in die Datenmapper (Accessors) und das Repository zu packen.
Derzeit sind Datenobjekte und Accessoren implementiert. Das Repository ist gerade in der gedanklichen Entstehung und soll im Laufe der kommenden Wochen realisiert werden. Sobald dies geschehen ist, werde ich versuchen, eine brauchbare Version ins Typo3 Forge zu stellen, dies macht aber erst dann Sinn, wenn sich die Schnittstellen nicht mehr wesentlich ändern.
Laut Wirtschaftswoche ist Karlsruher Fakultät für Informatik erneut auf Platz 1
Viele Jahre lang wurden im Informatikgebäude der Universität Karlsruhe, welche wohl gerade durch die Exzellenz ihrer Abgänger immer wieder Rankings gewinnt, waschbare Endloshandtücher verwendet. Die Umstellung auf Einweg-Papierhandtücher scheint für manche der exzellenten Studenten noch einige Probleme in der Handhabung der verschmutzten Papierhandtücher darzustellen, wie die abgebildeten Fotos zeigen.
Als intelligenter Workaround zum leichten Stopfen des Papierkorbes, welches sogar auf einem darüber befindlichen Zettel schmackhaft gemacht wird, sei vor allem das Werfen der Papierhandtücher auf den Boden daneben vermerkt.
Falls Sie also nach einem neuen Mitarbeiter suchen, welcher sich als intelligenter, teamfähiger und vor allem "sauberer" Kollege in Ihre Firma integrieren soll, sei Ihnen der Karlsruher Informatik-Absolvent besonders ans Herz gelegt!
Doctrine und der liebe Speicherverbrauch
Für einen Kunden hatte ich die Aufgabe, ein aus seiner Warenwirtschaft exportiertes XML Dokument in eine MySQL Datenbank zu importieren. Nichts leichter als das, dachte ich und benutzte für das Auslesen des Dokuments ein DOM Objekt und wollte mit Hilfe von Doctrine als DB Abstraktion - oder besser gesagt ORM - die Objekte in die Datenbank schreiben. Angefangen habe ich damit, 1700 Kundendatensätze in de fe_users Tabelle von Typo3 zu schreiben. Dabei bekam ich dann immer wieder Fehlermeldungen, dass das Skrip zu viel Speicher verbrauche. Mit anfangs 32MB Speicher pro Skript (php.ini) konnte ich mir auch noch vorstellen, dass das wohl zu wenig sein könnte. Also den Speicher auf 128 MB erhöht, trotzdem kamen Fehler.
Das machte mich dann doch stutzig. Nach längerer Suche hab ich rausgefunden, dass PHP mit Hilfe des Befehls
memory_get_usage()
den aktuellen Speicherverbrauch anzeigt. Dabei kam heraus, dass pro Schleifendurchlauf für einen Kunden, der aus dem XML geparsed wurde, sage und schreibe 60kb Speicher verbraucht wurden. In der Summe wurden daraus bis zu 190MB Speicherverbrauch bei 1700 einzulesenden Zeilen.
Zuerst hatte ich das DOM Objekt von simple_xml in Verdacht. Habe alles gegen einen SAX Parser ausgetauscht um danach festzustellen, dass immer noch 190MB verbraucht werden. Stück für Stück habe ich angefangen, alle Datenbankzugriffe über die Typo3 eigenen Methoden zu ersetzen und kam dabei letztendlich auf 14MB Speicherverbrauch, nachdem ich alles ersetzt hatte.
Die Quintessenz dieser Geschichte ist für mich, dass Doctrine zwar den Zugriff auf Daten sehr komfortabel macht, aber zumindest beim Auftreten von mehreren tausend Datensätzen absolut unbrauchbar ist. Übrigens hat auch das explizite Freigeben von Ressourcen mit Hilfe der Funktion
free()
keinerlei Auswirkungen auf den Speicherverbrauch gehabt! Vielleicht nehmen sich die Entwickler von Doctrine ja mal dem Problem an, so ist es jedenfalls für größere Projekte nicht wirklich brauchbar.
