diff --git a/.obsidian/plugins/text-extractor/cache/b16b34faae391e9f2d0705c9f7038aa2.json b/.obsidian/plugins/text-extractor/cache/b16b34faae391e9f2d0705c9f7038aa2.json new file mode 100644 index 0000000..566bae6 --- /dev/null +++ b/.obsidian/plugins/text-extractor/cache/b16b34faae391e9f2d0705c9f7038aa2.json @@ -0,0 +1 @@ +{"path":"Attachments/Pasted image 20250116171230.png","text":"Turn- Cassette CD FM Amplifier Other Half of table Player Player Receiver P Cassette Player AM/FM Receiver Turn- Half of Cassette and Amplifier table Player Right Left Left Speaker and J L Right Speaker and Speaker Speaker CD Player AM Receiver","libVersion":"0.3.2","langs":"deu+eng+fra"} \ No newline at end of file diff --git a/.obsidian/workspace.json b/.obsidian/workspace.json index 870748b..b77d5d5 100644 --- a/.obsidian/workspace.json +++ b/.obsidian/workspace.json @@ -58,20 +58,6 @@ "title": "Want to Learn List" } }, - { - "id": "43f7b49fd4e189cd", - "type": "leaf", - "state": { - "type": "markdown", - "state": { - "file": "Templates/Course Template.md", - "mode": "source", - "source": false - }, - "icon": "lucide-file", - "title": "Course Template" - } - }, { "id": "1b8bf7d6aec0816c", "type": "leaf", @@ -551,18 +537,20 @@ }, "active": "0276c662bb61f53b", "lastOpenFiles": [ + "5 Media/0 Books/Software Project Survival Guide by Steve McConnell.md", + "2 Personal/Lists/Want to Learn List.md", + "Templates/Course Template.md", + "5 Media/8 Courses/Design Patterns by Construx.md", + "Attachments/Pasted image 20250116171230.png", "Temporary/Interviews as an Employer.md", + "5 Media/0 Books/More Effective Agile by Steve McConnell.md", "Attachments/Pasted image 20250116163238.png", "Attachments/Pasted image 20250116163115.png", - "5 Media/8 Courses/Design Patterns by Construx.md", "Temporary/Untitled 1.md", "Attachments/Pasted image 20250116161534.png", "Attachments/Pasted image 20250116161217.png", "Attachments/Pasted image 20250116160836.png", "Temporary/Untitled.md", - "Templates/Course Template.md", - "5 Media/0 Books/More Effective Agile by Steve McConnell.md", - "5 Media/0 Books/Software Project Survival Guide by Steve McConnell.md", "5 Media/0 Books/Design Patterns by null.md", "5 Media/0 Books/null by null.md", "Templates/Book Template.md", @@ -584,7 +572,6 @@ "Attachments/Pasted image 20250115112343.png", "Temporary/Startup Culture List.md", "Attachments/Pasted image 20250115111900.png", - "Attachments/Pasted image 20250115111654.png", "2 Personal/Alkademiker/Projekte/Tischbeine Motorisiert.md", "Temporary/Jira Tutorial.md", "Temporary/3D Tourenviewer.md", diff --git a/2 Personal/Lists/Want to Learn List.md b/2 Personal/Lists/Want to Learn List.md index 9601eb6..237cbe8 100644 --- a/2 Personal/Lists/Want to Learn List.md +++ b/2 Personal/Lists/Want to Learn List.md @@ -8,8 +8,8 @@ tags: # Want to Learn List ## Engineering -- [ ] prompt engineering and AI bsics: read papers -- [ ] Neuro & motor control combo with robitics +- [ ] prompt engineering and AI basics: read papers +- [ ] Neuro & motor control combo with robotics - [ ] Dash - [ ] AI course (coursera / free code camp) - [ ] Algorithm courses diff --git a/5 Media/8 Courses/Design Patterns by Construx.md b/5 Media/8 Courses/Design Patterns by Construx.md index 4170a92..e997af9 100644 --- a/5 Media/8 Courses/Design Patterns by Construx.md +++ b/5 Media/8 Courses/Design Patterns by Construx.md @@ -83,10 +83,53 @@ The programmer needs to focus much more on semantics, because the complier will > It is a tool to reduce and manage complexity. what is the role of one function / subroutine? The more abstraction you have, the less performant the code becomes. -Abstraction i +Abstraction is not learnable. Good abstractions lead to clean code, which is maintainable and leads to less defects. +### Encapsulate Design Decisions +Abstraction: permission to ignore +Encapsulation: I prevent you from knowing +Meaning they are not the same thing. +Goal: +- **hide design decision** (data representation, algorithms, etc.) +- **Modules should be black boxes**: programm to an interface, not through an interface +Idea: Design by Contract +Requires vs Guarantees +A function promises to give certain outputs depending on the inputs +This is important for documentation of code if the code is used by different people. Docstrings for example. +We only worry about semantic things. Explain exactly what the input values should be and what the return values will be. Explain exactly what errors and exceptions. Include Constraints on state (function may open file), include performance limits (use no more than 200 bytes per instance, etc). +Defensive contract: requires less and guarantees more (check input for example). +Contracts are great, because you can treat the function as a blackbox. When you modify the contract you need to inform all the users of the function about the updates of the contract + +**Desing by Contract is the means to encapsulation** +Use: **Purpose, Requires and Guarantees** + +### Maximize Cohesion, Minimize Coupling +**Cohesion**: Indivisibility of a given part: Does this function do exactly one thing? It should also not split functionality into two separate functions +**Coupling**: Dependence between parts: Do not connect things that don't need to be connected. If you must connect things, connect them such that they can be disconnected as easily as possible. + +Goal: Highly cohesive, very loosely coupled + +Generally software solves problems by *Decomposition, solution, recomposition*. There are an infinite amount of different solutions, which have different quality. Cohesion and Coupling characterise the quality of the solution. + +![[Pasted image 20250116171230.png]] + +Always try to Decouple code: + +| **Avoid** | **Do** | +| ----------------------------------- | -------------------------------------------------------------------------------------------------------- | +| Global variables (form of coupling) | Design by Contract | +| Friend (C++) | Dependency inversion: if you depend on things, depend on the most generic thing (type of car, not model) | +| Self-modifying code | Publish-subscribe (observer pattern) | +| Reflection | Law of Demeter | +#### Law of Demeter +Principle of least knowledge. +a.b().c() breaks the law --> violates coupling +a.b() doesn't break the law + +### Design to Invariants, Design +Product Families: attack different target markets with different value propositions with the same base platform: (pickup truck and suv example. For ford it's the same car (slight difference in )) --- ## Exercises diff --git a/Attachments/Pasted image 20250116171230.png b/Attachments/Pasted image 20250116171230.png new file mode 100644 index 0000000..269e74a Binary files /dev/null and b/Attachments/Pasted image 20250116171230.png differ diff --git a/Temporary/Interviews as an Employer.md b/Temporary/Interviews as an Employer.md index f757955..a722668 100644 --- a/Temporary/Interviews as an Employer.md +++ b/Temporary/Interviews as an Employer.md @@ -11,7 +11,7 @@ tags: - Don't focus on C++ (other language) --> this is learnable - Focus on abstraction (less learnable) - Can we eliminate one of the 4 images? ![[Pasted image 20250116163115.png]] - - Find as many different ways to remove 1 from the others. less than 8 (not interested in hiring you). This is important because abstracting is not learnable. Abstraction leads to clean code. --> focus on non-learnable skills during the interview. the rest can be done in the onboarding process. + - Find as many different ways to remove 1 from the others. less than 8 (not interested in hiring you). This is important because abstracting is not learnable. Abstraction leads to clean code. --> focus on non-learnable skills during the interview. the rest can be done in the onboarding process (see [[Design Patterns by Construx#Use Abstractions]]. ![[Pasted image 20250116163238.png]] Pizza: singleton vs many, payment type, gold: periodic element on table vs compounds