Slides

Klar, ein eigenes CMS wird kaum noch jemand aufziehen, außer man hat Gründe die ganz klar dafür sprechen. Aber selbst die scheinbar grundlegenden Gebiete wie beispielsweise das Gestalten der HTML Grundstruktur sind nicht so einfach: die verschiedenen IE-Versionen wollen ja unterstützt werden; Firefox, Opera, Safari und Chrome in all ihren Versionen auch; und wie wär’s mit Smartphones und Tablets? Ganz zu schweigen von den ganzen internetfähigen TVs und Spielekonsolen. Außerdem will man ja die neusten Errungenschaften aktueller Browser verwenden: Schatten, runde Boxen, eigene Schriftarten, HTML5-Video und alle anderen interessanten Spielereien.

Ich verwende seit einer ganzen Weile schon 960.gs und andere Frameworks wenn ich eine neue Seite entwerfe, das ist so selbstverständlich wie ein JavaScript-Framework (hat eigentlich noch jemand Lust auf JS ohne jQuery, DOJO und dergleichen?). Allerdings hat sich die Erde seit ich dieses Grundgerüst ausgewählt habe ein wenig weitergedreht und es gibt deutlich bessere Grundgerüste. Alle der folgenden Boilerplates sind nicht nur gute Startpunkte, sondern stellen auch jeweils best practices dar und steigern die eigene Produktivität ungemein.

HTML5 Boilerplate

Hierbei handelt es sich um das derzeit ultimative Grundgrüst für HTML5 Websites, die mit den meisten Browsern kompatibel sein sollen. Es liefert alles was man für einen soliden Start benötigt. Darunter auch Features die man typischerweise erst bemerkt wenns kracht. Beispielsweise wenn das HTML5 Video nicht abspielt, hier würde die Boilerplate Serverkonfiguration greifen, welche die benötigten korrekten Mime-Types setzt. Ferner sind Standardbibliotheken wie jQuery und Modernizr bereits über ein CDN eingebunden, mitsamt lokalem Fallback (ja auch das macht Sinn, die Skripte im CDN sind mit gewisser Wahrscheinlichkeit bereits im Cache des Besuchers, der lokale Fallback greift falls das CDN mal nicht online sein sollte).

Skeleton

Im Vergleich zum oben genannten HTML5 Boilerplate konzentriert Skeleton sich rein auf die Darstellung in unterschiedlichen Medientypen. So wird das Grid beispielsweise in Abhängigkeit von der Fensterbreite ausgerichtet und ist somit auch für die vergleichsweise kleinen Displays auf Smartphones geeignet. Ferner können die media queries dafür verwendet werden, um in Abhängigkeit von der Fläche Schriftarten und weitere Stile entsprechend anzupassen. Hinzu kommen einige UI Elemente, welche ebenfalls mit verschiedenen Gerätearten funktionieren.

HTML Email Boilerplate

Gerne vergessen, aber nicht weniger wichtig im E-Commerce: die HTML-Mail. Hier gelten leicht andere Spielregeln als im Browser, die Clients können auch durchaus selbst Webservices sein, beispielsweise GMail. Dieses Grundgerüst dient als recht solider Startpunkt um mit den verschiedenen Systemen klar zu kommen.

Ich bin da kein Stückchen anders und habe in meiner Sammlung von Snippets eine Methode um einer Seite ein Hintergrundbild zu verpassen und es auf die gesamte verfügbare Fläche des Fensters zu strecken (in diesem Fall leider mit unbekannter Quelle).

html
{
    background: url(pic.jpg) no-repeat center center fixed;
    -webkit-background-size: cover;
    -moz-background-size: cover;
    -o-background-size: cover;
    background-size: cover;
    filter: progid:DXImageTransform.Microsoft.AlphaImageLoader
	    (src='pic.jpg', sizingMethod='scale');
    -ms-filter: "progid:DXImageTransform.Microsoft.AlphaImageLoader
	    (src='pic.jpg', sizingMethod='scale')";
}

Die Vorteile sind schnell erzählt:

