der-nerd.de

Link: http://bit.ly/9SrCPn

Armes Deutschland! Kaum hat sich die Nation nach der Tragödie auf der Loveparade in Duisburg einigermaßen gefasst, schon wird das Land vom nächsten Drama heimgesucht: In der Nacht vom 04.08.2010 auf den 05.08.2010 wurde in Neuenkirchen ein großer Blumenkübel vor einem Altenheim durch Unbekannte umgestoßen und zerbrochen. Ich konnte es minutenlang nicht fassen - heute Mittag saß ich wie versteinert vor dem Monitor und starrte schockiert die Meldungen an, die mich über alle Kanäle gleichzeitig erreichten - Zeitungen, Twitter, Facebook... Normalerweise lasse ich solche Tragödien emotional nicht allzu nah an mich ran, doch heute fiel es mir schwer, die Tränen zu unterdrücken. Ich habe in meinem ganzen Leben noch nie etwas so schreckliches gesehen.

Was soll aus der Menschheit nur werden, wenn solche Alpträume plötzlich Realität werden - wie heute vormittag? In was für einer Welt werden unsere Kinder leben? Sind vielleicht alle unsere Blumenkübel nun in Gefahr? Was sollen wir tun? Traurigerweise hat die Erfahrung (z.B. im Fall der Kinderschändungs-Skandale) gezeigt, dass nur wenige dieser barbarischen Ereignisse an die Presse kommen. Es ist also nur die Spitze des Eisbergs, und ich muss hier leider die harte und traurige Wahrheit aussprechen, ohne mir ein Blatt vor den Mund zu nehmen: Es sind mit Sicherheit mehr Blumenkübel betroffen als nur dieser eine. Diese unmenschlichen Akte bleiben deswegen im Verborgenen, weil Betroffene sie aus Angst verheimlichen und verdrängen wollen. Und Unbeteiligte sehen einfach weg. Oh weh, oh weh dieser Welt!

Wenn ich mir die schockierenden Bilder ansehe, so erinnere ich mich ungewollt zurück an ein anderes tragisches Ereignis, was vor rund neun Jahren passiert ist: Der Anschlag auf das World Trade Center am 09.11.2001.  So wie damals sind die Menschen heute fassungslos und fragen sich: Warum? Warum sind menschliche Wesen zu so etwas fähig? In diesen Augenblicken durchleben wir 9-11 aufs Neue.

Liebe Leser! Wir müssen jetzt zusammenhalten. Wir dürfen das Ereignis nicht totschweigen, wir dürfen die schrecklichen Bilder des zerbrochenen Blumenkübels nicht verdrängen. Wir müssen offen darüber reden. Mit unseren Liebsten, mit unseren Freunden, mit unseren Kindern. Es ist ein großer Schmerz für unsere Nation und sogar für die gesamte Welt. Aber wir müssen jetzt stark sein. Wir müssen Mut, Kraft und Zuversicht schöpfen. Wir müssen zeigen, dass das Leben immernoch weitergeht.

So long,

- Oleg

Link: http://www.google.com/images

Alles, was einen Anfang hat, hat leider auch ein Ende. Milliarden von Internetnutzern haben vor einigen Tagen einen treuen Freund und Partner verloren: Die Bildersuche von Google. Liebe Leser, ich rufe hiermit zu einer Schweigeminute auf.

... 60 sek

... 30 sek

So, Minute vorbei. Wie bei jeder Totenrede erzähle ich jetzt die Lebensgeschichte der Google-Bildersuche. Angefangen hat alles im Januar des Jahres 1998, als das Unternehmen Google Inc. gegründet wurde. Wie diverse andere Suchmaschinen bot Google neben der Suche nach textuellen Inhalten auch eine Bildersuche an, die soweit auch ausgezeichnet funktioniert hat. Diese Bildersuche ist zum aktuellen Zeitpunkt noch auf der deutschen Version der Google-Bildersuche zu sehen. Man gibt einen Suchbegriff ein, und im Viewport erscheinen mehrere Zeilen mit Vorschaubildern der Bildergebnisse. Bei meiner Bildschirmauflösung von 1920x1080 sind das drei Zeilen und sechs Spalten. Am unteren Rand der Seite sind die nächsten zehn Ergebnisseiten zu sehen, sowie die Links "Vorwärts" und "Zurück". Das ist seit je her das Mittel der Wahl, um große Listen oder Tabellen seitenweise darzustellen.

