Added Vorlesung 16.11

LerntagebuchBeispiel.md

@@ -1,4 +1,4 @@
-<pre><div class="text_to_html">
+
   # Mein Lerntagebuch für Programmiermethoden und -werkzeuge Das
   ist ein Beispiel wie ein Lerntagebuch aussehen könnte. ## SU 01
   (21.10.2021) ### Lernziel - Organisatorisches -
@@ -19,4 +19,4 @@
   weg. Aber wenn mich irgendwas stört oder begeistert, kann ich es
   hier anmerken. --- ## SU 02 (28.10.2021) ...hier geht's bald
   weiter
-</div></pre>
+

lerntagebuch.md

@@ -1,8 +1,11 @@
-Vorlesung(2.11.2022)
+# Mein Lerntagebuch für Programmiermethoden und -werkzeuge
 
-Lernziele
+## Vorlesung (2.11.2022)
+
+### Lernziele
 
 Es gibt viele Arten von programmierParadigmen:
+ 
 1. Imperative programmierung erklärt, dass ein Programm aus einer Folge von Anweisungen besteht, die vorgeben,
 in welcher Reihenfolge was vom Computer getan werden soll.
 2. Bei Deklarative Programmierung steht die Beschreibung des Problems im Vordergrund. Danach wird der Lösungsweg automatisch ermittelt.
@@ -34,13 +37,13 @@ STUPID
 - Indescriptive Naming
 - Duplication
 
-Kritik
+### Kritik
 
 Keep It Simple and Stupid(Komplezität soll vermieden werden).
 
-Vorlesung(9.11)
+## Vorlesung (9.11)
 
-Lernziele
+### Lernziele
 
 Entwurfmuster (design patterns) sind bewährte Lösungsschablonen für wiederkehrende Entwurfsprobleme
 sowohl in der Architektur als auch in der Softwarearchitektur und -entwicklung. Sie stellen damit
@@ -49,7 +52,7 @@ Sie stammt aus der Architektur mit der Verbreitung von Programmiersprachen adapt
 
 Die Vorteile davon ist:
 1. erprobte Lösungen für Wiederkehrende Aufgaben.
-2. Vor- und Nachteile sind bekannt.
+3. Vor- und Nachteile sind bekannt.
 3. die Kommunikation vereinfachen.
 4. eignen sich zur Dokumentation.
 
@@ -89,6 +92,85 @@ Andere automatisierte Refactorings sind Umbenennungen, Signaturen von Methoden,
 von Codeteilen. Debugging wird erklärt durch die Beobachtung des Programms während der Laufzeit, um Fehler zu identifizieren  
 und zu löschen.
 
-Kritik
+### Kritik
 
 Keine für diese Woche :D.
+
+## Vorlesung (16.11)
+
+### Lernziele
+
+*git* als Source Code Management.
+
+Konzepte von *git*:
+
+1. basiert auf _change sets_, nicht Datei.
+2. *commits* wird von SHA gesichert.
+3. *branches* sind Aufkleber auf commits.
+4. Staging area(siehe Kritik).
+
+Safety creates confidence:
+
+1. permanenter Zugriff auf den letzten Arbeitszustand.
+2. Zugang zu verschiedenen Status (production, develop, feature in progress).
+3.   Änderungen im Laufe der Zeit/zwischen Funktionen oder *branches* vergleichen.
+
+Simple methods vs SCM:
+
+|Simple methods               | Source Code Management         |
+|---------------------------- |------------------------------- |
+|exsessive disk usage         |optimised for minimal disk usage|
+|chunky granularity           |fine granularity                |
+|no ”commit message”          |annotated change                |
+|hard to navigate / search    |easy navigation/search          |
+|manual merges                |automated merge                 |
+|copies/archives on net shares|change history as tree          |
+|simple local copies          |
+|zip archives                 |
+|no tooling required          |
+|easy diff                    |
+| no technical relationships  |
+
+Centralized SCM:
+
+|Pro|Contra|
+|---|---|
+|Jeder *commit* für verfügbar| zentrale Instanz erforderlich|
+|aktueller Editor allen bekannt|*locking* verhindert paralleles Arbeiten|
+|easy backup/restore|*branching* und *merging* sofort sichtbar für alle|
+|unbegrenzte Ressourcen für das Repository|keine Offline-Arbeit|
+
+Distributed SCM: 
+|Pro|Contra|
+|---|---|
+|kein zentraler Server nötig|local history out of sync|
+|mehrere *remotes* möglich|kein Schutz gegen gleichzeitige Änderungen|
+|arbeiten ohne (ständigen) Netzzugang|
+|implizite backups|
+|Offline-Arbeit - lokale "Experimente"privat bleiben|
+
+Branching:
+
+1. master/main
+2. develop
+3. release
+4. hotfix
+5. feature
+
+Rebase vs Merge:
+
+|`rebase` wenn|`merge` wenn|
+|---|---|
+|an einem unfertigen *feature* arbeiten, das noch nicht in andere *branches* eingebunden wurde|aktuell _branch develop_ oder *master*|
+|eine saubere Historie ist erwünscht|Die Historie sollte mit der Zeitachse synchron bleiben|
+|dein *branch* hat viele Commits (mit funktionierenden UnitTests)|dein *branch* wurde bereits gemerged|
+|einen "Squash-Commit" vorzubereiten|
+
+### Kritik
+
+Keep commits small and clean for easier problem solving and back tracking.
+
+
+
+
+