• Kommt ohne JavaScript aus
• Funktioniert bei ausreichend vielen Browsern, selbst ältere InternetExplorer Versionen kommen durch den filter-Fallback damit klar
• Das Seitenverhältnis des Bildes bleibt erhalten, überhängende Abschnitte am Rand sind einfach nicht sichtbar
• Die Lösung ist leicht erklärt, schnell eingebaut und nur wenige Zeilen lang

Doch ist leider nicht alles Gold was glänzt. Ja, das Bild wird auch in älteren IE Versionen korrekt dargestellt. Das stand auch so am Fundort und da ich mich nicht nur auf geschriebenes verlasse sondern auch gerne selber teste, ab ins Adobe BrowserLab damit & zu paar anderen Diensten die mir einen Screenshot der Page mit einer gegebenen Browserversion erstellen.

Alles wird korrekt dargestellt, so weit so gut. Bis die Seite live war und ich darauf hingewiesen wurde, dass im IE8 die Links nicht funktionieren. Klasse, live getestet hatte ich wegen Zeitdruck nur mit dem bei mir installierten IE10 und der ist ein wunderbares Beispiel dafür, dass die ganze Emulierung älterer IE-Versionen nicht taugt.

Nach einigem Testen stellte sich heraus, dass eben die filter/-ms-filter Fallbacks bewirken, dass sich das Hintergrundbild scheinbar über die gesamte Page legt und die Klicks deswegen nicht an den Links ankommen. Ähnliche Probleme gibt es auch an anderen Ecken mit filter.

Da geht sie hin, die schöne heile „ich funktioniere in allen Browsern“-Lösung. Die filter-Fallbacks sind nun verschwunden, zusätzlich sorgt ein <!–[if lt IE 9]> dafür, dass alle InternetExplorer bis zur Version 8 einen ganz normalen Hintergrund angezeigt bekommen. Schade :/

Heute kam der Neustart allerdings nicht in Frage, und bevor ich nochmal nach einer besseren Lösung als kill -9 PID suchen muss, hier der (fast) 100%ige Weg zur Erinnerung.

1. Mit ps x die PID des Prozesses ausfindig machen
2. Den Prozessbaum nach dieser PID durchsuchen: ps -ef –forest | less
3. Mit kill PID‘ den Prozess des darüberliegenden Elternknotens beenden

Das dürfte einen Großteil der Zombies erledigen, ansonsten ist es immer einge gute Idee sich die Mounts und die laufenden Dienste nochmal anzuschauen. Eine vergleichbare Lösung gibt es am Fundort im übrigen auch  für Solaris. Nicht vergessen, dass dieser Spaß root-Rechte erfordert, sprich sudo voranstellen oder anderweitig Administrationsrechte organisieren. Wobei gegen manche Zombies aber noch kein Kraut gewachsen ist.

PS: totgesagte Blogs leben länger :)

Eines dieser Features ist die Stocks genannte Metro App. Diese hat allerdings noch keine Suche, und so war ich vorerst nicht in der Lage den DAX als Index hinzuzufügen. Beim Hinzufügen einfach DAX zu schreiben funktioniert leider nicht, es wird “Unable to find that symbol” gemeldet.

Im Kopf hatte ich noch das Symbol ^GDAXI. Und tatsächlich, das wurde akzeptiert. Nur werden hierfür leider keine Werte geliefert. Auch google konnte mir nicht weiterhelfen. Die Idee war nun das gleiche Symbol zu verwenden wie MSN auf der Finance Seite. Das klappte auch.

Um also den DAX hinzuzufügen:

1. Rechtsklick in der Metro App
2. Auf das + Klicken: “Add Stock”
3. Als Symbol $DE:DAX eintippen und auf Add klicken
4. Optional: wieder ein Rechtsklick, gefolgt von einem Klick auf die Stecknadel “Pin Stock”. Im darauffolgenden Dialog eine beliebige Bezeichnung eintippen und der DAX erscheint im Metro-Menü

Hoffe damit irgendwem ein wenig zu helfen. Meine ersten Eindrücke von Windows 8 werde ich demnächst zusammenfassen, möchte das ganze erst noch ein wenig einwirken lassen. Die ersten Eindrücke zu VS11 und den neuen C# & .NET Features wird es auch geben.

