Beiträge von MarkusWB

Hallo Anna, Tobi hat die Kategorien schon sehr gut aufgezählt. Ich würde deiner Fallstudie noch einen zweiten Teil spendieren: nicht nur bewerten, wie stark der Lock-in ist, sondern auch, welche Gegenmaßnahmen das Unternehmen hätte ergreifen können. Das macht sich in einer Projektarbeit meistens gut, weil es zeigt, dass du über die reine Analyse hinausdenkst.

Typische Gegenmaßnahmen, die in der Literatur und auch bei uns im Studium immer wieder genannt werden:

• Multi-Cloud-Strategie: Anwendungen bewusst so bauen, dass sie auf mehreren Anbietern lauffähig sind, z. B. über Containerisierung. Das reduziert zwar nicht automatisch alle Abhängigkeiten, verteilt aber das Risiko.
• Offene Standards und Abstraktionsschichten: Statt direkt gegen die proprietäre API zu programmieren, eine eigene Schnittstellenschicht einziehen, die die Anwendung vom konkreten Dienst entkoppelt. Kostet am Anfang Mehraufwand, zahlt sich aber beim Wechsel aus.
• Standardisierte Datenformate: Wo möglich offene Formate nutzen statt anbieterspezifischer Exporte, damit eine Migration ohne großen Qualitätsverlust läuft.
• Infrastructure-as-Code mit neutralen Tools: Es gibt Automatisierungswerkzeuge, die mehrere Cloud-Anbieter ansprechen können, statt sich auf die anbieterspezifische Lösung festzulegen.

Wichtig für deine Bewertung: Diese Maßnahmen schließen sich meist nicht gegenseitig aus, sondern wirken nur, wenn man mehrere kombiniert. Und man sollte in der Fallstudie auch ehrlich abwägen, dass komplette Anbieterunabhängigkeit oft teurer in der Entwicklung ist – das ist ja gerade der Trade-off, den Unternehmen eingehen.

Eigentlich bin ich eher im Elektrotechnik-Bereich unterwegs, aber in meinem Fernstudium läuft eine Einsendeaufgabe zur Wirtschaftsinformatik mit rein, und dort soll ich einen Geschäftsprozess als BPMN-Diagramm abbilden. Grundsätzlich verstehe ich das Prinzip mit Start- und Endereignissen, Aktivitäten und Gateways, aber bei den Gateway-Typen komme ich ständig durcheinander.

Exklusiv (XOR) habe ich mir noch halbwegs gemerkt – da geht nur ein Pfad weiter. Aber bei parallel (AND) und inklusiv (OR) verwechsle ich ständig, welches jetzt zwingend alle Pfade gleichzeitig öffnet und welches optional mehrere Pfade erlaubt. In der Aufgabe hatte ich einen Fall, wo je nach Bestellung sowohl Rechnung als auch Lieferschein UND ggf. noch eine Sonderfreigabe nötig ist, und ich wusste nicht, ob das jetzt parallel oder inklusiv sein muss.

Hat jemand eine einfache Eselsbrücke oder Faustregel, mit der man das auch unter Zeitdruck in der Klausur schnell und sicher zuordnen kann, ohne jedes Mal lange nachzudenken?

Marco hat das schon gut zusammengefasst, ich will nur noch einen Kniff ergänzen, der mir bei Sarrus geholfen hat, als ich selbst ständig die Vorzeichen verhauen habe.

Ich schreibe mir die Vorzeichen nicht erst am Ende dazu, sondern baue sie von Anfang an als festes Schema über die Zahlen. Konkret mache ich das so:

• Matrix zweimal nebeneinander, wie Marco beschrieben hat.
• Über jede der drei Hauptdiagonalen schreibe ich klein ein "+", über jede Nebendiagonale ein "−", bevor ich überhaupt irgendetwas ausrechne.
• Erst danach setze ich die Produkte ein, inklusive der Vorzeichen, die schon in der Matrix stehen. Also z.B. (−2)·5·(−3) als ein Produkt, nicht in Einzelschritten im Kopf.
• Am Ende steht da eine Kette aus plus und minus, die ich stur von links nach rechts abarbeite, ohne nochmal zu überlegen, "war das jetzt eine Haupt- oder Nebendiagonale".