Seit 2009 existiert eine weitere bekannte Suchmaschine von Microsoft mit dem Namen Bing . Diese Suchmaschine kann - genauso wie Google - unter Anderem textuelle Inhalte, Bilder und Videos finden. Die Indexierung ist weitgehend in Ordnung, somit sind die Ergebnisse von Bing durchaus brauchbar. Nichtsdestotrotz kann Bing wohl kaum mit der Popularität von Google mithalten. Einer der Gründe für die eher mäßigen Erfolge von Bing ist meiner Meinung nach die Darstellung der Bildersuchergebnisse. Die Ergebnisse werden nämlich ALLE auf EINER einzigen Seite angezeigt, ohne eine Aufteilung in Ergebnisseiten. Um nicht das halbe Internet in den Browser zu laden, verwendet die Webseite dabei einen Trick: Beim Runterscrollen werden weitere Inhalte dynamisch nachgeladen. Ab einem bestimmten Punkt (wahrscheinlich bei 1000 Bildergebnissen) wird nicht mehr nachgeladen, und das Suchergebnis ist nun vollkommen: Ein gigantisches div-Element mit hunderten von Vorschaubildern. Ich frage mich, wer diese hirnrissige Idee in die Welt gesetzt hat. Zu den Nachteilen dieser Darstellung gehören:

• Eine relativ hohe Belastung für den Browser aufgrund der Bilder (Iron-Taskmanager meldet 120kb für den Tab)
• Weitere Browserbelastung durch die Ausführung des Javascripts für das Nachladen
• Ein völliger Übersichtsverlust der Suchergebnisse, d.h. wenn man einmal runtergescrollt hat und ein Ergebnis weiter oben sehen will, muss man es wieder suchen und keine Seitenzahl als Anhaltspunkt.
• Eine Belastung für den Mittelfinger und das Mausrad des Benutzers (verdammt, ich hatte nach dem Gescrolle einen Krampf in der Hand! Ich glaube, ich verklage Microsoft auf 20.000 Euro Schmerzensgeld)

So verhält es sich bei Bing, und ich war mir bis jetzt eigentlich sicher, dass diese Probleme bei den Layout-Verantwortlichen bei Google belächelt wurden. Schließlich hatte Google bis dato ein bequemes, browser- und benutzerfreundliches Layout bei der Darstellung der Bildersuche. Doch nun hat Google das unglaubliche getan: Sie haben das Layout von Bing übernommen, obwohl es eigentlich genau umgekehrt sein sollte. Warum lernen in dieser Welt plötzlich die Besseren von den Schlechteren? WARUM? Dem aufmerksamen Betrachter wird aufgefallen sein, dass die Suchoptionen bei der Googles Bildsuche vom oberen zum linken Bildschirmrand gewandert sind, wo sie bei Bing von Anfang an zu finden waren. Das ist sicherlich durchaus sinnvoll, und somit ist es verständlich, dass Google diese Änderung übernommen hat. Aber das bedeutet doch nicht, dass man gleich alles von Bing nachäffen muss...

Google hat das Nachladen der Bilder übrigens etwas anders geregelt: Nach wahrscheinlich 1000 Bildern ist die Seite zu Ende und erweitert sich auch nicht durch das Scrollevent des Browsers, allerdings kann man unten eine Schaltfläche drücken, die nochmal so viele Ergebnisse nachlädt. Das ist jedoch nur einmal möglich, eine dritte Portion von Bildern kann man (zur Zeit jedenfalls) nicht mehr nachladen, die Maximalanzahl der Suchergebnisse ist erreicht. Als ob das alles nicht schon schlimm genug wäre, Google hat noch eins draufgesetzt: Die Bilder werden nicht tabellarisch dargestellt, sondern quasi direkt hintereinander, wobei ihre Breite berücksichtigt wird. Das bedeutet, dass in eine Zeile mit mehr schmalen Bildern auch mehr Ergebnisse enthält als eine Zeile mit breiteren Bildern. Es wird kein Gitternetz eingehalten, wie es bei Bing der Fall ist. Dadurch bekommt die Ergebnisseite das Aussehen einer künstlerischen Kollage und nicht das eines strukturierten Suchergebnisses. Beim Mouseover wird jeweilige Bild etwas vergrößert und verdeckt damit teilweise andere Bilder. Ich kann mir nur einen Grund für diese Entscheidung vorstellen: Google hat Probleme mit der Serverkapazität und deswegen wollen die Verantwortlichen durch dieses abscheuliche Interface Benutzer abschrecken und davon abhalten, die Bildersuche zu verwenden.