Im vergangenen Beitrag habe ich gezeigt wie man mit yield return ein IEnumerable<T> als eine Art Stream erzeugen kann. Bevor ich aber die Vorteile davon aufzeige, muss noch das IShortTuple Interface implementiert werden. Als zusätzliche Einschränkung wählen wir noch, dass diese Implementierung sich in einem Dictionary gut verhalten soll. Das heißt wir wollen möglichst wenige Kollisionen der Hashwerte. Falls es doch zu Kollisionen kommt muss die Equals-Methode herhalten. Gleichheit definieren wir als Wertgleichheit der beiden Properties.

interface IShortTuple
{
    ushort A { get; set; }
    ushort B { get; set; }
}

Nun gibt es im .NET Framework bereits ein Tupel, jedoch verhält es sich eher grottig in Dictionaries (warum sich Tuple<…> so und nicht anders verhält erklärt Microsoft mit dem Einsatzzweck). Jedenfalls scheint das .NET Tuple die Hashcodes der einzelnen Elemente zu nehmen und mit folgender Funktion zu verwursteln (die Macht der Reflection möge mit uns sein)

// Yepp, this is why you should not use tuples of numeric values as dictionary keys
internal static int CombineHashCodes(int h1, int h2)
{
    return (((h1 << 5) + h1) ^ h2);
}

Das Taugt für unseren Einsatzzweck natürlich wenig. Also schreiben wir eine eigene Implementierung, welche bei einem so kleinen Interface kaum der Rede wert ist. GetHashCode() gibt einen Integer zurück und da wir nur zwei shorts haben, können wir eindeutige (im Sinne von “ohne Kollisionen”) Hash-Codes für unsere Implementierung berechnen. Hierzu verschieben wir einen der beiden Werte um 16 Bit und “verodern” (sorry für das Wort) die Beiden zu einem Integer.

struct BitShiftTuple : IShortTuple
{
    public ushort A { get; set; }
    public ushort B { get; set; }

    public override int GetHashCode()
    {
        return A | (B << 16);
    }
}

Mit einer vergleichbaren Implementierung war ich jetzt eine ganze Weile lang zufrieden. Um ehrlich zu sein, war ich gar nicht auf der Suche nach einer besseren Lösung. Beim Stöbern in der MSDN Doku bin ich jedoch auf das StructLayout Attribut gestoßen. Hierdurch kann die Anordnung der Felder in einem Struct explizit angegeben werden, wobei auch Überlappungen möglich sind. Perfekt, so können wir beispielsweise ein Struct definieren, welches Felder für A und B sowie für den Hash hat. Dabei legen wir A und B so in dem Struct aus, dass A den ersten 16 Bit des Structs und B den zweiten 16 Bit entspricht:

[StructLayout(LayoutKind.Explicit)]
internal struct LayoutTuple : IShortTuple
{
    [FieldOffset(0)]
    private int hash;

    [FieldOffset(0)]
    private ushort a;

    [FieldOffset(2)]
    private ushort b;

    public override int GetHashCode()
    {
        return this.hash;
    }

    public ushort A
    {
        get { return this.a; }
        set { this.a = value; }
    }

    public ushort B
    {
        get { return this.b; }
        set { this.b = value; }
    }
}

Den Hash müssen wir demnach gar nicht mehr berechnen. Die Frage die sich nun stellt ist ob uns dies tatsächlich einen Performance-Vorteil gibt. Ebenso muss das mit einer Implementierung verglichen werden, die sich vergleichbar verhält, aber ohne das explizite Layout des Structs auskommt. Das Thema für den nächsten Teil ist also ein 1×1 des Profilings, ich freue mich schon :)

Um die obigen Methoden abzurunden sollte noch Equals überschrieben oder besser IEquatable implementiert werden, wobei der Code einfach nur die Hash-Werte vergleichen muss, falls die zu vergleichenden Objekte unser Interface implementieren (Vorsicht: das Interface gibt ansich nicht vor wie GetHashCode implementiert ist. CodeContracts sind als zukünftiges Thema aber bereits vorgemerkt).