Der Trick dahinter: Du trennst das Erkennen des Vorzeichens (Diagonale ja/nein) komplett vom Rechnen mit negativen Zahlen in der Matrix. Genau diese Vermischung ist bei mir früher die Fehlerquelle gewesen, vor allem unter Zeitdruck in der Klausur.

Zur Kontrolle nutze ich übrigens gern die Eigenschaft, dass sich die Determinante nicht ändert, wenn ich eine Zeile mit einem Vielfachen einer anderen addiere. Damit kann ich mir vor dem Sarrus noch schnell eine Null in die Matrix "zaubern" und hinterher mit Laplace querchecken.

Daniel, dem kann ich mich anschließen, und ich kenne genau diese Überlegung noch aus meinem eigenen Projekt. Ein Aspekt, der in der Diskussion hier noch etwas kurz kam: der Deployment-Aufwand lässt sich sehr gut quantitativ in der Hausarbeit argumentieren, nicht nur qualitativ.

Ich würde in der Arbeit kurz skizzieren, was ein produktiver Betrieb deiner 3-4 Microservices tatsächlich bedeuten würde: jeder Service braucht ein eigenes Deployment-Artefakt, eine eigene Pipeline-Konfiguration, eigene Health-Checks, eigene Versionierung der Schnittstellen. Dazu kommt Betriebsverantwortung, die bei dir als Einzelperson ja komplett auf dich fällt – es gibt niemanden, der parallel einen anderen Service betreut. Das lässt sich schön als Argument formulieren: der organisatorische Nutzen von Microservices (parallele, unabhängige Teams) entsteht erst, wenn tatsächlich mehrere Personen unabhängig deployen. Bei einer Person fällt dieser Vorteil komplett weg, der Aufwand bleibt aber bestehen.

Merksatz, den ich mir dafür notiert habe: Microservices verschieben Komplexität von innerhalb des Codes nach außen in die Infrastruktur – das lohnt sich nur, wenn du diese Infrastruktur-Komplexität auch wirklich brauchst, sonst zahlst du nur drauf. Für die Bewertung ist es meiner Erfahrung nach überzeugender, wenn du diese Kosten-Nutzen-Abwägung explizit machst, statt die Architektur einfach zu setzen.

Marco und Robert haben das Gerüst wirklich sauber zusammengefasst, da gibt's fachlich nichts zu ergänzen. Ich schreib trotzdem noch was zur Abbruchbedingung dazu, weil mich das in der Klausur am meisten Zeit gekostet hat, bis ich einen festen Reflex dafür hatte.

Ich geh in der Klausur immer so vor: Nach jedem Umformungsschritt lese ich NUR die Z-Zeile von links nach rechts durch den Variablenbereich (also bis zur RHS-Spalte, die zählt nicht mit). Sobald dort alle Einträge ≥ 0 sind, ist Schluss – fertig optimiert. Ich markiere mir dabei testweise negative Werte mit einem Minuszeichen am Rand, dann sehe ich auf einen Blick, ob noch was zu tun ist, ohne die ganze Zeile nochmal gedanklich durchzugehen.

Ein Punkt, der mir in der Klausur Zeit gespart hat: Ich prüfe die Abbruchbedingung VOR der Quotientenregel, nicht erst danach. Wenn die Z-Zeile schon sauber ist, spare ich mir die ganze Pivotzeilen-Rechnung im letzten Schritt komplett.

Noch ein Tipp aus eigener Erfahrung: Am Ende immer kurz die Lösung in die ursprünglichen Nebenbedingungen einsetzen und die Probe machen. Mir ist in der Klausur einmal ein Vorzeichenfehler in der Z-Zeile durchgerutscht, und ohne Probe hätte ich das nicht gemerkt – das Tableau sah "fertig" aus, war aber falsch umgeformt.

