Compare commits
28
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
8d5c57d561 | ||
|
|
3a2e1a8d15 | ||
|
|
ac89d69365 | ||
|
|
552949811e | ||
|
|
030bb322a2 | ||
|
|
9631a1c45b | ||
|
|
4245ea2567 | ||
|
|
51146d3dfc | ||
|
|
fda4aca4c7 | ||
|
|
aff352fa91 | ||
|
|
ea7e905c61 | ||
|
|
512fbd9d3d | ||
|
|
64f4729f45 | ||
|
|
c35541961e | ||
|
|
d8f68183f3 | ||
|
|
705c5e3457 | ||
|
|
9b0b6bc9d6 | ||
|
|
62cd97c51a | ||
|
|
9f2c78d536 | ||
|
|
fb0db03db9 | ||
|
|
f9185d25e0 | ||
|
|
4f3b680951 | ||
|
|
a2b1c0484a | ||
|
|
1480d31a54 | ||
|
|
514896db33 | ||
|
|
b21e2394d5 | ||
|
|
7da018d92c | ||
|
|
9e12447528 |
@@ -0,0 +1,197 @@
|
||||
# AGENTS.md - Agent Guidelines for HdM Slides
|
||||
|
||||
This file contains comprehensive guidelines for agentic coding agents working on the HdM Slides project.
|
||||
|
||||
## Project Overview
|
||||
|
||||
This project builds presentation decks for Marp, supporting multiple courses:
|
||||
- **223015b** - Dateiformate, Schnittstellen, Speichermedien (6 Kapitel)
|
||||
- **223015c** - Internettechnologien (3 Kapitel)
|
||||
|
||||
## Development Workflow
|
||||
|
||||
### Build Commands
|
||||
```bash
|
||||
# Development
|
||||
make dev # Start single dev server on port 3000
|
||||
npm run dev # Alternative command for development server
|
||||
|
||||
# Build
|
||||
make build # Build all courses (HTML + PDF)
|
||||
make build-b # Build 223015b only
|
||||
make build-c # Build 223015c only
|
||||
make html # HTML only builds
|
||||
make pdf # PDF only builds
|
||||
|
||||
# Klausur Folien
|
||||
make klausur # Extract klausurfolien for all courses
|
||||
make klausur-b # Extract klausurfolien for 223015b
|
||||
make klausur-c # Extract klausurfolien for 223015c
|
||||
|
||||
# Deployment
|
||||
make deploy # Deploy all courses (requires explicit permission)
|
||||
make deploy-b # Deploy 223015b only
|
||||
make deploy-c # Deploy 223015c only
|
||||
|
||||
# Utilities
|
||||
make qr URL=... # Generate QR code
|
||||
make optimize-images COURSE=223015b # Resize images
|
||||
make clean # Remove generated files
|
||||
```
|
||||
|
||||
### Testing
|
||||
No specific test framework is used. To validate changes:
|
||||
1. Start dev server: `make dev`
|
||||
2. Open http://localhost:3000/223015b/ or /223015c/
|
||||
3. Verify slides render correctly
|
||||
4. Run `make build` to ensure no build errors
|
||||
5. Check generated files in `build/` directory
|
||||
|
||||
## Code Style Guidelines
|
||||
|
||||
### File Structure
|
||||
- Slides in `slides/<course>/` following naming pattern `NN-topic.md`
|
||||
- Assets in `slides/<course>/assets/`
|
||||
- Always reference images as `./assets/filename.png`
|
||||
- Scripts in `scripts/`
|
||||
- Themes in `themes/`
|
||||
- Generated output in `build/` (gitignored)
|
||||
|
||||
### Naming Conventions
|
||||
- Slide files: `NN-topic.md` (e.g., `01-grundlagen.md`, `02-bilder.md`)
|
||||
- Images: `snake_case.jpg` or `kebab-case.jpg`
|
||||
- Klausur files: `klausurfolien.md` (auto-generated)
|
||||
- Function names in scripts: `snake_case`
|
||||
- Variable names in scripts: `snake_case`
|
||||
|
||||
### Markdown Style
|
||||
- Use ATX-style headers (`# ## ###`)
|
||||
- YAML frontmatter for slide metadata at top of each file
|
||||
- Never include a final `---` (creates empty slide)
|
||||
- Use `<!-- _class: klausur -->` for exam-relevant slides
|
||||
- Use relative paths for assets: `./assets/image.png`
|
||||
|
||||
### Script Style
|
||||
- Use `#!/usr/bin/env bash` shebang
|
||||
- Use `set -e` for error handling
|
||||
- Use `2>/dev/null || true` for optional operations
|
||||
- Define variables in UPPER_CASE at script top
|
||||
- Use colors for terminal output: `\033[0;32m` etc.
|
||||
|
||||
### Git Workflow
|
||||
- Commit messages: ALWAYS lowercase
|
||||
- NEVER add co-authoring lines or generated footers
|
||||
- Follow semantic naming: "add-...", "fix-...", "update-..."
|
||||
- Commit changes to scripts, Makefile, documentation separately from slide content
|
||||
|
||||
## Agent Restrictions
|
||||
|
||||
### Security
|
||||
- NEVER run commands outside `/home/mwc/Coding/hdm` folder
|
||||
- NEVER run build/deploy commands without explicit user request
|
||||
- NEVER run deploy commands (make deploy, scp, etc.) without explicit permission
|
||||
|
||||
### File Protection
|
||||
Slide files in `slides/*/*.md` are main content files:
|
||||
- **ALLOWED**: Adding slides, adjusting content, fixing typos, enhancing sections
|
||||
- **FORBIDDEN** (without permission): Deleting slides, removing sections, bulk deletions
|
||||
- Before ANY deletion: ALWAYS ask user for confirmation
|
||||
|
||||
### Klausur Handling
|
||||
- Klausur files (`klausurfolien.md`) are auto-generated
|
||||
- NEVER edit klausurfolien.md files directly
|
||||
- To update klausurfolien: edit source slides with `<!-- _class: klausur -->` markers
|
||||
- Run `make klausur` to regenerate
|
||||
|
||||
## Development Patterns
|
||||
|
||||
### Adding New Slides
|
||||
1. Create new file following `NN-topic.md` pattern
|
||||
2. Copy frontmatter from existing slides in the same course
|
||||
3. Update Makefile `_KAPITEL` variable if needed
|
||||
4. Test with `make dev`
|
||||
|
||||
### Modifying Existing Slides
|
||||
1. Edit the appropriate markdown file in `slides/<course>/`
|
||||
2. Maintain consistent styling with course theme
|
||||
3. Preserve image paths as `./assets/...`
|
||||
4. Test changes with dev server
|
||||
|
||||
### Working with Assets
|
||||
1. Place images in `slides/<course>/assets/`
|
||||
2. Use descriptive names: `diagram-network.jpg`, `example-code.png`
|
||||
3. Optimize with `make optimize-images COURSE=223015b`
|
||||
4. Reference as `./assets/filename.ext`
|
||||
|
||||
### Course-Specific Configuration
|
||||
Each course has specific settings in Makefile:
|
||||
- Course name and title
|
||||
- Kapitel list (slide files)
|
||||
- Deploy path
|
||||
- Theme colors (in generate-index.sh)
|
||||
|
||||
## Common Tasks
|
||||
|
||||
### Debugging Build Issues
|
||||
1. Check Makefile syntax: `make -n build`
|
||||
2. Verify Marp CLI installation: `npx @marp-team/marp-cli --version`
|
||||
3. Check file permissions: `ls -la slides/`
|
||||
4. Validate markdown syntax with dev server
|
||||
|
||||
### Updating Course Structure
|
||||
1. Update `_KAPITEL` variables in Makefile
|
||||
2. Ensure slide files follow naming convention
|
||||
3. Update course-specific themes if needed
|
||||
4. Test both dev and build processes
|
||||
|
||||
### Working with Themes
|
||||
- Custom theme in `themes/custom-theme.css`
|
||||
- Course themes defined in individual slide frontmatter
|
||||
- Use consistent color schemes per course
|
||||
- Test theme changes across all slides
|
||||
|
||||
## Deployment Process
|
||||
|
||||
Deployment to production server requires explicit permission:
|
||||
1. Build process: `make build` (HTML + PDF)
|
||||
2. Index generation: automatically handled
|
||||
3. Deploy to remote server via SCP
|
||||
4. Root index deployment
|
||||
|
||||
**IMPORTANT**: Never run deployment commands without explicit user permission.
|
||||
|
||||
## Tools and Dependencies
|
||||
|
||||
### Core Dependencies
|
||||
- Marp CLI for slide rendering
|
||||
- Bash scripts for automation
|
||||
- Make for build orchestration
|
||||
- Git for version control
|
||||
|
||||
### Optional Tools
|
||||
- qrencode for QR generation (via nix)
|
||||
- ImageMagick for image optimization
|
||||
- Python 3 for simple HTTP server (legacy)
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
Since there's no formal test suite:
|
||||
1. Manual testing with dev server
|
||||
2. Build process validation
|
||||
3. Slide rendering checks
|
||||
4. Asset path verification
|
||||
5. Cross-browser compatibility checks (important)
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
- **Port conflicts**: Use `make dev-kill` to clean up processes
|
||||
- **Build failures**: Check file permissions and Marp CLI installation
|
||||
- **Asset loading**: Verify relative paths and file existence
|
||||
- **Deploy issues**: Check SSH keys and remote permissions
|
||||
|
||||
### Getting Help
|
||||
1. Check this AGENTS.md file first
|
||||
2. Review Makefile targets and scripts
|
||||
3. Test changes incrementally
|
||||
4. Maintain backup of working configurations
|
||||
@@ -12,6 +12,7 @@ This project builds presentation decks for Marp, supporting multiple courses.
|
||||
- Agent NEVER runs commands outside this folder
|
||||
- Agent NEVER runs build/deploy commands without explicit user request
|
||||
- Agent NEVER runs deploy commands (make deploy, scp, etc.) without explicit user permission
|
||||
- Agent NEVER runs `git checkout --` or `git restore` on files with uncommitted work. To undo specific changes, use targeted Edit operations instead.
|
||||
|
||||
## Critical File Protection
|
||||
|
||||
@@ -48,10 +49,7 @@ make deploy # Deploy all (ASK FIRST!)
|
||||
## Nix Flake Commands
|
||||
|
||||
```bash
|
||||
nix develop # Dev shell with all tools
|
||||
nix run .#qr -- "https://example.com" # Generate QR code
|
||||
nix run .#qr-slides -- 223015b # QR for course
|
||||
nix run .#optimize-img -- <path> # Optimize images
|
||||
nix develop # Dev shell with all tools (node 22, npm, make)
|
||||
```
|
||||
|
||||
## Code Style Guidelines
|
||||
|
||||
@@ -7,19 +7,13 @@
|
||||
COURSES = 223015b 223015c
|
||||
SLIDES_DIR = slides
|
||||
|
||||
# Port configuration (index starts at BASE_PORT, courses increment from there)
|
||||
BASE_PORT = 1310
|
||||
INDEX_PORT = $(BASE_PORT)
|
||||
|
||||
# Course-specific settings
|
||||
223015b_NAME = Dateiformate, Schnittstellen, Speichermedien
|
||||
223015b_PORT = 1311
|
||||
223015b_KAPITEL = 00-intro 01-grundlagen-text-audio 02-bild-audio-video 03-speichermedien-schnittstellen 04-distribution-apis-zukunft 05-vertiefung-offene-fragen klausur
|
||||
223015b_KAPITEL = 00-intro 01-grundlagen-text-audio 02-bild-audio-video 03-speichermedien-schnittstellen 04-distribution-apis-zukunft 05-vertiefung-offene-fragen klausurfolien klausurfragen
|
||||
223015b_DEPLOY_PATH = /home/tengo/html/hdm/223015b
|
||||
|
||||
223015c_NAME = Internettechnologien
|
||||
223015c_PORT = 1312
|
||||
223015c_KAPITEL = 01-geschichte-grundlagen-html 02-netzwerke-protokolle-css 03-interaktivitaet-javascript klausur
|
||||
223015c_KAPITEL = 01-geschichte-grundlagen-html 02-netzwerke-protokolle-css 03-interaktivitaet-javascript klausurfolien klausurfragen
|
||||
223015c_DEPLOY_PATH = /home/tengo/html/hdm/223015c
|
||||
|
||||
DEPLOY_HOST = tengo@tuttle.uberspace.de
|
||||
@@ -33,9 +27,7 @@ help:
|
||||
@echo " 223015c - Internettechnologien"
|
||||
@echo ""
|
||||
@echo "Development:"
|
||||
@echo " make dev - Both servers + index (ports 1311, 1312, 1313)"
|
||||
@echo " make dev-b - Dev server for 223015b (port 1312)"
|
||||
@echo " make dev-c - Dev server for 223015c (port 1313)"
|
||||
@echo " make dev - Start development server (port 3000)"
|
||||
@echo ""
|
||||
@echo "Build:"
|
||||
@echo " make build - Build all courses"
|
||||
@@ -43,7 +35,7 @@ help:
|
||||
@echo " make build-c - Build 223015c only"
|
||||
@echo " make pdf - Export all to PDF"
|
||||
@echo " make html - Export all to HTML"
|
||||
@echo " make klausur - Extract klausur slides"
|
||||
@echo " make klausur - Extract klausurfolien slides"
|
||||
@echo ""
|
||||
@echo "Tools:"
|
||||
@echo " make qr URL=... - Generate QR code for URL"
|
||||
@@ -63,25 +55,14 @@ build/.exists:
|
||||
@mkdir -p build/223015b build/223015c
|
||||
@touch $@
|
||||
|
||||
# Development servers
|
||||
# Development server
|
||||
dev:
|
||||
@./scripts/dev-server.sh
|
||||
|
||||
dev-kill:
|
||||
@-pkill -f "python3 -m http.server" 2>/dev/null || true
|
||||
@-pkill -f "marp-cli.*--server" 2>/dev/null || true
|
||||
@sleep 0.5
|
||||
|
||||
dev-b:
|
||||
@echo "Starting 223015b dev server on port $(223015b_PORT)..."
|
||||
@echo "Open: http://localhost:$(223015b_PORT)"
|
||||
PORT=$(223015b_PORT) npx @marp-team/marp-cli --server $(SLIDES_DIR)/223015b/
|
||||
|
||||
dev-c:
|
||||
@echo "Starting 223015c dev server on port $(223015c_PORT)..."
|
||||
@echo "Open: http://localhost:$(223015c_PORT)"
|
||||
PORT=$(223015c_PORT) npx @marp-team/marp-cli --server $(SLIDES_DIR)/223015c/
|
||||
|
||||
# Build functions
|
||||
define build_course
|
||||
@echo "Building $(1)..."
|
||||
@@ -158,7 +139,7 @@ klausur-c:
|
||||
@./scripts/extract-klausur.sh 223015c
|
||||
|
||||
klausur: klausur-b klausur-c
|
||||
@echo "Klausur slides extracted for all courses!"
|
||||
@echo "Klausurfolien slides extracted for all courses!"
|
||||
|
||||
# QR Code generation (uses nix-shell)
|
||||
qr:
|
||||
@@ -198,7 +179,8 @@ HDM_DEPLOY_PATH = /home/tengo/html/hdm
|
||||
|
||||
build-index: build/.exists
|
||||
@echo "Building root index..."
|
||||
@echo '<!DOCTYPE html><html lang="de"><head><meta charset="UTF-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>HdM Vorlesungen</title><style>*{box-sizing:border-box;margin:0;padding:0}body{font-family:-apple-system,BlinkMacSystemFont,"SF Pro Display","Segoe UI",Roboto,sans-serif;max-width:720px;margin:0 auto;padding:3rem 1.5rem;background:#fafafa;color:#1d1d1f;line-height:1.5}h1{font-size:2rem;font-weight:600;letter-spacing:-0.02em;margin-bottom:.5rem}.subtitle{color:#86868b;font-size:1rem}.courses{margin-top:2rem;display:flex;flex-direction:column;gap:.75rem}a.course{display:block;background:#fff;border-radius:12px;padding:1.5rem;text-decoration:none;color:inherit;box-shadow:0 1px 3px rgba(0,0,0,0.08);transition:all .2s ease;cursor:pointer}a.course:hover{transform:translateY(-2px);box-shadow:0 4px 12px rgba(0,0,0,0.12)}.course-label{font-size:.7rem;font-weight:600;text-transform:uppercase;letter-spacing:.05em}.course-b .course-label{color:#1e5f8a}.course-c .course-label{color:#d63384}.course-title{font-size:1.15rem;font-weight:500;color:#1d1d1f;margin:.25rem 0}.course-info{font-size:.85rem;color:#86868b}.section-title{font-size:1rem;font-weight:600;color:#86868b;margin-top:2.5rem;margin-bottom:.75rem}.references{display:flex;flex-direction:column;gap:.75rem}footer{margin-top:2.5rem;padding-top:1.5rem;border-top:1px solid #e5e5e7;color:#86868b;font-size:.85rem}footer a{color:#1d1d1f;text-decoration:none}footer a:hover{text-decoration:underline}.qr-section{margin-top:2.5rem;padding:1.5rem;background:#fff;border-radius:12px;box-shadow:0 1px 3px rgba(0,0,0,0.08);text-align:center}.qr-code{width:100%;height:auto}.qr-url{margin-top:.75rem;font-size:.85rem;color:#86868b}</style></head><body><h1>HdM Vorlesungen</h1><p class="subtitle">Wintersemester 2025/26 · Michael Czechowski</p><div class="courses"><a class="course course-b" href="223015b/"><span class="course-label">223015b</span><div class="course-title">Dateiformate, Schnittstellen, Speichermedien & Distributionswege</div><span class="course-info">6 Kapitel · Modul "Technik 1"</span></a><a class="course course-c" href="223015c/"><span class="course-label">223015c</span><div class="course-title">Grundlagen IT- und Internettechnik</div><span class="course-info">3 Kapitel · Modul "Technik 1"</span></a></div><h2 class="section-title">Referenzen</h2><div class="references"><a class="course" href="https://codecrispi.es/"><span class="course-label">Plattform</span><div class="course-title">Code Crispies</div><span class="course-info">Selbstlernplattform</span></a></div><div class="qr-section"><img src="qr-root.svg" alt="QR Code" class="qr-code"><p class="qr-url">https://librete.ch/hdm/</p></div><footer><a href="mailto:mail@librete.ch">Kontakt</a></footer></body></html>' > build/index.html
|
||||
@mkdir -p build
|
||||
@./scripts/generate-root-index.sh
|
||||
|
||||
# Deploy
|
||||
define deploy_course
|
||||
|
||||
@@ -27,10 +27,12 @@ build/ # Generated output (gitignored)
|
||||
## Development
|
||||
|
||||
```bash
|
||||
# Start dev servers (hot reload)
|
||||
make dev # All courses + index
|
||||
make dev-b # 223015b only (port 1311)
|
||||
make dev-c # 223015c only (port 1312)
|
||||
# Start development server (hot reload)
|
||||
make dev # Single server for all courses (port 3000)
|
||||
|
||||
# Access individual courses:
|
||||
# 223015b: http://localhost:3000/223015b/
|
||||
# 223015c: http://localhost:3000/223015c/
|
||||
```
|
||||
|
||||
## Build
|
||||
@@ -43,7 +45,7 @@ make html # HTML only
|
||||
make pdf # PDF only
|
||||
```
|
||||
|
||||
## Klausur Slides
|
||||
## Klausur Folien
|
||||
|
||||
Extract exam-relevant slides (marked with `<!-- _class: klausur -->`) into a single file:
|
||||
|
||||
@@ -53,7 +55,7 @@ make klausur-b # 223015b only
|
||||
make klausur-c # 223015c only
|
||||
```
|
||||
|
||||
Output: `slides/<course>/klausur.md`
|
||||
Output: `slides/<course>/klausurfolien.md`
|
||||
|
||||
The generated file includes:
|
||||
- A title slide per kapitel for orientation
|
||||
|
||||
@@ -0,0 +1,469 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<quiz>
|
||||
|
||||
<!-- ============================================================
|
||||
223015c – Grundlagen IT- und Internettechnik
|
||||
40 Punkte / 40 Minuten
|
||||
Michael Czechowski – HdM Stuttgart – WS 2025/26
|
||||
============================================================ -->
|
||||
|
||||
<!-- ─── 3 pt – Von-Neumann: 5 Komponenten ─── -->
|
||||
<question type="matching">
|
||||
<n><text>Q1 – Von-Neumann: Komponenten zuordnen</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ordne jeder Komponente der Von-Neumann-Architektur ihre
|
||||
Funktion zu.</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Die 5 Komponenten: ALU (Rechnen), Steuerwerk (Befehle steuern), Speicherwerk (Programme UND Daten), Ein-/Ausgabe (Peripherie), Bus-System (Verbindung).</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<answer fraction="100"><text>Rechenwerk (ALU)</text><match>Führt arithmetische und logische Operationen durch.</match></answer>
|
||||
<answer fraction="100"><text>Steuerwerk</text><match>Holt, dekodiert und steuert die Ausführung von Befehlen.</match></answer>
|
||||
<answer fraction="100"><text>Speicherwerk</text><match>Enthält sowohl Programme als auch Daten (Stored Program Concept).</match></answer>
|
||||
<answer fraction="100"><text>Ein-/Ausgabe</text><match>Schnittstelle zu externen Geräten wie Tastatur, Bildschirm, Netzwerk.</match></answer>
|
||||
<answer fraction="100"><text>Bus-System</text><match>Verbindet alle Komponenten mittels Adress-, Daten- und Steuerbus.</match></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – Von-Neumann vs Harvard: Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q2 – Von-Neumann vs. Harvard</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ein Arduino-Mikrocontroller nutzt die <strong>Harvard-Architektur</strong>.
|
||||
Ein modernes Smartphone nutzt eine (modifizierte) Von-Neumann-Architektur.</p>
|
||||
<p><strong>Warum ist die Harvard-Architektur für Echtzeit-Anwendungen
|
||||
auf dem Arduino vorteilhafter, und was wäre der Nachteil, wenn
|
||||
das Smartphone diese Architektur verwenden würde?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Harvard: separate Code/Daten-Speicher → paralleler Zugriff, schneller. Nachteil: Code und Daten nicht aus gleichem Speicher nahtlos mischbar → weniger Flexibilität, kein „Laden beliebiger Apps" wie bei Von-Neumann.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – Speed vs. Flexibilität.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was getrennte Speicher für Code und Daten bedeuten.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Harvard nutzt <strong>separate Speicher</strong> für Code und Daten → paralleler Zugriff, schneller. Beim Smartphone wäre es schwieriger, beliebige Apps zu laden – weniger Flexibilität.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Harvard ist langsamer, aber sicherer – daher für Echtzeit geeignet. Smartphones brauchen die Geschwindigkeit nicht.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Beide Architekturen sind funktional identisch – der Unterschied liegt nur im Gehäuse.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Von-Neumann ist schneller durch gemeinsamen Speicher. Harvard wird gewählt, weil Echtzeit-Apps weniger Speicher brauchen.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – Stored Program Concept Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q3 – Stored Program Concept</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Vor der Von-Neumann-Architektur mussten bei Maschinen wie dem
|
||||
ENIAC Programme durch <strong>Umstecken von Kabeln</strong> eingegeben
|
||||
werden.</p>
|
||||
<p><strong>Was konkret ermöglicht das Stored Program Concept, was
|
||||
vorher nicht möglich war? Nenne zwei Beispiele.</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Stored Program: Programme werden als Daten im Speicher abgelegt → austauschbar ohne Hardwareänderung. Ermöglicht: Betriebssysteme, Apps installieren/löschen, Multitasking, Updates.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – Programme als Daten im Speicher = Flexibilität.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – der Kern liegt darin, dass Programme im Speicher als Daten residieren.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Programme werden als <strong>Daten im Speicher</strong> abgelegt → z. B. Apps können installiert/gelöscht werden und <strong>Multitasking</strong> (mehrere Programme gleichzeitig) wird möglich.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Programme werden auf separater Hardware gespeichert → die Hauptspeicher-Kapazität wird ums Doppelte gesteigert.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Die Hardware kann jetzt selbst Befehle erfinden – kein Mensch muss mehr programmieren.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Nur ein einzelnes Programm kann gleichzeitig laufen, aber es kann schneller geladenen werden.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – HTML Metadaten: Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q4 – HTML: <head> vs. <body></text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ein Student erstellt eine Webseite und platziert <em>alles</em>
|
||||
im <code><body></code> – auch den <code><title></code>
|
||||
und die <code><meta name="description"></code>.</p>
|
||||
<p><strong>Welche zwei konkreten Konsequenzen hat das?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>title und meta description gehören in <head>. Im <body>: (1) kein Titel im Browser-Tab / Suchergebnis, (2) keine Beschreibung für Suchmaschinen/Screen-Reader → SEO und Accessibility beeinträchtigt.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – Metadaten im Body werden nicht als solche interpretiert.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – <head> und <body> haben spezifische Funktionen.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[(1) Der Browser-Tab zeigt <strong>keinen Titel</strong> an. (2) Suchmaschinen haben <strong>keine Beschreibung</strong> für das Snippet → schlechte SEO und Screen-Reader können die Seite nicht richtig vorlesen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Kein Problem – Browser ignorieren die Unterscheidung zwischen <code><head></code> und <code><body></code>.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[(1) Der Titel wird im Seiteninhalt sichtbar angezeigt. (2) Die description wird als Text auf der Seite eingeblendet.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Nur das Fehlen von <code><meta charset></code> ist ein Problem – title und description funktionieren überall.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 3 pt – Accessibility Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q5 – Barrierefreiheit: Curb-Cut-Effekt</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Der <strong>Curb-Cut-Effekt</strong> beschreibt, wie eine
|
||||
barrierefreie Lösung – ursprünglich für Menschen mit Behinderung –
|
||||
letztendlich <em>allen</em> zugute kommt.</p>
|
||||
<p><strong>Nenne ein konkretes Web-Beispiel, das diesen Effekt
|
||||
demonstriert, und erkläre, wer davon profitiert.</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Beispiel: Untertitel (für Gehörlose) → helfen auch in lauter Umgebung, beim Sprachlernen, bei Ton aus. Alt-Texte (für Screen-Reader) → helfen auch SEO. Semantisches HTML → besser für alle.</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – Barrierefreiheit hilft allen.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, welche barrierefreien Maßnahmen auch Menschen ohne Behinderung nutzen.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>Untertitel:</strong> Gedacht für Gehörlose, helfen aber auch in lauter Umgebung, beim Sprachlernen oder wenn der Ton aus ist – profitiert fast jedermann.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Barrierefreie Webseiten sind langsamer zu laden – der Curb-Cut-Effekt beschreibt diesen negativen Nebeneffekt.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der Curb-Cut-Effekt bedeutet, dass barrierefreie Seiten nur für Menschen mit Behinderung nützlich sind.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Dark Mode:</strong> Gedacht für Sehbehinderung, hilft auch in dunkler Umgebung – Beispiel für den Curb-Cut-Effekt.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – EAA / WCAG ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q6 – European Accessibility Act</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Der <strong>European Accessibility Act (EAA)</strong> ist seit
|
||||
Juni 2025 in Kraft.</p>
|
||||
<p><strong>Was bedeutet das konkret für ein deutsches
|
||||
E-Commerce-Unternehmen, das eine Webseite betreibt?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>EAA verpflichtet u. a. E-Commerce-Anbieter zur Barrierefreiheit. Die Webseite muss WCAG-Standards erfüllen. Bei Verstoß: Bußgelder bis 100.000 € möglich.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – rechtliche Pflicht zur Barrierefreiheit.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – der EAA erstellt eine rechtliche Verpflichtung für bestimmte Sektoren.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Die Webseite <strong>muss barrierefreiheitstechnisch</strong> WCAG-Standards erfüllen – E-Commerce ist explizit im EAA geregelt. Bei Verstoß: Bußgelder möglich.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der EAA betrifft nur öffentliche Behörden – private Unternehmen sind ausgenommen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Das Unternehmen muss nur eine englische Version der Webseite bereitstellen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der EAA regelt nur die Barrierefreiheit von mobilen Apps, nicht von Webseiten.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 3 pt – TCP/IP Schichten: Protokoll → Schicht ─── -->
|
||||
<question type="matching">
|
||||
<n><text>Q7 – TCP/IP: Protokoll → Schicht</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ordne jedem Protokoll die richtige TCP/IP-Schicht zu.</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Anwendung: HTTP, DNS, SMTP. Transport: TCP, UDP. Internet: IP. Netzzugang: Ethernet, WLAN.</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<answer fraction="100"><text>HTTP</text><match>Anwendung</match></answer>
|
||||
<answer fraction="100"><text>TCP</text><match>Transport</match></answer>
|
||||
<answer fraction="100"><text>IP</text><match>Internet</match></answer>
|
||||
<answer fraction="100"><text>Ethernet</text><match>Netzzugang</match></answer>
|
||||
<answer fraction="100"><text>DNS</text><match>Anwendung</match></answer>
|
||||
<answer fraction="100"><text>UDP</text><match>Transport</match></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 3 pt – Encapsulation: D-S-P-F ─── -->
|
||||
<question type="matching">
|
||||
<n><text>Q8 – Encapsulation: Dateneinheit → Schicht</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Bei der Übertragung wird eine Nachricht von Schicht zu Schicht
|
||||
verpackt (Encapsulation). Ordne jeder Dateneinheit die zugehörige
|
||||
Schicht zu.</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Daten (Anwendung) → Segment (Transport, +Ports) → Paket (Internet, +IP) → Frame (Netzzugang, +MAC). Merkhilfe: D-S-P-F.</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<answer fraction="100"><text>Daten</text><match>Anwendungsschicht – die eigentliche Nachricht (z. B. HTML-Seite).</match></answer>
|
||||
<answer fraction="100"><text>Segment</text><match>Transportschicht – Daten + Ports und Sequenznummern.</match></answer>
|
||||
<answer fraction="100"><text>Paket</text><match>Internetschicht – Segment + IP-Adressen (Quelle und Ziel).</match></answer>
|
||||
<answer fraction="100"><text>Frame</text><match>Netzzugangsschicht – Paket + MAC-Adressen und Prüfsumme.</match></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 3 pt – IP vs MAC vs Port Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q9 – IP vs. MAC vs. Port: Transfer-Szenario</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Dein Laptop sendet eine HTTPS-Anfrage an einen Webserver in
|
||||
einem anderen Land. Das Paket durchläuft mehrere Router.</p>
|
||||
<p><strong>Welche der folgenden Aussagen über die Adressen auf dem
|
||||
Weg ist korrekt?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>IP-Adresse des Ziel-Servers bleibt konstant (global). MAC-Adresse ändert sich bei jedem Hop (lokal, nächster Router). Port 443 (HTTPS) bleibt konstant.</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – nur MAC ändert sich unterwegs.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, welche Adresse bei jedem Hop neu gesetzt wird.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Die <strong>IP-Adresse</strong> des Servers bleibt konstant, der <strong>Port</strong> (443) ändert sich nicht – die <strong>MAC-Adresse</strong> wird an jedem Router neu gesetzt (lokal, ein Hop).]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Alle drei Adressen (IP, MAC, Port) ändert sich bei jedem Router.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Die MAC-Adresse bleibt konstant, die IP-Adresse ändert sich bei jedem Hop.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[IP und Port ändert sich, MAC bleibt konstant – MAC ist die globale Adresse.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 3 pt – 3-Way Handshake: Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q10 – TCP 3-Way-Handshake: Was passiert wäre?</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Der Client sendet ein <strong>SYN</strong> zum Server.
|
||||
Das SYN-Paket geht verloren – es erreicht den Server nie.</p>
|
||||
<p><strong>Was passiert als nächstes, und warum wird keine
|
||||
Verbindung aufgebaut?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Der Server erhält kein SYN → sendet kein SYN-ACK zurück → der Client bekommt keine Antwort → Verbindung wird nicht aufgebaut. TCP wird das SYN nach einem Timeout erneut senden (Neuübertragung).</text></generalfeedback>
|
||||
<defaultgrade>3</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – ohne SYN beim Server: kein SYN-ACK, kein Handshake.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was der Server ohne SYN tun kann.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Der Server kennt die Anfrage nicht → sendet <strong>kein SYN-ACK</strong> → der Client erhält keine Antwort → <strong>keine Verbindung</strong>. Der Client wird das SYN nach einem Timeout erneut senden.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der Server sendet trotzdem ein SYN-ACK, da die IP-Adresse bekannt ist – die Verbindung wird trotzdem aufgebaut.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der Client sendet direkt ein ACK als Fallback – die Verbindung wird mit zwei Paketen aufgebaut.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Das verloren gegangene SYN wird automatisch vom Netzwerk rekonstruiert – kein Problem.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – TCP vs UDP Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q11 – TCP vs. UDP: Videostreaming</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ein Videostreaming-Dienst sendet Daten an deinen Browser.
|
||||
Ein einzelnes Paket geht verloren.</p>
|
||||
<p><strong>Warum wählt der Dienst <strong>UDP</strong> statt TCP,
|
||||
obwohl ein Paket verloren geht?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Bei Echtzeit-Video ist Verzögerung schlimmer als Paketverlust. TCP würde das Paket erneut anfordern → Video friert. UDP ignoriert das Verlust → kurzer Artefakt, Video läuft weiter.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – bei Echtzeit ist Verzögerung ärger als Verlust.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was TCP bei einem verlorenen Paket tun würde.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[Bei <strong>Echtzeit</strong> ist Verzögerung schlimmer als Verlust. TCP würde das Paket <strong>erneut anfordern</strong> → Video friert ein. UDP ignoriert es → kurzer Glitch, Video läuft weiter.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[UDP sendet jedes Paket doppelt, daher geht statistisch nie etwas verloren.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[TCP kann bei Videostreaming nicht verwendet werden, da es zu langsam für Multimedia ist.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[UDP ist immer schneller als TCP – deshalb nutzt jeder Streaming-Dienst UDP.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – HTTP Methoden: Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q12 – HTTP-Methoden: Szenario</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ein Nutzer aktualisiert sein Profilbild auf einer Webseite.
|
||||
Das Foto wird zum Server gesendet und das <strong>alte Bild
|
||||
ersetzt</strong>.</p>
|
||||
<p><strong>Welche HTTP-Methode wird für diese Operation verwendet,
|
||||
und warum nicht GET?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>PUT – Daten ersetzen (eine existierende Ressource wird überschrieben). GET ruft nur Daten ab, sendet keine Daten zum Server.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – PUT für das Ersetzen einer Ressource.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was „ersetzen" in HTTP bedeutet.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>PUT</strong> – ersetzt eine existierende Ressource. GET ruft nur Daten ab und sendet <em>keine</em> Daten zum Server.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>GET</strong> – GET kann auch Daten senden, wenn eine URL mit Parameter verwendet wird.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>POST</strong> – POST ist immer für das Ersetzen von Daten zuständig.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>DELETE</strong> – DELETE sendet das neue Foto und löscht gleichzeitig das alte.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – HTTP Status-Codes Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q13 – HTTP Status-Codes: Fehlerdiagnose</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Du rufst eine Webseite auf und der Browser zeigt folgende
|
||||
Fehlermeldung an:</p>
|
||||
<pre>HTTP/1.1 503 Service Unavailable</pre>
|
||||
<p><strong>Was bedeutet dieser Code, und wer ist für die Behebung
|
||||
zuständig – du oder der Betreiber der Webseite?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>503 ist ein 5xx-Code = Server-Fehler. Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim Serverbetreiber, nicht beim Nutzer.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – 5xx = Server-Problem, nicht dein Fehler.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was die Ziffer „5" im Code bedeutet.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>Server-Fehler:</strong> Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim <strong>Betreiber</strong> – du kannst nur später erneut versuchen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Client-Fehler: Du hast die falsche URL eingegeben – ein 5xx-Code bedeutet, dass deine Anfrage falsch war.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Erfolgs-Code: 503 bedeutet, dass der Server die Anfrage erfolgreich umgeleitet hat.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der Code bedeutet, dass der Server die Seite dauerhaft verschoben hat – du muss die neue URL suchen.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – DNS Ablauf Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q14 – DNS: Rolle im Ablauf</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Du gibst <code>https://hdm-stuttgart.de</code> in die
|
||||
Adresszeile ein.</p>
|
||||
<p><strong>Was passiert <em>vor</em> dem TCP-Handshake, und warum
|
||||
ist dieser Schritt zwingend nötig?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>DNS-Auflösung: Der Name „hdm-stuttgart.de" wird in eine IP-Adresse umgewandelt. TCP braucht eine IP-Adresse – names können nicht direkt verbunden werden.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – DNS vor TCP, Name → IP.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, was TCP als Zieladresse braucht.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>DNS-Auflösung:</strong> Der Name <code>hdm-stuttgart.de</code> wird in eine <strong>IP-Adresse</strong> umgewandelt. TCP kann nur zu IP-Adressen Verbindungen aufbauen, nicht zu Namen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Der Browser sendet direkt den Namen an den Server – DNS wird erst danach für die Verschlüsselung benötigt.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[DNS passiert nach dem TCP-Handshake – erst wird die Verbindung aufgebaut, dann der Name aufgelöst.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[DNS ist nur für HTTPS nötig – bei HTTP kann der Name direkt verwendet werden.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – CSS Spezifität Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q15 – CSS Spezifität: Welche Regel gewinnt?</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Gegeben folgender CSS-Code:</p>
|
||||
<pre>
|
||||
p { color: blue; } /* (A) */
|
||||
.highlight { color: green; } /* (B) */
|
||||
#main { color: red; } /* (C) */
|
||||
</pre>
|
||||
<p>Ein Element <code><p class="highlight" id="main">Text</p></code>
|
||||
wird angezeigt.<br>
|
||||
<strong>Welche Farbe zeigt der Text an, und warum?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Spezifität: ID (0,1,0,0) > Klasse (0,0,1,0) > Element (0,0,0,1). Alle drei Regeln treffen das Element – ID #main gewinnt → rot.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – ID gewinnt durch höchste Spezifität.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege die Spezifitätswerte: ID > Klasse > Element.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>Rot</strong> – die ID-Regel <code>#main</code> hat die höchste Spezifität (0,1,0,0) und gewinnt über Klasse (0,0,1,0) und Element (0,0,0,1).]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Blau</strong> – die Element-Regel steht zuerst im Code und hat daher Vorrang.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Grün</strong> – Klassen-Selektoren haben immer Vorrang vor IDs.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Rot</strong> – die letzte Regel im Code gewinnt immer, unabhängig vom Selektor-Typ.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 2 pt – Responsive Design Transfer ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q16 – Responsive Design: Mobile First</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Ein Developer schreibt folgendes CSS:</p>
|
||||
<pre>
|
||||
.container { background: white; }
|
||||
|
||||
@media (min-width: 768px) {
|
||||
.container { background: blue; }
|
||||
}
|
||||
|
||||
@media (min-width: 1024px) {
|
||||
.container { background: green; }
|
||||
}
|
||||
</pre>
|
||||
<p><strong>Welche Farbe hat <code>.container</code> bei einem
|
||||
Bildschirm von 900 px Breite, und warum?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Mobile First: Basis = white. Bei 900px greift min-width: 768px → blue. min-width: 1024px greift NICHT (900 < 1024). Ergebnis: blau.</text></generalfeedback>
|
||||
<defaultgrade>2</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – 768px greift, 1024px nicht.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – überlege, welche min-width-Bedingungen bei 900px erfüllt sind.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>Blau</strong> – bei 900 px greift <code>min-width: 768px</code> (900 ≥ 768), aber <code>min-width: 1024px</code> greift nicht (900 < 1024).]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Weiß</strong> – Media-Queries gelten nur ab 1024 px, darunter bleibt immer die Basis-Farbe.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Grün</strong> – die letzte Media-Query überschreibt immer alle vorherigen.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Weiß</strong> – bei 900 px greift keine Media-Query, da 900 zwischen den beiden Breakpoints liegt.]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 1 pt – Zusammen: Der Ablauf eines Klicks ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q17 – Zusammen: Reihenfolge eines HTTPS-Aufrufs</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Du gibst eine URL ein. <strong>Welche Reihenfolge der Schritte
|
||||
ist korrekt?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Korrekte Reihenfolge: (1) DNS-Auflösung, (2) TCP 3-Way-Handshake, (3) HTTP-Request (GET), (4) HTTP-Response (200 OK + HTML).</text></generalfeedback>
|
||||
<defaultgrade>1</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – DNS → TCP → HTTP Request → HTTP Response.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – an erster Stelle steht immer die DNS-Auflösung.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[(1) DNS → (2) TCP-Handshake → (3) HTTP GET → (4) HTTP 200 OK]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[(1) TCP-Handshake → (2) DNS → (3) HTTP GET → (4) HTTP 200 OK]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[(1) HTTP GET → (2) DNS → (3) TCP-Handshake → (4) HTTP 200 OK]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[(1) DNS → (2) HTTP GET → (3) TCP-Handshake → (4) HTTP 200 OK]]></text></answer>
|
||||
</question>
|
||||
|
||||
<!-- ─── 1 pt – Bonusfrage: Spezifität Edge Case ─── -->
|
||||
<question type="multichoice">
|
||||
<n><text>Q18 – CSS: 100 Element-Selektoren vs. 1 Klasse</text></n>
|
||||
<questiontext type="html">
|
||||
<text><![CDATA[
|
||||
<p>Es gibt zwei CSS-Regeln für ein <code><p></code>-Element:</p>
|
||||
<pre>
|
||||
p p p p p p p p p p { color: blue; } /* 100× Element-Selektor */
|
||||
.highlight { color: red; } /* 1× Klasse */
|
||||
</pre>
|
||||
<p>Das Element hat die Klasse <code>highlight</code>.
|
||||
<strong>Welche Farbe gewinnt?</p>
|
||||
]]></text>
|
||||
</questiontext>
|
||||
<generalfeedback type="html"><text>Eine einzelne Klasse (0,0,1,0) schlägt immer hundert Element-Selektoren (0,0,0,100). Spezifität wird nicht additiv „aufgezählt" – die Stelle zählt als Einheit.</text></generalfeedback>
|
||||
<defaultgrade>1</defaultgrade>
|
||||
<penalty>0.25</penalty>
|
||||
<hidden>0</hidden>
|
||||
<single>true</single>
|
||||
<shuffleanswers>true</shuffleanswers>
|
||||
<correctfeedback type="html"><text>Genau – eine Klasse gewinnt immer gegen beliebig viele Elemente.</text></correctfeedback>
|
||||
<incorrectfeedback type="html"><text>Nein – Spezifität funktioniert nicht durch Addition innerhalb einer Stelle.</text></incorrectfeedback>
|
||||
<answer fraction="100"><text><![CDATA[<strong>Rot</strong> – eine Klasse (0,0,1,0) gewinnt immer gegen beliebig viele Element-Selektoren (0,0,0,n). Spezifität-Stellen überschreiben sich, nicht addieren.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Blau</strong> – 100 Element-Selektoren ergeben 0,0,0,100 = höhere Spezifität als 0,0,1,0.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[<strong>Blau</strong> – die längere Regel (mehr Selektoren) hat immer höhere Spezifität.]]></text></answer>
|
||||
<answer fraction="0"><text><![CDATA[Unentschieden – die Regeln haben exakt gleiche Spezifität.]]></text></answer>
|
||||
</question>
|
||||
|
||||
</quiz>
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,439 @@
|
||||
Here is the quiz converted into a clean, readable Markdown format. I have preserved the structure, code snippets, and feedback for each question.
|
||||
|
||||
---
|
||||
|
||||
# 223015c – Grundlagen IT- und Internettechnik
|
||||
|
||||
**WS 2025/26 – Michael Czechowski – HdM Stuttgart**
|
||||
**40 Punkte / 40 Minuten**
|
||||
|
||||
---
|
||||
|
||||
### Q1 – Von-Neumann: Komponenten zuordnen (3 pt)
|
||||
|
||||
**Ordne jeder Komponente der Von-Neumann-Architektur ihre Funktion zu.**
|
||||
|
||||
* **Rechenwerk (ALU):** Führt arithmetische und logische Operationen durch.
|
||||
* **Steuerwerk:** Holt, dekodiert und steuert die Ausführung von Befehlen.
|
||||
* **Speicherwerk:** Enthält sowohl Programme als auch Daten (Stored Program Concept).
|
||||
* **Ein-/Ausgabe:** Schnittstelle zu externen Geräten wie Tastatur, Bildschirm, Netzwerk.
|
||||
* **Bus-System:** Verbindet alle Komponenten mittels Adress-, Daten- und Steuerbus.
|
||||
|
||||
> **Feedback:** Die 5 Komponenten: ALU (Rechnen), Steuerwerk (Befehle steuern), Speicherwerk (Programme UND Daten), Ein-/Ausgabe (Peripherie), Bus-System (Verbindung).
|
||||
|
||||
---
|
||||
|
||||
### Q2 – Von-Neumann vs. Harvard (2 pt)
|
||||
|
||||
**Ein Arduino-Mikrocontroller nutzt die Harvard-Architektur. Ein modernes Smartphone nutzt eine (modifizierte) Von-Neumann-Architektur.**
|
||||
|
||||
**Warum ist die Harvard-Architektur für Echtzeit-Anwendungen auf dem Arduino vorteilhafter, und was wäre der Nachteil, wenn das Smartphone diese Architektur verwenden würde?**
|
||||
|
||||
* [ ] Harvard ist langsamer, aber sicherer – daher für Echtzeit geeignet. Smartphones brauchen die Geschwindigkeit nicht.
|
||||
* [x] **Harvard nutzt separate Speicher für Code und Daten → paralleler Zugriff, schneller. Beim Smartphone wäre es schwieriger, beliebige Apps zu laden – weniger Flexibilität.** ✅
|
||||
* [ ] Beide Architekturen sind funktional identisch – der Unterschied liegt nur im Gehäuse.
|
||||
* [ ] Von-Neumann ist schneller durch gemeinsamen Speicher. Harvard wird gewählt, weil Echtzeit-Apps weniger Speicher brauchen.
|
||||
|
||||
> **Feedback:** Harvard: separate Code/Daten-Speicher → paralleler Zugriff, schneller. Nachteil: Code und Daten nicht aus gleichem Speicher nahtlos mischbar → weniger Flexibilität, kein „Laden beliebiger Apps" wie bei Von-Neumann.
|
||||
|
||||
---
|
||||
|
||||
### Q3 – Stored Program Concept (2 pt)
|
||||
|
||||
**Vor der Von-Neumann-Architektur mussten bei Maschinen wie dem ENIAC Programme durch Umstecken von Kabeln eingegeben werden.**
|
||||
|
||||
**Was konkret ermöglicht das Stored Program Concept, was vorher nicht möglich war? Nenne zwei Beispiele.**
|
||||
|
||||
* [ ] Programme werden auf separater Hardware gespeichert → die Hauptspeicher-Kapazität wird ums Doppelte gesteigert.
|
||||
* [ ] Die Hardware kann jetzt selbst Befehle erfinden – kein Mensch muss mehr programmieren.
|
||||
* [x] **Programme werden als Daten im Speicher abgelegt → z. B. Apps können installiert/gelöscht werden und Multitasking (mehrere Programme gleichzeitig) wird möglich.** ✅
|
||||
* [ ] Nur ein einzelnes Programm kann gleichzeitig laufen, aber es kann schneller geladenen werden.
|
||||
|
||||
> **Feedback:** Stored Program: Programme werden als Daten im Speicher abgelegt → austauschbar ohne Hardwareänderung. Ermöglicht: Betriebssysteme, Apps installieren/löschen, Multitasking, Updates.
|
||||
|
||||
---
|
||||
|
||||
### Q4 – HTML: `<head>` vs. `<body>` (2 pt)
|
||||
|
||||
**Ein Student erstellt eine Webseite und platziert *alles* im `<body>` – auch den `<title>` und die `<meta name="description">`.**
|
||||
|
||||
**Welche zwei konkreten Konsequenzen hat das?**
|
||||
|
||||
* [ ] Kein Problem – Browser ignorieren die Unterscheidung zwischen `<head>` und `<body>`.
|
||||
* [x] **(1) Der Browser-Tab zeigt keinen Titel an. (2) Suchmaschinen haben keine Beschreibung für das Snippet → schlechte SEO und Screen-Reader können die Seite nicht richtig vorlesen.** ✅
|
||||
* [ ] (1) Der Titel wird im Seiteninhalt sichtbar angezeigt. (2) Die description wird als Text auf der Seite eingeblendet.
|
||||
* [ ] Nur das Fehlen von `<meta charset>` ist ein Problem – title und description funktionieren überall.
|
||||
|
||||
> **Feedback:** title und meta description gehören in `<head>`. Im `<body>`: (1) kein Titel im Browser-Tab / Suchergebnis, (2) keine Beschreibung für Suchmaschinen/Screen-Reader → SEO und Accessibility beeinträchtigt.
|
||||
|
||||
---
|
||||
|
||||
### Q5 – Barrierefreiheit: Curb-Cut-Effekt (3 pt)
|
||||
|
||||
**Der Curb-Cut-Effekt beschreibt, wie eine barrierefreie Lösung – ursprünglich für Menschen mit Behinderung – letztendlich *allen* zugute kommt.**
|
||||
|
||||
**Nenne ein konkretes Web-Beispiel, das diesen Effekt demonstriert, und erkläre, wer davon profitiert.**
|
||||
|
||||
* [ ] Barrierefreie Webseiten sind langsamer zu laden – der Curb-Cut-Effekt beschreibt diesen negativen Nebeneffekt.
|
||||
* [ ] Der Curb-Cut-Effekt bedeutet, dass barrierefreie Seiten nur für Menschen mit Behinderung nützlich sind.
|
||||
* [x] **Untertitel: Gedacht für Gehörlose, helfen aber auch in lauter Umgebung, beim Sprachlernen oder wenn der Ton aus ist – profitiert fast jedermann.** ✅
|
||||
* [ ] **Dark Mode:** Gedacht für Sehbehinderung, hilft auch in dunkler Umgebung – Beispiel für den Curb-Cut-Effekt.
|
||||
|
||||
> **Feedback:** Beispiel: Untertitel (für Gehörlose) → helfen auch in lauter Umgebung, beim Sprachlernen, bei Ton aus. Alt-Texte (für Screen-Reader) → helfen auch SEO. Semantisches HTML → besser für alle.
|
||||
|
||||
---
|
||||
|
||||
### Q6 – European Accessibility Act (2 pt)
|
||||
|
||||
**Der European Accessibility Act (EAA) ist seit Juni 2025 in Kraft.**
|
||||
|
||||
**Was bedeutet das konkret für ein deutsches E-Commerce-Unternehmen, das eine Webseite betreibt?**
|
||||
|
||||
* [ ] Der EAA betrifft nur öffentliche Behörden – private Unternehmen sind ausgenommen.
|
||||
* [ ] Das Unternehmen muss nur eine englische Version der Webseite bereitstellen.
|
||||
* [x] **Die Webseite muss barrierefreiheitstechnisch WCAG-Standards erfüllen – E-Commerce ist explizit im EAA geregelt. Bei Verstoß: Bußgelder möglich.** ✅
|
||||
* [ ] Der EAA regelt nur die Barrierefreiheit von mobilen Apps, nicht von Webseiten.
|
||||
|
||||
> **Feedback:** EAA verpflichtet u. a. E-Commerce-Anbieter zur Barrierefreiheit. Die Webseite muss WCAG-Standards erfüllen. Bei Verstoß: Bußgelder bis 100.000 € möglich.
|
||||
|
||||
---
|
||||
|
||||
### Q7 – TCP/IP: Protokoll → Schicht (3 pt)
|
||||
|
||||
**Ordne jedem Protokoll die richtige TCP/IP-Schicht zu.**
|
||||
|
||||
* **HTTP:** Anwendung
|
||||
* **DNS:** Anwendung
|
||||
* **TCP:** Transport
|
||||
* **UDP:** Transport
|
||||
* **IP:** Internet
|
||||
* **Ethernet:** Netzzugang
|
||||
|
||||
> **Feedback:** Anwendung: HTTP, DNS, SMTP. Transport: TCP, UDP. Internet: IP. Netzzugang: Ethernet, WLAN.
|
||||
|
||||
---
|
||||
|
||||
### Q8 – Encapsulation: Dateneinheit → Schicht (3 pt)
|
||||
|
||||
**Bei der Übertragung wird eine Nachricht von Schicht zu Schicht verpackt (Encapsulation). Ordne jeder Dateneinheit die zugehörige Schicht zu.**
|
||||
|
||||
* **Daten:** Anwendungsschicht – die eigentliche Nachricht (z. B. HTML-Seite).
|
||||
* **Segment:** Transportschicht – Daten + Ports und Sequenznummern.
|
||||
* **Paket:** Internetschicht – Segment + IP-Adressen (Quelle und Ziel).
|
||||
* **Frame:** Netzzugangsschicht – Paket + MAC-Adressen und Prüfsumme.
|
||||
|
||||
> **Feedback:** Daten (Anwendung) → Segment (Transport, +Ports) → Paket (Internet, +IP) → Frame (Netzzugang, +MAC). Merkhilfe: D-S-P-F.
|
||||
|
||||
---
|
||||
|
||||
### Q9 – IP vs. MAC vs. Port: Transfer-Szenario (3 pt)
|
||||
|
||||
**Dein Laptop sendet eine HTTPS-Anfrage an einen Webserver in einem anderen Land. Das Paket durchläuft mehrere Router.**
|
||||
|
||||
**Welche der folgenden Aussagen über die Adressen auf dem Weg ist korrekt?**
|
||||
|
||||
* [ ] Alle drei Adressen (IP, MAC, Port) ändert sich bei jedem Router.
|
||||
* [x] **Die IP-Adresse des Servers bleibt konstant, der Port (443) ändert sich nicht – die MAC-Adresse wird an jedem Router neu gesetzt (lokal, ein Hop).** ✅
|
||||
* [ ] Die MAC-Adresse bleibt konstant, die IP-Adresse ändert sich bei jedem Hop.
|
||||
* [ ] IP und Port ändert sich, MAC bleibt konstant – MAC ist die globale Adresse.
|
||||
|
||||
> **Feedback:** IP-Adresse des Ziel-Servers bleibt konstant (global). MAC-Adresse ändert sich bei jedem Hop (lokal, nächster Router). Port 443 (HTTPS) bleibt konstant.
|
||||
|
||||
---
|
||||
|
||||
### Q10 – TCP 3-Way-Handshake: Was passiert wäre? (3 pt)
|
||||
|
||||
**Der Client sendet ein SYN zum Server. Das SYN-Paket geht verloren – es erreicht den Server nie.**
|
||||
|
||||
**Was passiert als nächstes, und warum wird keine Verbindung aufgebaut?**
|
||||
|
||||
* [ ] Der Server sendet trotzdem ein SYN-ACK, da die IP-Adresse bekannt ist – die Verbindung wird trotzdem aufgebaut.
|
||||
* [x] **Der Server kennt die Anfrage nicht → sendet kein SYN-ACK → der Client erhält keine Antwort → keine Verbindung. Der Client wird das SYN nach einem Timeout erneut senden.** ✅
|
||||
* [ ] Der Client sendet direkt ein ACK als Fallback – die Verbindung wird mit zwei Paketen aufgebaut.
|
||||
* [ ] Das verloren gegangene SYN wird automatisch vom Netzwerk rekonstruiert – kein Problem.
|
||||
|
||||
> **Feedback:** Der Server erhält kein SYN → sendet kein SYN-ACK zurück → der Client bekommt keine Antwort → Verbindung wird nicht aufgebaut. TCP wird das SYN nach einem Timeout erneut senden (Neuübertragung).
|
||||
|
||||
---
|
||||
|
||||
### Q11 – TCP vs. UDP: Videostreaming (2 pt)
|
||||
|
||||
**Ein Videostreaming-Dienst sendet Daten an deinen Browser. Ein einzelnes Paket geht verloren.**
|
||||
|
||||
**Warum wählt der Dienst UDP statt TCP, obwohl ein Paket verloren geht?**
|
||||
|
||||
* [ ] UDP sendet jedes Paket doppelt, daher geht statistisch nie etwas verloren.
|
||||
* [x] **Bei Echtzeit ist Verzögerung schlimmer als Verlust. TCP würde das Paket erneut anfordern → Video friert ein. UDP ignoriert es → kurzer Glitch, Video läuft weiter.** ✅
|
||||
* [ ] TCP kann bei Videostreaming nicht verwendet werden, da es zu langsam für Multimedia ist.
|
||||
* [ ] UDP ist immer schneller als TCP – deshalb nutzt jeder Streaming-Dienst UDP.
|
||||
|
||||
> **Feedback:** Bei Echtzeit-Video ist Verzögerung schlimmer als Paketverlust. TCP würde das Paket erneut anfordern → Video friert. UDP ignoriert das Verlust → kurzer Artefakt, Video läuft weiter.
|
||||
|
||||
---
|
||||
|
||||
### Q12 – HTTP-Methoden: Szenario (2 pt)
|
||||
|
||||
**Ein Nutzer aktualisiert sein Profilbild auf einer Webseite. Das Foto wird zum Server gesendet und das *alte Bild ersetzt*.**
|
||||
|
||||
**Welche HTTP-Methode wird für diese Operation verwendet, und warum nicht GET?**
|
||||
|
||||
* [ ] **GET** – GET kann auch Daten senden, wenn eine URL mit Parameter verwendet wird.
|
||||
* [x] **PUT – ersetzt eine existierende Ressource. GET ruft nur Daten ab und sendet *keine* Daten zum Server.** ✅
|
||||
* [ ] **POST** – POST ist immer für das Ersetzen von Daten zuständig.
|
||||
* [ ] **DELETE** – DELETE sendet das neue Foto und löscht gleichzeitig das alte.
|
||||
|
||||
> **Feedback:** PUT – Daten ersetzen (eine existierende Ressource wird überschrieben). GET ruft nur Daten ab, sendet keine Daten zum Server.
|
||||
|
||||
---
|
||||
|
||||
### Q13 – HTTP Status-Codes: Fehlerdiagnose (2 pt)
|
||||
|
||||
**Du rufst eine Webseite auf und der Browser zeigt folgende Fehlermeldung an:**
|
||||
`HTTP/1.1 503 Service Unavailable`
|
||||
|
||||
**Was bedeutet dieser Code, und wer ist für die Behebung zuständig – du oder der Betreiber der Webseite?**
|
||||
|
||||
* [ ] Client-Fehler: Du hast die falsche URL eingegeben – ein 5xx-Code bedeutet, dass deine Anfrage falsch war.
|
||||
* [ ] Erfolgs-Code: 503 bedeutet, dass der Server die Anfrage erfolgreich umgeleitet hat.
|
||||
* [x] **Server-Fehler: Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim Betreiber – du kannst nur später erneut versuchen.** ✅
|
||||
* [ ] Der Code bedeutet, dass der Server die Seite dauerhaft verschoben hat – du muss die neue URL suchen.
|
||||
|
||||
> **Feedback:** 503 ist ein 5xx-Code = Server-Fehler. Der Server ist überlastet oder temporär nicht verfügbar. Verantwortung liegt beim Serverbetreiber, nicht beim Nutzer.
|
||||
|
||||
---
|
||||
|
||||
### Q14 – DNS: Rolle im Ablauf (2 pt)
|
||||
|
||||
**Du gibst `https://hdm-stuttgart.de` in die Adresszeile ein.**
|
||||
|
||||
**Was passiert *vor* dem TCP-Handshake, und warum ist dieser Schritt zwingend nötig?**
|
||||
|
||||
* [ ] Der Browser sendet direkt den Namen an den Server – DNS wird erst danach für die Verschlüsselung benötigt.
|
||||
* [x] **DNS-Auflösung: Der Name `hdm-stuttgart.de` wird in eine IP-Adresse umgewandelt. TCP kann nur zu IP-Adressen Verbindungen aufbauen, nicht zu Namen.** ✅
|
||||
* [ ] DNS passiert nach dem TCP-Handshake – erst wird die Verbindung aufgebaut, dann der Name aufgelöst.
|
||||
* [ ] DNS ist nur für HTTPS nötig – bei HTTP kann der Name direkt verwendet werden.
|
||||
|
||||
> **Feedback:** DNS-Auflösung: Der Name „hdm-stuttgart.de" wird in eine IP-Adresse umgewandelt. TCP braucht eine IP-Adresse – names können nicht direkt verbunden werden.
|
||||
|
||||
---
|
||||
|
||||
### Q15 – CSS Spezifität: Welche Regel gewinnt? (2 pt)
|
||||
|
||||
**Gegeben folgender CSS-Code:**
|
||||
|
||||
```css
|
||||
p { color: blue; } /* (A) */
|
||||
.highlight { color: green; } /* (B) */
|
||||
#main { color: red; } /* (C) */
|
||||
|
||||
```
|
||||
|
||||
**Ein Element `<p class="highlight" id="main">Text</p>` wird angezeigt.**
|
||||
**Welche Farbe zeigt der Text an, und warum?**
|
||||
|
||||
* [ ] **Blau** – die Element-Regel steht zuerst im Code und hat daher Vorrang.
|
||||
* [ ] **Grün** – Klassen-Selektoren haben immer Vorrang vor IDs.
|
||||
* [x] **Rot – die ID-Regel `#main` hat die höchste Spezifität (0,1,0,0) und gewinnt über Klasse (0,0,1,0) und Element (0,0,0,1).** ✅
|
||||
* [ ] **Rot** – die letzte Regel im Code gewinnt immer, unabhängig vom Selektor-Typ.
|
||||
|
||||
> **Feedback:** Spezifität: ID (0,1,0,0) > Klasse (0,0,1,0) > Element (0,0,0,1). Alle drei Regeln treffen das Element – ID #main gewinnt → rot.
|
||||
|
||||
---
|
||||
|
||||
### Q16 – Responsive Design: Mobile First (2 pt)
|
||||
|
||||
**Ein Developer schreibt folgendes CSS:**
|
||||
|
||||
```css
|
||||
.container { background: white; }
|
||||
|
||||
@media (min-width: 768px) {
|
||||
.container { background: blue; }
|
||||
}
|
||||
|
||||
@media (min-width: 1024px) {
|
||||
.container { background: green; }
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
**Welche Farbe hat `.container` bei einem Bildschirm von 900 px Breite, und warum?**
|
||||
|
||||
* [ ] **Weiß** – Media-Queries gelten nur ab 1024 px, darunter bleibt immer die Basis-Farbe.
|
||||
* [ ] **Grün** – die letzte Media-Query überschreibt immer alle vorherigen.
|
||||
* [x] **Blau – bei 900 px greift `min-width: 768px` (900 ≥ 768), aber `min-width: 1024px` greift nicht (900 < 1024).** ✅
|
||||
* [ ] **Weiß** – bei 900 px greift keine Media-Query, da 900 zwischen den beiden Breakpoints liegt.
|
||||
|
||||
> **Feedback:** Mobile First: Basis = white. Bei 900px greift min-width: 768px → blue. min-width: 1024px greift NICHT (900 < 1024). Ergebnis: blau.
|
||||
|
||||
---
|
||||
|
||||
### Q17 – Zusammen: Reihenfolge eines HTTPS-Aufrufs (1 pt)
|
||||
|
||||
**Du gibst eine URL ein. Welche Reihenfolge der Schritte ist korrekt?**
|
||||
|
||||
* [ ] (1) TCP-Handshake → (2) DNS → (3) HTTP GET → (4) HTTP 200 OK
|
||||
* [x] **(1) DNS → (2) TCP-Handshake → (3) HTTP GET → (4) HTTP 200 OK** ✅
|
||||
* [ ] (1) HTTP GET → (2) DNS → (3) TCP-Handshake → (4) HTTP 200 OK
|
||||
* [ ] (1) DNS → (2) HTTP GET → (3) TCP-Handshake → (4) HTTP 200 OK
|
||||
|
||||
> **Feedback:** Korrekte Reihenfolge: (1) DNS-Auflösung, (2) TCP 3-Way-Handshake, (3) HTTP-Request (GET), (4) HTTP-Response (200 OK + HTML).
|
||||
|
||||
---
|
||||
|
||||
### Q18 – Bonusfrage: Spezifität Edge Case (1 pt)
|
||||
|
||||
**Es gibt zwei CSS-Regeln für ein `<p>`-Element:**
|
||||
|
||||
```css
|
||||
p p p p p p p p p p { color: blue; } /* 100× Element-Selektor */
|
||||
.highlight { color: red; } /* 1× Klasse */
|
||||
|
||||
```
|
||||
|
||||
**Das Element hat die Klasse `highlight`. Welche Farbe gewinnt?**
|
||||
|
||||
* [ ] **Blau** – 100 Element-Selektoren ergeben 0,0,0,100 = höhere Spezifität als 0,0,1,0.
|
||||
* [x] **Rot – eine Klasse (0,0,1,0) gewinnt immer gegen beliebig viele Element-Selektoren (0,0,0,n). Spezifität-Stellen überschreiben sich, nicht addieren.** ✅
|
||||
* [ ] **Blau** – die längere Regel (mehr Selektoren) hat immer höhere Spezifität.
|
||||
* [ ] Unentschieden – die Regeln haben exakt gleiche Spezifität.
|
||||
|
||||
> **Feedback:** Eine einzelne Klasse (0,0,1,0) schlägt immer hundert Element-Selektoren (0,0,0,100). Spezifität wird nicht additiv „aufgezählt" – die Stelle zählt als Einheit.
|
||||
|
||||
---
|
||||
|
||||
### Q19 – Von-Neumann: Der Flaschenhals (Engpass)
|
||||
|
||||
**Die Von-Neumann-Architektur hat einen bekannten Nachteil, den sogenannten „Von-Neumann-Flaschenhals“. Was ist damit gemeint?**
|
||||
|
||||
* [ ] Das Steuerwerk kann Befehle schneller verarbeiten, als das Rechenwerk sie berechnen kann.
|
||||
* [x] **Die CPU ist schneller als der Datentransfer über den gemeinsamen Bus. Da Daten und Befehle denselben Bus nutzen, müssen sie nacheinander geladen werden.** ✅
|
||||
* [ ] Der Speicher verliert seine Daten, wenn der Strom abgeschaltet wird, was den Startvorgang verlangsamt.
|
||||
* [ ] Die Ein-/Ausgabegeräte blockieren den Prozessor dauerhaft, da sie keinen eigenen Speicher haben.
|
||||
|
||||
> **Feedback:** Der Flaschenhals entsteht, weil Befehle und Daten sich den gleichen Weg (Bus) teilen müssen und der Speicherzugriff langsamer ist als die CPU-Geschwindigkeit.
|
||||
|
||||
---
|
||||
|
||||
### Q20 – HTML: Encoding (Charset)
|
||||
|
||||
**In Q4 ging es um Metadaten. Ein weiteres wichtiges Tag im `<head>` ist `<meta charset="UTF-8">`. Was ist die konkrete Konsequenz, wenn dieses Tag fehlt oder falsch ist?**
|
||||
|
||||
* [ ] Die Webseite lädt gar nicht, da der Browser den Binärcode nicht interpretieren kann.
|
||||
* [x] **Sonderzeichen (Umlaute, Emojis) werden als kryptische Symbole („Hieroglyphen“) dargestellt, da der Browser die falsche Zeichenkodierung rät.** ✅
|
||||
* [ ] Die Seite wird langsamer, da der Browser erst alle Sprachen der Welt durchprobieren muss.
|
||||
* [ ] Das CSS wird nicht geladen, da CSS zwingend UTF-8 voraussetzt.
|
||||
|
||||
> **Feedback:** Ohne definierte `charset` (Zeichensatz) nutzt der Browser oft einen Standard (z. B. Latin-1), was bei UTF-8-gespeicherten Dateien zu Darstellungsfehlern bei ä, ö, ü oder Emojis führt.
|
||||
|
||||
---
|
||||
|
||||
### Q21 – Barrierefreiheit: POUR-Prinzip
|
||||
|
||||
**Die WCAG basieren auf vier Prinzipien (POUR). Eines davon ist „Bedienbarkeit“ (Operable). Welches Szenario beschreibt eine Verletzung dieses Prinzips?**
|
||||
|
||||
* [ ] Der Textkontrast ist zu gering (grau auf hellgrau), sodass man ihn kaum lesen kann.
|
||||
* [x] **Eine Navigation funktioniert nur per Maus (Hover), ist aber per Tastatur (Tab-Taste) nicht erreichbar.** ✅
|
||||
* [ ] Der Inhalt ist in sehr komplizierter Fachsprache geschrieben, die ein Laie nicht versteht.
|
||||
* [ ] Die Webseite stürzt in alten Browsern ab.
|
||||
|
||||
> **Feedback:** „Bedienbar“ bedeutet, dass die Schnittstelle (Buttons, Links) von jedem genutzt werden kann – also auch ohne Maus (nur Tastatur). Kontrast gehört zu „Wahrnehmbar“ (Perceivable).
|
||||
|
||||
---
|
||||
|
||||
### Q22 – Encapsulation: Die Empfänger-Seite (Decapsulation)
|
||||
|
||||
**In Q8 haben wir Daten verpackt. Wenn der Server das Signal empfängt, passiert das Gegenteil (Decapsulation). In welcher Reihenfolge werden die Header *entfernt*?**
|
||||
|
||||
* [ ] Anwendung (HTTP) → Transport (TCP) → Internet (IP) → Netzzugang (Ethernet)
|
||||
* [ ] Es werden alle Header gleichzeitig entfernt, sobald die Daten im RAM liegen.
|
||||
* [x] **Netzzugang (Ethernet-Header weg) → Internet (IP-Header weg) → Transport (TCP-Header weg) → Daten.** ✅
|
||||
* [ ] Internet (IP) → Netzzugang (Ethernet) → Transport (TCP) → Anwendung (HTTP)
|
||||
|
||||
> **Feedback:** Das Auspacken erfolgt in umgekehrter Reihenfolge wie das Einpacken (Zwiebel-Prinzip). Erst wird der Umschlag (Ethernet) geöffnet, dann das Paket (IP), dann das Segment (TCP).
|
||||
|
||||
---
|
||||
|
||||
### Q23 – Ports: Wozu genau?
|
||||
|
||||
**Wir wissen aus Q9, dass IP-Adressen Computer identifizieren. Wozu genau dient dann die Port-Nummer (z. B. 80 oder 443) auf dem Zielrechner?**
|
||||
|
||||
* [ ] Sie bestimmt die Geschwindigkeit der Verbindung.
|
||||
* [ ] Sie dient zur Verschlüsselung der Daten.
|
||||
* [x] **Sie adressiert den konkreten Dienst bzw. die Anwendung auf dem Computer (z. B. Webserver vs. Mailserver).** ✅
|
||||
* [ ] Sie zeigt an, ob der Computer per WLAN oder Kabel verbunden ist.
|
||||
|
||||
> **Feedback:** Die IP ist wie die Hausnummer (welches Gebäude?), der Port ist wie die Türnummer oder der Name an der Klingel (wer im Haus soll das Paket bekommen? Webserver? Mailserver?).
|
||||
|
||||
---
|
||||
|
||||
### Q24 – TCP: Sequenznummern
|
||||
|
||||
**TCP ist zuverlässig. Ein Mechanismus dafür sind „Sequenznummern“ im Header. Welches Problem lösen diese konkret?**
|
||||
|
||||
* [ ] Sie verhindern, dass Hacker die Verbindung abhören können.
|
||||
* [x] **Pakete können im Internet unterschiedliche Routen nehmen und in falscher Reihenfolge ankommen. Sequenznummern erlauben das korrekte Sortieren beim Empfänger.** ✅
|
||||
* [ ] Sie zählen, wie viele Benutzer gerade gleichzeitig auf dem Server sind.
|
||||
* [ ] Sie bestimmen die maximale Größe einer Datei.
|
||||
|
||||
> **Feedback:** Da IP-Pakete überholen können, kommen Teil 2 und Teil 3 vielleicht vor Teil 1 an. TCP sortiert sie anhand der Nummern wieder richtig. UDP macht das nicht.
|
||||
|
||||
---
|
||||
|
||||
### Q25 – HTTP Methoden: Sicherheit
|
||||
|
||||
**Warum sollte man niemals die GET-Methode verwenden, um sensible Daten (z. B. ein Passwort) an den Server zu senden?**
|
||||
|
||||
* [ ] GET ist langsamer als POST und Passwörter müssen schnell übertragen werden.
|
||||
* [x] **Bei GET stehen die Daten sichtbar in der URL (Browser-Verlauf, Server-Logs, Proxy-Server). Bei POST stehen sie im Body.** ✅
|
||||
* [ ] GET erlaubt nur Zahlen, keine Buchstaben.
|
||||
* [ ] GET-Anfragen werden vom Server nicht verschlüsselt, POST-Anfragen immer.
|
||||
|
||||
> **Feedback:** Parameter bei GET hängen an der URL (`?pw=123`). Das ist in der History und in Logs sichtbar. HTTPS verschlüsselt zwar beides auf der Leitung, aber die URL ist an zu vielen Stellen sichtbar.
|
||||
|
||||
---
|
||||
|
||||
### Q26 – HTTP Status: 404 Not Found
|
||||
|
||||
**Du erhältst einen 404-Fehler. In Q13 (503) lag der Fehler beim Server. Wer hat beim 404-Fehler „Schuld“ bzw. wo liegt die Ursache meistens?**
|
||||
|
||||
* [ ] Der Server ist abgestürzt.
|
||||
* [ ] Das Internet ist ausgefallen.
|
||||
* [x] **Der Client (Nutzer). Es wurde eine URL angefordert, die es nicht gibt (Tippfehler oder veralteter Link).** ✅
|
||||
* [ ] Der DNS-Server konnte den Namen nicht auflösen.
|
||||
|
||||
> **Feedback:** 4xx-Codes sind Client-Errors. Der Server funktioniert super, er sagt dir nur: „Das, was du (Client) suchst, habe ich nicht.“
|
||||
|
||||
---
|
||||
|
||||
### Q27 – CSS: `!important` vs. ID
|
||||
|
||||
**In Q15 hat die ID gewonnen. Nun ändern wir den Code:**
|
||||
|
||||
```css
|
||||
#main { color: red; }
|
||||
p { color: blue !important; }
|
||||
|
||||
```
|
||||
|
||||
**Welche Farbe hat das `<p id="main">` Element nun?**
|
||||
|
||||
* [ ] **Rot** – ID ist immer noch spezifischer als ein Element-Selektor.
|
||||
* [ ] **Lila** – Die Farben mischen sich.
|
||||
* [x] **Blau** – `!important` durchbricht die normale Spezifitäts-Kaskade und gewinnt sogar gegen IDs (außer die ID hat auch !important). ✅
|
||||
* [ ] **Rot** – `!important` wird von modernen Browsern ignoriert.
|
||||
|
||||
> **Feedback:** `!important` ist die „Atombombe“ im CSS. Es überschreibt normale Spezifitätsregeln (ID, Klasse, Element). Es sollte daher sehr sparsam eingesetzt werden.
|
||||
|
||||
---
|
||||
|
||||
### Q28 – Responsive Design: Desktop First
|
||||
|
||||
**In Q16 nutzten wir `min-width` (Mobile First). Wie würde die Media Query aussehen, wenn wir „Desktop First“ arbeiten würden (also Standard ist Desktop, Anpassung für kleine Screens)?**
|
||||
|
||||
* [ ] `@media (device-width: small) { ... }`
|
||||
* [ ] `@media (min-width: ...)` – das bleibt gleich, nur die Reihenfolge ändert sich.
|
||||
* [x] **`@media (max-width: ...)` – Wir definieren Stile für Bildschirme, die *kleiner* als eine bestimmte Breite sind.** ✅
|
||||
* [ ] `@media (mobile: true) { ... }`
|
||||
|
||||
> **Feedback:** Desktop First bedeutet: Das Basis-CSS ist für große Schirme. Mit `max-width` (maximale Breite) definieren wir Ausnahmen für Geräte, die schmaler sind (Tablets, Handys).
|
||||
@@ -1,5 +1,5 @@
|
||||
{
|
||||
description = "HdM Slides - Marp presentation builder with tools";
|
||||
description = "HdM Slides - Marp presentation builder";
|
||||
|
||||
inputs = {
|
||||
nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
|
||||
@@ -9,114 +9,19 @@
|
||||
outputs = { self, nixpkgs, flake-utils }:
|
||||
flake-utils.lib.eachDefaultSystem (system:
|
||||
let
|
||||
pkgs = nixpkgs.legacyPackages.${system};
|
||||
|
||||
# QR code generator script
|
||||
qr-gen = pkgs.writeShellScriptBin "qr" ''
|
||||
if [ -z "$1" ]; then
|
||||
echo "Usage: qr <url> [output.png]"
|
||||
echo ""
|
||||
echo "Examples:"
|
||||
echo " qr https://example.com"
|
||||
echo " qr https://example.com my-qr.png"
|
||||
echo " qr 'https://librete.ch/hdm/223015b/' slides-qr.png"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
URL="$1"
|
||||
OUTPUT="''${2:-qr-code.png}"
|
||||
|
||||
${pkgs.qrencode}/bin/qrencode -o "$OUTPUT" -s 10 -m 2 "$URL"
|
||||
echo "Generated: $OUTPUT"
|
||||
'';
|
||||
|
||||
# QR code for course slides
|
||||
qr-slides = pkgs.writeShellScriptBin "qr-slides" ''
|
||||
COURSE="''${1:-223015b}"
|
||||
OUTPUT="''${2:-build/$COURSE/qr-$COURSE.png}"
|
||||
|
||||
mkdir -p "$(dirname "$OUTPUT")"
|
||||
${pkgs.qrencode}/bin/qrencode -o "$OUTPUT" -s 10 -m 2 "https://librete.ch/hdm/$COURSE/"
|
||||
echo "Generated QR for $COURSE: $OUTPUT"
|
||||
'';
|
||||
|
||||
# Image optimizer script
|
||||
optimize-img = pkgs.writeShellScriptBin "optimize-img" ''
|
||||
if [ -z "$1" ]; then
|
||||
echo "Usage: optimize-img <image-or-directory> [max-width]"
|
||||
echo ""
|
||||
echo "Resizes images to max width (default: 1920px)"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
TARGET="$1"
|
||||
MAX_WIDTH="''${2:-1920}"
|
||||
|
||||
if [ -d "$TARGET" ]; then
|
||||
for img in "$TARGET"/*.{png,jpg,jpeg,webp} 2>/dev/null; do
|
||||
[ -f "$img" ] || continue
|
||||
echo "Optimizing: $(basename "$img")"
|
||||
${pkgs.imagemagick}/bin/magick "$img" -resize "''${MAX_WIDTH}x>" -quality 85 "$img"
|
||||
done
|
||||
elif [ -f "$TARGET" ]; then
|
||||
echo "Optimizing: $TARGET"
|
||||
${pkgs.imagemagick}/bin/magick "$TARGET" -resize "''${MAX_WIDTH}x>" -quality 85 "$TARGET"
|
||||
else
|
||||
echo "Error: $TARGET not found"
|
||||
exit 1
|
||||
fi
|
||||
echo "Done!"
|
||||
'';
|
||||
|
||||
pkgs = import nixpkgs { inherit system; };
|
||||
in {
|
||||
# Development shell with all tools
|
||||
devShells.default = pkgs.mkShell {
|
||||
buildInputs = with pkgs; [
|
||||
nodejs_20
|
||||
nodejs_22
|
||||
nodePackages.npm
|
||||
qrencode
|
||||
imagemagick
|
||||
gnumake
|
||||
];
|
||||
|
||||
shellHook = ''
|
||||
echo "HdM Slides Development Environment"
|
||||
echo ""
|
||||
echo "Available commands:"
|
||||
echo " make dev-b - Start 223015b dev server (port 1312)"
|
||||
echo " make dev-c - Start 223015c dev server (port 1313)"
|
||||
echo " make build - Build all courses"
|
||||
echo " qr <url> - Generate QR code"
|
||||
echo " qr-slides 223015b - Generate QR for course"
|
||||
echo " optimize-img <dir> - Optimize images"
|
||||
echo ""
|
||||
echo "HdM Slides - run 'make' for available commands"
|
||||
'';
|
||||
};
|
||||
|
||||
# Standalone apps
|
||||
packages = {
|
||||
qr = qr-gen;
|
||||
qr-slides = qr-slides;
|
||||
optimize-img = optimize-img;
|
||||
default = qr-gen;
|
||||
};
|
||||
|
||||
# Direct runnable apps
|
||||
apps = {
|
||||
qr = {
|
||||
type = "app";
|
||||
program = "${qr-gen}/bin/qr";
|
||||
};
|
||||
qr-slides = {
|
||||
type = "app";
|
||||
program = "${qr-slides}/bin/qr-slides";
|
||||
};
|
||||
optimize-img = {
|
||||
type = "app";
|
||||
program = "${optimize-img}/bin/optimize-img";
|
||||
};
|
||||
default = self.apps.${system}.qr;
|
||||
};
|
||||
}
|
||||
);
|
||||
}
|
||||
|
||||
+3
-2
@@ -3,13 +3,14 @@
|
||||
"version": "1.0.0",
|
||||
"description": "HdM Stuttgart - Lecture Slides (Marp)",
|
||||
"scripts": {
|
||||
"dev:b": "PORT=1312 marp --server --allow-local-files courses/223015b/slides/",
|
||||
"dev:c": "PORT=1313 marp --server --allow-local-files courses/223015c/slides/",
|
||||
"dev": "PORT=3000 marp --server --allow-local-files slides/",
|
||||
"build": "make build",
|
||||
"build:b": "make build-b",
|
||||
"build:c": "make build-c",
|
||||
"pdf": "make pdf",
|
||||
"html": "make html",
|
||||
"klausur": "make klausur",
|
||||
"deploy": "make deploy",
|
||||
"test": "echo \"No tests specified\" && exit 0"
|
||||
},
|
||||
"keywords": ["marp", "slides", "hdm", "lectures"],
|
||||
|
||||
+20
-73
@@ -1,106 +1,53 @@
|
||||
#!/usr/bin/env bash
|
||||
# Development server script for HdM slides
|
||||
# Starts index server + marp servers for each course
|
||||
# Simplified development server for HdM slides
|
||||
# Starts single Marp server for all courses
|
||||
|
||||
set -e
|
||||
|
||||
# Configuration
|
||||
INDEX_PORT=1310
|
||||
COURSE_B_PORT=1311
|
||||
COURSE_C_PORT=1312
|
||||
SLIDES_DIR="slides"
|
||||
DEV_INDEX_DIR=".dev-index"
|
||||
DEV_PORT=3000
|
||||
|
||||
# Colors
|
||||
RED='\033[0;31m'
|
||||
GREEN='\033[0;32m'
|
||||
BLUE='\033[0;34m'
|
||||
RED='\033[0;31m'
|
||||
NC='\033[0m' # No Color
|
||||
|
||||
# Cleanup function
|
||||
cleanup() {
|
||||
echo -e "\n${RED}Shutting down servers...${NC}"
|
||||
kill $PID_INDEX $PID_B $PID_C 2>/dev/null || true
|
||||
echo -e "\n${RED}Shutting down dev server...${NC}"
|
||||
pkill -f "marp-cli.*--server" 2>/dev/null || true
|
||||
exit 0
|
||||
}
|
||||
|
||||
# Kill existing processes on our ports
|
||||
# Kill existing processes on our port
|
||||
kill_existing() {
|
||||
echo -e "${BLUE}Cleaning up existing processes...${NC}"
|
||||
# Kill marp processes first
|
||||
pkill -9 -f "marp-cli" 2>/dev/null || true
|
||||
pkill -f "python3 -m http.server" 2>/dev/null || true
|
||||
# Kill ports including marp's WebSocket ports (37717-37720 range)
|
||||
fuser -k $INDEX_PORT/tcp $COURSE_B_PORT/tcp $COURSE_C_PORT/tcp 2>/dev/null || true
|
||||
fuser -k 37717/tcp 37718/tcp 37719/tcp 37720/tcp 2>/dev/null || true
|
||||
sleep 2
|
||||
}
|
||||
|
||||
# Generate dev index
|
||||
generate_index() {
|
||||
mkdir -p "$DEV_INDEX_DIR"
|
||||
cat > "$DEV_INDEX_DIR/index.html" << 'EOF'
|
||||
<!DOCTYPE html>
|
||||
<html lang="de">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width,initial-scale=1">
|
||||
<title>HdM Slides - Dev</title>
|
||||
<style>
|
||||
*{box-sizing:border-box;margin:0;padding:0}
|
||||
body{font-family:-apple-system,BlinkMacSystemFont,"SF Pro Display","Segoe UI",Roboto,sans-serif;max-width:720px;margin:0 auto;padding:3rem 1.5rem;background:#fafafa;color:#1d1d1f;line-height:1.5}
|
||||
h1{font-size:2rem;font-weight:600;letter-spacing:-0.02em;margin-bottom:.5rem}
|
||||
.subtitle{color:#86868b;font-size:1rem}
|
||||
.courses{margin-top:2rem;display:flex;flex-direction:column;gap:.75rem}
|
||||
a.course{display:block;background:#fff;border-radius:12px;padding:1.5rem;text-decoration:none;color:inherit;box-shadow:0 1px 3px rgba(0,0,0,0.08);transition:all .2s ease;cursor:pointer}
|
||||
a.course:hover{transform:translateY(-2px);box-shadow:0 4px 12px rgba(0,0,0,0.12)}
|
||||
.course-label{font-size:.7rem;font-weight:600;text-transform:uppercase;letter-spacing:.05em}
|
||||
.course-b .course-label{color:#1e5f8a}
|
||||
.course-c .course-label{color:#d63384}
|
||||
.course-title{font-size:1.15rem;font-weight:500;color:#1d1d1f;margin:.25rem 0}
|
||||
.course-info{font-size:.85rem;color:#86868b}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<h1>HdM Slides</h1>
|
||||
<p class="subtitle">Development Server</p>
|
||||
<div class="courses">
|
||||
EOF
|
||||
echo " <a class=\"course course-b\" href=\"http://localhost:$COURSE_B_PORT\"><span class=\"course-label\">223015b</span><div class=\"course-title\">Dateiformate, Schnittstellen, Speichermedien & Distributionswege</div><span class=\"course-info\">Port $COURSE_B_PORT</span></a>" >> "$DEV_INDEX_DIR/index.html"
|
||||
echo " <a class=\"course course-c\" href=\"http://localhost:$COURSE_C_PORT\"><span class=\"course-label\">223015c</span><div class=\"course-title\">Grundlagen IT- und Internettechnik</div><span class=\"course-info\">Port $COURSE_C_PORT</span></a>" >> "$DEV_INDEX_DIR/index.html"
|
||||
cat >> "$DEV_INDEX_DIR/index.html" << 'EOF'
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
EOF
|
||||
fuser -k $DEV_PORT/tcp 2>/dev/null || true
|
||||
sleep 1
|
||||
}
|
||||
|
||||
# Main
|
||||
trap cleanup SIGINT SIGTERM
|
||||
|
||||
kill_existing
|
||||
generate_index
|
||||
|
||||
echo -e "${GREEN}Starting development servers...${NC}"
|
||||
echo -e "${GREEN}Starting development server...${NC}"
|
||||
echo ""
|
||||
echo -e " Index: ${BLUE}http://localhost:$INDEX_PORT${NC}"
|
||||
echo -e " 223015b: ${BLUE}http://localhost:$COURSE_B_PORT${NC}"
|
||||
echo -e " 223015c: ${BLUE}http://localhost:$COURSE_C_PORT${NC}"
|
||||
echo -e " Server: ${BLUE}http://localhost:$DEV_PORT${NC}"
|
||||
echo -e " Slides: ${BLUE}$SLIDES_DIR/${NC}"
|
||||
echo ""
|
||||
echo -e "Press ${RED}Ctrl+C${NC} to stop all servers"
|
||||
echo -e "Available courses:"
|
||||
echo -e " 223015b: ${BLUE}http://localhost:$DEV_PORT/223015b/${NC}"
|
||||
echo -e " 223015c: ${BLUE}http://localhost:$DEV_PORT/223015c/${NC}"
|
||||
echo ""
|
||||
echo -e "Press ${RED}Ctrl+C${NC} to stop the server"
|
||||
echo ""
|
||||
|
||||
# Start servers
|
||||
python3 -m http.server $INDEX_PORT --directory "$DEV_INDEX_DIR" &
|
||||
PID_INDEX=$!
|
||||
# Start single Marp server for all slides
|
||||
PORT=$DEV_PORT npx @marp-team/marp-cli --server "$SLIDES_DIR/"
|
||||
|
||||
PORT=$COURSE_B_PORT npx @marp-team/marp-cli --server "$SLIDES_DIR/223015b/" &
|
||||
PID_B=$!
|
||||
|
||||
sleep 3 # Stagger starts to avoid WebSocket port collision
|
||||
|
||||
PORT=$COURSE_C_PORT npx @marp-team/marp-cli --server "$SLIDES_DIR/223015c/" &
|
||||
PID_C=$!
|
||||
|
||||
# Wait for any process to exit
|
||||
# Wait for process to exit
|
||||
wait
|
||||
@@ -1,19 +1,19 @@
|
||||
#!/usr/bin/env bash
|
||||
# Extract klausur-relevant slides from all kapitel
|
||||
# Usage: ./extract-klausur.sh <course_id>
|
||||
# Output: slides/<course>/klausur.md
|
||||
# Output: slides/<course>/klausurfolien.md
|
||||
|
||||
set -e
|
||||
|
||||
COURSE="${1:-223015b}"
|
||||
SLIDES_DIR="slides/$COURSE"
|
||||
OUTPUT_FILE="$SLIDES_DIR/klausur.md"
|
||||
OUTPUT_FILE="$SLIDES_DIR/klausurfolien.md"
|
||||
|
||||
# Find the first kapitel file (01-*.md) to copy styles from
|
||||
FIRST_KAPITEL=$(ls "$SLIDES_DIR"/01-*.md 2>/dev/null | head -1)
|
||||
# Find the first kapitel file (00-intro.md or 01-*.md) to copy styles from
|
||||
FIRST_KAPITEL=$(ls "$SLIDES_DIR"/00-intro.md "$SLIDES_DIR"/01-*.md 2>/dev/null | head -1)
|
||||
|
||||
if [[ -z "$FIRST_KAPITEL" ]]; then
|
||||
echo "Error: No 01-*.md file found in $SLIDES_DIR"
|
||||
echo "Error: No 00-intro.md or 01-*.md file found in $SLIDES_DIR"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
@@ -57,7 +57,7 @@ awk '
|
||||
' "$FIRST_KAPITEL" >> "$OUTPUT_FILE"
|
||||
|
||||
# Process each kapitel file in order - extract klausur slides only
|
||||
for md_file in $(ls "$SLIDES_DIR"/[0-9][0-9]-*.md 2>/dev/null | grep -v klausur | sort); do
|
||||
for md_file in $(ls "$SLIDES_DIR"/[0-9][0-9]-*.md 2>/dev/null | grep -v klausurfolien | sort); do
|
||||
filename=$(basename "$md_file")
|
||||
kapitel_num=$(echo "$filename" | grep -oE '^[0-9]+' | sed 's/^0*//')
|
||||
|
||||
|
||||
+118
-21
@@ -41,6 +41,16 @@ TOPIC_MAP["vertiefung-offene-fragen"]="Vertiefung & Offene Fragen"
|
||||
TOPIC_MAP["geschichte-grundlagen-html"]="Geschichte, Grundlagen & HTML"
|
||||
TOPIC_MAP["netzwerke-protokolle-css"]="Netzwerke, Protokolle & CSS"
|
||||
TOPIC_MAP["interaktivitaet-javascript"]="Interaktivität & JavaScript"
|
||||
TOPIC_MAP["klausurfragen"]="Klausurfragen"
|
||||
|
||||
# Configure which topics should appear disabled per course
|
||||
# Two modes: fully disabled (non-clickable card) and buttons-disabled (link remains clickable, buttons are disabled)
|
||||
declare -A DISABLED_FULL
|
||||
declare -A DISABLED_BUTTONS
|
||||
# For course B: chapters 3,4,5 should be fully disabled
|
||||
DISABLED_FULL["223015b"]="speichermedien-schnittstellen distribution-apis-zukunft vertiefung-offene-fragen"
|
||||
# For course C: chapter 3 should keep link clickable but buttons disabled
|
||||
DISABLED_BUTTONS["223015c"]="interaktivitaet-javascript"
|
||||
|
||||
cat > "$BUILD_DIR/index.html" << HEADER
|
||||
<!DOCTYPE html>
|
||||
@@ -61,6 +71,15 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
||||
line-height: 1.5;
|
||||
}
|
||||
header { margin-bottom: 2rem; }
|
||||
.breadcrumb {
|
||||
margin-bottom: 1rem;
|
||||
font-size: 0.85rem;
|
||||
}
|
||||
.breadcrumb a {
|
||||
color: #86868b;
|
||||
text-decoration: none;
|
||||
}
|
||||
.breadcrumb a:hover { text-decoration: underline; }
|
||||
h1 {
|
||||
font-size: 1.75rem;
|
||||
font-weight: 600;
|
||||
@@ -68,6 +87,12 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
||||
margin-bottom: 0.5rem;
|
||||
color: $ACCENT_COLOR;
|
||||
}
|
||||
.course-heading {
|
||||
font-size: 1.25rem;
|
||||
font-weight: 500;
|
||||
color: #1d1d1f;
|
||||
margin-bottom: 0.25rem;
|
||||
}
|
||||
.subtitle {
|
||||
color: #86868b;
|
||||
font-size: 0.95rem;
|
||||
@@ -77,7 +102,8 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
||||
font-size: 0.875rem;
|
||||
margin-top: 0.25rem;
|
||||
}
|
||||
.kapitel {
|
||||
/* Use the .termine wrapper and add a gap between cards */
|
||||
.termine {
|
||||
margin-top: 1.5rem;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
@@ -93,6 +119,7 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
||||
grid-template-columns: 1fr auto auto;
|
||||
align-items: center;
|
||||
gap: 1rem;
|
||||
padding: 0; /* inner padding handled by kapitel-link */
|
||||
}
|
||||
.kapitel-card:hover {
|
||||
transform: translateY(-2px);
|
||||
@@ -105,6 +132,8 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
||||
color: inherit;
|
||||
grid-column: 1;
|
||||
}
|
||||
/* Disabled look: dim the entire card and prevent pointer events */
|
||||
.kapitel-card.disabled { opacity: 0.6; pointer-events: none; }
|
||||
.kapitel-label {
|
||||
font-size: 0.7rem;
|
||||
font-weight: 600;
|
||||
@@ -135,11 +164,11 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
||||
white-space: nowrap;
|
||||
position: relative;
|
||||
z-index: 1;
|
||||
margin-right: 0.5rem;
|
||||
}
|
||||
.btn-slides {
|
||||
background: $ACCENT_COLOR;
|
||||
color: #fff;
|
||||
margin-right: 0.5rem;
|
||||
}
|
||||
.btn-slides:hover {
|
||||
filter: brightness(1.1);
|
||||
@@ -147,9 +176,9 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
||||
.btn-pdf {
|
||||
background: #f5f5f7;
|
||||
color: #1d1d1f;
|
||||
margin-right: 1rem;
|
||||
}
|
||||
.btn-pdf:hover { background: #e8e8ed; }
|
||||
.btn-disabled { opacity: 0.6; pointer-events: none; }
|
||||
/* Make entire card clickable via overlay */
|
||||
.kapitel-link::after {
|
||||
content: '';
|
||||
@@ -198,9 +227,11 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
||||
</head>
|
||||
<body>
|
||||
<header>
|
||||
<h1>$TITLE</h1>
|
||||
<p class="breadcrumb"><a href="../">← Kursübersicht</a></p>
|
||||
<h1>HdM Vorlesungen</h1>
|
||||
<h2 class="course-heading">$TITLE</h2>
|
||||
<p class="subtitle">$SUBTITLE</p>
|
||||
<p class="meta">HdM Stuttgart · Wintersemester 2025/26 · Michael Czechowski</p>
|
||||
<p class="meta">HdM Stuttgart · Sommersemester 2026 · Michael Czechowski</p>
|
||||
</header>
|
||||
<div class="termine">
|
||||
HEADER
|
||||
@@ -216,7 +247,7 @@ for html in $(ls "$BUILD_DIR"/[0-9][0-9]-*.html 2>/dev/null | sort); do
|
||||
# Look up nice topic name or fallback
|
||||
topic="${TOPIC_MAP[$topic_raw]}"
|
||||
if [[ -z "$topic" ]]; then
|
||||
topic=$(echo "$topic_raw" | sed 's/-/ /g' | sed 's/.*/\u&/')
|
||||
topic=$(echo "$topic_raw" | sed 's/-/ /g' | sed 's/.*/\\u&/')
|
||||
fi
|
||||
|
||||
# Handle kapitel number
|
||||
@@ -228,42 +259,108 @@ for html in $(ls "$BUILD_DIR"/[0-9][0-9]-*.html 2>/dev/null | sort); do
|
||||
|
||||
pdf_filename="${filename%.html}.pdf"
|
||||
|
||||
# Check if PDF exists
|
||||
# Determine whether this topic is configured as disabled for this course
|
||||
disabled_full=false
|
||||
disabled_buttons=false
|
||||
for t in ${DISABLED_FULL["$COURSE"]}; do
|
||||
if [[ "$topic_raw" == "$t" ]]; then
|
||||
disabled_full=true
|
||||
break
|
||||
fi
|
||||
done
|
||||
if [[ "$disabled_full" == false ]]; then
|
||||
for t in ${DISABLED_BUTTONS["$COURSE"]}; do
|
||||
if [[ "$topic_raw" == "$t" ]]; then
|
||||
disabled_buttons=true
|
||||
break
|
||||
fi
|
||||
done
|
||||
fi
|
||||
|
||||
# Decide card class
|
||||
card_class="kapitel-card"
|
||||
if [[ "$disabled_full" == true ]] || [[ "$disabled_buttons" == true ]]; then
|
||||
card_class="$card_class disabled"
|
||||
fi
|
||||
|
||||
# Build link/button HTML depending on disabled state
|
||||
if [[ "$disabled_full" == true ]]; then
|
||||
# non-interactive card (visually dimmed and not clickable)
|
||||
link_html="<div class=\"kapitel-link\"><div class=\"kapitel-label\">$kapitel_label</div><div class=\"kapitel-title\">$topic</div></div>"
|
||||
slides_html="<span class=\"btn btn-slides btn-disabled\">Folien</span>"
|
||||
pdf_html=""
|
||||
if [[ -f "$BUILD_DIR/$pdf_filename" ]]; then
|
||||
pdf_html="<span class=\"btn btn-pdf btn-disabled\">PDF</span>"
|
||||
fi
|
||||
elif [[ "$disabled_buttons" == true ]]; then
|
||||
# link stays clickable, but buttons are disabled; card appears dimmed
|
||||
link_html="<a href=\"$filename\" class=\"kapitel-link\"><div class=\"kapitel-label\">$kapitel_label</div><div class=\"kapitel-title\">$topic</div></a>"
|
||||
slides_html="<span class=\"btn btn-slides btn-disabled\">Folien</span>"
|
||||
pdf_html=""
|
||||
if [[ -f "$BUILD_DIR/$pdf_filename" ]]; then
|
||||
pdf_html="<span class=\"btn btn-pdf btn-disabled\">PDF</span>"
|
||||
fi
|
||||
else
|
||||
# normal interactive card
|
||||
pdf_link=""
|
||||
if [[ -f "$BUILD_DIR/$pdf_filename" ]]; then
|
||||
pdf_link="<a href=\"$pdf_filename\" class=\"btn btn-pdf\">PDF</a>"
|
||||
fi
|
||||
link_html="<a href=\"$filename\" class=\"kapitel-link\"><div class=\"kapitel-label\">$kapitel_label</div><div class=\"kapitel-title\">$topic</div></a>"
|
||||
slides_html="<a href=\"$filename\" class=\"btn btn-slides\">Folien</a>"
|
||||
pdf_html="$pdf_link"
|
||||
fi
|
||||
|
||||
cat >> "$BUILD_DIR/index.html" << LINK
|
||||
<div class="kapitel-card">
|
||||
<a href="$filename" class="kapitel-link">
|
||||
<div class="kapitel-label">$kapitel_label</div>
|
||||
<div class="kapitel-title">$topic</div>
|
||||
</a>
|
||||
<a href="$filename" class="btn btn-slides">Folien</a>
|
||||
$pdf_link
|
||||
<div class="$card_class">
|
||||
$link_html
|
||||
$slides_html
|
||||
$pdf_html
|
||||
</div>
|
||||
LINK
|
||||
|
||||
done
|
||||
|
||||
# Add klausur entry if it exists
|
||||
if [[ -f "$BUILD_DIR/klausur.html" ]]; then
|
||||
# Add klausurfolien entry if it exists
|
||||
if [[ -f "$BUILD_DIR/klausurfolien.html" ]]; then
|
||||
pdf_link=""
|
||||
if [[ -f "$BUILD_DIR/klausur.pdf" ]]; then
|
||||
pdf_link="<a href=\"klausur.pdf\" class=\"btn btn-pdf\">PDF</a>"
|
||||
if [[ -f "$BUILD_DIR/klausurfolien.pdf" ]]; then
|
||||
pdf_link="<a href=\"klausurfolien.pdf\" class=\"btn btn-pdf\">PDF</a>"
|
||||
fi
|
||||
cat >> "$BUILD_DIR/index.html" << KLAUSUR
|
||||
<div class="kapitel-card" style="border-left: 3px solid $ACCENT_COLOR;">
|
||||
<a href="klausur.html" class="kapitel-link">
|
||||
<a href="klausurfolien.html" class="kapitel-link">
|
||||
<div class="kapitel-label">Prüfung</div>
|
||||
<div class="kapitel-title">Klausurrelevante Folien</div>
|
||||
</a>
|
||||
<a href="klausur.html" class="btn btn-slides">Folien</a>
|
||||
<a href="klausurfolien.html" class="btn btn-slides">Folien</a>
|
||||
$pdf_link
|
||||
</div>
|
||||
KLAUSUR
|
||||
fi
|
||||
|
||||
# Add klausurfragen entry if it exists (HTML and/or PDF)
|
||||
if [[ -f "$BUILD_DIR/klausurfragen.html" ]] || [[ -f "$BUILD_DIR/klausurfragen.pdf" ]]; then
|
||||
pdf_link=""
|
||||
if [[ -f "$BUILD_DIR/klausurfragen.pdf" ]]; then
|
||||
pdf_link="<a href=\"klausurfragen.pdf\" class=\"btn btn-pdf\">PDF</a>"
|
||||
fi
|
||||
slides_link=""
|
||||
if [[ -f "$BUILD_DIR/klausurfragen.html" ]]; then
|
||||
slides_link="<a href=\"klausurfragen.html\" class=\"btn btn-slides\">Folien</a>"
|
||||
fi
|
||||
cat >> "$BUILD_DIR/index.html" << KLAUSURFRAGEN
|
||||
<div class="kapitel-card" style="border-left: 3px solid $ACCENT_COLOR;">
|
||||
<a href="klausurfragen.html" class="kapitel-link">
|
||||
<div class="kapitel-label">Prüfung</div>
|
||||
<div class="kapitel-title">Klausurfragen</div>
|
||||
</a>
|
||||
$slides_link
|
||||
$pdf_link
|
||||
</div>
|
||||
KLAUSURFRAGEN
|
||||
fi
|
||||
|
||||
cat >> "$BUILD_DIR/index.html" << FOOTER
|
||||
</div>
|
||||
<div class="qr-section">
|
||||
@@ -272,7 +369,7 @@ cat >> "$BUILD_DIR/index.html" << FOOTER
|
||||
</div>
|
||||
<footer>
|
||||
<a href="mailto:mail@librete.ch">Kontakt</a> ·
|
||||
<a href="../">Alle Kurse</a>
|
||||
<a href="../">Kursübersicht</a>
|
||||
</footer>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
Executable
+187
@@ -0,0 +1,187 @@
|
||||
#!/usr/bin/env bash
|
||||
# Generate root index.html for /hdm/
|
||||
# Lists all courses (klausurfragen are now per-course)
|
||||
|
||||
BUILD_DIR="build"
|
||||
|
||||
cat > "$BUILD_DIR/index.html" << 'HEADER'
|
||||
<!DOCTYPE html>
|
||||
<html lang="de">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>HdM Vorlesungen</title>
|
||||
<style>
|
||||
* { box-sizing: border-box; margin: 0; padding: 0; }
|
||||
body {
|
||||
font-family: -apple-system, BlinkMacSystemFont, "SF Pro Display", "Segoe UI", Roboto, sans-serif;
|
||||
max-width: 720px;
|
||||
margin: 0 auto;
|
||||
padding: 3rem 1.5rem;
|
||||
background: #fafafa;
|
||||
color: #1d1d1f;
|
||||
line-height: 1.5;
|
||||
}
|
||||
h1 {
|
||||
font-size: 2rem;
|
||||
font-weight: 600;
|
||||
letter-spacing: -0.02em;
|
||||
margin-bottom: 0.5rem;
|
||||
}
|
||||
.subtitle { color: #86868b; font-size: 1rem; }
|
||||
.courses {
|
||||
margin-top: 2rem;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 0.75rem;
|
||||
}
|
||||
.course-card {
|
||||
position: relative;
|
||||
background: #fff;
|
||||
border-radius: 12px;
|
||||
box-shadow: 0 1px 3px rgba(0,0,0,0.08);
|
||||
transition: all 0.2s ease;
|
||||
display: grid;
|
||||
grid-template-columns: 1fr auto auto;
|
||||
align-items: center;
|
||||
gap: 1rem;
|
||||
}
|
||||
.course-card:hover {
|
||||
transform: translateY(-2px);
|
||||
box-shadow: 0 4px 12px rgba(0,0,0,0.12);
|
||||
}
|
||||
.course-link {
|
||||
display: block;
|
||||
padding: 1.25rem 1.5rem;
|
||||
text-decoration: none;
|
||||
color: inherit;
|
||||
grid-column: 1;
|
||||
}
|
||||
.course-link::after {
|
||||
content: '';
|
||||
position: absolute;
|
||||
inset: 0;
|
||||
border-radius: 12px;
|
||||
}
|
||||
.course-label {
|
||||
font-size: 0.7rem;
|
||||
font-weight: 600;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.05em;
|
||||
}
|
||||
.course-b .course-label { color: #1e5f8a; }
|
||||
.course-c .course-label { color: #d63384; }
|
||||
.course-title {
|
||||
font-size: 1.15rem;
|
||||
font-weight: 500;
|
||||
color: #1d1d1f;
|
||||
margin: 0.25rem 0;
|
||||
}
|
||||
.course-info { font-size: 0.85rem; color: #86868b; }
|
||||
.btn {
|
||||
display: inline-flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
padding: 0.5rem 1rem;
|
||||
border-radius: 8px;
|
||||
text-decoration: none;
|
||||
font-size: 0.8rem;
|
||||
font-weight: 500;
|
||||
transition: all 0.2s;
|
||||
white-space: nowrap;
|
||||
position: relative;
|
||||
z-index: 1;
|
||||
margin-right: 0.5rem;
|
||||
}
|
||||
.btn-slides {
|
||||
background: #6c757d;
|
||||
color: #fff;
|
||||
}
|
||||
.btn-slides:hover { filter: brightness(1.1); }
|
||||
.btn-pdf {
|
||||
background: #f5f5f7;
|
||||
color: #1d1d1f;
|
||||
}
|
||||
.btn-pdf:hover { background: #e8e8ed; }
|
||||
.section-title {
|
||||
font-size: 1rem;
|
||||
font-weight: 600;
|
||||
color: #86868b;
|
||||
margin-top: 2.5rem;
|
||||
margin-bottom: 0.75rem;
|
||||
}
|
||||
.references {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 0.75rem;
|
||||
}
|
||||
footer {
|
||||
margin-top: 2.5rem;
|
||||
padding-top: 1.5rem;
|
||||
border-top: 1px solid #e5e5e7;
|
||||
color: #86868b;
|
||||
font-size: 0.85rem;
|
||||
}
|
||||
footer a { color: #1d1d1f; text-decoration: none; }
|
||||
footer a:hover { text-decoration: underline; }
|
||||
.qr-section {
|
||||
margin-top: 2.5rem;
|
||||
padding: 1.5rem;
|
||||
background: #fff;
|
||||
border-radius: 12px;
|
||||
box-shadow: 0 1px 3px rgba(0,0,0,0.08);
|
||||
text-align: center;
|
||||
}
|
||||
.qr-code { width: 100%; height: auto; }
|
||||
.qr-url { margin-top: 0.75rem; font-size: 0.85rem; color: #86868b; }
|
||||
@media (max-width: 600px) {
|
||||
.course-card { grid-template-columns: 1fr; }
|
||||
.course-link { padding-bottom: 0.75rem; }
|
||||
.btn { margin: 0 1rem 1rem 1.5rem; }
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<h1>HdM Vorlesungen</h1>
|
||||
<p class="subtitle">Sommersemester 2026 · Michael Czechowski</p>
|
||||
<div class="courses">
|
||||
<div class="course-card course-b">
|
||||
<a href="223015b/" class="course-link">
|
||||
<span class="course-label">223015b</span>
|
||||
<div class="course-title">Dateiformate, Schnittstellen, Speichermedien & Distributionswege</div>
|
||||
<span class="course-info">6 Kapitel · Modul "Technik 1"</span>
|
||||
</a>
|
||||
</div>
|
||||
<div class="course-card course-c">
|
||||
<a href="223015c/" class="course-link">
|
||||
<span class="course-label">223015c</span>
|
||||
<div class="course-title">Grundlagen IT- und Internettechnik</div>
|
||||
<span class="course-info">3 Kapitel · Modul "Technik 1"</span>
|
||||
</a>
|
||||
</div>
|
||||
HEADER
|
||||
|
||||
cat >> "$BUILD_DIR/index.html" << 'FOOTER'
|
||||
</div>
|
||||
<h2 class="section-title">Referenzen</h2>
|
||||
<div class="references">
|
||||
<div class="course-card">
|
||||
<a href="https://codecrispi.es/" class="course-link">
|
||||
<span class="course-label">Plattform</span>
|
||||
<div class="course-title">Code Crispies</div>
|
||||
<span class="course-info">Selbstlernplattform</span>
|
||||
</a>
|
||||
</div>
|
||||
</div>
|
||||
<div class="qr-section">
|
||||
<img src="qr-root.svg" alt="QR Code" class="qr-code">
|
||||
<p class="qr-url">https://librete.ch/hdm/</p>
|
||||
</div>
|
||||
<footer>
|
||||
<a href="mailto:mail@librete.ch">Kontakt</a>
|
||||
</footer>
|
||||
</body>
|
||||
</html>
|
||||
FOOTER
|
||||
|
||||
echo "Generated $BUILD_DIR/index.html"
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
|
||||
@@ -82,7 +82,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
|
||||
@@ -68,6 +68,38 @@ section.aufgabe {
|
||||
section.aufgabe footer {
|
||||
display: none;
|
||||
}
|
||||
section.erklaerung {
|
||||
font-size: 1.1rem;
|
||||
background: repeating-linear-gradient(
|
||||
135deg,
|
||||
#e3f2fd,
|
||||
#e3f2fd 40px,
|
||||
#fff 40px,
|
||||
#fff 80px
|
||||
) !important;
|
||||
}
|
||||
@media print {
|
||||
section.erklaerung {
|
||||
background: #e3f2fd !important;
|
||||
}
|
||||
}
|
||||
section.erklaerung h1 {
|
||||
font-size: 1.5rem;
|
||||
color: #1e5f8a;
|
||||
margin-bottom: 0.3rem;
|
||||
}
|
||||
section.erklaerung ul,
|
||||
section.erklaerung ol {
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung p {
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung table {
|
||||
font-size: 0.9rem;
|
||||
}
|
||||
</style>
|
||||
|
||||
<!-- _class: invert -->
|
||||
@@ -270,6 +302,30 @@ KLAUSURRELEVANT:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Kompression – Vertiefung
|
||||
|
||||
Claude Shannon definierte 1948 die **Entropie** als theoretische Untergrenze der Kompression. Ein Text mit gleichmäßiger Zeichenverteilung hat hohe Entropie (schwer komprimierbar); repetitive Texte haben niedrige Entropie.
|
||||
|
||||
**Verlustfreie Kompression** erreicht diese Grenze durch:
|
||||
- **Statistische Kodierung:** Huffman, Arithmetic Coding
|
||||
- **Wörterbuch-Methoden:** LZ77, LZ78, DEFLATE (ZIP, PNG)
|
||||
- Originalzustand ist exakt rekonstruierbar
|
||||
|
||||
**Verlustbehaftete Kompression** unterschreitet die Grenze, indem sie menschliche Wahrnehmungsgrenzen ausnutzt:
|
||||
|
||||
| Sinneskanal | Psychophysisches Modell | Ausnutzung |
|
||||
|-------------|------------------------|------------|
|
||||
| Gehör | Maskierungseffekte, Hörschwelle | MP3: Töne unter Maskierungsschwelle weglassen |
|
||||
| Sehen | Farbauflösung, Kontrastempfindlichkeit | JPEG: Chroma-Subsampling, hohe Frequenzen verwerfen |
|
||||
|
||||
**Shannon-Limit:** Verlustfreie Kompression kann nicht unter die Entropie; verlustbehaftete kann beliebig weit gehen – auf Kosten der Qualität.
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
@@ -837,6 +893,29 @@ Eselsbrücke: "Kilo Mega Giga Tera Peta Exa Zetta Yotta"
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Dateneinheiten – Vertiefung
|
||||
|
||||
Zwei konkurrierende Standards existieren seit der IEC-Normierung 1998:
|
||||
|
||||
| Präfix | SI (Dezimal) | IEC (Binär) | Differenz |
|
||||
|--------|--------------|-------------|-----------|
|
||||
| Kilo | 1.000 (10³) | 1.024 (2¹⁰) KiB | 2,4% |
|
||||
| Mega | 1.000.000 (10⁶) | 1.048.576 MiB | 4,9% |
|
||||
| Giga | 10⁹ | 2³⁰ GiB | 7,4% |
|
||||
| Tera | 10¹² | 2⁴⁰ TiB | 10% |
|
||||
|
||||
**Warum der Unterschied wächst:** (2¹⁰)ⁿ ÷ (10³)ⁿ = 1,024ⁿ. Bei Terabyte sind es bereits 10% Abweichung.
|
||||
|
||||
**Festplatten-Marketing:** Hersteller nutzen SI (dezimal), Betriebssysteme zeigen IEC (binär). Eine „1 TB"-Festplatte zeigt daher nur 931 GiB an – technisch korrekt, aber verwirrend.
|
||||
|
||||
**Historischer Kontext:** RAM wurde immer binär gemessen (2ⁿ Adressen), Festplatten ursprünglich dezimal (physikalische Geometrie). Die IEC führte 1998 KiB/MiB/GiB ein – diese Notation setzt sich langsam durch.
|
||||
|
||||
---
|
||||
|
||||
# Datenwachstum der Menschheit
|
||||
|
||||
| Jahr | Datenmenge | Kontext |
|
||||
@@ -903,6 +982,32 @@ VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Digitaler Wendepunkt – Vertiefung
|
||||
|
||||
Die Studie von Hilbert & López (Science, 2011) analysierte 60 Speichertechnologien von 1986–2007. Der Wendepunkt 2002 markiert den Moment, ab dem mehr Information digital als analog existierte.
|
||||
|
||||
**Was 1986 „analog" bedeutete:**
|
||||
- Bücher, Zeitungen, Magazine: ~8 EB
|
||||
- Vinyl-Schallplatten, Musikkassetten: ~12 EB
|
||||
- VHS-Kassetten, Filmrollen: ~60 EB
|
||||
|
||||
**Warum analog stagnierte:** Physische Medien haben Kapazitätsgrenzen. Eine VHS speichert 10 GB; eine Blu-ray (2006) bereits 50 GB auf kleinerer Fläche.
|
||||
|
||||
**LTO-Magnetband überlebt** trotz „alter" Technologie:
|
||||
| Medium | Kosten/TB | Lebensdauer | Energiebedarf |
|
||||
|--------|-----------|-------------|---------------|
|
||||
| SSD | ~50 € | 5–10 Jahre | Dauerstrom |
|
||||
| HDD | ~15 € | 3–5 Jahre aktiv | Dauerstrom |
|
||||
| LTO-9 | ~5 € | 30+ Jahre | Nur beim Zugriff |
|
||||
|
||||
AWS Glacier, Google Coldline und Film-Archive nutzen LTO – langsamer Zugriff, aber unschlagbar günstig und langlebig.
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
@@ -1004,6 +1109,29 @@ Visueller Kontrast: Analog vs. Digital
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Analoge Medien – Vertiefung
|
||||
|
||||
Analoge Speicherung codiert Information als **kontinuierliche physikalische Größe**: Rillentiefe (Vinyl), Magnetfeldstärke (Tonband), Silberkorn-Dichte (Film). Es gibt keine diskreten Stufen – theoretisch unendliche Auflösung, praktisch begrenzt durch Rauschen.
|
||||
|
||||
**Generationsverlust** entsteht, weil jede Kopie neues Rauschen addiert:
|
||||
- Schallplatte → Kassette: Frequenzgang leidet, Rauschen steigt
|
||||
- VHS → VHS: Farbsättigung sinkt, Schärfe nimmt ab
|
||||
- 3. Generation: oft unbrauchbar
|
||||
|
||||
| Medium | Typische Auflösung | Dynamik |
|
||||
|--------|-------------------|---------|
|
||||
| Vinyl (audiophil) | ~20–20.000 Hz | ~70 dB |
|
||||
| Tonband (Studio) | ~30–15.000 Hz | ~55 dB |
|
||||
| 35mm Film | ~4K-äquivalent | ~13 Blendenstufen |
|
||||
|
||||
**Paradox der Analogtechnik:** Das Original ist einzigartig und unersetzlich – aber genau deshalb anfällig. Jedes Abspielen einer Schallplatte trägt mikroskopisch Material ab; jeder Filmdurchlauf riskiert Kratzer.
|
||||
|
||||
---
|
||||
|
||||
# Analoge Medien: Vor- und Nachteile
|
||||
|
||||
| Vorteile | Nachteile |
|
||||
@@ -1071,6 +1199,30 @@ Paradox: Gerade die Perfektion wurde zum "Problem"
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Digitale Medien – Vertiefung
|
||||
|
||||
Digitale Speicherung quantisiert kontinuierliche Signale in diskrete Werte. Der **Quantisierungsfehler** (Differenz zum Original) ist der Preis der Digitalisierung – aber einmal digitalisiert, bleibt die Information exakt.
|
||||
|
||||
**Bit-identische Kopien** revolutionierten die Medienindustrie:
|
||||
- Keine Qualitätskette mehr: 1000. Kopie = 1. Kopie = Original
|
||||
- Kosten pro Kopie: praktisch null (nur Speicherplatz)
|
||||
- Perfekte Archivierung: Bits altern nicht (nur der Datenträger)
|
||||
|
||||
| Aspekt | Analog | Digital |
|
||||
|--------|--------|---------|
|
||||
| Kopiervorgang | Physikalischer Prozess | Bit-Kopie |
|
||||
| Qualität pro Generation | Verschlechtert | Identisch |
|
||||
| Fehlerkorrektur | Unmöglich | Möglich (ECC, RAID) |
|
||||
| Formatmigration | Verlust | Verlustfrei möglich |
|
||||
|
||||
**Die Kehrseite:** Digitale Obsoleszenz. Ein DOCX von 2025 ist in 50 Jahren womöglich unlesbar – während ein Buch von 1525 heute noch lesbar ist. Offene Formate (PDF/A, FLAC, PNG) mildern dieses Risiko.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
@@ -1089,6 +1241,31 @@ Paradox: Gerade die Perfektion wurde zum "Problem"
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Digitale Speichermedien – Vertiefung
|
||||
|
||||
Jede Technologie hat physikalische Vor- und Nachteile:
|
||||
|
||||
**Optisch (CD/DVD/Blu-ray):** Laser liest Pits (Vertiefungen) und Lands (Erhöhungen). Robust gegen Magnetfelder, aber empfindlich gegenüber Kratzern und UV-Licht. M-DISC verspricht 1000 Jahre – unter Laborbedingungen.
|
||||
|
||||
**Magnetisch (HDD/LTO):** Magnetisierte Bereiche auf rotierenden Platten oder Band. HDDs haben bewegliche Teile (Verschleiß); LTO-Bänder sind passiv und extrem langlebig, aber sequentieller Zugriff.
|
||||
|
||||
**Flash (SSD/USB/SD):** Elektronen in Floating Gates speichern Bits. Keine beweglichen Teile, aber begrenzte Schreibzyklen (TLC: ~3.000, SLC: ~100.000). Ohne Strom verlieren Zellen nach Jahren ihre Ladung.
|
||||
|
||||
| Szenario | Empfehlung | Grund |
|
||||
|----------|------------|-------|
|
||||
| Betriebssystem | NVMe SSD | Geschwindigkeit |
|
||||
| Videoarchiv | HDD | Kapazität/Preis |
|
||||
| Langzeitarchiv | LTO + M-DISC | Lebensdauer |
|
||||
| Austausch | USB/SD | Portabilität |
|
||||
|
||||
**Cloud** ist physisch HDD/SSD/LTO in Rechenzentren – kein eigenes Medium, sondern Zugriffsmethode.
|
||||
|
||||
---
|
||||
|
||||
# Das Speicherproblem der Digitalisierung
|
||||
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
|
||||
@@ -68,6 +68,38 @@ section.aufgabe {
|
||||
section.aufgabe footer {
|
||||
display: none;
|
||||
}
|
||||
section.erklaerung {
|
||||
font-size: 1.1rem;
|
||||
background: repeating-linear-gradient(
|
||||
135deg,
|
||||
#e3f2fd,
|
||||
#e3f2fd 40px,
|
||||
#fff 40px,
|
||||
#fff 80px
|
||||
) !important;
|
||||
}
|
||||
@media print {
|
||||
section.erklaerung {
|
||||
background: #e3f2fd !important;
|
||||
}
|
||||
}
|
||||
section.erklaerung h1 {
|
||||
font-size: 1.5rem;
|
||||
color: #1e5f8a;
|
||||
margin-bottom: 0.3rem;
|
||||
}
|
||||
section.erklaerung ul,
|
||||
section.erklaerung ol {
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung p {
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung table {
|
||||
font-size: 0.9rem;
|
||||
}
|
||||
</style>
|
||||
|
||||
<!-- _class: invert -->
|
||||
@@ -220,6 +252,26 @@ KLAUSURRELEVANT:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Rastergrafik – Vertiefung
|
||||
|
||||
Ein Pixel ist die kleinste adressierbare Einheit. Bei 24-Bit-Farbtiefe speichert jeder Pixel drei 8-Bit-Werte (0–255) für Rot, Grün und Blau. Diese additive Farbmischung erzeugt 256³ = 16,7 Millionen mögliche Farbtöne.
|
||||
|
||||
**Speicherberechnung:** `Breite × Höhe × Bytes pro Pixel`
|
||||
|
||||
| Auflösung | Farbtiefe | Berechnung | Größe |
|
||||
|-----------|-----------|------------|-------|
|
||||
| 1920×1080 | 24 Bit (3 B) | 2.073.600 × 3 | 6,2 MB |
|
||||
| 4K (3840×2160) | 24 Bit | 8.294.400 × 3 | 24,9 MB |
|
||||
| 4K | 32 Bit (4 B) | 8.294.400 × 4 | 33,2 MB |
|
||||
|
||||
Der Alpha-Kanal (32 Bit) speichert Transparenz als Wert von 0 (unsichtbar) bis 255 (vollständig sichtbar). PNG nutzt dies für weiche Kanten; JPEG unterstützt keinen Alpha-Kanal.
|
||||
|
||||
---
|
||||
|
||||
# Das Problem der Skalierung
|
||||
|
||||
**Vergrößern:**
|
||||
@@ -274,6 +326,30 @@ KLAUSURRELEVANT:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Vektorgrafik – Vertiefung
|
||||
|
||||
Vektorgrafiken speichern keine Pixel, sondern mathematische Beschreibungen: Koordinaten, Kurvenparameter (Bézier-Kontrollpunkte), Füllfarben, Strichstärken. Der Renderer berechnet die Pixel erst bei der Ausgabe – daher beliebig skalierbar.
|
||||
|
||||
**Bézier-Kurven** (Pierre Bézier, 1962, für Renault-Karosserien entwickelt):
|
||||
- Definiert durch Ankerpunkte und Kontrollpunkte
|
||||
- Kubische Bézier: 2 Anker + 2 Kontrollpunkte
|
||||
- Mathematisch exakt reproduzierbar
|
||||
|
||||
| Aspekt | Raster | Vektor |
|
||||
|--------|--------|--------|
|
||||
| Skalierung 10× | Pixel sichtbar | Perfekt scharf |
|
||||
| Foto-Realismus | Gut geeignet | Unpraktikabel |
|
||||
| Dateigröße Logo | Wächst mit Auflösung | Konstant (~5 KB) |
|
||||
| Editierbarkeit | Destruktiv | Nicht-destruktiv |
|
||||
|
||||
**Rasterisierung:** GPU wandelt Vektordaten in Pixel um. Geschieht bei jeder Darstellung neu – deshalb ist ein 4K-Monitor schärfer als ein 1080p-Monitor bei gleichem SVG.
|
||||
|
||||
---
|
||||
|
||||
# Raster- und Vektorgrafiken
|
||||
|
||||
| | Raster | Vektor |
|
||||
@@ -338,6 +414,28 @@ KLAUSURRELEVANT:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Psychovisuelle Wahrnehmung – Vertiefung
|
||||
|
||||
Die Netzhaut enthält ~120 Mio. Stäbchen (Helligkeitswahrnehmung) aber nur ~6 Mio. Zapfen (Farbwahrnehmung). Dieses 20:1-Verhältnis erklärt, warum JPEG Farbinformationen stärker reduzieren kann als Helligkeitsinformationen.
|
||||
|
||||
**Räumliche Frequenz** beschreibt, wie schnell sich die Helligkeit über eine Bildfläche ändert:
|
||||
- **Niedrig:** Himmel, Wand – große einheitliche Flächen
|
||||
- **Hoch:** Haare, Texturen, Schrift – schnelle Wechsel
|
||||
|
||||
Das Auge ist ein Tiefpassfilter: Hohe Frequenzen (feine Details) werden schwächer wahrgenommen. JPEG verwirft daher zuerst die hohen Frequenzen – der Qualitätsverlust bleibt meist unsichtbar.
|
||||
|
||||
| Biologisches Limit | Ausnutzung in JPEG |
|
||||
|-------------------|-------------------|
|
||||
| Farbauflösung ~20× geringer | Chroma Subsampling (4:2:0) |
|
||||
| Hohe Frequenzen unscharf | DCT + Quantisierung |
|
||||
| Kontrast-Maskierung | Artefakte in Texturen versteckt |
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
@@ -442,6 +540,34 @@ KLAUSURRELEVANT:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Farbraumkonversion – Vertiefung
|
||||
|
||||
RGB→YCbCr nutzt die Biologie des menschlichen Auges: 120 Mio. Stäbchen (Helligkeit) vs. nur 6 Mio. Zapfen (Farbe) – ein 20:1-Verhältnis. Die Transformation erfolgt über eine lineare Matrix:
|
||||
|
||||
```
|
||||
Y = 0.299·R + 0.587·G + 0.114·B
|
||||
Cb = −0.169·R − 0.331·G + 0.500·B + 128
|
||||
Cr = 0.500·R − 0.419·G − 0.081·B + 128
|
||||
```
|
||||
|
||||
Die Gewichtung (G dominiert mit 59%) entspricht der spektralen Empfindlichkeit des Auges bei Tageslicht. Y enthält alle Schärfeinformation; Cb/Cr können reduziert werden.
|
||||
|
||||
**Chroma Subsampling – Notation J:a:b** (bezogen auf 4×2 Pixel):
|
||||
|
||||
| Schema | Farbdaten | Einsatz |
|
||||
|--------|-----------|---------|
|
||||
| 4:4:4 | 100% | Postproduktion, Grafik |
|
||||
| 4:2:2 | 50% | Broadcast, Pro-Video |
|
||||
| 4:2:0 | 25% | JPEG, H.264, Streaming |
|
||||
|
||||
Bei 4:2:0 teilen sich 4 Pixel einen Farbwert, behalten aber individuelle Helligkeit → 50% Dateneinsparung bei kaum sichtbarem Unterschied.
|
||||
|
||||
---
|
||||
|
||||
# JPEG Schritt 2: Chroma Subsampling
|
||||
|
||||
**Notation `J:a:b`** (bezogen auf 4×2 Pixel-Block):
|
||||
@@ -623,12 +749,36 @@ KLAUSURRELEVANT:
|
||||
- Präfix-frei: Kein Code ist Anfang eines anderen
|
||||
- Häufigstes Zeichen = kürzester Code
|
||||
- Auch in ZIP, PNG, MP3 verwendet
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
-->
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Huffman-Coding – Vertiefung
|
||||
|
||||
David Huffman entwickelte 1952 als Student am MIT einen optimalen Algorithmus für präfixfreie Codes – ursprünglich als Hausaufgabe, die zur Veröffentlichung führte.
|
||||
|
||||
**Algorithmus (Bottom-Up-Baumkonstruktion):**
|
||||
1. Alle Symbole nach Häufigkeit sortieren
|
||||
2. Die zwei seltensten Symbole zu einem Knoten kombinieren
|
||||
3. Wiederholen bis nur noch die Wurzel übrig ist
|
||||
4. Codes ablesen: links = 0, rechts = 1
|
||||
|
||||
**Präfixfreiheit:** Kein Code ist Anfang eines anderen → sofort dekodierbar ohne Trennzeichen.
|
||||
|
||||
| Eigenschaft | Huffman | Arithmetisch |
|
||||
|-------------|---------|--------------|
|
||||
| Einheit | Ganze Bits | Fraktionale Bits |
|
||||
| Optimalität | Optimal für ganze Bits | Näher an Entropie |
|
||||
| Geschwindigkeit | Schneller | Langsamer |
|
||||
| JPEG-Einsatz | Standard (Baseline) | Optional (selten) |
|
||||
|
||||
JPEG verwendet zwei Huffman-Tabellen: eine für DC-Koeffizienten (Durchschnittswerte), eine für AC-Koeffizienten (Frequenzen). Die Tabellen sind im JPEG-Header gespeichert.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
@@ -772,6 +922,28 @@ KLAUSURRELEVANT:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# WebP & AVIF – Vertiefung
|
||||
|
||||
**WebP** entstand 2010 aus Googles VP8-Videocodec (On2 Technologies, für $133M gekauft). Statt I-Frames für Video werden sie als Einzelbilder verwendet. WebP nutzt Intra-Frame-Prediction, die benachbarte Blöcke zur Vorhersage verwendet – effizienter als JPEGs blockweise DCT.
|
||||
|
||||
**AVIF** basiert auf dem AV1-Videocodec, entwickelt 2015–2018 von der Alliance for Open Media (Google, Apple, Netflix, Amazon, Microsoft, Mozilla). Nach dem Patent-Chaos von H.265/HEVC vereinten sich die Konkurrenten für einen lizenzfreien Standard.
|
||||
|
||||
| Aspekt | WebP | AVIF |
|
||||
|--------|------|------|
|
||||
| Basis-Codec | VP8/VP9 | AV1 |
|
||||
| Kompression vs. JPEG | 25–35% besser | 50% besser |
|
||||
| HDR/Wide Gamut | Nein | Ja (10/12 Bit) |
|
||||
| Encoding-Geschwindigkeit | Schnell | Sehr langsam |
|
||||
| Browser-Support 2025 | 97%+ | 93%+ |
|
||||
|
||||
**Warum JPEG dominiert:** Kameras, Bildbearbeitungssoftware und Content-Management-Systeme sind auf JPEG optimiert. Der Wechsel erfordert Infrastruktur-Updates über die gesamte Pipeline.
|
||||
|
||||
---
|
||||
|
||||
# Formatwahl in der Praxis
|
||||
|
||||
| Anwendung | Format |
|
||||
@@ -890,6 +1062,33 @@ KLAUSURRELEVANT:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Container vs. Codec – Vertiefung
|
||||
|
||||
**Container** (Multiplexer-Format) organisiert mehrere Datenströme mit Timing-Informationen. Er enthält keine Kompressionslogik, sondern synchronisiert Video, Audio, Untertitel und Metadaten.
|
||||
|
||||
**Codec** (Coder-Decoder) definiert den Kompressionsalgorithmus. Derselbe Container kann verschiedene Codecs enthalten – die Dateiendung verrät den Codec nicht.
|
||||
|
||||
| Container | Entwickler | Typische Codecs | Besonderheit |
|
||||
|-----------|------------|-----------------|--------------|
|
||||
| MP4 | ISO/MPEG | H.264, H.265, AAC | Web-Standard, DRM-fähig |
|
||||
| MKV | Matroska | Alle | Beliebig viele Streams, Kapitel |
|
||||
| WebM | Google | VP9, AV1, Opus | HTML5-optimiert, lizenzfrei |
|
||||
| MOV | Apple | ProRes, H.264 | Professionelle Produktion |
|
||||
|
||||
**Metadaten im Container:**
|
||||
- Timecodes für Frame-genaue Synchronisation
|
||||
- Kapitelmarken, Thumbnails
|
||||
- Sprach-Tags für Audio/Untertitel
|
||||
- HDR-Metadaten (MaxCLL, MaxFALL)
|
||||
|
||||
**Praktisches Problem:** Eine `.mp4`-Datei mit AV1-Codec spielt auf älteren Geräten nicht ab, obwohl sie MP4 „unterstützen" – der Hardware-Decoder fehlt für AV1.
|
||||
|
||||
---
|
||||
|
||||
# Gängige Container
|
||||
|
||||
| Container | Verwendung |
|
||||
@@ -1115,6 +1314,32 @@ KLAUSURRELEVANT:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# H.264/AVC – Vertiefung
|
||||
|
||||
H.264 (2003) ermöglichte erst YouTube (2005), Netflix-Streaming (2007) und Blu-ray. Vor H.264 war MPEG-2 Standard – H.264 erreichte bei gleicher Qualität die halbe Bitrate.
|
||||
|
||||
**Technische Innovationen:**
|
||||
- **Variable Blockgrößen:** 16×16 bis 4×4 Macroblocks (MPEG-2: nur 16×16)
|
||||
- **Intra-Prediction:** Blöcke werden aus Nachbarn vorhergesagt
|
||||
- **In-Loop Deblocking:** Filter reduziert Blockartefakte vor der Referenzierung
|
||||
- **CABAC:** Arithmetic Coding ersetzt Huffman (10–15% effizienter)
|
||||
|
||||
| Profile | Anwendung | Max. Auflösung |
|
||||
|---------|-----------|----------------|
|
||||
| Baseline | Videotelefonie, ältere Geräte | 480p |
|
||||
| Main | Broadcast, Streaming | 1080p |
|
||||
| High | Blu-ray, professionell | 4K |
|
||||
|
||||
**Hardware-Ubiquität:** Seit 2010 hat jedes Smartphone, jede GPU, jeder Smart-TV einen H.264-Hardware-Decoder. Encoding in Echtzeit braucht keine CPU – das ermöglichte erst mobiles Video-Streaming und Videotelefonie.
|
||||
|
||||
**Patent-Pool (MPEG-LA):** ~2.000 Patente von 30+ Unternehmen. Endnutzer-Streaming ist lizenzfrei; Hardware-Hersteller zahlen ~$0,20/Gerät.
|
||||
|
||||
---
|
||||
|
||||
# Das Patent-Problem
|
||||
|
||||
**H.264 ist nicht frei**
|
||||
@@ -1221,6 +1446,29 @@ KLAUSURRELEVANT:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# AV1 – Vertiefung
|
||||
|
||||
Die **Alliance for Open Media** (2015) vereinte Konkurrenten nach dem Patent-Chaos von H.265/HEVC. Drei separate Patent-Pools (MPEG-LA, HEVC Advance, Velos Media) machten H.265-Lizenzierung unberechenbar – die Industrie wollte einen garantiert lizenzfreien Standard.
|
||||
|
||||
**Gründungsmitglieder:** Google, Mozilla, Cisco, Netflix, Amazon, Microsoft. Apple trat 2018 bei – historisch, da Apple sonst eigene Standards bevorzugt.
|
||||
|
||||
| Technische Innovation | Beschreibung |
|
||||
|----------------------|--------------|
|
||||
| Superblocks | Bis 128×128 Pixel (H.264: max 16×16) |
|
||||
| Prediction Modes | 56 Intra-Modi (H.264: 9) |
|
||||
| Transform | 10 verschiedene Transformtypen |
|
||||
| Film Grain Synthesis | Filmkorn wird als Parameter übertragen |
|
||||
|
||||
**Encoding-Performance:** Software-Encoding ist 50–200× langsamer als H.264. Erst Hardware-Encoder (Intel ab Gen 12, NVIDIA RTX 40, Apple M3) machen Echtzeit-Encoding praktikabel.
|
||||
|
||||
**Adoption 2025:** YouTube und Netflix nutzen AV1 für 4K/8K-Streams. 2024 gewann AV1 einen Emmy für technische Innovation – offene Standards können Industriestandard werden.
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: 'https://blog.mozilla.org/en/mozilla/av1-video-codec-wins-emmy/' -->
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
|
||||
@@ -68,6 +68,38 @@ section.aufgabe {
|
||||
section.aufgabe footer {
|
||||
display: none;
|
||||
}
|
||||
section.erklaerung {
|
||||
font-size: 1.1rem;
|
||||
background: repeating-linear-gradient(
|
||||
135deg,
|
||||
#e3f2fd,
|
||||
#e3f2fd 40px,
|
||||
#fff 40px,
|
||||
#fff 80px
|
||||
) !important;
|
||||
}
|
||||
@media print {
|
||||
section.erklaerung {
|
||||
background: #e3f2fd !important;
|
||||
}
|
||||
}
|
||||
section.erklaerung h1 {
|
||||
font-size: 1.5rem;
|
||||
color: #1e5f8a;
|
||||
margin-bottom: 0.3rem;
|
||||
}
|
||||
section.erklaerung ul,
|
||||
section.erklaerung ol {
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung p {
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung table {
|
||||
font-size: 0.9rem;
|
||||
}
|
||||
</style>
|
||||
|
||||
<!-- _class: invert -->
|
||||
@@ -82,7 +114,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||||
|
||||
@@ -235,6 +267,29 @@ Kleine SSD für System + große HDD für Archiv.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# HDD vs. SSD – Vertiefung
|
||||
|
||||
**HDD (Hard Disk Drive):** Magnetplatten rotieren mit 5.400–7.200 RPM; ein Schreib-/Lesekopf schwebt nanometerweit über der Oberfläche. Die Zugriffszeit setzt sich zusammen aus Seek Time (Kopf bewegen) + Rotational Latency (warten auf Sektor).
|
||||
|
||||
**SSD (Solid State Drive):** NAND-Flash-Zellen speichern Bits als elektrische Ladung. Kein mechanischer Zugriff → konstant schnelle Latenz. Aber: Zellen haben begrenzte Schreibzyklen (P/E Cycles).
|
||||
|
||||
| Aspekt | HDD | SATA SSD | NVMe SSD |
|
||||
|--------|-----|----------|----------|
|
||||
| Latenz | 5–10 ms | 0,1 ms | 0,02 ms |
|
||||
| Seq. Lesen | 150 MB/s | 550 MB/s | 7.000 MB/s |
|
||||
| IOPS (4K random) | 100 | 90.000 | 1.000.000 |
|
||||
| TBW (1 TB Modell) | ∞ | 600 TBW | 600 TBW |
|
||||
|
||||
**Wear Leveling:** SSD-Controller verteilen Schreibvorgänge gleichmäßig, um einzelne Zellen nicht vorzeitig zu erschöpfen. TRIM informiert den Controller über gelöschte Blöcke.
|
||||
|
||||
**Praxis:** System-SSD für OS/Anwendungen (Geschwindigkeit), HDD für Medienarchiv (Kapazität/Preis). RAID schützt vor Einzelausfällen bei beiden.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Dateisysteme
|
||||
@@ -484,6 +539,30 @@ Warum 1 Offsite?
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# 3-2-1-Backup-Regel – Vertiefung
|
||||
|
||||
Peter Krogh formulierte die Regel 2005 in „The DAM Book" (Digital Asset Management). Sie schützt gegen unterschiedliche Verlustszenarien:
|
||||
|
||||
| Bedrohung | Schutz durch | Beispiel |
|
||||
|-----------|--------------|----------|
|
||||
| Hardware-Defekt | 3 Kopien | SSD stirbt → HDD-Backup vorhanden |
|
||||
| Firmware-Bug/Ransomware | 2 Medientypen | Malware infiziert nur ein System |
|
||||
| Feuer/Diebstahl/Flut | 1 Offsite | Haus brennt → Cloud-Backup sicher |
|
||||
|
||||
**Moderne Erweiterung 3-2-1-1-0:**
|
||||
- **+1** Air-Gapped (offline, nicht verbunden)
|
||||
- **+0** Verifizierte Backups (regelmäßig Restore testen)
|
||||
|
||||
**Ransomware-Problem:** Vernetzte Backups werden oft mitverschlüsselt. Air-Gapped-Medien (externe HDD im Safe, LTO-Band) bleiben sicher, weil sie physisch getrennt sind.
|
||||
|
||||
**Realitäts-Check:** Die meisten Datenverluste entstehen durch menschliche Fehler (versehentliches Löschen), nicht Hardware-Ausfälle. Versionierte Backups (Time Machine, Borg) schützen auch davor – die gelöschte Datei existiert noch in älteren Snapshots.
|
||||
|
||||
---
|
||||
|
||||
# Backup-Arten
|
||||
|
||||
**Vollständig (Full):**
|
||||
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
|
||||
@@ -83,7 +83,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
|
||||
@@ -83,7 +83,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
<style>
|
||||
@@ -92,6 +92,8 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||||
|
||||
---
|
||||
@@ -277,14 +279,12 @@ Breite × Höhe × Farbtiefe (in Bytes)
|
||||
| 32 | 16,7 Mio. + Alpha | Transparenz |
|
||||
|
||||
<!--
|
||||
BERECHNUNG: Breite × Höhe × (Farbtiefe / 8)
|
||||
BEISPIEL: 1920×1080 × 24 Bit = 1920×1080×3 = 6.220.800 Bytes ≈ 6,2 MB
|
||||
|
||||
Farbtiefe erklärt:
|
||||
- 1 Bit: 2^1 = 2 Farben
|
||||
- 8 Bit: 2^8 = 256 Farben
|
||||
- 24 Bit: 2^24 = 16.777.216 Farben (je 8 Bit für R, G, B)
|
||||
- 32 Bit: 24 Bit + 8 Bit Alpha-Kanal
|
||||
KLAUSURRELEVANT:
|
||||
- Formel: Breite × Höhe × (Farbtiefe / 8) = Bytes
|
||||
- Beispielrechnung: 1920 × 1080 × 3 = 6.220.800 Bytes ≈ 6,2 MB
|
||||
- Farbtiefe: 2^n Farben bei n Bit
|
||||
- 24 Bit = 8 Bit pro Kanal (R, G, B)
|
||||
- 32 Bit = 24 Bit + 8 Bit Alpha (Transparenz)
|
||||
-->
|
||||
|
||||
|
||||
@@ -306,17 +306,15 @@ Farbtiefe erklärt:
|
||||
<circle cx="50" cy="50" r="40" fill="#ff0000"/>
|
||||
```
|
||||
|
||||
<small>SVG beschreibt nicht jeden einzelnen Pixel im Raster, sondern deklariert wie Farben und Formen gesetzt werden.</small>
|
||||
<small>SVG beschreibt WAS gezeichnet werden soll, nicht WIE jeder Pixel aussieht.</small>
|
||||
|
||||
<!--
|
||||
Vektorgrafiken beschreiben WAS gezeichnet werden soll.
|
||||
Rastergrafiken beschreiben WIE jeder Pixel aussieht.
|
||||
|
||||
Rendering-Pipeline:
|
||||
Vektordaten → Rasterisierung → Framebuffer → Display
|
||||
|
||||
Beim Skalieren werden einfach die Koordinaten multipliziert.
|
||||
Keine Information geht verloren.
|
||||
KLAUSURRELEVANT:
|
||||
- Vektor = Beschreibung (deklarativ)
|
||||
- Raster = Pixel für Pixel (imperativ)
|
||||
- Rendering-Pipeline: Vektordaten → Rasterisierung → Display
|
||||
- Skalierung = Koordinaten multiplizieren → keine Information geht verloren
|
||||
- SVG = Scalable Vector Graphics (Web-Standard)
|
||||
-->
|
||||
|
||||
|
||||
@@ -334,18 +332,17 @@ Keine Information geht verloren.
|
||||
- Niedrige Frequenzen besser als hohe
|
||||
|
||||
**JPEG nutzt das aus:**
|
||||
- Farbauflösung reduzieren (aber Helligkeit behalten)
|
||||
- Farbauflösung reduzieren (Helligkeit behalten)
|
||||
- Glatte Flächen effizient speichern
|
||||
- Hohe Frequenzen (Details) verwerfen
|
||||
- Hohe Frequenzen (feine Details) verwerfen
|
||||
|
||||
<!--
|
||||
Das ist die visuelle Entsprechung zur Psychoakustik.
|
||||
|
||||
Das Auge hat mehr Rezeptoren für Helligkeit (Stäbchen)
|
||||
als für Farbe (Zapfen).
|
||||
|
||||
Hohe Frequenzen = schnelle Wechsel = feine Details
|
||||
Niedrige Frequenzen = langsame Wechsel = große Flächen
|
||||
KLAUSURRELEVANT:
|
||||
- Mehr Stäbchen (Helligkeit) als Zapfen (Farbe) im Auge
|
||||
- "Frequenz" = räumliche Frequenz = wie schnell ändert sich Helligkeit?
|
||||
- Niedrig = langsame Änderung = große gleichmäßige Fläche
|
||||
- Hoch = schnelle Änderung = feine Details, Kanten
|
||||
- Analogie zur Psychoakustik bei MP3 (letztes Mal)
|
||||
-->
|
||||
|
||||
|
||||
@@ -357,24 +354,25 @@ Niedrige Frequenzen = langsame Wechsel = große Flächen
|
||||
|
||||

|
||||
|
||||
# JPEG: Schritt 1 – Farbraumkonversion
|
||||
# JPEG Schritt 1: Farbraumkonversion
|
||||
|
||||
**RGB → Y'CbCr** (seltener Y'UV)
|
||||
**RGB → Y'CbCr**
|
||||
|
||||
- **Y** = Helligkeit (Luminanz) – Was das Auge am besten sieht
|
||||
- **Y** = Helligkeit (Luminanz)
|
||||
- **Cb** = Blau-Gelb-Anteil (Chrominanz)
|
||||
- **Cr** = Rot-Grün-Anteil (Chrominanz)
|
||||
|
||||
**Warum diese Trennung?**
|
||||
Y (Helligkeit) behält volle Auflösung.
|
||||
Cb/Cr (Farbe) kann reduziert werden – Auge merkt es kaum.
|
||||
**Warum?**
|
||||
Y (Helligkeit) behält volle Auflösung
|
||||
Cb/Cr (Farbe) kann reduziert werden
|
||||
|
||||
<!--
|
||||
YCbCr ist wie RGB ein Tripel aus 3 Werten pro Pixel.
|
||||
Der Unterschied: Statt Rot-Grün-Blau speichern wir Helligkeit + 2 Farbdifferenzen.
|
||||
|
||||
Die Umrechnung ist reversibel (mathematische Transformation).
|
||||
Der Clou: Jetzt können wir Helligkeit und Farbe getrennt behandeln.
|
||||
KLAUSURRELEVANT:
|
||||
- YCbCr = auch 3 Werte pro Pixel, aber anders organisiert
|
||||
- Statt R-G-B: Helligkeit + 2 Farbdifferenzen
|
||||
- Umrechnung ist reversibel (mathematische Transformation)
|
||||
- Vorteil: Helligkeit und Farbe getrennt behandelbar
|
||||
- Bild zeigt: Y (oben), Cb (Mitte), Cr (unten)
|
||||
-->
|
||||
|
||||
|
||||
@@ -384,14 +382,14 @@ Der Clou: Jetzt können wir Helligkeit und Farbe getrennt behandeln.
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# JPEG: Schritt 6 – Huffman-Coding
|
||||
# JPEG Schritt 6: Huffman-Coding
|
||||
|
||||
**Verlustfreie Kompression der Restwerte**
|
||||
|
||||
**Idee:** Statt fester 8 Bit pro Wert → variable Bitlänge
|
||||
Häufige Werte bekommen kurze Bit-Sequenzen.
|
||||
**Idee:** Variable Bitlänge statt fester 8 Bit
|
||||
Häufige Werte → kurze Codes
|
||||
|
||||
| Zeichen | Häufigkeit | Code (Bit-Sequenz) |
|
||||
| Zeichen | Häufigkeit | Code |
|
||||
|---------|------------|------|
|
||||
| e | 40% | `0` (1 Bit) |
|
||||
| a | 25% | `10` (2 Bit) |
|
||||
@@ -400,9 +398,74 @@ Häufige Werte bekommen kurze Bit-Sequenzen.
|
||||
| u | 5% | `1111` (4 Bit) |
|
||||
|
||||
<!--
|
||||
Huffman-Coding ist verlustfrei.
|
||||
Der "Code" ist eine Bit-Sequenz, die das Zeichen eindeutig identifiziert.
|
||||
Weil "e" am häufigsten vorkommt, bekommt es den kürzesten Code.
|
||||
KLAUSURRELEVANT:
|
||||
- Huffman = verlustfrei, optimal für bekannte Häufigkeiten
|
||||
- Präfix-frei: Kein Code ist Anfang eines anderen
|
||||
- Häufigstes Zeichen = kürzester Code
|
||||
- Auch in ZIP, PNG, MP3 verwendet
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
<!--
|
||||
# Huffman-Coding: Beispiel
|
||||
|
||||
**Originaltext:** `ABRACADABRA` (11 Zeichen × 8 Bit = 88 Bit)
|
||||
|
||||
**Häufigkeitsanalyse:**
|
||||
A=5, B=2, R=2, C=1, D=1
|
||||
|
||||
**Huffman-Baum → Codes:**
|
||||
| Zeichen | Häufigkeit | Code |
|
||||
|---------|------------|------|
|
||||
| A | 5 | `0` |
|
||||
| B | 2 | `10` |
|
||||
| R | 2 | `110` |
|
||||
| C | 1 | `1110` |
|
||||
| D | 1 | `1111` |
|
||||
|
||||
**Codiert:** `0 10 110 0 1110 0 1111 0 10 110 0` = **23 Bit**
|
||||
**Kompression:** 88 → 23 Bit = **74% gespart**
|
||||
|
||||
|
||||
- Beispiel Schritt für Schritt durchrechnen
|
||||
- Warum funktioniert's? A kommt 5× vor, bekommt kürzesten Code
|
||||
- Präfix-Eigenschaft: Kein Code ist Anfang eines anderen → eindeutig dekodierbar
|
||||
- Frage: "Was passiert, wenn alle Zeichen gleich häufig sind?" → Keine Ersparnis
|
||||
- In JPEG: Nicht Buchstaben, sondern DCT-Koeffizienten werden so codiert
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# WebP & AVIF: Moderne Alternativen
|
||||
|
||||
**WebP (Google, 2010):**
|
||||
- Lossy und Lossless
|
||||
- Transparenz und Animationen
|
||||
- 25–35% kleiner als JPEG
|
||||
|
||||
**AVIF (2019):**
|
||||
- Basiert auf AV1-Video-Codec
|
||||
- 50% kleiner als JPEG
|
||||
- HDR-Unterstützung, patent-frei
|
||||
|
||||
**Browser-Support 2025:** WebP universell, AVIF wächst
|
||||
|
||||
<!--
|
||||
KLAUSURRELEVANT:
|
||||
- WebP: VP8-Kompression (Google Video-Codec)
|
||||
- AVIF: Alliance for Open Media (Google, Netflix, Amazon, Apple, Mozilla)
|
||||
- Beide besser als JPEG, aber Kompatibilität bleibt Problem
|
||||
- JPEG bleibt dominant: alte Kameras, Software, Workflows
|
||||
-->
|
||||
|
||||
|
||||
@@ -414,28 +477,22 @@ Weil "e" am häufigsten vorkommt, bekommt es den kürzesten Code.
|
||||
|
||||
# Container und Codec
|
||||
|
||||
**Container = Das Dateiformat (Beispiel: MP4)**
|
||||
**Container = Dateiformat (z.B. MP4)**
|
||||
Die "Box", die verschiedene Streams zusammenpackt:
|
||||
- Video-Stream
|
||||
- Audio-Stream(s)
|
||||
- Untertitel
|
||||
- Metadaten
|
||||
|
||||
**Codec = Der Kompressionsalgorithmus (Beispiel: AV1)**
|
||||
Entscheidet, WIE komprimiert wird.
|
||||
|
||||
**Codec = Kompressionsalgorithmus (z.B. H.264)**
|
||||
Bestimmt, WIE komprimiert wird
|
||||
|
||||
<!--
|
||||
Container ≠ Codec
|
||||
Das ist ein häufiges Missverständnis.
|
||||
|
||||
MP4 ist ein Container, nicht ein Codec.
|
||||
Ein MP4 kann H.264, H.265 oder AV1 enthalten.
|
||||
|
||||
Übrigens: JPEG ist ein Codec (für Bilder), kein Container.
|
||||
Bei Bildern fallen Container und Codec oft zusammen.
|
||||
|
||||
Tools wie MediaInfo zeigen beide Informationen.
|
||||
KLAUSURRELEVANT:
|
||||
- Container ≠ Codec (häufiges Missverständnis!)
|
||||
- MP4 kann H.264, H.265 oder AV1 enthalten
|
||||
- Gleiche Endung, unterschiedlicher Inhalt
|
||||
- Tool-Tipp: MediaInfo zeigt beides an
|
||||
-->
|
||||
|
||||
|
||||
@@ -451,19 +508,19 @@ Tools wie MediaInfo zeigen beide Informationen.
|
||||
|
||||
**Warum dominant?**
|
||||
- Exzellente Kompression (~100:1 möglich)
|
||||
- Hardware-Support in jedem Gerät seit ~2010
|
||||
- Hardware-Decoder in jedem Gerät seit ~2010
|
||||
- YouTube, Netflix, Blu-ray – alles H.264
|
||||
|
||||
**Features:**
|
||||
- Variable Block-Größen (16×16 bis 4×4)
|
||||
- Deblocking-Filter (reduziert Block-Artefakte)
|
||||
- Deblocking-Filter (reduziert Artefakte)
|
||||
|
||||
<!--
|
||||
H.264 revolutionierte Video-Streaming.
|
||||
Ohne H.264 kein Netflix, kein YouTube in HD.
|
||||
|
||||
Hardware-Decoder bedeutet: Kein CPU-Aufwand, kein Akku-Drain.
|
||||
Selbst billige Smartphones können H.264 abspielen.
|
||||
KLAUSURRELEVANT:
|
||||
- H.264 revolutionierte Video-Streaming
|
||||
- Ohne H.264 kein Netflix, kein YouTube HD
|
||||
- Hardware-Decoder = kein CPU-Aufwand, kein Akku-Drain
|
||||
- Selbst billigste Smartphones können H.264 abspielen
|
||||
-->
|
||||
|
||||
|
||||
@@ -486,17 +543,16 @@ Google, Netflix, Amazon, Microsoft, Apple, Mozilla...
|
||||
- 8K, HDR, hohe Frame-Rates
|
||||
|
||||
**Stand 2025:**
|
||||
YouTube und Netflix nutzen AV1 für 4K/8K
|
||||
YouTube, Netflix nutzen AV1 für 4K/8K
|
||||
Hardware-Encoder in aktuellen GPUs
|
||||
|
||||
<!--
|
||||
AOM = Alliance for Open Media, gegründet 2015.
|
||||
Historisch: Konkurrierende Tech-Giganten vereint.
|
||||
|
||||
Das Ziel: Nie wieder Patent-Chaos wie bei H.265.
|
||||
|
||||
Problem: Encoding ist sehr langsam (10-100× vs. H.264).
|
||||
Hardware-Encoder lösen das zunehmend.
|
||||
KLAUSURRELEVANT:
|
||||
- AOM gegründet 2015 – historisch: Konkurrenten vereint
|
||||
- Ziel: Nie wieder Patent-Chaos wie bei H.265
|
||||
- Problem: Encoding sehr langsam (10–100× vs. H.264)
|
||||
- Hardware-Encoder lösen das zunehmend
|
||||
- AV1 gewann 2024 einen Emmy für technische Innovation
|
||||
-->
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Grundlagen IT- und Internettechnik (223015c)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: "Kapitel 1: Geschichte, Grundlagen & HTML"
|
||||
---
|
||||
|
||||
@@ -68,6 +68,38 @@ section.aufgabe {
|
||||
section.aufgabe footer {
|
||||
display: none;
|
||||
}
|
||||
section.erklaerung {
|
||||
font-size: 1.1rem;
|
||||
background: repeating-linear-gradient(
|
||||
135deg,
|
||||
#fce4ec,
|
||||
#fce4ec 40px,
|
||||
#fff 40px,
|
||||
#fff 80px
|
||||
) !important;
|
||||
}
|
||||
@media print {
|
||||
section.erklaerung {
|
||||
background: #fce4ec !important;
|
||||
}
|
||||
}
|
||||
section.erklaerung h1 {
|
||||
font-size: 1.5rem;
|
||||
color: #a02060;
|
||||
margin-bottom: 0.3rem;
|
||||
}
|
||||
section.erklaerung ul,
|
||||
section.erklaerung ol {
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung p {
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung table {
|
||||
font-size: 0.9rem;
|
||||
}
|
||||
</style>
|
||||
|
||||
<!-- _class: invert -->
|
||||
@@ -83,7 +115,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
|
||||
|
||||
@@ -96,24 +128,13 @@ Hochschule der Medien Stuttgart
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Kapitel 1
|
||||
## Geschichte, Grundlagen & HTML
|
||||
|
||||
---
|
||||
|
||||
# Kursübersicht
|
||||
|
||||
**3 Termine (10:00 – 16:30 Uhr):**
|
||||
**Kapitel:**
|
||||
|
||||
| # | Datum | Thema |
|
||||
|---|-------|-------|
|
||||
| 1 | 20.12.2025 | Geschichte, Grundlagen & **HTML** |
|
||||
| 2 | 10.01.2026 | Netzwerke, Protokolle, **semantisches HTML** & **CSS** |
|
||||
| 3 | 24.01.2026 | Interaktivität, Animationen & **JavaScript** |
|
||||
|
||||
**Format:** Theorie + viele Hands-On-Übungen
|
||||
1. Geschichte, Grundlagen & **HTML**
|
||||
2. Netzwerke, Protokolle, **semantisches HTML** & **CSS**
|
||||
3. Interaktivität, Animationen & **JavaScript**
|
||||
|
||||
**Ziel:** "Gelernte Hilflosigkeit" ablegen
|
||||
|
||||
@@ -121,8 +142,15 @@ Hochschule der Medien Stuttgart
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Teil 1: Die Geschichte
|
||||
## Von der Geburtsstunde des erten Computer-Algorithmus bis zur Vernetzung des gesamten Globus
|
||||
# Kapitel 1
|
||||
## Geschichte, Grundlagen & HTML
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Die Geschichte des Computers
|
||||
## Vom ersten Algorithmus bis zum globalen Netzwerk
|
||||
|
||||
---
|
||||
|
||||
@@ -144,14 +172,13 @@ Antoine Claudet
|
||||
|
||||
**Die erste Programmiererin der Welt**
|
||||
|
||||
- Arbeitete mit **Charles Babbage** an der "Analytical Engine"
|
||||
- Ihre »Notes« zu Babbages Maschine: **umfangreicher als sein Text**
|
||||
- 1843 publiziert – unter Initialen »A.A.L.« Ada Augusta Lovelace
|
||||
- Erst **1953** wiederentdeckt und gewürdigt
|
||||
- Schrieb **1843** den ersten Algorithmus für eine Maschine, die nie fertiggestellt wurde
|
||||
- Erste Programmiererin – 100 Jahre vor dem ersten Computer
|
||||
- Zusammenarbeit mit Charles Babbage an der *Analytical Engine*
|
||||
- Ihre Notizen: umfangreicher als sein Originaltext
|
||||
- Erst 1953 wiederentdeckt und gewürdigt
|
||||
|
||||
<!--
|
||||
Babbage: Mathematiker, besessen von Rechenmaschinen. Erst die Difference Engine, dann die Analytical Engine – nie fertig gebaut, aber revolutionär im Konzept.
|
||||
Babbage: Mathematiker, besessen von Rechenmaschinen. Erste Maschine: Difference Engine (reine Rechenmaschine). Zweite Maschine: Analytical Engine – programmierbar, mit Lochkarten gesteuert. Nie fertig gebaut, aber revolutionär im Konzept.
|
||||
|
||||
Ada: Tochter von Lord Byron, dem Dichter. Die Mutter – selbst Mathematikerin – hatte Angst, Ada könnte den "Wahnsinn" des Vaters erben. Also: strikte naturwissenschaftliche Erziehung. Weg von der Poesie, hin zur Logik.
|
||||
|
||||
@@ -181,19 +208,25 @@ Herman Hollerith, ca. 1890
|
||||
|
||||
# Herman Hollerith (1860–1929)
|
||||
|
||||
**Das Problem:** US-Volkszählung 1880 dauerte **7 Jahre** zur Auswertung
|
||||
**Erfinder der Lochkarten-Datenverarbeitung**
|
||||
|
||||
**Die Lösung:** Lochkarten + elektromechanische Tabelliermaschine
|
||||
|
||||
**1890 Census:** 62 Millionen Menschen in **2,5 Jahren** gezählt
|
||||
|
||||
**Ersparnis:** 5 Millionen Dollar (damals!)
|
||||
- **Problem:** Volkszählung 1880 brauchte 7 Jahre zur Auswertung
|
||||
- **Lösung:** Lochkarten + elektromechanische Tabelliermaschine
|
||||
- **Ergebnis:** 1890 Census in 2,5 Jahren – 5 Mio. Dollar gespart
|
||||
- Gründete Firma, die später zu IBM wurde
|
||||
|
||||
<!--
|
||||
Hollerith: Deutsch-amerikanischer Ingenieur
|
||||
Inspiration: Jacquard-Webstuhl (Lochkarten für Muster)
|
||||
Lochkarte = erstes standardisiertes Datenformat
|
||||
Eine Karte = ein Datensatz (eine Person)
|
||||
Hollerith: Deutsch-amerikanischer Ingenieur, Statistiker am US Census Bureau.
|
||||
|
||||
Das Problem: Die USA wuchsen so schnell, dass die Volkszählung von 1880 erst 1887 fertig ausgewertet war – die nächste Zählung stand schon bevor.
|
||||
|
||||
Inspiration: Jacquard-Webstuhl. Dieser französische Webstuhl nutzte seit 1804 Lochkarten zur Steuerung komplexer Muster. Hollerith übertrug das Prinzip auf Daten.
|
||||
|
||||
Seine Innovation: Eine Lochkarte = ein Datensatz (eine Person). Die Position der Löcher codierte Informationen (Alter, Geschlecht, Beruf etc.). Elektromechanische Maschine las die Karten und zählte automatisch.
|
||||
|
||||
1896 gründete er die Tabulating Machine Company. Nach mehreren Fusionen entstand daraus 1924 IBM – International Business Machines.
|
||||
|
||||
Die Lochkarte blieb bis in die 1970er das Standardformat für Dateneingabe.
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -213,6 +246,17 @@ US Census Bureau
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||

|
||||
|
||||
<!--
|
||||
Hollerith-Lochkartenmaschine
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||

|
||||
|
||||
<!--
|
||||
@@ -224,19 +268,23 @@ US Census Bureau
|
||||
|
||||
# Die Geburt von IBM
|
||||
|
||||
**1896:** Hollerith gründet "Tabulating Machine Company"
|
||||
**Vom Einmannbetrieb zum Technologieriesen**
|
||||
|
||||
**1911:** Fusion → "Computing-Tabulating-Recording Company" (CTR)
|
||||
|
||||
**1924:** Umbenennung in **International Business Machines (IBM)**
|
||||
|
||||
IBM dominiert die nächsten 50 Jahre die Computerwelt.
|
||||
- 1896: Hollerith gründet *Tabulating Machine Company*
|
||||
- 1911: Fusion zur *Computing-Tabulating-Recording Company* (CTR)
|
||||
- 1924: Umbenennung in **International Business Machines (IBM)**
|
||||
- Dominiert die nächsten 50 Jahre die Computerwelt
|
||||
|
||||
<!--
|
||||
Thomas J. Watson Sr. → "THINK"-Motto
|
||||
IBM = "Big Blue"
|
||||
Lochkarten = Standard bis in die 1970er
|
||||
Heute: IBM als Cloud- und AI-Unternehmen (Watson, Red Hat)
|
||||
Thomas J. Watson Sr. übernahm 1914 die Führung und prägte IBM entscheidend. Sein Motto: "THINK" – stand auf Schildern in jedem IBM-Büro.
|
||||
|
||||
Warum "Big Blue"? IBMs Firmenfarbe war dunkelblau, ihre Großrechner hatten blaue Gehäuse. Der Spitzname entstand in den 1960ern.
|
||||
|
||||
Geschäftsmodell: IBM verkaufte nicht nur Maschinen, sondern vermietete sie – inklusive Wartung. Kunden waren abhängig. Ein frühes "Software-as-a-Service"-Modell.
|
||||
|
||||
Lochkarten blieben Standard bis in die 1970er. Die 80-Spalten-Karte prägte sogar frühe Bildschirmbreiten (80 Zeichen).
|
||||
|
||||
Heute: IBM hat sich neu erfunden – Cloud-Computing, KI (Watson), und 2019 Übernahme von Red Hat für 34 Milliarden Dollar.
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -257,39 +305,23 @@ Dehomag = Deutsche Hollerith-Maschinen GmbH (IBM-Tochter)
|
||||
|
||||
# IBM und NS-Deutschland
|
||||
|
||||
**Dehomag** = Deutsche Hollerith-Maschinen GmbH (IBM-Tochter)
|
||||
**Technologie im Dienst des Terrors**
|
||||
|
||||
**Einsatz:**
|
||||
- Volkszählung 1933 (Identifikation von Juden)
|
||||
- **Dehomag:** Deutsche Hollerith-Maschinen GmbH (IBM-Tochter)
|
||||
- Volkszählung 1933: Identifikation von Juden
|
||||
- Verwaltung der Konzentrationslager
|
||||
- Logistik der Deportationen
|
||||
|
||||
**Edwin Black:** *"IBM and the Holocaust"* (2001)
|
||||
→ Edwin Black: *"IBM and the Holocaust"* (2001)
|
||||
|
||||
<!--
|
||||
Kontroverse Geschichte
|
||||
IBM profitierte, lieferte Maschinen, wartete sie
|
||||
"Technologie ist neutral" – wirklich?
|
||||
Wichtige Lektion für MedienethikerInnen
|
||||
-->
|
||||
Die Volkszählung 1933 fragte erstmals systematisch nach "Rasse" und Religion. Lochkarten ermöglichten die schnelle Auswertung – wer war Jude, wer Halbjude, wer mit wem verheiratet?
|
||||
|
||||
---
|
||||
Dehomag war IBMs profitabelste Auslandstochter. IBM lieferte nicht nur Maschinen, sondern auch maßgeschneiderte Lochkarten und Wartung. Die Maschinen in den KZs trugen IBM-Seriennummern.
|
||||
|
||||
# Lektionen für heute
|
||||
Edwin Blacks Buch basiert auf tausenden Dokumenten. IBM bestritt die Vorwürfe, zahlte aber 2001 Entschädigungen an Holocaust-Überlebende.
|
||||
|
||||
* Technologie ist nie neutral
|
||||
|
||||
|
||||
<!--
|
||||
* **2025:**
|
||||
* Big Data
|
||||
* Generative KI
|
||||
* Social Media
|
||||
* Rasterfahndung ([https://netzpolitik.org/](https://netzpolitik.org/2025/stuttgart-buendnis-plant-demonstration-gegen-palantir-einsatz/))
|
||||
|
||||
Facebook, Cambridge Analytica, Oracle Blue Kai
|
||||
Gesichtserkennung, Überwachung, Social Credit System (China)
|
||||
Verantwortung von TechnikerInnen und MedienarbeiterInnen
|
||||
Die Frage für MedienarbeiterInnen: Hätte IBM "Nein" sagen können? Sollen? Müssen? Technologie ist nie neutral – sie wird von Menschen für Zwecke eingesetzt.
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -315,17 +347,24 @@ Bletchley Park
|
||||
|
||||
# Alan Turing (1912–1954)
|
||||
|
||||
**Vater der theoretischen Informatik**
|
||||
**Begründer der theoretischen Informatik**
|
||||
|
||||
- 1936: **Turing-Maschine** – theoretisches Modell eines Computers
|
||||
- 1939–1945: **Bletchley Park** – Enigma-Entschlüsselung
|
||||
- 1950: "Computing Machinery and Intelligence" → **Turing-Test**
|
||||
- **2013:** Posthume königliche Begnadigung
|
||||
- 1936: Turing-Maschine – definiert, was Computer können (und was nicht)
|
||||
- 1940er: Enigma-Entschlüsselung mit elektromechanischen Maschinen
|
||||
- 1950: Turing-Test – erste formale Definition von "Künstlicher Intelligenz"
|
||||
|
||||
<!--
|
||||
Genialer Mathematiker und Logiker
|
||||
Rettete vermutlich Millionen Leben durch Enigma-Arbeit
|
||||
Erst 2009 offizielle Entschuldigung der brit. Regierung
|
||||
Alan Turing war seiner Zeit Jahrzehnte voraus. Mit 24 Jahren definierte er, was "Berechnung" mathematisch bedeutet – bevor es echte Computer gab.
|
||||
|
||||
Bletchley Park: Geheimes Entschlüsselungszentrum 80 km nördlich von London. 10.000 Menschen arbeiteten dort, darunter viele Frauen. Streng geheim bis in die 1970er.
|
||||
|
||||
Seine Arbeit verkürzte den Krieg um geschätzte 2-4 Jahre und rettete Millionen Leben. Aber er durfte nie darüber sprechen.
|
||||
|
||||
1952 wurde Turing wegen Homosexualität verurteilt – damals illegal in Großbritannien. Er wurde chemisch kastriert. 1954 starb er an Zyanidvergiftung, vermutlich Suizid. Er war 41.
|
||||
|
||||
2009: Offizielle Entschuldigung von Premierminister Gordon Brown.
|
||||
2013: Königliche Begnadigung durch Queen Elizabeth II.
|
||||
2021: 50-Pfund-Schein mit Turings Porträt.
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -333,88 +372,36 @@ Erst 2009 offizielle Entschuldigung der brit. Regierung
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||

|
||||

|
||||
|
||||
<!--
|
||||
Bletchley Park, England
|
||||
Geheimes Entschlüsselungszentrum im WWII
|
||||
Der Turing-Test (1950): Ein Interrogator kommuniziert per Text mit einem Menschen und einer Maschine. Kann er nicht zuverlässig unterscheiden, wer wer ist, besteht die Maschine den Test.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Enigma & Bletchley Park
|
||||
|
||||
**Das Problem:** Deutsche Enigma-Maschine erzeugte 158 Trillionen mögliche Einstellungen
|
||||
|
||||
**Turings Lösung:** "Bombe" Elektro-mechanischer Entschlüssler
|
||||
|
||||
**Ergebnis:**
|
||||
- Alliierten konnten deutschen Funkverkehr mitlesen
|
||||
|
||||
**Geheim bis 1970er!** Turing starb ohne Anerkennung.
|
||||
|
||||
<!--
|
||||
Enigma: Elektrische Rotor-Chiffriermaschine
|
||||
Täglich neue Einstellungen
|
||||
Bombe: Vorläufer moderner Computer
|
||||
Parallelisierte Berechnung
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Die Turing-Maschine (1936)
|
||||
|
||||
**Theoretisches Modell eines Computers:**
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────┐
|
||||
│ ... │ 0 │ 1 │ 1 │ 0 │ 1 │ 0 │ ... │ ← Unendliches Band
|
||||
└─────────────────────────────────────────┘
|
||||
↑
|
||||
┌─────────────┐
|
||||
│ Lese-/ │
|
||||
│ Schreibkopf │
|
||||
└─────────────┘
|
||||
↓
|
||||
┌─────────────┐
|
||||
│ Zustand │ ← Endliche Zustände
|
||||
└─────────────┘
|
||||
```
|
||||
|
||||
**Beweis:** Alles Berechenbare kann so berechnet werden!
|
||||
→ Grundlage für **alle** modernen Computer
|
||||
|
||||
<!--
|
||||
Abstraktes Gedankenmodell
|
||||
Kein echter Bau nötig
|
||||
Church-Turing-These
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||

|
||||
|
||||
---
|
||||
|
||||
# Das Manhattan-Projekt (1942–1945)
|
||||
|
||||
**Ziel:** Bau der ersten Atombombe
|
||||
**Problem:** Millionen von Berechnungen nötig für:
|
||||
- Ballistik-Berechnungen
|
||||
- Implosions-Simulationen
|
||||
- Nuklearphysik-Gleichungen
|
||||
|
||||
**Problem:** Berechnung von Implosionswellen
|
||||
→ Millionen von Berechnungen nötig
|
||||
**Lösung 1943:** Menschliche "Computer"
|
||||
→ Mathematikerinnen mit Taschenrechnern & IBM-Lochkarten
|
||||
|
||||
**Team:**
|
||||
- J. Robert Oppenheimer (Leitung)
|
||||
- Richard Feynman (Rechenabteilung)
|
||||
- **John von Neumann** (Mathematik & Stoßwellen)
|
||||
**Zu langsam** → Bedarf an automatischer Berechnung
|
||||
|
||||
**Schlüsselfigur:** John von Neumann (Mathematik & Stoßwellen)
|
||||
|
||||
<!--
|
||||
Los Alamos, New Mexico
|
||||
Geheimes Labor, beste WissenschaftlerInnen der Welt
|
||||
Von Neumann kam 1943 als Berater
|
||||
Los Alamos, New Mexico – geheimes Labor, beste WissenschaftlerInnen der Welt.
|
||||
|
||||
"Computer" war ein Job-Titel! Meist Mathematikerinnen. Richard Feynman leitete eine Abteilung davon.
|
||||
|
||||
Von Neumann kam 1943 als Berater. Seine mathematischen Fähigkeiten waren legendär.
|
||||
|
||||
Das ENIAC-Projekt in Philadelphia sollte die Berechnungen beschleunigen.
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -441,27 +428,6 @@ Arbeitete am Manhattan-Projekt mit
|
||||
|
||||
---
|
||||
|
||||
# Das Problem der Berechnung
|
||||
|
||||
**Manhattan-Projekt brauchte:**
|
||||
- Ballistik-Berechnungen
|
||||
- Implosions-Simulationen
|
||||
- Nuklearphysik-Gleichungen
|
||||
|
||||
**Lösung 1943:** Menschliche "Computer"
|
||||
→ Mit Taschenrechnern, Tabellen, IBM-Lochkarten
|
||||
|
||||
**Zu langsam** → Bedarf an automatischer Berechnung
|
||||
|
||||
<!--
|
||||
"Computer" war ein Job-Titel!
|
||||
Meist Mathematikerinnen
|
||||
Feynman leitete eine Abteilung davon
|
||||
ENIAC-Projekt in Philadelphia sollte helfen
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
@@ -495,6 +461,96 @@ Programmiert durch 6 Frauen (ENIAC Girls)
|
||||
|
||||
---
|
||||
|
||||
# Von-Neumann-Architektur (1945)
|
||||
|
||||
**Die zentrale Idee: Programme und Daten im selben Speicher**
|
||||
|
||||
**Vorher (z.B. ENIAC):** Programme durch Umstecken von Kabeln
|
||||
→ Tagelange Arbeit für jedes neue Problem
|
||||
|
||||
**Nachher:** Programme als austauschbare Daten im Speicher
|
||||
→ Grundlage aller Computer: Laptop, Smartphone, Server
|
||||
|
||||
<!--
|
||||
John von Neumann beschrieb 1945 das Prinzip im "First Draft of a Report on the EDVAC".
|
||||
|
||||
Vorher (ENIAC): Programme durch Umstecken von Kabeln – tagelange Arbeit für jedes neue Problem. Nachher: Programme als Daten im Speicher – austauschbar in Sekunden.
|
||||
|
||||
Das Revolutionäre: Programme liegen im selben Speicher wie Daten. Das klingt selbstverständlich, war aber ein Paradigmenwechsel. Vorher war ein Computer eine Maschine für genau ein Problem.
|
||||
|
||||
Der "Von-Neumann-Flaschenhals": CPU und Speicher teilen sich einen Bus – die Bandbreite begrenzt die Geschwindigkeit. Moderne CPUs umgehen das mit Caches (L1/L2/L3).
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #fce4ec -->
|
||||
|
||||
# Von-Neumann: 5 Komponenten
|
||||
|
||||
| Komponente | Funktion |
|
||||
|------------|----------|
|
||||
| **Rechenwerk (ALU)** | Führt Berechnungen durch |
|
||||
| **Steuerwerk** | Interpretiert Befehle, steuert Ablauf |
|
||||
| **Speicherwerk** | Speichert Programme UND Daten |
|
||||
| **Ein-/Ausgabe** | Tastatur, Bildschirm, Netzwerk |
|
||||
| **Bus-System** | Verbindet alle Komponenten |
|
||||
|
||||
<!--
|
||||
VON-NEUMANN-ARCHITEKTUR (1945): Grundlage aller modernen Computer
|
||||
5 KOMPONENTEN:
|
||||
- ALU (Arithmetic Logic Unit): Rechnet (+, -, ×, ÷) und vergleicht (>, <, =)
|
||||
- Steuerwerk: Holt Befehle, dekodiert sie, steuert Ausführung (Fetch-Decode-Execute)
|
||||
- Speicherwerk: RAM (flüchtig) + ROM (permanent), enthält Code UND Daten
|
||||
- Ein-/Ausgabe (I/O): Tastatur, Maus, Bildschirm, Netzwerk, USB, Sensoren
|
||||
- Bus-System: Adressbus (wo), Datenbus (was), Steuerbus (wie)
|
||||
KERNPRINZIP: Stored Program Concept - Programme im selben Speicher wie Daten
|
||||
VORHER (z.B. ENIAC): Programme durch Umstecken von Kabeln, tagelange Arbeit
|
||||
NACHHER: Programme als austauschbare Daten → Flexibilität, Software-Industrie möglich
|
||||
PRÜFUNGSRELEVANT: 5 Komponenten benennen und erklären können, Stored Program Concept
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #fce4ec -->
|
||||
|
||||
# Von-Neumann-Architektur: Bedeutung
|
||||
|
||||
**Ohne Von-Neumann-Architektur:**
|
||||
- Kein Betriebssystem
|
||||
- Keine Apps
|
||||
- Kein Multitasking
|
||||
- Keine Updates bzw. Veränderungen am Computer System
|
||||
|
||||
**Die meisten Computer** basieren auf diesem Prinzip:
|
||||
Laptop, Smartphone, Server, Spielkonsole...
|
||||
|
||||
**Ausnahme:** Mikrocontroller & DSPs nutzen oft die **Harvard-Architektur**
|
||||
(separate Speicher für Code und Daten → schneller für Echtzeitanwendungen)
|
||||
|
||||
<!--
|
||||
BEDEUTUNG VON-NEUMANN-ARCHITEKTUR:
|
||||
- Betriebssystem möglich: Lädt verschiedene Programme aus gleichem Speicher
|
||||
- Apps installierbar: Können gelöscht/installiert werden ohne Hardware-Änderung
|
||||
- Multitasking: Mehrere Programme gleichzeitig im Speicher
|
||||
- Updates: Software austauschbar, Hardware bleibt gleich
|
||||
- Universalrechner: Gleiche Hardware für Text, Spiele, Video, Wissenschaft
|
||||
HARVARD-ARCHITEKTUR (Alternative):
|
||||
- Separate Speicher für Code und Daten
|
||||
- Vorteil: Schneller (paralleler Zugriff), sicherer (Code nicht überschreibbar)
|
||||
- Nachteil: Weniger flexibel, aufwändiger
|
||||
- Anwendung: Mikrocontroller (Arduino, ESP32), DSPs, einige ARM-Chips
|
||||
MODERNE CPUs: Modified Harvard (L1-Cache getrennt für Speed, RAM gemeinsam für Flexibilität)
|
||||
PRÜFUNGSRELEVANT: Warum Von-Neumann revolutionär, Unterschied zu Harvard, Beispiele
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
@@ -574,118 +630,62 @@ Die Software priorisierte kritische Aufgaben automatisch
|
||||
|
||||
---
|
||||
|
||||
# Von Neumanns Idee (1945)
|
||||
# Lektionen für heute
|
||||
|
||||
**"First Draft of a Report on the EDVAC"**
|
||||
**Technologie ist nie neutral**
|
||||
|
||||
**Kernidee:** Programm und Daten im **selben Speicher**
|
||||
- Big Data ermöglicht Massenüberwachung
|
||||
- KI-Systeme übernehmen Entscheidungen über Menschen
|
||||
- Social Media schädigt die psychische Gesundheit Minderjähriger
|
||||
- PimEyes: RAF-Terroristin in 30 Minuten gefunden – Polizei brauchte 30 Jahre
|
||||
|
||||
**Vorher:** Hardware = Programm (Umstecken)
|
||||
**Nachher:** Software = austauschbar (laden)
|
||||
|
||||
→ **Gespeichertes Programm** = Revolution
|
||||
→ Verantwortung liegt bei denen, die Technologie bauen und einsetzen
|
||||
|
||||
<!--
|
||||
EDVAC = Electronic Discrete Variable Automatic Computer
|
||||
Nachfolger von ENIAC
|
||||
Von Neumann schrieb den Bericht
|
||||
Daher: "Von-Neumann-Architektur"
|
||||
Aktuelle Beispiele (in Reihenfolge der Folie):
|
||||
|
||||
1. Big Data / Palantir: US-Firma liefert Überwachungssoftware an Polizei und Geheimdienste. In Deutschland nutzen es bereits Hessen, NRW, Bayern und Baden-Württemberg. Kritiker warnen vor "Rasterfahndung auf Knopfdruck".
|
||||
Quellen: https://www.zdfheute.de/politik/deutschland/palantir-einsatz-polizei-deutschland-alternative-100.html
|
||||
https://www.heise.de/en/news/Baden-Wuerttemberg-decides-on-the-use-of-Palantir-11075477.html
|
||||
|
||||
2. KI-Systeme: Algorithmen entscheiden über Kreditvergabe, Bewerbungen, Sozialleistungen. Oft intransparent, oft diskriminierend. Beispiel: Niederlande "Toeslagenaffaire" – Steuerbehörde nutzte Algorithmus, der Familien mit Migrationshintergrund systematisch als Betrüger einstufte. Regierung Rutte trat 2021 zurück.
|
||||
Quelle: https://netzpolitik.org/2021/kindergeldaffaere-niederlande-zahlen-millionenstrafe-wegen-datendiskriminierung/
|
||||
|
||||
3. Social Media: 2026 verloren Meta und Google einen Prozess in Kalifornien – ihre Plattformen schädigen nachweislich die psychische Gesundheit Minderjähriger.
|
||||
Quelle: https://www.latimes.com/california/story/2026-03-25/social-media-lawsuit-trial-meta-google-verdict
|
||||
|
||||
4. PimEyes/Clearview: Gesichtserkennungsdienste mit Milliarden Fotos aus dem Internet. Februar 2024: Ein Journalist fand RAF-Terroristin Daniela Klette in 30 Minuten – die Polizei hatte 30 Jahre gesucht. Beide Dienste gelten in der EU als illegal.
|
||||
Quelle: https://netzpolitik.org/2024/nancy-faeser-was-das-innenministerium-zur-gesichtserkennung-plant/
|
||||
|
||||
Weitere Beispiele:
|
||||
|
||||
Cambridge Analytica (2018): Facebook-Daten von 87 Mio. Nutzern wurden für politische Werbung genutzt. Ob das tatsächlich Wahlen beeinflusst hat, ist umstritten – die Firmen behaupten es gerne, Belege fehlen.
|
||||
|
||||
China Social Credit System: Punktesystem für "gutes Verhalten". Wer zu oft bei Rot geht, bekommt keinen Kredit mehr.
|
||||
|
||||
Die Frage: Wer entscheidet, was mit Technologie gemacht wird? Die Entwickler? Die Firmen? Die Politik? Wir alle?
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Von-Neumann-Architektur
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────┐
|
||||
│ CPU │
|
||||
│ ┌─────────────┐ ┌─────────────────┐ │
|
||||
│ │ Rechenwerk │ │ Steuerwerk │ │
|
||||
│ │ (ALU) │ │ (Control Unit) │ │
|
||||
│ └─────────────┘ └─────────────────┘ │
|
||||
└─────────────────────────────────────────┘
|
||||
↕ Bus-System ↕
|
||||
┌─────────────────┐ ┌──────────────────┐
|
||||
│ Speicherwerk │ │ Ein-/Ausgabewerk │
|
||||
│ (Memory) │ │ (I/O) │
|
||||
└─────────────────┘ └──────────────────┘
|
||||
```
|
||||
|
||||
<!--
|
||||
5 Grundkomponenten
|
||||
JEDER Computer folgt diesem Prinzip
|
||||
Euer Laptop, euer Handy, der Server dieser Präsentation
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #fce4ec -->
|
||||
|
||||
# Die 5 Komponenten
|
||||
# Von-Neumann-Architektur: Erklaerung
|
||||
|
||||
| Komponente | Funktion |
|
||||
|------------|----------|
|
||||
| **Rechenwerk (ALU)** | Führt Berechnungen durch |
|
||||
| **Steuerwerk** | Interpretiert Befehle, steuert Ablauf |
|
||||
| **Speicherwerk** | Speichert Programme UND Daten |
|
||||
| **Ein-/Ausgabe** | Tastatur, Bildschirm, Netzwerk |
|
||||
| **Bus-System** | Verbindet alle Komponenten |
|
||||
**Definition:** Das revolutionaere Prinzip, dass Programme und Daten im selben Speicher liegen und Programme somit wie Daten behandelt werden koennen.
|
||||
|
||||
**Wichtig:** Programme und Daten **gemeinsam** im Speicher!
|
||||
**Kernpunkte:**
|
||||
- **Stored Program Concept:** Programme sind austauschbare Daten
|
||||
- **Universalrechner:** Gleiche Hardware fuer beliebige Aufgaben
|
||||
- **Software-Flexibilitaet:** Programme koennen geladen, geaendert und geloescht werden
|
||||
|
||||
<!--
|
||||
VON-NEUMANN-ARCHITEKTUR (1945): Grundlage aller modernen Computer
|
||||
5 KOMPONENTEN:
|
||||
- ALU (Arithmetic Logic Unit): Rechnet (+, -, ×, ÷) und vergleicht (>, <, =)
|
||||
- Steuerwerk: Holt Befehle, dekodiert sie, steuert Ausführung (Fetch-Decode-Execute)
|
||||
- Speicherwerk: RAM (flüchtig) + ROM (permanent), enthält Code UND Daten
|
||||
- Ein-/Ausgabe (I/O): Tastatur, Maus, Bildschirm, Netzwerk, USB, Sensoren
|
||||
- Bus-System: Adressbus (wo), Datenbus (was), Steuerbus (wie)
|
||||
KERNPRINZIP: Stored Program Concept - Programme im selben Speicher wie Daten
|
||||
VORHER (z.B. ENIAC): Programme durch Umstecken von Kabeln, tagelange Arbeit
|
||||
NACHHER: Programme als austauschbare Daten → Flexibilität, Software-Industrie möglich
|
||||
PRÜFUNGSRELEVANT: 5 Komponenten benennen und erklären können, Stored Program Concept
|
||||
-->
|
||||
**Vorher (ENIAC):** Programmierung durch Umstecken von Kabeln → Tage fuer jedes neue Programm
|
||||
|
||||
---
|
||||
**Nachher:** Software als austauschbare Datei → Betriebssysteme, Apps, Updates moeglich
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #fce4ec -->
|
||||
|
||||
# Von-Neumann-Architektur: Bedeutung
|
||||
|
||||
**Ohne Von-Neumann-Architektur:**
|
||||
- Kein Betriebssystem
|
||||
- Keine Apps
|
||||
- Kein Multitasking
|
||||
- Keine Updates bzw. Veränderungen am Computer System
|
||||
|
||||
**Die meisten Computer** basieren auf diesem Prinzip:
|
||||
Laptop, Smartphone, Server, Spielkonsole...
|
||||
|
||||
**Ausnahme:** Mikrocontroller & DSPs nutzen oft die **Harvard-Architektur**
|
||||
(separate Speicher für Code und Daten → schneller für Echtzeitanwendungen)
|
||||
|
||||
<!--
|
||||
BEDEUTUNG VON-NEUMANN-ARCHITEKTUR:
|
||||
- Betriebssystem möglich: Lädt verschiedene Programme aus gleichem Speicher
|
||||
- Apps installierbar: Können gelöscht/installiert werden ohne Hardware-Änderung
|
||||
- Multitasking: Mehrere Programme gleichzeitig im Speicher
|
||||
- Updates: Software austauschbar, Hardware bleibt gleich
|
||||
- Universalrechner: Gleiche Hardware für Text, Spiele, Video, Wissenschaft
|
||||
HARVARD-ARCHITEKTUR (Alternative):
|
||||
- Separate Speicher für Code und Daten
|
||||
- Vorteil: Schneller (paralleler Zugriff), sicherer (Code nicht überschreibbar)
|
||||
- Nachteil: Weniger flexibel, aufwändiger
|
||||
- Anwendung: Mikrocontroller (Arduino, ESP32), DSPs, einige ARM-Chips
|
||||
MODERNE CPUs: Modified Harvard (L1-Cache getrennt für Speed, RAM gemeinsam für Flexibilität)
|
||||
PRÜFUNGSRELEVANT: Warum Von-Neumann revolutionär, Unterschied zu Harvard, Beispiele
|
||||
-->
|
||||
**Harvard-Architektur (Alternative):** Getrennter Speicher fuer Code und Daten → schneller, aber weniger flexibel (Arduino, DSPs)
|
||||
|
||||
---
|
||||
|
||||
@@ -696,19 +696,29 @@ PRÜFUNGSRELEVANT: Warum Von-Neumann revolutionär, Unterschied zu Harvard, Beis
|
||||
|
||||
---
|
||||
|
||||
# Das Problem (1960er)
|
||||
# Kalter Krieg: Das Problem der Kommunikation
|
||||
|
||||
**Kalter Krieg:**
|
||||
- Was passiert bei einem Nuklearangriff?
|
||||
- Zentrale Kommunikation → ein Treffer = alles tot
|
||||
**1957:** Sputnik-Schock → USA investiert massiv in Forschung
|
||||
→ **ARPA** (Advanced Research Projects Agency) wird gegründet
|
||||
|
||||
**DARPA** (Defense Advanced Research Projects Agency):
|
||||
→ Dezentrales Netzwerk, das Angriffe überlebt
|
||||
**Das Problem:** Zentrale Netzwerke sind verwundbar
|
||||
→ Ein Treffer = gesamte Kommunikation tot
|
||||
|
||||
**Die Idee (Paul Baran, 1964):** Packet Switching
|
||||
→ Nachrichten in kleine Pakete aufteilen
|
||||
→ Jedes Paket findet seinen eigenen Weg
|
||||
→ Kein einzelner Punkt kann das Netz zerstören
|
||||
|
||||
<!--
|
||||
ARPA (später DARPA) = Pentagon-Forschung
|
||||
Sputnik-Schock 1957 → USA investiert in Forschung
|
||||
Paul Baran (RAND Corp): Packet Switching
|
||||
Sputnik-Schock (4. Oktober 1957): Die Sowjetunion schießt den ersten künstlichen Satelliten ins All – "Sputnik 1". Die USA sind schockiert: Wenn die Sowjets Satelliten in den Orbit bringen können, können sie auch Atomwaffen über Kontinente schießen. Die gefühlte technologische Überlegenheit der USA ist über Nacht zerstört.
|
||||
|
||||
Reaktion: Präsident Eisenhower gründet 1958 ARPA (Advanced Research Projects Agency) im Pentagon. Auftrag: Die USA sollen nie wieder technologisch überrascht werden. ARPA finanziert Grundlagenforschung an Universitäten – daraus entsteht später das Internet.
|
||||
|
||||
Paul Baran (RAND Corporation, 1964): Entwickelt das Konzept des "Packet Switching". Statt einer durchgehenden Verbindung (wie beim Telefon) werden Nachrichten in kleine Pakete zerlegt. Jedes Paket wird unabhängig durchs Netz geroutet. Fällt ein Knoten aus, finden die Pakete einen anderen Weg. Das macht das Netz resilient gegen Angriffe.
|
||||
|
||||
Parallel und unabhängig: Donald Davies am britischen National Physical Laboratory entwickelt dasselbe Konzept und prägt den Begriff "Packet Switching".
|
||||
|
||||
ARPA wird später zu DARPA (Defense Advanced Research Projects Agency) umbenannt.
|
||||
-->
|
||||
|
||||
---
|
||||
@@ -779,6 +789,18 @@ Kostenlos freigegeben → darum existiert es
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||

|
||||
|
||||
<!--
|
||||
Unterseekabel-Karte: Über 400 Kabel verbinden die Kontinente.
|
||||
Quelle: TeleGeography Submarine Cable Map
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 1,3 Millionen Kilometer Unterseekabel
|
||||
|
||||
**Heute:**
|
||||
@@ -787,19 +809,28 @@ Kostenlos freigegeben → darum existiert es
|
||||
- **>400** Unterseekabel weltweit
|
||||
- Daten reisen mit **Lichtgeschwindigkeit** (Glasfaser)
|
||||
|
||||
**Das Internet ist physisch!** Keine "Cloud" ohne Kabel.
|
||||
Keine "Cloud" ohne Kabel – das Internet ist physische Infrastruktur.
|
||||
|
||||
**Five Eyes** (USA, UK, Kanada, Australien, Neuseeland):
|
||||
→ Zapfen Unterseekabel an – globale Massenüberwachung
|
||||
|
||||
<!--
|
||||
Google, Meta, Microsoft besitzen eigene Kabel
|
||||
Sabotage-Risiko (Russland, Anker)
|
||||
Latenz: Frankfurt → New York = ~80ms
|
||||
|
||||
Five Eyes: Geheimdienstallianz aus dem Zweiten Weltkrieg (UKUSA-Abkommen, 1946). Die fünf Länder teilen systematisch Überwachungsdaten. 2013 durch Edward Snowden enthüllt: NSA und GCHQ zapfen Unterseekabel direkt an (Programm "Tempora" des GCHQ, "Upstream" der NSA). Über diese Kabel läuft fast der gesamte internationale Internetverkehr – wer sie anzapft, kann potenziell alles mitlesen.
|
||||
|
||||
Erweiterte Allianzen: Nine Eyes (+Dänemark, Frankreich, Niederlande, Norwegen), Fourteen Eyes (+Deutschland, Belgien, Italien, Spanien, Schweden).
|
||||
|
||||
Deutschland ist also kein Five-Eyes-Mitglied, aber Teil der Fourteen Eyes. Der BND kooperiert eng mit der NSA (Operation Eikonal: BND leitete Daten vom Frankfurter Internetknoten DE-CIX an die NSA weiter).
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Teil 2: Bits & Bytes
|
||||
# Bits & Bytes
|
||||
## Die Sprache der Computer
|
||||
|
||||
---
|
||||
@@ -945,9 +976,9 @@ Fehlercodes: Windows zeigt diese bei Bluescreens
|
||||
|
||||
| Einheit (Bit) | Einheit (Byte) |
|
||||
|---------------|----------------|
|
||||
| 1 Kbit = 1.000 Bit | 1 KB = 1.000 Byte |
|
||||
| 1 Mbit = 1.000.000 Bit | 1 MB = 1.000.000 Byte |
|
||||
| 1 Gbit = 1 Mrd. Bit | 1 GB = 1 Mrd. Byte |
|
||||
| 1 Kbit = 1.000 Bit | 1 KB = 1.000 Byte = 8.000 Bit |
|
||||
| 1 Mbit = 1.000.000 Bit | 1 MB = 1.000.000 Byte = 8 Mbit |
|
||||
| 1 Gbit = 1 Mrd. Bit | 1 GB = 1 Mrd. Byte = 8 Gbit |
|
||||
|
||||
**Praxis:** 100 Mbit/s Internet = **12,5 MB/s** Download
|
||||
|
||||
@@ -962,35 +993,9 @@ Warum? Marketing - 100 klingt besser als 12,5
|
||||
|
||||
---
|
||||
|
||||
# Warum zeigt meine 1TB-Festplatte nur 931GB?
|
||||
|
||||
**Zwei Zählweisen:**
|
||||
|
||||
| Dezimal (Hersteller) | Binär (Computer) |
|
||||
|---------------------|------------------|
|
||||
| Kilo = 1.000 | Kibi = 1.024 (2¹⁰) |
|
||||
| Mega = 1.000.000 | Mebi = 1.048.576 (2²⁰) |
|
||||
| Giga = 1.000.000.000 | Gibi = 1.073.741.824 (2³⁰) |
|
||||
| Tera = 1.000.000.000.000 | Tebi = 1.099.511.627.776 (2⁴⁰) |
|
||||
|
||||
**Das Problem:**
|
||||
- Hersteller verkauft: 1 TB = 1.000.000.000.000 Bytes
|
||||
- Computer rechnet: 1 TiB = 1.099.511.627.776 Bytes
|
||||
- Differenz: **9,1%** → zeigt nur **931 GB**
|
||||
|
||||
<!--
|
||||
Dezimal: SI-System (Système International) - Basis 10
|
||||
Binär: IEC-Standard (International Electrotechnical Commission) - Basis 2
|
||||
Kibi/Mebi/Gibi = Kunstwörter für binäre Einheiten
|
||||
Hersteller nutzen Dezimal = klingt größer = Marketing
|
||||
Windows zeigt binär, schreibt aber "GB" statt "GiB"
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Teil 3: Eure erste Webseite
|
||||
# Unsere erste Webseite
|
||||
## HTML-Grundlagen
|
||||
|
||||
---
|
||||
@@ -1117,6 +1122,34 @@ PRÜFUNGSRELEVANT: Was gehört in <head>, Unterschied zu <body>, wichtigste Meta
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# HTML Metadaten – Vertiefung
|
||||
|
||||
Der `<head>`-Bereich enthält Informationen *über* das Dokument, nicht den sichtbaren Inhalt. Diese Metadaten steuern Browser-Verhalten, Suchmaschinen-Indexierung und Social-Media-Vorschauen.
|
||||
|
||||
**Kritische Meta-Tags:**
|
||||
|
||||
| Tag | Funktion | Beispiel |
|
||||
|-----|----------|----------|
|
||||
| `<title>` | Browser-Tab, Suchergebnis-Titel | `<title>HdM Stuttgart</title>` |
|
||||
| `<meta charset>` | Zeichenkodierung (Umlaute!) | `<meta charset="UTF-8">` |
|
||||
| `<meta viewport>` | Mobile Darstellung | `width=device-width, initial-scale=1` |
|
||||
| `<meta description>` | Suchergebnis-Snippet (max 160 Zeichen) | SEO-kritisch |
|
||||
|
||||
**Open Graph Protocol (Facebook, 2010):**
|
||||
```html
|
||||
<meta property="og:title" content="Artikel-Titel">
|
||||
<meta property="og:image" content="https://example.com/preview.jpg">
|
||||
```
|
||||
Steuert die Vorschau beim Teilen auf Facebook, LinkedIn, WhatsApp, Slack.
|
||||
|
||||
**SEO-Relevanz:** Google nutzt `<title>` und `<meta description>` für Ranking und Snippet-Anzeige. Fehlende Metadaten = schlechtere Auffindbarkeit.
|
||||
|
||||
---
|
||||
|
||||
# HTML-Tags und Attribute
|
||||
|
||||
```html
|
||||
@@ -1340,6 +1373,33 @@ PRÜFUNGSRELEVANT: Arten von Einschränkungen, Screenreader-Beispiele, WCAG
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Web-Zugänglichkeit – Vertiefung
|
||||
|
||||
**a11y** = Accessibility (a + 11 Buchstaben + y). Die WHO schätzt, dass 15% der Weltbevölkerung eine Behinderung haben – das sind über 1 Milliarde potenzielle Nutzer.
|
||||
|
||||
**Arten von Einschränkungen:**
|
||||
|
||||
| Typ | Permanent | Temporär | Situativ |
|
||||
|-----|-----------|----------|----------|
|
||||
| Visuell | Blindheit | Nach Augen-OP | Grelle Sonne |
|
||||
| Motorisch | Amputation | Gebrochener Arm | Baby auf dem Arm |
|
||||
| Auditiv | Taubheit | Ohrenentzündung | Laute Umgebung |
|
||||
| Kognitiv | Legasthenie | Müdigkeit | Ablenkung |
|
||||
|
||||
**Assistive Technologien:**
|
||||
- **Screenreader:** NVDA (Windows, kostenlos), VoiceOver (Apple, integriert), JAWS (kommerziell)
|
||||
- **Braillezeilen:** Taktile Ausgabe, ~40–80 Zeichen
|
||||
- **Switch-Geräte:** Ein-Knopf-Steuerung für motorische Einschränkungen
|
||||
- **Eye-Tracking:** Blicksteuerung für Bewegungsunfähige
|
||||
|
||||
Screenreader lesen den DOM sequenziell – semantisches HTML (`<nav>`, `<main>`, `<button>`) ermöglicht Navigation per Tastenkürzel.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
@@ -1379,6 +1439,35 @@ PRÜFUNGSRELEVANT: EAA kennen, Curb-Cut-Effekt erklären können, Business Case
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Rechtliche Anforderungen – Vertiefung
|
||||
|
||||
Der **European Accessibility Act (EAA)** trat am 28. Juni 2025 in Kraft und betrifft erstmals auch private Unternehmen – nicht nur öffentliche Stellen.
|
||||
|
||||
**Betroffene Sektoren:**
|
||||
- E-Commerce (Online-Shops)
|
||||
- Bankdienstleistungen
|
||||
- Telekommunikation
|
||||
- E-Books und E-Reader
|
||||
- Ticketing und Check-in-Terminals
|
||||
|
||||
**WCAG 2.2 – Konformitätsstufen:**
|
||||
|
||||
| Level | Anforderung | Beispiel |
|
||||
|-------|-------------|----------|
|
||||
| A | Minimum | Alt-Texte für Bilder |
|
||||
| AA | Gesetzlicher Standard | Kontrast 4,5:1, Tastaturnavigation |
|
||||
| AAA | Optimal | Gebärdensprache für Videos |
|
||||
|
||||
**Curb-Cut-Effekt:** Barrierefreiheit hilft allen. Bordsteinabsenkungen für Rollstühle nutzen auch Kinderwagen, Rollkoffer, Fahrräder. Untertitel helfen Gehörlosen, aber auch in lauten Umgebungen oder beim Sprachlernen.
|
||||
|
||||
**Sanktionen:** Bis zu 100.000 € Bußgeld bei Verstößen.
|
||||
|
||||
---
|
||||
|
||||
# WCAG: Der Standard
|
||||
|
||||
**W**eb **C**ontent **A**ccessibility **G**uidelines
|
||||
@@ -1532,6 +1621,38 @@ Echte NutzerInnen einbeziehen = Gold-Standard
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Barrierefreiheit testen – Vertiefung
|
||||
|
||||
Automatisierte Tests finden nur ~30% der Barrierefreiheitsprobleme. Der Rest erfordert manuelles Testen und idealerweise echte Nutzer mit Behinderungen.
|
||||
|
||||
**Tastatur-Test (5 Minuten, jeder kann's):**
|
||||
1. Maus weglegen, nur Tab + Enter + Pfeiltasten nutzen
|
||||
2. Fokus-Indikator immer sichtbar? (kein `outline: none;`!)
|
||||
3. Logische Reihenfolge? (nicht kreuz und quer)
|
||||
4. Alle interaktiven Elemente erreichbar?
|
||||
|
||||
**Automatisierte Tools:**
|
||||
|
||||
| Tool | Typ | Findet |
|
||||
|------|-----|--------|
|
||||
| axe DevTools | Browser-Extension | ~30% der WCAG-Verstöße |
|
||||
| WAVE | Browser-Extension | Struktur-Probleme, Kontrast |
|
||||
| Lighthouse | Chrome DevTools | Performance + Accessibility |
|
||||
| Pa11y | CLI | CI/CD-Integration |
|
||||
|
||||
**Screenreader-Kurztest:**
|
||||
- macOS: `Cmd + F5` (VoiceOver)
|
||||
- Windows: NVDA installieren (kostenlos)
|
||||
- Augen schließen, nur zuhören: Ist die Seite verständlich?
|
||||
|
||||
**Gold-Standard:** Usability-Tests mit Menschen, die Assistive Technologien täglich nutzen.
|
||||
|
||||
---
|
||||
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Grundlagen IT- und Internettechnik (223015c)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: "Kapitel 2: Netzwerke, Protokolle & CSS"
|
||||
---
|
||||
|
||||
@@ -71,6 +71,38 @@ section.aufgabe footer {
|
||||
section.glossar {
|
||||
font-size: 1.4rem;
|
||||
}
|
||||
section.erklaerung {
|
||||
font-size: 1.1rem;
|
||||
background: repeating-linear-gradient(
|
||||
135deg,
|
||||
#fce4ec,
|
||||
#fce4ec 40px,
|
||||
#fff 40px,
|
||||
#fff 80px
|
||||
) !important;
|
||||
}
|
||||
@media print {
|
||||
section.erklaerung {
|
||||
background: #fce4ec !important;
|
||||
}
|
||||
}
|
||||
section.erklaerung h1 {
|
||||
font-size: 1.5rem;
|
||||
color: #a02060;
|
||||
margin-bottom: 0.3rem;
|
||||
}
|
||||
section.erklaerung ul,
|
||||
section.erklaerung ol {
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung p {
|
||||
font-size: 1.0rem;
|
||||
line-height: 1.4;
|
||||
}
|
||||
section.erklaerung table {
|
||||
font-size: 0.9rem;
|
||||
}
|
||||
</style>
|
||||
|
||||
<!-- _class: invert -->
|
||||
@@ -86,7 +118,7 @@ section.glossar {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
|
||||
|
||||
@@ -402,6 +434,31 @@ SPEAKER NOTES:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# TCP/IP-Modell – Vertiefung
|
||||
|
||||
Das TCP/IP-Modell entstand praktisch aus dem ARPANET (1970er), im Gegensatz zum theoretischen OSI-Modell (7 Schichten, 1984). TCP/IP hat sich durchgesetzt, weil es das reale Internet beschreibt.
|
||||
|
||||
**Schicht-Aufgaben im Detail:**
|
||||
|
||||
| Schicht | Frage | Protokolle | Geräte |
|
||||
|---------|-------|------------|--------|
|
||||
| 4 Anwendung | Was will ich? | HTTP, DNS, SMTP, FTP | – (Software) |
|
||||
| 3 Transport | Kommt es an? Welches Programm? | TCP, UDP | – (Software) |
|
||||
| 2 Internet | Welcher Rechner weltweit? | IP, ICMP | Router |
|
||||
| 1 Netzzugang | Wie zum Nachbarn? | Ethernet, WLAN, PPP | Switch, Access Point |
|
||||
|
||||
**OSI vs. TCP/IP:**
|
||||
- OSI Schicht 5–7 (Session, Presentation, Application) → TCP/IP Schicht 4
|
||||
- OSI Schicht 1–2 (Physical, Data Link) → TCP/IP Schicht 1
|
||||
|
||||
**Warum Schichten?** Abstraktion. HTTP muss nicht wissen, ob Ethernet oder WLAN verwendet wird. Änderungen in einer Schicht betreffen andere nicht.
|
||||
|
||||
---
|
||||
|
||||
# Schichten verpacken Daten
|
||||
|
||||
```
|
||||
@@ -461,6 +518,33 @@ SPEAKER NOTES:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Dateneinheiten & Encapsulation – Vertiefung
|
||||
|
||||
**Encapsulation** (Verkapselung): Jede Schicht fügt ihren Header hinzu, ohne den Inhalt der oberen Schicht zu verändern.
|
||||
|
||||
**Was jeder Header enthält:**
|
||||
|
||||
| Schicht | Einheit | Header-Inhalte |
|
||||
|---------|---------|----------------|
|
||||
| Anwendung | Daten | HTTP-Header, Cookies, Content-Type |
|
||||
| Transport | Segment | Quell-/Zielport, Sequenznummer, Flags (SYN, ACK) |
|
||||
| Internet | Paket | Quell-/Ziel-IP, TTL, Protokoll (TCP=6, UDP=17) |
|
||||
| Netzzugang | Frame | Quell-/Ziel-MAC, EtherType, CRC-Prüfsumme |
|
||||
|
||||
**Overhead-Rechnung (1 Byte HTTP-Body):**
|
||||
- Ethernet: 14 + 4 Bytes (Header + Trailer)
|
||||
- IP: 20 Bytes (ohne Optionen)
|
||||
- TCP: 20 Bytes (ohne Optionen)
|
||||
- **Minimum: 58 Bytes für 1 Byte Nutzlast**
|
||||
|
||||
**Decapsulation:** Empfänger packt in umgekehrter Reihenfolge aus. Jede Schicht prüft ihren Header (z.B. CRC) und reicht Nutzdaten nach oben.
|
||||
|
||||
---
|
||||
|
||||
# Warum ist das clever?
|
||||
|
||||
**Ohne Schichten:**
|
||||
@@ -640,6 +724,34 @@ SPEAKER NOTES:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# IP, MAC, Port – Vertiefung
|
||||
|
||||
Drei Adressebenen lösen drei verschiedene Probleme:
|
||||
|
||||
**IP-Adresse (Schicht 2 – Internet):**
|
||||
- Hierarchisch aufgebaut: Netzwerk-Teil + Host-Teil
|
||||
- Router lesen nur den Netzwerk-Teil für Routing-Entscheidungen
|
||||
- IPv4: 32 Bit (z.B. 192.168.1.1), IPv6: 128 Bit
|
||||
|
||||
**MAC-Adresse (Schicht 1 – Netzzugang):**
|
||||
- 48 Bit, vom Hersteller fest vergeben (theoretisch)
|
||||
- Erste 24 Bit = OUI (Organizationally Unique Identifier) = Hersteller
|
||||
- Nur relevant für den **nächsten Hop** – wird bei jedem Router ersetzt
|
||||
- ARP (Address Resolution Protocol) übersetzt IP → MAC
|
||||
|
||||
**Port (Schicht 3 – Transport):**
|
||||
- 16 Bit → 65.535 mögliche Ports
|
||||
- Well-Known Ports (0–1023): HTTP=80, HTTPS=443, SSH=22
|
||||
- Ephemeral Ports (49152–65535): Dynamisch für Client-Verbindungen
|
||||
|
||||
**Warum ändert sich nur MAC?** IP ist das Endziel (Brief-Adresse), MAC ist der aktuelle Bote (wer trägt den Brief gerade?).
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Die Reise eines Klicks
|
||||
@@ -922,6 +1034,36 @@ SPEAKER NOTES:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# 3-Way-Handshake – Vertiefung
|
||||
|
||||
Der Handshake synchronisiert **Sequenznummern** – essenziell für TCPs Zuverlässigkeit.
|
||||
|
||||
**Warum zufällige Startwerte (ISN)?**
|
||||
- Sicherheit: Verhindert Session-Hijacking durch Raten
|
||||
- Eindeutigkeit: Unterscheidet alte von neuen Verbindungen
|
||||
- ISN = Initial Sequence Number, vom OS zufällig gewählt
|
||||
|
||||
**TCP-Flags im Handshake:**
|
||||
|
||||
| Paket | Flags | Bedeutung |
|
||||
|-------|-------|-----------|
|
||||
| 1 | SYN | Client will Verbindung, sendet seine ISN |
|
||||
| 2 | SYN+ACK | Server akzeptiert, sendet seine ISN, bestätigt Client-ISN+1 |
|
||||
| 3 | ACK | Client bestätigt Server-ISN+1 |
|
||||
|
||||
**Was passiert bei Problemen?**
|
||||
- Kein SYN-ACK → Client wiederholt SYN (Timeout)
|
||||
- SYN-Flood-Attacke: Millionen SYNs ohne ACK → Server-Ressourcen erschöpft
|
||||
- Schutz: SYN-Cookies (Server speichert keinen State bis ACK kommt)
|
||||
|
||||
**Verbindungsabbau:** 4-Way-Handshake (FIN → ACK → FIN → ACK) oder RST für sofortigen Abbruch.
|
||||
|
||||
---
|
||||
|
||||
# Nach dem Handshake
|
||||
|
||||
**Status:** Die TCP-Verbindung steht.
|
||||
@@ -1429,6 +1571,38 @@ SPEAKER NOTES:
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# TCP vs. UDP – Vertiefung
|
||||
|
||||
Beide sind Transport-Protokolle (Schicht 3), aber mit fundamental unterschiedlichen Garantien.
|
||||
|
||||
**TCP (Transmission Control Protocol):**
|
||||
- Verbindungsorientiert (Handshake vor Daten)
|
||||
- Sequenznummern → Reihenfolge garantiert
|
||||
- ACKs + Retransmission → Kein Datenverlust
|
||||
- Flow Control (Sliding Window) → Empfänger nicht überlasten
|
||||
- Congestion Control → Netzwerk nicht überlasten
|
||||
|
||||
**UDP (User Datagram Protocol):**
|
||||
- Verbindungslos (Fire-and-Forget)
|
||||
- Keine Sequenznummern, keine ACKs
|
||||
- Header nur 8 Bytes (TCP: 20+ Bytes)
|
||||
- Anwendung muss selbst für Zuverlässigkeit sorgen
|
||||
|
||||
| Anwendung | Protokoll | Grund |
|
||||
|-----------|-----------|-------|
|
||||
| HTTP/HTTPS | TCP | Vollständigkeit kritisch |
|
||||
| DNS | UDP | Kleine Pakete, schnelle Antwort |
|
||||
| Video-Streaming | UDP/QUIC | Latenz wichtiger als Perfektion |
|
||||
| Online-Gaming | UDP | Echtzeit, veraltete Daten nutzlos |
|
||||
|
||||
**QUIC:** Googles Protokoll kombiniert UDP-Geschwindigkeit mit TCP-ähnlicher Zuverlässigkeit (HTTP/3).
|
||||
|
||||
---
|
||||
|
||||
# Warum UDP bei Video-Calls?
|
||||
|
||||
**Szenario:** Ein Paket geht verloren.
|
||||
@@ -1508,6 +1682,37 @@ Das wird wichtiger, wenn ihr mit REST-APIs arbeitet.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# HTTP-Methoden – Vertiefung
|
||||
|
||||
HTTP-Methoden definieren die **Semantik** der Anfrage – was der Client vom Server erwartet.
|
||||
|
||||
**CRUD-Mapping (Create, Read, Update, Delete):**
|
||||
|
||||
| Methode | CRUD | Idempotent | Safe | Typischer Einsatz |
|
||||
|---------|------|------------|------|-------------------|
|
||||
| GET | Read | Ja | Ja | Ressource abrufen |
|
||||
| POST | Create | Nein | Nein | Formular, neue Ressource |
|
||||
| PUT | Update | Ja | Nein | Ressource vollständig ersetzen |
|
||||
| PATCH | Update | Nein | Nein | Ressource teilweise ändern |
|
||||
| DELETE | Delete | Ja | Nein | Ressource löschen |
|
||||
|
||||
**Idempotent:** Mehrfaches Ausführen hat denselben Effekt wie einmaliges (GET, PUT, DELETE).
|
||||
**Safe:** Ändert nichts am Server (nur GET, HEAD, OPTIONS).
|
||||
|
||||
**REST-Prinzip:** URLs identifizieren Ressourcen, Methoden definieren Aktionen.
|
||||
```
|
||||
GET /users/42 → Benutzer 42 abrufen
|
||||
PUT /users/42 → Benutzer 42 vollständig ersetzen
|
||||
DELETE /users/42 → Benutzer 42 löschen
|
||||
POST /users → Neuen Benutzer erstellen
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
@@ -1543,6 +1748,31 @@ Status-Codes sagen euch, was passiert ist.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# HTTP Status-Codes – Vertiefung
|
||||
|
||||
Die erste Ziffer kategorisiert die Antwort:
|
||||
|
||||
| Bereich | Kategorie | Häufige Codes |
|
||||
|---------|-----------|---------------|
|
||||
| 1xx | Informational | 100 Continue, 101 Switching Protocols |
|
||||
| 2xx | Success | 200 OK, 201 Created, 204 No Content |
|
||||
| 3xx | Redirection | 301 Moved Permanently, 302 Found, 304 Not Modified |
|
||||
| 4xx | Client Error | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found |
|
||||
| 5xx | Server Error | 500 Internal Error, 502 Bad Gateway, 503 Unavailable |
|
||||
|
||||
**Wichtige Unterscheidungen:**
|
||||
- **401 vs. 403:** 401 = nicht authentifiziert (wer bist du?), 403 = nicht autorisiert (du darfst nicht)
|
||||
- **301 vs. 302:** 301 = permanent umgezogen (Cache-fähig), 302 = temporär (nicht cachen)
|
||||
- **304 Not Modified:** Browser hat Cache, Server bestätigt: noch aktuell → spart Bandbreite
|
||||
|
||||
**API-Design:** Korrekte Status-Codes sind wichtig für Clients. `200` bei Fehler mit `{"error": "..."}` im Body ist schlechtes Design.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
@@ -1579,6 +1809,40 @@ Wie Encapsulation funktioniert.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Netzwerk-Grundlagen – Vertiefung
|
||||
|
||||
Die vier Kernkonzepte für Web-Entwickler:
|
||||
|
||||
**1. DNS-Auflösung:**
|
||||
- Browser fragt DNS-Resolver (z.B. 8.8.8.8)
|
||||
- Rekursive Abfrage: Root → TLD → Authoritative
|
||||
- Caching auf jeder Ebene (TTL = Time To Live)
|
||||
|
||||
**2. TCP-Verbindungsaufbau:**
|
||||
- 3-Way-Handshake vor jeder HTTP-Anfrage (HTTP/1.1)
|
||||
- Keep-Alive: Verbindung bleibt offen für mehrere Requests
|
||||
- HTTP/2: Multiplexing – viele Requests über eine Verbindung
|
||||
|
||||
**3. HTTP Request/Response:**
|
||||
```
|
||||
Request: Methode + URL + Header + (Body)
|
||||
Response: Status + Header + Body
|
||||
```
|
||||
|
||||
**4. Schichten & Adressen:**
|
||||
| Was bleibt gleich? | Was ändert sich? |
|
||||
|-------------------|------------------|
|
||||
| Ziel-IP | MAC-Adressen (bei jedem Hop) |
|
||||
| Ports | – |
|
||||
|
||||
**Debugging:** Browser DevTools (F12 → Network) zeigt alle Requests, Timing, Header.
|
||||
|
||||
---
|
||||
|
||||
# Werkzeuge zum Selbst-Erkunden
|
||||
|
||||
**Im Browser (F12 → Network-Tab):**
|
||||
@@ -1870,6 +2134,33 @@ Inline-Styles schlagen alles – außer !important, was ihr vermeiden solltet.
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# CSS Spezifität – Vertiefung
|
||||
|
||||
Spezifität bestimmt, welche CSS-Regel gewinnt, wenn mehrere auf dasselbe Element zutreffen. Sie wird als 4-stellige Zahl berechnet: **(Inline, IDs, Klassen, Elemente)**.
|
||||
|
||||
**Berechnung:**
|
||||
|
||||
| Selektor | Inline | IDs | Klassen | Elemente | Gesamt |
|
||||
|----------|--------|-----|---------|----------|--------|
|
||||
| `p` | 0 | 0 | 0 | 1 | 0,0,0,1 |
|
||||
| `.info` | 0 | 0 | 1 | 0 | 0,0,1,0 |
|
||||
| `p.info` | 0 | 0 | 1 | 1 | 0,0,1,1 |
|
||||
| `#header` | 0 | 1 | 0 | 0 | 0,1,0,0 |
|
||||
| `#header .nav a` | 0 | 1 | 1 | 1 | 0,1,1,1 |
|
||||
|
||||
**Wichtige Regeln:**
|
||||
- Eine Klasse (0,0,1,0) schlägt **jede Anzahl** von Elementen (0,0,0,99)
|
||||
- Eine ID schlägt jede Anzahl von Klassen
|
||||
- `!important` bricht alles → vermeiden, da schwer zu überschreiben
|
||||
|
||||
**Best Practice:** Flache Spezifität anstreben. BEM-Methodik (`.block__element--modifier`) hält Spezifität gleichmäßig niedrig.
|
||||
|
||||
---
|
||||
|
||||
# Box-Modell
|
||||
|
||||
```
|
||||
@@ -2117,6 +2408,37 @@ Das Gegenteil wäre Desktop First mit max-width – aber Mobile First ist heute
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: erklaerung -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
|
||||
# Responsive Design – Vertiefung
|
||||
|
||||
**Mobile First** ist der Standard: Basis-CSS für kleine Screens, dann Erweiterungen für größere.
|
||||
|
||||
**Breakpoints (gängige Werte):**
|
||||
|
||||
| Breakpoint | Gerät | Media Query |
|
||||
|------------|-------|-------------|
|
||||
| < 576px | Smartphone (Portrait) | Basis (kein Query) |
|
||||
| ≥ 576px | Smartphone (Landscape) | `@media (min-width: 576px)` |
|
||||
| ≥ 768px | Tablet | `@media (min-width: 768px)` |
|
||||
| ≥ 992px | Desktop | `@media (min-width: 992px)` |
|
||||
| ≥ 1200px | Large Desktop | `@media (min-width: 1200px)` |
|
||||
|
||||
**Viewport-Meta-Tag (kritisch!):**
|
||||
```html
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
```
|
||||
Ohne diesen Tag ignorieren mobile Browser eure Media Queries und rendern die Desktop-Version verkleinert.
|
||||
|
||||
**Moderne Alternativen zu Media Queries:**
|
||||
- `clamp()`: `font-size: clamp(1rem, 2vw, 2rem);`
|
||||
- Container Queries: Reagieren auf Container-Größe statt Viewport
|
||||
- CSS Grid `auto-fit`/`auto-fill`: Automatisches Responsive Layout
|
||||
|
||||
---
|
||||
|
||||
# Zusammenfassung CSS
|
||||
|
||||
**Selektoren:**
|
||||
|
||||
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Grundlagen IT- und Internettechnik (223015c)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: "Kapitel 3: Interaktivität & JavaScript"
|
||||
---
|
||||
|
||||
@@ -83,7 +83,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 45 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.4 MiB |
@@ -4,7 +4,7 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Grundlagen IT- und Internettechnik (223015c)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: "Kapitel 1: Geschichte, Grundlagen & HTML"
|
||||
---
|
||||
<style>
|
||||
@@ -93,7 +93,7 @@ section.aufgabe footer {
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Wintersemester 2025/26**
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015c/](https://librete.ch/hdm/223015c/)
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user