Ich möchte nun in einer kleinen Serie – mit offenem Ziel – kleine, coole und eventuell nicht jedem bekannte C# Features vorstellen. In mundgerechten Häppchen die in einen Feierabend passen: Let’s code :)

Nehmen wir nun kurz an wir wollen eine Liste erstellen. Der Inhalt spielt vorerst keine Rolle, wir müssen ihn nur irgendwie berechnen können. Um in diesem Beispiel mit irgendwas arbeiten zu können, erzeugen wir eine Reihe von Objekten, die durch folgendes Interface definiert sind

internal interface IShortTuple
{
    ushort A {get;set;}
    ushort B {get;set;}
}

Sehr kreativ, ja. Wir erzeugen die Objekte wie folgt:

internal static IEnumerable<T> CreateTestCollection<T>(ushort size)
    where T : IShortTuple, new()
{
    IList<T> tmp = new List<T>();

    for (ushort i = 0; i < size; i++)
    {
        for (ushort j = 0; j < size; j++)
        {
            tmp.Add(new T() { A = i, B = j });
        }
    }

    return tmp;
}

Die Einschränkung bezüglich der Größe ist willkürlich. Wer will aber schon bei solchen Beispielen lange auf Ergebnisse warten? Nun ist die Art wie die Objekte erzeugt werden nicht grade optimal. Wir erzeugen eine Liste, füllen diese von A bis Z und geben sie anschließend an einem Stück zurück. Sprich: der gesamte Thread wartet auf unsere Berechnung. Wenn wir für dieses Beispiel ferner annehmen, dass diese Daten einfach in die Konsole geschrieben werden sollen, wird klar, warum das Vorgehen ungeschickt ist: die erste Ausgabe erfolgt nachdem alles berechnet wurde obwohl wir die ersten Teile bereits kennen.

Nun steht in der Methodensignatur IEnumerable<T>, wir könnten also dieses Interface implementieren und dann auch gleich noch IEnumerator<T> um unser gewünschtes Verhalten zu erreichen. Insgesamt etwas aufwändig, denn es geht viel einfacher:

internal static IEnumerable<T> CreateDebugCollection<T>(ushort size)
    where T : IShortTuple, new()
{
    for (ushort i = 0; i < size; i++)
    {
        for (ushort j = 0; j < size; j++)
        {
            yield return new T() { A = i, B = j };
        }
    }
}

Durch das yield Keyword wird dem Compiler mitgeteilt, dass es sich bei dieser Funktion um einen Iterator-Block handelt. Hierbei werden die einzelnen Werte zurückgegeben sobald sie verfügbar sind, in etwa wie in einem Stream. Iteriert man nun über dieses IEnumerable und schreibt dabei alle Werte in die Konsole wird man merken, dass es keine merkbare Wartezeit gibt bis die ersten Zeilen erscheinen.

In den folgenden Artikeln werde ich verschiedene Aspekte dieser Code-Snippets detailierter betrachten. Unter anderem wie man das Interface IShortTuple am geschicktesten implementiert, einige Messungen mit dem Profiler und einer Priese PLINQ.

Aber zuerst ein paar Worte zu meiner Leitung. Ich surfe mit “bis zu 18Mbit/s”, wenn ich 14 bis 16Mbit/s behaupte ist das aber realistischer. Besonders in Anbetracht der Tatsache, dass gute 16000er Leitungen auch 1-2Mbit hinter dieser Höchstmarke zurückbleiben (nicht gute Leitungen um ein ganzes Stückchen mehr). Wie testet man das aber wenn Speedtests nicht akkurat sind? Ein guter Anhaltspunkt ist die Geschwindigkeit die sich einpendelt wenn man eine etwas größere Datei läd. Und bitte nicht die größte Zahl aussuchen die kurzfristig angezeigt wird sondern mit dem Selbstbetrug aufhören und an das glauben was sich nach einer ganzen Weile einpendelt. So sieht man auf dem ersten Screenshot wie die Übertragung bei 3,1MB/s (= 24,8Mbit/s) einen Peak hat, was aber weit über den Möglichkeiten meiner Leitung liegt und sich später bei 1,7-1,8MB/s einpendelt (= 13,6 bis 14,4Mbit/s).