Starker Thread, da sind schon richtig viele gute Ansätze zusammengekommen. Ich will noch einen ganz pragmatischen Punkt ergänzen, den ich bei meinen eigenen Einsendeaufgaben in der Elektrotechnik-Richtung öfter genutzt habe: Wenn man den VIF über die Software laufen lässt, lohnt es sich, die Variablen vorher zu standardisieren (also z-transformieren). Das ändert zwar nichts am VIF-Wert selbst, weil der ja aus dem R² der Hilfsregression kommt und das ist skaleninvariant, aber es macht die Koeffizienten in der Hilfsregression viel besser vergleichbar, wenn du dir die Ausgabe genauer anschaust, um zu verstehen, welche Variable wie stark zum Problem beiträgt.

Praktisch gehe ich bei VIF-Checks immer so vor:

• Erst das Gesamtmodell rechnen und R² bzw. F-Test notieren, als Referenzpunkt
• Dann VIF für jede Variable einzeln prüfen und wie Marco schon sagte, die Grenzwerte nicht stur anwenden, sondern im Kontext der Fallzahl sehen, bei kleinen Stichproben sind die Standardfehler ohnehin schon größer
• Zum Schluss den von Robert erwähnten Stabilitätstest, also Variable raus und schauen, ob sich die übrigen Koeffizienten stark bewegen

Gerade der letzte Schritt hat mir in der Hausarbeit mehr gebracht als die reine VIF-Zahl, weil ich damit auch Zusammenhänge sichtbar machen konnte, die nicht sofort offensichtlich waren. Viel Erfolg, Robert, klingt so, als hättest du jetzt ein gutes Werkzeugset für die Diskussion im Text.

Eigentlich bin ich ja eher im Elektrotechnik-Bereich unterwegs, aber Wirtschaftsinformatik hatte ich als Wahlmodul mit drin und jetzt sitze ich an genau dieser Cloud-Frage fest. Im Skript stehen SaaS, PaaS und IaaS nur mit ein, zwei Sätzen und einem Bildchen, aber in der Klausur soll man die Verantwortungsbereiche von Anbieter und Kunde sauber trennen können.

Mein Verständnis bisher:

• IaaS: Anbieter stellt Hardware/Virtualisierung, Kunde kümmert sich um Betriebssystem, Middleware, Anwendung
• PaaS: Anbieter übernimmt zusätzlich das Betriebssystem und die Laufzeitumgebung, Kunde liefert nur noch die Anwendung
• SaaS: komplett fertige Anwendung, Kunde nutzt sie nur noch

Ist das so grob richtig oder hab ich da eine Ebene vergessen bzw. verwechsle ich was? Und wie würdet ihr das an einem einfachen Beispiel pro Modell festmachen, das man sich in der Klausur schnell merken kann? Vielleicht hat ja jemand von euch eine Eselsbrücke oder eine Grafik, die das für euch verständlich gemacht hat.

Ich bin zwar bei Elektrotechnik/Technik unterwegs und nicht in der Wirtschaftsinformatik, aber das Thema betrifft mich bei den Programmier-Modulen genauso, deshalb wollte ich mal fragen, wie ihr das seht.

Bei meinem aktuellen Projekt steht in der Aufgabenstellung, ich solle auf "sauberen Code" achten. Jetzt sitze ich da mit meinem kleinen Einzelprojekt und frage mich ehrlich gesagt, ob sich der Mehraufwand lohnt. Sprechende Variablennamen statt a, b, c, kleine Funktionen statt einer langen durchgehenden Methode - das kostet alles Zeit beim Schreiben, und am Ende lese ich den Code doch nur selbst.

Ich habe schon gemerkt, dass ich nach ein paar Wochen Pause selbst nicht mehr auf Anhieb verstehe, was ich mir bei manchen Zeilen gedacht habe. Insofern ahne ich, dass da schon was dran sein könnte am Clean-Code-Gedanken, auch ohne fremdes Publikum.

Trotzdem würde mich interessieren:

• Bewertet ihr sowas tatsächlich konkret in der Korrektur oder ist das eher "nice to have"?
• Wie viel Zeit investiert ihr realistisch in sowas bei kleinen Projekten?