Mir ist soeben eine Parallele zur Darstellung der Bildergebnisse in den Sinn gekommen: In der Antike wurden Texte oft auf Papyrusrollen (engl. "scroll" - von daher auch "scrollen", klingelt's??) geschrieben, nicht in Bücher mit Seiten wie heute. Diese Papyrusrollen konnten durchaus lang sein, deswegen war jedes Ende an einer Art Walze aus Holz befestigt. Man konnte den Text so auf die beiden Walzen aufrollen ("to scroll"), dass man die gesuchte Textstelle vor sich hatte. Irgendwann in der späteren Antike wurden diese Rollen jedoch von den Büchern abgelöst, wie wir sie heute kennen - mit Seiten zum Umblättern. Das war schließlich viel bequemer als die Papyrusrolle. Warum geht also Bing den umgekehrten Weg und bevorzugt die digitale Papyrusrolle vor der konventionellen, seitenweisen Darstellung? Und warum macht Google diesen Unsinn nach?

Doch das ist nicht genug, es wird alles noch schlimmer. Wenn man bei Google nun so ein Bild anklickt, gelangt man nicht mehr zur gewohnten Darstellung mit den Bilddetails im oberen Teil der Seite und der Webseite des Bildes im unteren. Stattdessen wird eine sog. Lightbox mit dem Bild in verkleinerter Größe aufgerufen, während die Webseite hinter einem grauen Schleier im Hintergrund zu sehen ist. In diesem Zustand ist die Webseite weder bedienbar noch scrollbar. Um zur Seite zu gelangen, muss man die Lightbox schließen. Durch den Klick auf den Schließen-Button wird einfach die Webseite des Bildergebnisses aufgerufen, ohne irgendwelche Google-Elemente. Man kann somit also die gesamte Webseite nach dem Bild durchsuchen, und es ist nirgends mehr das Vorschaubild zu sehen. Die Lightbox verursacht eine massive Belastung für den Browser, besonders dann, wenn ein großes Originalbild verkleinert dargestellt werden muss. Die Verkleinerung wird nämlich (anders als bei den Vorschaubildern) nicht von Google erledigt. Das Bild behält seine URL bei, es wird lediglich in der größe der Lightbox dargestellt. Dieses Problem gab es vor vielen Jahren, wenn z.B. Benutzer in Foren, Blogs oder CMS-Systemen Bilder von ihrer Digitalkamera in Originalgröße hochgeladen und in einem img-Tag mit fester Breite und Höhe angezeigt haben. Wer diese Erfahrung nicht kennt, darf das gerne mal mit 5-10 Bildern auf einer HTML-Seite probieren. Der Browser wird einen langsamen und qualvollen Tod sterben. Ich dachte eigentlich, dass wir in Zeiten von GDlib über diese Probleme hinweg sind - aber scheinbar sind solche Dinge genauso wie Papyrusrollen plötzlich wieder in. Um der Mode voraus zu sein, hole ich mir am Besten gleich einen Lendenschurz und eine Keule -.-

Vielleicht dringt diese Idee ja sogar bis in den Buchdruck vor und vielleicht können wir demnächst Harry Potter auf einer verdammten FAXROLLE lesen, nur weil das ach so modern und innovativ ist und Bing und Google das ja auch so machen?? Und wie wäre es, wenn ich meinen Blog so umstelle, dass alle Posts seit Beginn meiner Schreibkarriere auf einer einzigen Seite dargestellt werden?

Eines steht fest: Für mich ist die Bildersuche von Google hiermit gestorben. Ich werde in Zukunft nur noch Yahoo und Altavista verwenden, bei denen die Bildersuche immernoch benutzerfreundlich ist. Ich hoffe, dass dies Betreiber dieser beiden Suchmaschinen mehr Hirn im Kopf haben und nicht auch mit dem Papyrusrollen-Trend mitziehen.

So long

- Oleg

 

P.S.: Ein Freund hat mir gerade folgenden Hinweis gegeben: Bei Google kann man ganz am unteren Rand der Seite auf "Switch to basic version" klicken. Das bereitet dem Grauen ein Ende. Allerdings wird diese Einstellungen ersten Erkenntnissen nach nicht im Cookie gespeichert und ist nur für die aktuelle Suche gültig... Mal sehen, ob das noch geändert wird.

Hallo alle zusammen,

hier eine kleine Mitteilung in eigener Sache: Ich nach einigem Überlegen habe ich mich dazu entschlossen, das alte winterliche Design des Blogs gegen etwas Neues auszutauschen. Meine beiden Wunsch-Designs hatten leider technische Schwierigkeiten, die mitunter mit dem Update des Blogsystems zu tun haben könnten, aber dieses Design hier ist visuell ganz okay (auch wenn es mir etwas zu hell ist) und scheint soweit zu funktionieren.

Wenn ich Zeit habe, werde ich mal die weiteren verfügbaren Designs durchprobieren - mal sehen, ob ich etwas schönes finde. Es sollte nicht zu bunt, aber auch nicht komplett düster sein. Gleichzeitig soll es sich vom typischen Industrial-Look (wie er bei vielen Unternehmens-Webseiten zu finden ist) abheben.

So long,

- Oleg

Link: http://www.mcdonalds.de/produkte/nuernburger.html

Die Nürnberger Rostbratwurst - eine Spezialität, auf die wir Nürberger schon seit über 500 Jahren stolz sind, lockt täglich Touristen aus aller Welt nach in unsere wunderschöne mittelfränkische Metropole der Würste, Lebkuchen und Biere. Die Bratwurst gibt es schon seit langem in diversen Wurstbuden zu kaufen, und auch beim Grillen darf sie nicht fehlen. Jeder Supermarkt hier in Mittelfranken und wohl auch in ganz Deutschland bietet rohe Bratwürste, die auf dem Grill ihr deftiges Aroma entfalten.

Nun taucht die berühmte Bratwurst in eine vollkommen neue Verkaufsdimension ein: Uli Hoeneß, ehemaliger Fussballspieler und aktueller Präsident des FC Bayern - heute auch Gesellschafter von HoWe Wurstwaren KG ist - hat sich mit der umsatzstarken Gastronomiekette McDonald's zusammengeschlossen: Ab nun soll die Nürnberger Rostbratwurst deutschlandweit bei McDonald's über die Theke gehen, und zwar unter dem Namen "Nürnburger". Der Nürnburger entspricht unseren allgemein bekannten "Drei im Weggla": Drei kleine Würstchen im Brötchen, im Falle des Nürnburgers mit Senf und Röstzwiebeln verfeinert.

Und so geht unsere Wurst auf Deutschlandreise. Jetzt kann jeder schnell und unkompliziert in den Genuss unserer fränkischen Spezialität kommen, sei es in der Stadt, auf dem Rastplatz an der Autobahn oder im Einkaufszentrum. Herr Hoeneß, danke für die innovative Idee! Ich wünsche HoWe Wurstwaren KG und McDonald's viel Freude und kräftigen Umsatz beim Verkauf des Nürnburgers, und den Gästen natürlich einen guten Appetit :-) Und wer weiss, vielleicht wird sich unser Würstchen eines Tages auf den Flügeln von McDonald's bis in die USA und in andere ferne Länder vorkämpfen.

Hier noch einige Quellen zu dem Thema:

• Der Nürnburger bei McDonald's: http://www.mcdonalds.de/produkte/nuernburger.html
• Der Blog von Uli Hoeneß: http://www.ulis-nuernburger.de/
• Wikipedia: McDonalds: http://de.wikipedia.org/wiki/McDonalds
• Wikipedia: Uli Hoeneß: http://de.wikipedia.org/wiki/Uli_Hoeneß

Link: http://twitter.com/ElHibernetico

Wer eine Business-Anwendung programmiert, hebt sich - in der Theorie - von den oft als unsauber und amateurhaft geltenden Programmiertechniken der Skriptsprachen-Gemeinde ab. Streng objektorientierte Sprachen wie Java zwingen den Entwickler schon fast, eine saubere Struktur an Klassen für seine Software aufzubauen. Dank vielfältiger Fachliteratur wissen wir auch, was ein solcher objektorientierter Aufbau an Vorteilen mit sich bringt: Erweiterbarkeit, Anpassbarkeit, Modularität, geringe Kopplung, hohe Kohäsion und saubere Schnittstellen zählen da zu den Hauptargumenten. Eine schöne heile Welt? Wir werden sehen...

Natürlich benötigt jede ernsthafte Software mit irgendeiner Form von Datenbank im Hintergrund, in den allermeisten Fällen wird dabei auf SQL-basierte Systeme zurückgegriffen, wie z.B. den Microsoft SQL Server oder MySQL. Das große Problem aus Sicht der Puristen der Objektorientierung ist dabei jedoch die Tatsache, dass SQL-Datenbanken in aller Regel nicht mit Objekten arbeiten, jedenfalls nicht so, wie es die darunterliegende Programmiersprache benötigt. Die Kommunikation zwischen der Anwendung und der Datenbank läuft dabei mit Hilfe der robusten und stetig weiterentwickelten Abfragesprache SQL (Structured Query Language) bewerkstelligt. Unterschiedliche Datenbanken haben dabei unterschiedliche "Dialekte" dieser Sprache, d.h. Besonderheiten beim Escapen von Sonderzeichen, Spezialfunktionen, Trigger, Views, etc. Im Allgemeinen halten sich die Datenbanken bei einfachen Abfragen jedoch an den SQL-Standard. Die Anwendung muss sich ihre Objekte also aus der Ergebnismenge der SQL-Abfragen zusammenbauen, und beim Speichern dieser Objekte muss sie eine entsprechende Abfrage zusammenbauen.

Während viele Entwickler der Einfachheit halber die Abfragen mit Platzhaltern versehen und direkt in ihren Quelltext schreiben, herrscht besonders im Enterprise-Bereich die Meinung vor, dass sich zwischen der Anwendungslogik und der Datenbank eine abstrahierte Zwischenschicht befinden muss. Damit ist eine Komponente gemeint, die bei Lesevorgängen die zeilenbasierten Ergebnismengen einer SELECT-Abfrage in Objekte der Anwendungssprache umwandelt, und beim Speichern der Objekte eine INSERT- oder UPDATE-Abfrage generiert. Diese Zwischenschicht wird in der Fachsprache "Objektrelationaler Mapper" (ORM-Mapper) genannt.

Einer der (erschreckenderweise) besten und bekanntesten ORM-Mapper ist Hibernate. Diesen Mapper kann man in erster Linie mit Java oder .NET (nHibernate) verwenden. In vielen Kreisen wird Hibernate aufs Höchste gelobt, allerdings weiss jeder echte Programmierer, dass man sich auf die Lobgesänge der selbsternannten IT-Koryphäen nicht immer verlassen kann - denn das verhält sich ähnlich wie mit der Werbung für Alltagsprodukte wie Handys, Autos oder Versicherungsverträge. Man muss längerfristig mit dem System gearbeitet haben, um wirklich eine Aussage darüber treffen zu können.

Die vor allem bei Theoretikern vorherrschende Anerkennung für Hibernate wird bei der praktischen Anwendung dieses ORM-Mappers schnell schwinden: Der objektrelationale Mapper, der eigentlich die Arbeit mit Datenbanken vereinfachen soll, übernimmt nach und nach die Kontrolle über die gesamte Anwendungsstruktur. Der Entwickler muss nach und nach seine Autorität über seine Software an Hibernate abgeben - denn die geringste Abweichung von den Idealen und Vorstellungen von Hibernate wird diktatorisch aufs Härteste bestraft:

Mit einer Exception.

Nein, nicht mit irgendeiner hilfreichen Exception, die beim Progammierer ein Licht aufgehen lässt und ihn auf seinen Fehler hinweist, sondern mit einem sphinxischen Rätsel, was selbst die erfahrensten Entwickler erst nach tagelanger, zermürbender Fehlersuche lösen können. Man kann sich das etwa folgendermaßen versinnbildlichen: Ein verstauchter linker Fuß macht sich duch Schmerzen im rechten Handgelenk bemerkbar. OK, auch in diesem Fall kann man sich da den Zusammenhang erklären: Vielleicht ist im Fuß ein Nerv eingeklemmt und sendet fehlerhafte Signale an das Rückenmark, die dann als Schmerzen im Handgelenk interpretiert werden. Aber selbst wenn das biologisch möglich ist - man wird es wohl kaum einem Arzt vorwerfen können, dass er das Problem nicht auf den ersten Blick erkennt, vielleicht auch nicht auf den zweiten Blick.

Ein weiteres Highlight von Hibernate ist der Umgang mit Beziehungen zwischen Objekten bzw. Datenbanktabellen: Man nehme an, wir haben eine Klasse "Hersteller" und eine Klasse "Produkt". Ein Hersteller kann dabei n Produkte haben:

• Hersteller "CoffeeMaster" (ID=1); Produkte: "UltraJava 2000", "Espressomat 650i" und "SuperBean C300".
• Hersteller "SuperCafe" (ID=2); Produkte: "CoffeeCreator Plus" und "ExtraEspresso"

Man nehme an, wir möchten nun alle Produkte von CoffeeMaster löschen. Normalerweise würde man einfach ein SQL-Statement schreiben, welches alle Produkte mit der Eltern-ID 1 entfernt. Eine Zeile, fertig. Nicht jedoch bei Hibernate. Nachdem man dem System mit Hilfe von mindestens drei Klassen und sechs Methoden verklickert hat, dass man die Produkte löschen möchte, werden diese erstmal aus der Datenbank gezogen, schlimmstenfalls mit einem JOIN auf den Hersteller. Man muss doch schließlich genau wissen, was man da löscht. Logisch? NEIN. Danach werden die Produkte EINZELN gelöscht, mit einem Statement für jede Zeile. Der dahinterliegende Grund ist nämlich, dass die Hibernate-Logik sich massiv sträubt, mit simplen Parent-Child-Beziehungen zu arbeiten.

Man kann somit in der Tat auch kein Produkt erstellen und ihm als Parent-ID z.B. die 2 mitgeben, um es "SuperCafe" zuzuweisen. Man muss stattdessen das gesamte Objekt "SuperCafe" aus der Datenbank lesen und es beim Zusammenbauen des Produkt-Objektes an die Stelle stecken, wo normalerweise die 2 als Parent-ID ihren Platz hätte. Das heisst aber alles nicht, dass Hibernate nicht auch nur mit Wasser kocht: Nach dem Durchlaufen von hunderten von internen Methoden (und möglicherweise dem Werfen kryptischer Exceptions) generiert der ORM-Mapper am Ende auch nur ein Statement, welches eine neue Zeile in die Produkttabelle schreibt und ihr - so wie es schon seit Anbeginn der Menschheit gemacht wird - die 2 als Parent-ID mitgibt. Sämtliche Versuche, diese Logik zu umgehen, werden drakonisch mit furchterregenden Exceptions geahndet.

Aufgrund der vielen unnötigen Abfragen leidet zu einem gewissen Grad die Systemperformance. Das wird von Hibernate durch einen höchst umstrittenen Cache-Mechanismus gelöst: Die Grundidee dabei ist es, aus der Datenbank gelesen Objekte in einem Objekt-Cache zwischenzulagern. Wenn man also eine Anwendung mit vielen Benutzern und großen Datenmengen betreiben möchte, so ist es mit den 8GB RAM für das Serverchen längst nicht getan... Abgesehen davon, dass es eigentlich vollkommen kontraproduktiv ist, ineffiziente SQL-Abfragen durch ein Caching im Arbeitsspeicher auszugleichen (cf: das Waschbecken läuft über - egal, legen wir einfach mehr Lappen und Handtücher auf den Boden, wozu den Abfluss reinigen?), stellt der Caching-Mechanismus zudem auch noch Anforderungen an den Entwickler. Aufgrund der Zickigkeit von Hibernate müssen unnötige Klassen und Methoden erstellt werden und es müssen Kopplungen zwischen Klassen hergestellt werden, die für die Anwendungslogik keinerlei Sinn machen, sondern einzig und allein dem Zweck der Befriedigung von Hibernate dienen. Jede Entwicklung wird somit dank solcher vermeintlicher hilfreicher Frameworks zu einer schieren Dystopie.

Diese und viele andere Undinge kann man im Twitter-Account ElHiberntico verfolgen - und täglich kommen neue, furchteinflößende, gänsehauterregende oder schlichtweg deprimierende Berichte über die praktische Arbeit mit Hibernate - das Reservoir an möglichen Hibernate-Exceptions scheint nämlich unerschöpflich zu sein:

http://twitter.com/ElHibernetico

Viel Spaß beim Lesen - ich hoffe, es kriegt hier keiner Alpträume. Und wenn doch, dann sollte man einfach zur Beruhigung die Dokumentation zu den MySQL-Funktionen von PHP durchlesen, dann wird alles wieder gut :-)

So long

- Oleg