Ferner wird gerne angezeigt wie hoch (bzw. niedrig) der Ping ist. Gemeint ist damit die Latenz zwischen Absenden eines Pakets und dem Empfang der Antwort. Hier gilt je weniger desto besser. Dieser Wert lässt sich mit praktisch jedem PC nachmessen indem der Befehl ping gefolgt von einem Ziel eingetragen wird. Dies funktioniert mit Windows Systemen genau so, hierzu wird die Eingabeaufforderung gestartet (Visa/7: Windows-Taste -> cmd -> Enter; XP: Start -> Ausführen -> cmd.exe). Als Ziele eignen sich “google.de” oder die Domain des Internetanbieters oder jede größere Website. Mein Ping schwankt, je nach Ziel, zwischen 15ms und 30ms (außerhalb Deutschlands durchaus mal mehr).

Aber nun zu unseren Speedtests. Die beiden Tests decken zwei Extremfälle ab, der erste nimmt eine zu geringe Datenmenge für die Übertragung, das Ergebnis ist stark nach Oben verfälscht. Dem Zweiten möchte ich fast vorsätzliche Täuschung unterstellen, das ist aber meine persönliche Meinung und die Messgruppe ist mit einer Person auch relativ gering. Es kann natürlich auch irgendwo anders ein Problem bestehen.

Der Speedtest von Unitymedia zeigt mir im Schnitt um die 50Mbit/s an, das wären um die 6MB/s. Würde ich dies glauben sollte ich gleich mal eine Packung Merci an meinen ISP versenden, ein sensationelles Ergebnis. Natürlich aber leider falsch. Die anderen Werte sehen realistisch aus bei nomalen Servern in Deutschland.

Bei Kabel Deutschland sehen wir ein deutlich anderes Ergebnis. 3,135Mbit/s (hier würden Programme schon kB/s als Einheit wählen). So viel schafft sogar mein Handy, nein es schafft sogar mehr. Der Wert für die Upload-Geschwindigkeit ist ebenfalls etwas arg schlecht. Vom Ping müssen wir gar nicht reden, vor wenigen Tagen hatte ich einen besseren Wert zum Rechner meines Bruders (und der hat sicherlich eine schlechtere Anbindung als ein Server bei Kabel Deutschland). In anderen Worten: M-Net zu Vodafone/Arcor-Anwender war konstant unter 50ms, Kabel Deutschland zeigt mir über 60ms.

Unrealistische Werte? Messen wir doch mal selbst nach:

Hört hört, 28ms. Und auch beim Download bekomme ich auf Kabel Deutschland Servern deutlich mehr hin als beim Speedtest. Im Endeffekt bleibt es jeder Person selbst überlassen ob sie den Messergebnissen und Studien derjenigen glaubt die im gleichen Atemzug ein entsprechendes Produkt verkaufen wollen. Ich bin mir aber sicher, dass Kabel Deutschland eine ganze Stange an Faktoren aufzählen kann die solche Ergebnisse rechtfertigen (und warum ich unrecht habe und sie hier einfach nur schlechtmachen will, oder so).

Informatik Anfänger müssen sich zumindest nicht dafür schämen die Antwort gegooglet zu haben. Die folgenden Beispiele sind in C# geschieben, gelten jedoch im Prinzip auch für Java.

Sowohl ++i als auch i++ inkrementieren i um 1. Der Unterschied ist das “Ergebnis” dieser Auswertung. Damit meine ich nicht das Ergebnis, dass i um eins größer geworden ist, sondern den Rückgabewert. Man könnte ja auf die Idee kommen x = ++i zu schreiben und y = i++. In diesem Fall wären x und y nicht gleich. ++i inkrementiert zuerst i und wird dann zugewiesen, i++ wird zuerst zugewiesen und dann inkrementiert. Die Variable x wäre in diesem Beispiel also um eins größer als y.

Als Funktion kann man sich das in etwa so vorstellen für i++

static int VarPlusPlus(ref int variable)
{
    int tmp = variable;
    variable += 1;
    return tmp;
}

und wie folgt für ++i.