Marco hat das schon sehr sauber zusammengefasst, das deckt sich auch mit meiner Erfahrung aus den Mathe-Modulen. Ich will nur noch einen Punkt ergänzen, der mir am Anfang auch nicht klar war: die Grenzwertbetrachtung für x gegen unendlich und die für x gegen einen endlichen Wert sind zwei paar Schuhe.

Bei x gegen unendlich hat Robert recht mit dem Gradvergleich, da ist L'Hospital wirklich überdimensioniert. Aber sobald du einen Grenzwert für x gegen eine bestimmte Zahl berechnen sollst und sich dabei 0/0 ergibt, weil sowohl Zähler als auch Nenner an dieser Stelle eine Nullstelle haben, kommst du mit dem einfachen Kürzen manchmal nicht schnell genug weiter – besonders wenn die Faktorisierung nicht offensichtlich ist.

Klassisches Beispiel: der Grenzwert von (x³ − 1)/(x − 1) für x gegen 1. Du könntest hier Polynomdivision machen oder die dritte binomische Formel erweitert anwenden, um zu kürzen. Das geht, kostet aber Zeit und Konzentration. Mit L'Hospital leitest du einfach Zähler und Nenner getrennt ab: 3x²/1, setzt x=1 ein und hast sofort 3. Gerade bei höheren Potenzen oder wenn die Faktorisierung nicht auf den ersten Blick klappt, ist das oft der schnellere Weg.

Merksatz für mich: Gradvergleich bei Unendlich, L'Hospital als Werkzeug bei 0/0 bzw. ∞/∞ an einer konkreten Stelle, wenn Kürzen nicht sofort greift.

Marco hat das mit den Schnittkurven wirklich gut erklärt, das Bild mit der Tangentialebene am Ende ist auch für mich damals der Punkt gewesen, wo es "klick" gemacht hat.

Ich kann noch ein Beispiel aus der E-Technik beisteuern, das mir geholfen hat, weil es nicht nur abstrakte Geometrie ist. Stell dir ein Bauteil vor, dessen Widerstand R von Temperatur T und von einem angelegten Strom I abhängt, also R(T,I). Die partielle Ableitung ∂R/∂T bei festem I sagt dir dann: Wenn ich den Strom konstant halte und nur die Temperatur ein kleines bisschen ändere, wie stark reagiert der Widerstand darauf? Das ist genau die Schnittkurve von Marco, nur dass die Achsen eben nicht x und y heißen, sondern T und R.

Umgekehrt beschreibt ∂R/∂I bei fester Temperatur, wie empfindlich der Widerstand auf Stromänderungen reagiert, zum Beispiel durch Eigenerwärmung bei höheren Strömen. In der Praxis nutzt man solche partiellen Ableitungen z.B. bei Fehlerfortpflanzung oder Sensitivitätsanalysen, um abzuschätzen, welche Einflussgröße bei einer Messung oder einem Entwurf am meisten "Hebelwirkung" hat.

Merksatz für mich war immer: eine partielle Ableitung beantwortet die Frage "was passiert, wenn ich an genau einem Rädchen drehe und alle anderen festhalte" – das lässt sich auf fast jede technische Größe mit mehreren Einflussfaktoren übertragen.

Moin Tim, die Regel von Marco ist genau die, mit der ich auch arbeite, "innen gleich, außen bleibt" trifft es gut. Ich ergänze noch eine kleine Merkhilfe, die mir in der Klausur geholfen hat: Ich schreibe mir unter jede Matrix die Dimension in der Reihenfolge, wie das Produkt notiert ist, also bei A·B direkt (m x n)(n x q) hintereinander. Die beiden mittleren Zahlen berühren sich quasi, wenn die nicht gleich sind, geht's nicht. Stell dir das wie ein Reißverschluss vor, der nur zugeht, wenn die Zähne (die inneren Zahlen) zusammenpassen.

