ALBERT

Note: Erscheinungsjahr in Vorlageform:2008

Note: Inhalt: Vorwort. - Vorwort zur 2.Auflage. - TEIL I GRUNDLAGEN DER HISTORISCHEN KLIMAFORSCHUNG. - Klima in Perspektive: Eine Einführung. - Begründung und Forschungsansätze. - Forschungssituation in Mitteleuropa. - Auf Spurensuche: Quellen, Daten und Zitate. - Chroniken und Annalen: Die ersten Spuren von Wetter, Witterung und Klima. - Quelleninformation - Quellenbezug - Quellenkompilation: Die Dhein-Chronik. - Als das Wetter zum täglichen Ereignis wurde: Wetterjournale. - Vom Wetter auf See: Schiffsjournale. - Vom Wetter unterwegs: Itinerare. - Wetter nach Maß: Die Anfänge der Instrumentenmessung. - Gemalt, gepinselt und gehämmert: Bildhafte und plastische Informationen zum historischen Klima. - Klima auf Umwegen: Proxydaten. - Methoden zur Klimarekonstruktion. - "Hat man mir wahrhafftiglich versicheret": Die quellenkritische Interpretation von schriftlichen Quellenhinweisen. - Klima-, Witterungs- und Wettervorstellungen: Ein Beitrag zur Quellenkritik. - Quelle - Index - Klimawert: Die Transformation schriftlicher Klimahinweise. - Tägliche Wetteraufzeichnungen: Rückblicke der besonderen Art. - Historische Instrumentenmessdaten: Ein Brückenschlag zur Moderne. - Proxydaten: Ihre klimatische Interpretation. - Methoden: Eine Nachbetrachtung. - HISKLID: Aufbau und Struktur der Historischen Klimadatenbank. - TEIL II HITZE, FLUTEN, EIS UND STURM IM SPIEGELBILD DER QUELLEN. - Vom Optimum der Römerzeit über das Pessimum der Völkerwanderung ins Mittelalterliche Wärmeoptimum. - Prolog zum Mittelalterlichen Wärmeoptimum. - Das Klima von 1000 bis 1500. - Warme Zeiten - kalte Zeiten: Die Sommerverhältnisse von 1000 und 1500. - Aus der Kältekammer ins Treibhausklima: Die Winterverhältnisse von 1000 bis 1500. - Im Märzen der Bauer? Die Frühlingsverhältnisse von 1000 bis 1500. - Altweibersommer oder Herbststürme? Die Herbstverhältnisse von 1000 bis 1500. - Das Klima von 1500 bis 2000. - Der jährliche Witterungsgang von 1500 bis 1750. - Zur Kleinen Eiszeit - ein Epilog. - Aus der Kleinen Eiszeit ins Treibhausklima: Die Verhältnisse ab 1750. - Die derzeitigen Folgen. - Der Klimagang der letzten 1000 Jahre - eine Zusammenschau. - Der methodische Weg. - Zum Klimaverlauf ab dem Jahr 1000. - Zur Frage der Steuerungsmechanismen. - Klimarekonstruktionen und -simulationen der letzten 1000 Jahre auf der Basis von naturwissenschaftlichen Daten. - Wenn sich Wetter und Klima zur Katastrophe auswachsen. - Unwetter über Mitteleuropa. - Gewitter in Mitteleuropa. - Stürme und Orkane über Deutschland. - Die Sturmfluten an der deutschen Nord- und Ostseeküste. - Hochwasserereignisse an deutschen Flüssen. - Historische Hochwasser und Atmosphärische Zirkulationsdynamik. - Jahrhundert- und Jahrtausendhochwasser. - Höhenrauch - Sommerhitze - Winterstrenge - Hochwasser: Vier Schritte in die Katastrophe. - Die Hochwasserkatastrophe von 1824 am Neckar und aktuelle planerische Konsequenzen. - Klimakatastrophen in Mitteleuropa: Eine Nachlese. - Die zukünftige Entwicklung des Klimas und die Auswirkungen des Klimawandels in Mitteleuropa. - Die ökonomischen Folgen. - Erkenntniswege zum Treibhausklima. - Die historische Entwicklung des politischen Handlungsrahmens. - 1200 Jahre Klimageschichte: Ein Resümee. - Anhang. - Abkürzungen. - Literaturverzeichnis. - Sachregister. - Ortsregister.