static int PlusPlusVar(ref int variable)
{
    variable += 1;
    return variable;
}

Das ref bedeutet übrigens, dass i als Referenz übergeben wird und Änderungen in der Funktion an i auch außerhalb gültig sein werden (so wie man es von Objekten gewohnt ist). Aber das zu erklären ist ein anderes Thema.

Falls der Unterschied weiterhin nicht klar sein sollte, kann man es sich an einem kleinen Test verbildlichen. Unser Code:

Console.WriteLine("i++");
int i = 0;
Console.WriteLine("A: " + i++);
Console.WriteLine("B: " + i);

Console.WriteLine("++i");
i = 0;
Console.WriteLine("A: " + ++i);
Console.WriteLine("B: " + i);

und für die beiden Funktionen von oben

Console.WriteLine("VarPlusPlus");
i = 0;
Console.WriteLine("A: " + VarPlusPlus(ref i));
Console.WriteLine("B: " + i);

Console.WriteLine("PlusPlusVar");
i = 0;
Console.WriteLine("A: " + PlusPlusVar(ref i));
Console.WriteLine("B: " + i);

Und wie wirkt sich das auf Schleifen aus? Die kurze Antwort lautet: in C# kein bischen. Die lange Antwort braucht etwas mehr Platz. Zuerst der einfache Teil. Das Ergebnis der beiden folgenden Schleifen ist gleich, da der dritte Block der for-Schleife separat ausgewertet wird und die inkrementierte Variable verwendet wird, nicht der oben erwähnte Rückgabewert (es könnte dort ja auch x += 4 stehen).

Console.Write("i++ loop");
for (i = 0; i < 5; i++)
{
    Console.Write(" " + i);
}

Console.WriteLine();
Console.Write("++i loop");
for (i = 0; i < 5; ++i)
{
    Console.Write(" " + i);
}

Man wird trotzdem häufiger über Menschen stolpern, die ++i in for-Schleifen bevorzugen. Die Gründe hierfür sind verschieden, es fängt mit der persönlichen Preferenz an und endet mit Performance-Argumenten. So wird es hier und da heißen, dass i++ über ++i implementiert wird und i++ intern eine Kopie benötigt (vergleichbar mit den beiden oben erwähnten Funktionen).

Betrachtet man C# so ist dies allerdings keine wahre Aussage, zumindest nachdem der C# Compiler drübergelaufen ist. Denn das Resultat ist in C# völlig identisch und ich würde behaupten, dass dies auch für die meisten anderen Hochsprachen gelten wird.

Woher kommt dieser “Mythos” also? Lässt man den Personenkreis der einfach “anders” sein möchte mal außen vor, so werden es meistens ehemalige C++ Programmierer sein die (beim Namen C++ ausgerechnet) ++i bevorzugen. Denn gerade dort gehört es zum guten Ton die Präfix-Schreibweise zu verwenden. Ohne es zu wissen, würde ich zwar kurzerhand behaupten, dass die zusätzliche Kopie bei einem Integer auch bei C++ vom Compiler “wegoptimiert” wird, jedoch muss man ein wichtiges Detail beachten. C++ unterstüzt das Überschreiben von Operatoren und im Vergleich zu C# kann dort eben auch das ++ überschrieben werden. Und dafür, dass diese zusätzliche Kopie auch bei komplexen Klassen und in allen Fällen wegoptimiert wird, würde ich meine Hand nicht ins Feuer legen. Erst recht nicht wenn es um die Compiler vor 10, 20 oder mehr Jahren geht.

Lasst euch in C# oder Java also nicht von i++ oder ++i in for-Schleifen verwirren, da passiert nichts magisches. Der Programmierer hat sich einfach über Jahre an die Prefix-Schreibweise gewöhnt, oder möchte einfach ein wenig besonders sein :)