Was ich noch als Warnung ergänzen möchte, weil das in Klausuren regelmäßig Punkte kostet: Viele nehmen bei der Matrizenmultiplikation unbewusst Kommutativität an, weil man das aus dem Zahlenrechnen so gewohnt ist. Das ist bei Matrizen aber ein Trugschluss. Selbst wenn A·B und B·A beide definiert sind, zum Beispiel bei quadratischen Matrizen gleicher Größe, kommt in aller Regel etwas anderes raus. Typischer Klausurfehler ist, bei einer Gleichung wie A·X = B einfach von links mit A⁻¹ zu "kürzen" und dabei die Reihenfolge zu vertauschen. Da muss man exakt auf der Seite bleiben, auf der man multipliziert, also entweder von links oder von rechts, aber konsequent auf beiden Seiten der Gleichung gleich.

Dimensionen explizit hinschreiben kann ich nur unterstreichen, das hat mich selbst im Fernstudium einige Male vor Verrechnern bewahrt.

Marco hat das schon sauber auf den Punkt gebracht, ich ergänze nur noch ein kleines Rechenbeispiel, weil mir das damals selbst geholfen hat, das Prinzip wirklich zu verinnerlichen.

Nehmt f(x) = x^3. Dann f'(x) = 3x^2, f''(x) = 6x, f'''(x) = 6.

• f''(x0) = 0 bei x0 = 0
• f'''(0) = 6 ≠ 0 → also Wendepunkt garantiert, ohne dass man Testwerte einsetzen muss
• zusätzlich f'(0) = 0 → horizontale Tangente
• damit: Sattelpunkt bei x = 0

Zur Kontrolle trotzdem die Vorzeichen-Tabelle, gerade weil das in der Klausur schnell geht und man nichts auswendig lernen muss:

• x = -1: f''(-1) = -6 → negativ (Rechtskrümmung)
• x = 0: f''(0) = 0
• x = 1: f''(1) = 6 → positiv (Linkskrümmung)

Vorzeichenwechsel von − nach + bei x = 0 bestätigt: echter Wendepunkt.

Merksatz, den ich mir aufgeschrieben habe: f''=0 ist nur die Tür, durch die man gehen muss, aber erst der Vorzeichenwechsel (oder ersatzweise f'''≠0) zeigt, ob dahinter wirklich ein Wendepunkt liegt. Und ob's zusätzlich ein Sattelpunkt ist, hängt komplett unabhängig davon an f'(x0)=0. Beide Bedingungen immer getrennt prüfen, dann passiert einem in der Klausur kein Flüchtigkeitsfehler.

Marco hat das mit der Ableitungs-Probe schon sehr gut auf den Punkt gebracht, das ist auch bei mir der erste Blick geworden. Ich ergänze noch einen Praxis-Tipp aus der Elektrotechnik, da taucht sowas ständig bei Übertragungsfunktionen oder bei der Berechnung von Effektivwerten auf.

Ein Beispiel, das mir lange Kopfzerbrechen bereitet hat: das Integral über t * e^(-t) für eine Einschwingfunktion. Da sieht man auf den ersten Blick keine "passende innere Ableitung", weil e^(-t) nicht verkettet ist mit irgendwas, dessen Ableitung schon als Faktor dasteht. Das ist also klar partielle Integration, LIATE sagt dir dann auch gleich: t ist Algebra, also u = t, dv = e^(-t) dt.

Mein praktischer Rat für die Klausur, gerade wenn die Zeit knapp ist: Wenn euch nach kurzem Hinschauen kein Muster auffällt, einfach eines der beiden Verfahren konsequent durchziehen – notfalls auch mal probeweise substituieren und schauen, ob sich das Integral dadurch vereinfacht oder komplizierter wird. Wenn nach dem Einsetzen noch ein "hässliches" x oder t übrig bleibt, das sich nicht wegkürzt, ist das ein klares Zeichen, dass Substitution der falsche Weg war und man auf partielle Integration wechseln sollte. Diese Rückmeldung aus dem eigenen Rechenweg ist oft schneller als ewig am Anfang zu grübeln.