Note: Inhaltsverzeichnis Vorwort Einführung 1 Sauberer Code 1.1 Code, Code und nochmals Code 1.2 Schlechter Code 1.3 Die Lebenszykluskosten eines Chaos Das große Redesign in den Wolken Einstellung Das grundlegende Problem Sauberen Code schreiben - eine Kunst? Was ist sauberer Code? 1.4 Denkschulen 1.5 Wir sind Autoren 1.6 Die Pfadfinder-Regel 1.7 Vorläufer und Prinzipien 1.8 Zusammenfassung 2 Aussagekräftige Namen 2.1 Einführung 2.2 Zweckbeschreibende Namen wählen 2.3 Fehlinformationen vermeiden 2.4 Unterschiede deutlich machen 2.5 Aussprechbare Namen verwenden 2.6 Suchbare Namen verwenden 2.7 Codierungen vermeiden Ungarische Notation Member-Präfixe Interfaces und Implementierungen 2.8 Mentale Mappings vermeiden 2.9 Klassennamen 2.10 Methodennamen 2.11 Vermeiden Sie humorige Namen 2.12 Wählen Sie ein Wort pro Konzept 2.13 Keine Wortspiele 2.14 Namen der Lösungsdomäne verwenden 2.15 Namen der Problemdomäne verwenden 2.16 Bedeutungsvollen Kontext hinzufügen 2.17 Keinen überflüssigen Kontext hinzufügen 2.18 Abschließende Worte 3 Funktionen 3.1 Klein! Blöcke und Einrückungen 3.2 Eine Aufgabe erfüllen Abschnitte innerhalb von Funktionen 3.3 Eine Abstraktionsebene pro Funktion Code Top-down lesen: die Stepdown-Regel 3.4 Switch-Anweisungen 3.5 Beschreibende Namen verwenden 3.6 Funktionsargumente Gebräuchliche monadische Formen Flag-Argumente Dyadische Funktionen Triaden Argument-Objekte Argument-Listen Verben und Schlüsselwörter 3.7 Nebeneffekte vermeiden Output-Argumente 3.8 Anweisung und Abfrage trennen 3.9 Ausnahmen sind besser als Fehler-Codes Try/Catch-Blöcke extrahieren Fehler-Verarbeitung ist eine Aufgabe Der Abhängigkeitsmagnet Error.java 3.10 Don't Repeat Yourself 3.11 Strukturierte Programmierung 3.12 Wie schreibt man solche Funktionen? 3.13 Zusammenfassung 3.14 SetupTeardownlnduder 4 Kommentare 4.1 Kommentare sind kein Ersatz für schlechten Code 4.2 Erklären Sie im und durch den Code 4.3 Gute Kommentare Juristische Kommentare Informierende Kommentare Erklärung der Absicht Klarstellungen Warnungen vor Konsequenzen TODO-Kommentare Verstärkung Javadocs in öffentlichen APIs 4.4 Schlechte Kommentare Geraune Redundante Kommentare Irreführende Kommentare Vorgeschriebene Kommentare Tagebuch-Kommentare Geschwätz Beängstigendes Geschwätz Verwenden Sie keinen Kommentar, wenn Sie eine Funktion oder eine Variable verwenden können Positionsbezeichner Kommentare hinter schließenden Klammern Zuschreibungen und Nebenbemerkungen Auskommentierter Code HTML-Kommentare Nicht-lokale Informationen Zu viele Informationen Unklarer Zusammenhang Funktions-Header Javadocs in nicht-öffentlichem Code Beispiel 5 Formatierung 5.1 Der Zweck der Formatierung 5.2 Vertikale Formatierung Die Zeitungs-Metapher Vertikale Offenheit zwischen Konzepten Vertikale Dichte Vertikaler Abstand Vertikale Anordnung 5.3 Horizontale Formatierung Horizontale Offenheit und Dichte Horizontale Ausrichtung Einrückung Dummy-Bereiche 5.4 Team-Regeln 5.5 Uncle Bobs Formatierungsregeln 6 Objekte und Datenstrukturen 6.1 Datenabstraktion 6.2 Daten/Objekt-Anti-Symmetrie 6.3 Das Law of Demeter Zugkatastrophe Hybride Struktur verbergen 6.4 Datentransfer-Objekte Active Record 6.5 Zusammenfassung 7 Fehler-Handling 7.1 Ausnahmen statt Rückgabe-Codes 7.2 Try-Catch-Finally-Anweisungen zuerst schreiben 7.3 Unchecked Exceptions 7.4 Ausnahmen mit Kontext auslösen 7.5 Definieren Sie Exception-Klassen mit Blick auf die Anforderungen des Aufrufers 7.6 Den normalen Ablauf definieren 7.7 Keine Null zurückgeben 7.8 Keine Null übergeben 7.9 Zusammenfassung 8 Grenzen 8.1 Mit Drittanbieter-Code arbeiten 8.2 Grenzen erforschen und kennen lernen 8.3 log4J kennen lernen 8.4 Lern-Tests sind besser als kostenlos 8.5 Code verwenden, der noch nicht existiert 8.6 Saubere Grenzen 9 Unit-Tests 9.1 Die drei Gesetze der TDD 9.2 Tests sauber halten Tests ermöglichen die -heiten und -keiten 9.3 Saubere Tests Domänenspezifische Testsprache Ein Doppelstandard 9.4 Ein assert pro Test Ein Konzept pro Test 9.5 F.I.R.S.T 9.6 Zusammenfassung 10 Klassen 10.1 Klassenaufbau Einkapselung 10.2 Klassen sollten klein sein! Fünf Methoden sind nicht zu viel, oder? Das Single-Responsibility-Prinzip Kohäsion Kohäsion zu erhalten, führt zu vielen kleinen Klassen 10.3 Änderungen einplanen Änderungen isolieren 11 Systeme 11.1 Wie baut man eine Stadt? 11.2 Konstruktion und Anwendung eines Systems trennen Trennung in main Factories Dependency Injection 11.3 Aufwärtsskalierung Cross-Cutting Concerns 11.4 Java-Proxies 11.5 Reine Java-AOP-Frameworks 11.6 AspectJ-Aspekte 11.7 Die Systemarchitektur testen 11.8 Die Entscheidungsfindung optimieren 11.9 Standards weise anwenden, wenn sie nachweisbareinen Mehrwert bieten 11.10 Systeme brauchen domänenspezifische Sprachen 11.11 Zusammenfassung 12 Emergenz 12.1 Saubere Software durch emergentes Design 12.2 Einfache Design-Regel 1: Alle Tests bestehen 12.3 Einfache Design-Regeln 2-4: Refactoring 12.4 Keine Duplizierung 12.5 Ausdrucksstärke 12.6 Minimale Klassen und Methoden 12.7 Zusammenfassung 13 Nebenläufigkeit 13.1 Warum Nebenläufigkeit? Mythen und falsche Vorstellungen 13.2 Herausforderungen 13.3 Prinzipien einer defensiven Nebenläufigkeitsprogrammierung Single-Responsibility-Prinzip Korollar: Beschränken Sie den Gültigkeitsbereich von Daten Korollar: Arbeiten Sie mit Kopien der Daten Korollar: Threads sollten voneinander so unabhängig wie möglich sein 13.4 Lernen Sie Ihre Library kennen Thread-sichere Collections 13.5 Lernen Sie Ihre Ausführungsmodelle kennen Erzeuger-Verbraucher Leser-Schreiber Philosophenproblem 13.6 Achten Sie auf Abhängigkeiten zwischen synchronisierten Methoden 13.7 Halten Sie synchronisierte Abschnitte klein 13.8 Korrekten Shutdown-Code zu schreiben, ist schwer 13.9 Threaded-Code testen Behandeln Sie gelegentlich auftretende Fehler als potenzielle Threading-Probleme Bringen Sie erst den Nonthreaded-Code zum Laufen Machen Sie Ihren Threaded-Code pluggable Schreiben Sie anpassbaren Threaded-Code Den Code mit mehr Threads als Prozessoren ausführen Den Code auf verschiedenen Plattformen ausführen Code-Scheitem durch Instrumentierung provozieren Manuelle Codierung Automatisiert 13.10 Zusammenfassung 14 Schrittweise Verfeinerung 14.1 Args-Implementierung Wie habe ich dies gemacht? 14.2 Args: der Rohentwurf Deshalb hörte ich auf Über inkrementelle Entwicklung 14.3 String-Argumente 14.4 Zusammenfassung 15 JUnit im Detail 15.1 Das JUnit-Framework 15.2 Zusammenfassung 16 Refactoring von SerialDate 16.1 Zunächst bring es zum Laufen! 16.2 Dann mach es richtig! 16.3 Zusammenfassung 17 Smells und Heuristiken 17.1 Kommentare C1: Ungeeignete Informationen C2: Überholte Kommentare C3: Redundante Kommentare C4: Schlecht geschriebene Kommentare C5: Auskommentierter Code 17.2 Umgebung E1: Ein Build erfordert mehr als einen Schritt E2: Tests erfordern mehr als einen Schritt 17.3 Funktionen F1: Zu viele Argumente F2: Output-Argumente F3: Flag-Argumente F4: Tote Funktionen 17.4 Allgemein G1: Mehrere Sprachen in einer Quelldatei G2: Offensichtliches Verhalten ist nicht implementiert G3: Falsches Verhalten an den Grenzen G4: Übergangene Sicherungen G5: Duplizierung G6: Auf der falschen Abstraktionsebene codieren G7: Basisklasse hängt von abgeleiteten Klassen ab G8: Zu viele Informationen G9: Toter Code G10: Vertikale Trennung G11: Inkonsistenz G12: Müll G13: Künstliche Kopplung G14: Funktionsneid G15: Selektor-Argumente G16: Verdeckte Absicht G17: Falsche Zuständigkeit G18: Fälschlich als statisch deklarierte Methoden G19: Aussagekräftige Variablen verwenden G20: Funktionsname sollte die Aktion ausdrücken G21: Den Algorithmus verstehen G22: Logische Abhängigkeiten in physische umwandeln G23: Polymorphismus statt If/Else oder Switch/Case verwenden G24: Konventionen beachten G25: Magische Zahlen durch benannte Konstanten ersetzen G26: Präzise sein G27: Struktur ist wichtiger als Konvention G28: Bedingungen einkapseln G29: Negative Bedingunge