Es geht mir aber um etwas ganz anderes, denn zu Guttenberg wird derzeit zum alleinigen Sündenbock gemacht. Und obwohl die derzeitige Diskussion für viele Personen und Institutionen der Anlass hätte sein können mal ordentlich vor der eigenen Tür zu fegen, scheinen genau diese Personen jetzt nochmal ordentlich – zu gut Deutsch – „auf die Kacke zu hauen“. Selbst die katholische Kirche hat im Jahr 2010 mehr Willen zur Aufdeckung von Missständen gezeigt. Geschichten von Doktoranden, die nach 4 Jahren Nichtstun trotzdem ihren PhD bekommen oder von solchen, die ohne Hiwis keine Zeile Code hinbekommen hätten gibt es zu genüge, einige davon kenne ich aus erster Hand.

Heute früh sah ich ein Video das in der Kategorie „Wer im Glashaus sitzt…“ ganz weit oben rangiert. Es ist das Statement von Prof. Oliver Lepsius, seines Zeichens Staatsrechtler in Bayreuth, zur Causa Guttenberg. Prof. Lepsius geht mit dem Baron sehr scharf ins Gericht:

„Für mich steht außer Frage, dass – Herr zu Guttenberg ein Betrüger ist. Er hat planmäßig plagiiert, er hat eine Kollage von Plagiaten angefertigt.“

Gut(t) (sorry), der Aktuelle Stand des GuttenPlag Wikis scheint das erstmal zu bestätigen. Und auch sonst könnte dieses Interview – beim am Sonntag Morgen zugegeben recht müden Zuschauer – den Eindruck hinterlassen, dass hier endlich mal einer das sagt was gesagt werden muss.

Aber Moment mal, Bayreuth? Staatsrecht? Stimmt ja, da war der Baron, und grade aus Bayreuth kommt dann eine solche Antwort auf die Frage: “Wenn ein Student bei Ihnen eine solche Arbeit abliefern würde, mit den objektiven Passagen die von Anderen abgeschrieben worden sind, was würden Sie dem sagen wenn er sagen würde das hätte er gar nicht bemerkt?“:

„Ich würde ihn auslachen. [...] Wir reden [über] jemanden, der eine Arbeit abgibt am Ende eines langjährigen Promotionsverhältnisses, am Ende von jahrelangen Gesprächen mit dem Betreuer.“

Die Frage ist doch, warum wurde Guttenberg nicht ausgelacht? Hat in diesem Fall nicht das gesamte System versagt? Wie kann jemand eine „Kollage von Plagiaten“ abgeben, nachdem er jahrelang in engem Kontakt mit seinem Doktorvater stand? Noch bitterer wird die Geschichte wenn man auch die Abgründe der „Scientific Community“ in Deutschland kennt. Ich weiß, dass sich der Text dort anfangs so liest als hätte ein böser Professor dem Autor den Lolli geklaut, trotz aller Skepsis gehe ich mittlerweile aber davon aus, dass die dort geschilderten Sachverhalte der Wahrheit entsprechen (ich würde zumindest nicht behaupten, dass soetwas unmöglich erscheint).

In einer Randnotiz sagt Prof. Lepsius noch, dass ihn ein psychologisches Gutachten interessieren würde. Mich interessiert wie man sich so weit aus dem Fenster lehnen kann, wenn das eigene Nest grade ziemlich mies riecht. Ich bin zwar kein Psychologe, aber es sieht für mich auf allen Seiten (Guttenberg, Uni, Politik) nach genau dem selben Verhalten aus wie es der ein oder andere Banker vor nicht all zu langer Zeit an den Tag gelegt hat. Besonders wenn man sich noch folgende Aussage auf der Zunge zergehen lässt (zusammen mit meinem leckeren Sonntagsfrühstück):

Ich glaube aber, dass [...] aus dieser Situation gestärkt hervorgehen wird. [...] Und es werden die Konsequenzen gezogen. Die Gremien [...] haben schnell und solide gehandelt. Insofern können Sie auch sagen, ist die Welt auch wieder in Ordnung. Ich meine wo Menschen handeln, passieren Fehler.

… und sorry nochmal wegen der Milliarden an Steuergeldern mit denen wir gerettet werden mussten. Schuld waren aber eh die anderen.

Und bevor mir ein peinlicher Fehler unterläuft und ich temporär für immer auf meinen MSc oder mein Blog verzichten muss, möchte ich noch Nine99 als Quelle des Videos und des Links zum Artikel auf forschungsmafia.de nennen.