Eigentlich bin ich bei Elektrotechnik/Mathe zuhause, aber gerade hänge ich an einer Datenbank-Übung, die als Modul mit dranhängt, und komme bei den Joins ständig durcheinander. Inner Join hab ich noch im Griff, klar, nur Treffer aus beiden Tabellen. Aber sobald Left und Right Join mit fehlenden Zuordnungen ins Spiel kommen, verheddere ich mich total, welche Seite jetzt komplett übernommen wird und wo dann NULL-Werte auftauchen.

Ich habe mir schon Diagramme mit den klassischen Kreisen gezeichnet, aber am nächsten Tag ist es wieder weg. Full Join verwechsle ich dann auch noch gerne mit einem Cross Join, weil ich mir nicht merken kann, dass Full einfach beide Seiten inklusive der NULLs zusammenführt.

Hat jemand von euch eine simple Eselsbrücke oder eine Merkregel, mit der das dauerhaft hängen bleibt? Am liebsten irgendwas Bildliches oder eine kleine Geschichte, das funktioniert bei mir meistens besser als reine Definitionen auswendig zu lernen.

Ich sitze gerade an einem Modul zur Wirtschaftsinformatik und beiße mir an dem Begriff "zustandslos" bei REST-APIs die Zähne aus. Im Skript wird das als eines der wichtigsten Architekturprinzipien genannt, aber was das konkret bedeutet, erschließt sich mir noch nicht so richtig.

Ich habe verstanden, dass der Server sich angeblich nichts über vorherige Anfragen "merkt". Aber bedeutet das nicht, dass bei jeder Anfrage komplett neue Infos mitgeschickt werden müssen? Klingt für mich erstmal nach mehr Aufwand statt nach einem Vorteil.

Vielleicht kann mir das jemand an einem einfachen Alltagsbeispiel erklären, so wie man es auch einem Nicht-Informatiker klarmachen würde? Und warum genau soll das für Skalierbarkeit und Ausfallsicherheit so entscheidend sein? Ich stehe da gerade ziemlich auf dem Schlauch und würde das gerne wirklich verstehen, nicht nur auswendig für die Klausur lernen.

Guter Thread, ein Punkt fehlt mir noch, weil der in der Praxis und in der Klausur oft untergeht: Die O-Notation beschreibt meistens den Worst Case, und der kann sich stark vom typischen Fall unterscheiden.

• Quicksort liegt im Durchschnitt bei O(n log n), im ungünstigsten Fall aber bei O(n²), zum Beispiel bei ungünstiger Pivot-Wahl auf schon sortierten Daten. Deshalb wählen Implementierungen das Pivot zufällig oder als Median aus mehreren Werten.
• Eine Hashtabelle findet einen Eintrag im Durchschnitt in O(1), bei vielen Kollisionen im schlimmsten Fall aber in O(n).

Wenn in der Aufgabe also nur „Laufzeit von Quicksort?“ steht, lohnt sich ein Satz dazu, welchen Fall man meint: Best, Average oder Worst Case. Das zeigt, dass man die Notation verstanden und nicht nur die Tabelle auswendig gelernt hat.

Ich hatte genau deinen Fall (180er-Bachelor, 90-ECTS-Master) und bin mit Auflagen reingekommen. Zwei Dinge, die ich vorher gern gewusst hätte:

• Die Brückenmodule kosten zusätzlich Zeit und Geld. Bei mir waren es 30 ECTS neben dem ersten Mastersemester und dem Job – das härteste halbe Jahr des Studiums. Wenn dir ein 120-ECTS-Master inhaltlich genauso passt, nimm den. Die Studiendauer ist am Ende dieselbe, nur ohne diesen Stress.
• Lass dir die Zulassung mit Auflagen schriftlich mit Fristen geben. In meinem Bescheid stand, bis wann die Auflagen erfüllt sein müssen – wird das gerissen, ist die Zulassung weg.

Und keine Sorge wegen der Studienform: Im Zeugnis steht kein „Fernstudium“, und in der Bewerbung hat mich nie jemand danach gefragt. Gefragt wurde ich nach dem Thema der Abschlussarbeit.

Moin,

wir sind zu viert und müssen im Modul Softwaretechnik eine kleine Webanwendung bauen. Versionsverwaltung über Git ist Pflicht. Problem: Wir arbeiten alle direkt auf main, und fast jedes Mal beim Pushen gibt es Konflikte. Gestern hat einer im Frust „einfach seine Version genommen“ und damit die Arbeit von zwei Tagen von jemand anderem überschrieben. 🙄

Wie macht man das richtig? Jeder einen eigenen Branch? Und wann führt man die dann wieder zusammen? Im Skript steht Merge und Rebase, aber ehrlich gesagt verstehe ich nicht, wann man was nimmt.

Ich kann was zur Technikseite beitragen – hatte im Studium gerade Bauphysik-Grundlagen, und wir hatten das Problem in unserer alten Wohnung auch.

Warum ausgerechnet hinter dem Schrank an der Außenwand? Warme Luft kann mehr Feuchtigkeit aufnehmen als kalte. Kühlt die Raumluft an einer kalten Oberfläche ab, steigt dort die relative Luftfeuchte stark an. Schimmel braucht dafür nicht mal Tropfen – dauerhaft sehr hohe Feuchte direkt an der Oberfläche reicht. Ein Schrank vor der Außenwand hält die warme Raumluft von der Wand fern, die Ecke bleibt kalt. Genau da treffen Altbau-Wärmebrücke und Möbel zusammen.

Was du jetzt dokumentieren kannst (hilft im Streit enorm):

• Ein Thermo-Hygrometer (kostet ein paar Euro) ins Schlafzimmer stellen und die Werte morgens und abends notieren. Liegt die relative Luftfeuchte im Winter dauerhaft deutlich über etwa 60 %, ist das ein Warnsignal.
• Lüftungsprotokoll für zwei, drei Wochen: Uhrzeit, Dauer, Stoß- oder Kipplüften, Heizung an oder aus.
• Fotos mit Maßstab (Zollstock daneben) und Datum, alle ein bis zwei Wochen – so sieht man die Entwicklung.
• Wenn möglich die Oberflächentemperatur in der Ecke mit einem Infrarot-Thermometer messen und mit der Wandmitte vergleichen. Große Unterschiede sprechen eher für eine Wärmebrücke als für falsches Lüften.

Sofort umsetzbar: Schrank ein paar Zentimeter von der Wand abrücken, Stoßlüften (Fenster ganz auf, wenige Minuten) statt Dauerkipp, das Schlafzimmer nicht komplett auskühlen lassen. Den Schimmel nicht trocken abbürsten, da fliegen Sporen. Bei der Größe würde ich die Beseitigung ohnehin dem Vermieter bzw. einer Fachfirma überlassen – sonst entfernst du im Zweifel auch deine Beweise.

Und mach dir wegen des Abis keinen zusätzlichen Stress: Das Schreiben ist in einer Stunde aufgesetzt, danach liegt der Ball beim Vermieter 💪

Moin,

ich mache Technik im Fernstudium und habe gestern eine Einsendeaufgabe zurückbekommen: 5 von 20 Punkten. Kommentar des Korrektors in Gänze: „Aufgabenstellung verfehlt, Ausführungen bleiben an der Oberfläche.“ Mehr steht da nicht. 😐

Ich habe die Aufgabe zweimal gelesen und finde ehrlich gesagt nicht, dass ich das Thema verfehlt habe – ich habe halt einen anderen Schwerpunkt gesetzt als offenbar erwartet war. Jetzt frage ich mich:

• Kann man da überhaupt Widerspruch einlegen, oder ist das bei Einsendeaufgaben zwecklos?
• Gibt es sowas wie eine Zweitkorrektur, und muss man die begründen?
• Zählt so eine Note am Ende überhaupt fürs Zeugnis, oder ist das nur Übung?

Hat jemand das schon mal durchgezogen? Ich will keinen Streit vom Zaun brechen, aber so ganz ohne Rückmeldung lerne ich aus den 5 Punkten auch nichts.