Compare commits
34
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 | ||
|
|
7e4d4a8a4b | ||
|
|
3fa1e1b1dc | ||
|
|
a8343c9937 | ||
|
|
b951341376 | ||
|
|
0fab5005df | ||
|
|
2755d4dee0 |
No files matched your search
@@ -32,3 +32,4 @@ hdm-internettechnik-slides/
|
||||
# Temporary files
|
||||
*.tmp
|
||||
*.bak
|
||||
.idea
|
||||
@@ -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
|
||||
@@ -4,18 +4,19 @@ This project builds presentation decks for Marp, supporting multiple courses.
|
||||
|
||||
## Courses
|
||||
|
||||
- **223015b** - Dateiformate, Schnittstellen, Speichermedien (6 Termine)
|
||||
- **223015c** - Internettechnologien (3 Termine)
|
||||
- **223015b** - Dateiformate, Schnittstellen, Speichermedien (6 Kapitel)
|
||||
- **223015c** - Internettechnologien (3 Kapitel)
|
||||
|
||||
## Agent Restrictions
|
||||
|
||||
- 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
|
||||
|
||||
Slide files in `courses/*/slides/*.md` are main content files:
|
||||
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
|
||||
@@ -23,9 +24,9 @@ Slide files in `courses/*/slides/*.md` are main content files:
|
||||
## Project Structure
|
||||
|
||||
```
|
||||
courses/
|
||||
├── 223015b/slides/ # Dateiformate course
|
||||
└── 223015c/slides/ # Internettechnik course
|
||||
slides/
|
||||
├── 223015b/ # Dateiformate course
|
||||
└── 223015c/ # Internettechnik course
|
||||
scripts/ # Shared scripts
|
||||
themes/ # Custom Marp themes
|
||||
build/ # Generated output (gitignored)
|
||||
@@ -34,34 +35,32 @@ build/ # Generated output (gitignored)
|
||||
## Build Commands
|
||||
|
||||
```bash
|
||||
make dev-b # Dev server 223015b (port 1312)
|
||||
make dev-c # Dev server 223015c (port 1313)
|
||||
make dev-b # Dev server 223015b (port 1311)
|
||||
make dev-c # Dev server 223015c (port 1312)
|
||||
make build # Build all courses
|
||||
make build-b # Build 223015b only
|
||||
make build-c # Build 223015c only
|
||||
make html # HTML only
|
||||
make pdf # PDF only
|
||||
make klausur # Extract klausur slides → slides/*/klausur.md
|
||||
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
|
||||
|
||||
### File Structure
|
||||
- Slides in `courses/<course>/slides/`
|
||||
- Assets in `courses/<course>/slides/assets/`
|
||||
- Slides in `slides/<course>/`
|
||||
- Assets in `slides/<course>/assets/`
|
||||
- Always reference images as `./assets/filename.png`
|
||||
|
||||
### Naming Conventions
|
||||
- Slide files: `YYYY-MM-DD-termin-N-topic.md`
|
||||
- Slide files: `NN-topic.md` (e.g., `01-grundlagen.md`)
|
||||
- Images: `snake_case.jpg` or `kebab-case.jpg`
|
||||
|
||||
### Markdown Style
|
||||
|
||||
@@ -1,25 +1,19 @@
|
||||
# HdM Slides - Unified Makefile
|
||||
# Supports multiple courses: 223015b (Dateiformate) and 223015c (Internettechnik)
|
||||
|
||||
.PHONY: help dev dev-b dev-c build build-b build-c pdf html clean install deploy qr optimize-images
|
||||
.PHONY: help dev dev-b dev-c build build-b build-c pdf html klausur clean install deploy qr optimize-images
|
||||
|
||||
# Course configuration
|
||||
COURSES = 223015b 223015c
|
||||
COURSE_DIR = courses
|
||||
|
||||
# Port configuration (index starts at BASE_PORT, courses increment from there)
|
||||
BASE_PORT = 1310
|
||||
INDEX_PORT = $(BASE_PORT)
|
||||
SLIDES_DIR = slides
|
||||
|
||||
# Course-specific settings
|
||||
223015b_NAME = Dateiformate, Schnittstellen, Speichermedien
|
||||
223015b_PORT = 1311
|
||||
223015b_TERMINS = 2025-12-19-termin-0-intro 2025-12-19-termin-1-grundlagen-text-audio 2026-01-09-termin-2-bild-audio-video 2026-01-23-termin-3-speichermedien-schnittstellen 2026-01-30-termin-4-distribution-apis-zukunft 2026-xx-xx-termin-5-vertiefung-offene-fragen
|
||||
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_TERMINS = 2025-12-20-termin-1-geschichte-grundlagen-html 2026-01-10-termin-2-netzwerke-protokolle-css 2026-01-24-termin-3-interaktivitaet-javascript
|
||||
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,6 +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 klausurfolien slides"
|
||||
@echo ""
|
||||
@echo "Tools:"
|
||||
@echo " make qr URL=... - Generate QR code for URL"
|
||||
@@ -62,36 +55,25 @@ 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 $(COURSE_DIR)/223015b/slides/
|
||||
|
||||
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 $(COURSE_DIR)/223015c/slides/
|
||||
|
||||
# Build functions
|
||||
define build_course
|
||||
@echo "Building $(1)..."
|
||||
@mkdir -p build/$(1)
|
||||
@cp -r $(COURSE_DIR)/$(1)/slides/assets build/$(1)/ 2>/dev/null || true
|
||||
@cp -r $(COURSE_DIR)/$(1)/slides/materials build/$(1)/ 2>/dev/null || true
|
||||
@for f in $($(1)_TERMINS); do \
|
||||
if [ -f "$(COURSE_DIR)/$(1)/slides/$$f.md" ]; then \
|
||||
@cp -r $(SLIDES_DIR)/$(1)/assets build/$(1)/ 2>/dev/null || true
|
||||
@cp -r $(SLIDES_DIR)/$(1)/materials build/$(1)/ 2>/dev/null || true
|
||||
@for f in $($(1)_KAPITEL); do \
|
||||
if [ -f "$(SLIDES_DIR)/$(1)/$$f.md" ]; then \
|
||||
echo " Building $$f..."; \
|
||||
npx @marp-team/marp-cli $(COURSE_DIR)/$(1)/slides/$$f.md -o build/$(1)/$$f.html; \
|
||||
npx @marp-team/marp-cli $(COURSE_DIR)/$(1)/slides/$$f.md --pdf --allow-local-files -o build/$(1)/$$f.pdf; \
|
||||
npx @marp-team/marp-cli $(SLIDES_DIR)/$(1)/$$f.md -o build/$(1)/$$f.html; \
|
||||
npx @marp-team/marp-cli $(SLIDES_DIR)/$(1)/$$f.md --pdf --allow-local-files -o build/$(1)/$$f.pdf; \
|
||||
fi \
|
||||
done
|
||||
@./scripts/generate-index.sh $(1) build/$(1)
|
||||
@@ -110,12 +92,12 @@ build: build-b build-c
|
||||
define html_course
|
||||
@echo "Building HTML for $(1)..."
|
||||
@mkdir -p build/$(1)
|
||||
@cp -r $(COURSE_DIR)/$(1)/slides/assets build/$(1)/ 2>/dev/null || true
|
||||
@cp -r $(COURSE_DIR)/$(1)/slides/materials build/$(1)/ 2>/dev/null || true
|
||||
@for f in $($(1)_TERMINS); do \
|
||||
if [ -f "$(COURSE_DIR)/$(1)/slides/$$f.md" ]; then \
|
||||
@cp -r $(SLIDES_DIR)/$(1)/assets build/$(1)/ 2>/dev/null || true
|
||||
@cp -r $(SLIDES_DIR)/$(1)/materials build/$(1)/ 2>/dev/null || true
|
||||
@for f in $($(1)_KAPITEL); do \
|
||||
if [ -f "$(SLIDES_DIR)/$(1)/$$f.md" ]; then \
|
||||
echo " $$f.html"; \
|
||||
npx @marp-team/marp-cli $(COURSE_DIR)/$(1)/slides/$$f.md -o build/$(1)/$$f.html; \
|
||||
npx @marp-team/marp-cli $(SLIDES_DIR)/$(1)/$$f.md -o build/$(1)/$$f.html; \
|
||||
fi \
|
||||
done
|
||||
@./scripts/generate-index.sh $(1) build/$(1)
|
||||
@@ -133,10 +115,10 @@ html: html-b html-c
|
||||
define pdf_course
|
||||
@echo "Building PDFs for $(1)..."
|
||||
@mkdir -p build/$(1)
|
||||
@for f in $($(1)_TERMINS); do \
|
||||
if [ -f "$(COURSE_DIR)/$(1)/slides/$$f.md" ]; then \
|
||||
@for f in $($(1)_KAPITEL); do \
|
||||
if [ -f "$(SLIDES_DIR)/$(1)/$$f.md" ]; then \
|
||||
echo " $$f.pdf"; \
|
||||
npx @marp-team/marp-cli $(COURSE_DIR)/$(1)/slides/$$f.md --pdf --allow-local-files -o build/$(1)/$$f.pdf; \
|
||||
npx @marp-team/marp-cli $(SLIDES_DIR)/$(1)/$$f.md --pdf --allow-local-files -o build/$(1)/$$f.pdf; \
|
||||
fi \
|
||||
done
|
||||
endef
|
||||
@@ -149,6 +131,16 @@ pdf-c: build/.exists
|
||||
|
||||
pdf: pdf-b pdf-c
|
||||
|
||||
# Klausur slide extraction
|
||||
klausur-b:
|
||||
@./scripts/extract-klausur.sh 223015b
|
||||
|
||||
klausur-c:
|
||||
@./scripts/extract-klausur.sh 223015c
|
||||
|
||||
klausur: klausur-b klausur-c
|
||||
@echo "Klausurfolien slides extracted for all courses!"
|
||||
|
||||
# QR Code generation (uses nix-shell)
|
||||
qr:
|
||||
ifndef URL
|
||||
@@ -174,9 +166,9 @@ ifndef COURSE
|
||||
@echo "Usage: make optimize-images COURSE=223015b"
|
||||
else
|
||||
@echo "Optimizing images for $(COURSE)..."
|
||||
@mkdir -p $(COURSE_DIR)/$(COURSE)/slides/assets-original
|
||||
@nix-shell -p imagemagick --run 'for img in $(COURSE_DIR)/$(COURSE)/slides/assets/*.png $(COURSE_DIR)/$(COURSE)/slides/assets/*.jpg 2>/dev/null; do \
|
||||
[ -f "$$img" ] && cp "$$img" $(COURSE_DIR)/$(COURSE)/slides/assets-original/ && \
|
||||
@mkdir -p $(SLIDES_DIR)/$(COURSE)/assets-original
|
||||
@nix-shell -p imagemagick --run 'for img in $(SLIDES_DIR)/$(COURSE)/assets/*.png $(SLIDES_DIR)/$(COURSE)/assets/*.jpg 2>/dev/null; do \
|
||||
[ -f "$$img" ] && cp "$$img" $(SLIDES_DIR)/$(COURSE)/assets-original/ && \
|
||||
magick "$$img" -resize "1920x>" -quality 85 "$$img" && echo " Optimized: $$(basename $$img)"; \
|
||||
done || true'
|
||||
@echo "Done! Originals in assets-original/"
|
||||
@@ -187,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 Termine · 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 Termine · 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
|
||||
|
||||
@@ -1,182 +1,97 @@
|
||||
# HdM Slides
|
||||
|
||||
**Modul "Technik 1"** - 1. Semester - Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart - Wintersemester 2025/26
|
||||
Presentation slides for HdM Stuttgart courses, built with [Marp](https://marp.app/).
|
||||
|
||||
---
|
||||
## Courses
|
||||
|
||||
## Kurse
|
||||
| Code | Title | Kapitel |
|
||||
|------|-------|---------|
|
||||
| 223015b | Dateiformate, Schnittstellen, Speichermedien | 6 |
|
||||
| 223015c | Internettechnologien | 3 |
|
||||
|
||||
### 223015b - Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
## Project Structure
|
||||
|
||||
| # | Datum | Thema |
|
||||
|---|-------|-------|
|
||||
| 0 | 19.12.2025 | Intro |
|
||||
| 1 | 19.12.2025 | Grundlagen, Text & Audio |
|
||||
| 2 | 09.01.2026 | Bild- & Videoformate |
|
||||
| 3 | 23.01.2026 | Speichermedien & Schnittstellen |
|
||||
| 4 | 30.01.2026 | Distribution, APIs & Zukunft |
|
||||
| 5 | TBA | Vertiefung & offene Fragen |
|
||||
|
||||
### 223015c - Internettechnologien
|
||||
|
||||
| # | Datum | Thema |
|
||||
|---|-------|-------|
|
||||
| 1 | 20.12.2025 | Geschichte, Grundlagen & HTML |
|
||||
| 2 | 10.01.2026 | Netzwerke, Protokolle & CSS |
|
||||
| 3 | 24.01.2026 | Interaktivitat & JavaScript |
|
||||
|
||||
**Dozent:** Michael Czechowski - mail@librete.ch
|
||||
|
||||
---
|
||||
|
||||
## Quick Start
|
||||
|
||||
### Mit Nix (empfohlen)
|
||||
|
||||
```bash
|
||||
# Development shell mit allen Tools
|
||||
nix develop
|
||||
|
||||
# Oder direkt QR-Code generieren
|
||||
nix run .#qr -- "https://example.com"
|
||||
nix run .#qr-slides -- 223015b
|
||||
```
|
||||
|
||||
### Ohne Nix
|
||||
|
||||
```bash
|
||||
npm install
|
||||
make dev-b # 223015b auf Port 1312
|
||||
make dev-c # 223015c auf Port 1313
|
||||
slides/
|
||||
├── 223015b/ # Dateiformate course
|
||||
│ ├── 00-intro.md
|
||||
│ ├── 01-grundlagen-text-audio.md
|
||||
│ └── ...
|
||||
└── 223015c/ # Internettechnik course
|
||||
├── 01-geschichte-grundlagen-html.md
|
||||
└── ...
|
||||
scripts/ # Build scripts
|
||||
build/ # Generated output (gitignored)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Development
|
||||
|
||||
### Dev Server starten
|
||||
|
||||
```bash
|
||||
make dev-b # 223015b (Dateiformate) - http://localhost:1312
|
||||
make dev-c # 223015c (Internettechnik) - http://localhost:1313
|
||||
# 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
|
||||
## Build
|
||||
|
||||
```bash
|
||||
make build # Alle Kurse (HTML + PDF)
|
||||
make build-b # Nur 223015b
|
||||
make build-c # Nur 223015c
|
||||
make html # Nur HTML
|
||||
make pdf # Nur PDF
|
||||
make build # Build all (HTML + PDF)
|
||||
make build-b # Build 223015b only
|
||||
make build-c # Build 223015c only
|
||||
make html # HTML only
|
||||
make pdf # PDF only
|
||||
```
|
||||
|
||||
### Deploy
|
||||
## Klausur Folien
|
||||
|
||||
Extract exam-relevant slides (marked with `<!-- _class: klausur -->`) into a single file:
|
||||
|
||||
```bash
|
||||
make deploy # Alle Kurse
|
||||
make deploy-b # Nur 223015b
|
||||
make deploy-c # Nur 223015c
|
||||
make klausur # Extract all courses
|
||||
make klausur-b # 223015b only
|
||||
make klausur-c # 223015c only
|
||||
```
|
||||
|
||||
---
|
||||
Output: `slides/<course>/klausurfolien.md`
|
||||
|
||||
The generated file includes:
|
||||
- A title slide per kapitel for orientation
|
||||
- All slides marked with `<!-- _class: klausur -->`
|
||||
|
||||
## Tools
|
||||
|
||||
### QR-Code Generator
|
||||
```bash
|
||||
make qr URL=https://example.com # Generate QR code
|
||||
make qr-slides COURSE=223015b # QR for course URL
|
||||
make optimize-images COURSE=223015b # Resize images
|
||||
```
|
||||
|
||||
## Deploy
|
||||
|
||||
```bash
|
||||
# Mit Nix
|
||||
nix run .#qr -- "https://librete.ch/hdm/223015b/"
|
||||
nix run .#qr -- "https://example.com" output.png
|
||||
|
||||
# Mit Make
|
||||
make qr URL=https://example.com
|
||||
make qr URL=https://example.com OUTPUT=my-qr.png
|
||||
|
||||
# Fur Kurse
|
||||
make qr-slides COURSE=223015b
|
||||
make deploy # Deploy all courses
|
||||
make deploy-b # Deploy 223015b only
|
||||
make deploy-c # Deploy 223015c only
|
||||
```
|
||||
|
||||
### Bilder optimieren
|
||||
## Marking Slides as Klausur-Relevant
|
||||
|
||||
```bash
|
||||
# Mit Nix
|
||||
nix run .#optimize-img -- courses/223015b/slides/assets/
|
||||
|
||||
# Mit Make
|
||||
make optimize-images COURSE=223015b
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Projektstruktur
|
||||
|
||||
```
|
||||
hdm/
|
||||
├── courses/
|
||||
│ ├── 223015b/
|
||||
│ │ └── slides/
|
||||
│ │ ├── 2025-12-19-termin-1-grundlagen-text-audio.md
|
||||
│ │ ├── assets/
|
||||
│ │ └── materials/
|
||||
│ └── 223015c/
|
||||
│ └── slides/
|
||||
│ ├── 2025-12-20-termin-1-geschichte-grundlagen-html.md
|
||||
│ └── assets/
|
||||
├── scripts/
|
||||
│ └── generate-index.sh
|
||||
├── themes/
|
||||
│ └── custom-theme.css
|
||||
├── build/ # Generated output
|
||||
├── flake.nix # Nix flake with tools
|
||||
├── Makefile
|
||||
└── package.json
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Slides erstellen
|
||||
|
||||
### Frontmatter
|
||||
|
||||
```yaml
|
||||
---
|
||||
marp: true
|
||||
theme: uncover
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
---
|
||||
```
|
||||
|
||||
### Slide-Trennung
|
||||
Add this comment block after the slide separator:
|
||||
|
||||
```markdown
|
||||
# Slide 1
|
||||
|
||||
Content
|
||||
|
||||
---
|
||||
|
||||
# Slide 2
|
||||
<!-- _class: klausur -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _footer: '' -->
|
||||
<!-- _backgroundColor: #e3f2fd -->
|
||||
|
||||
More content
|
||||
# Your Slide Title
|
||||
|
||||
Content here...
|
||||
```
|
||||
|
||||
### Bilder
|
||||
|
||||
```markdown
|
||||

|
||||
```
|
||||
|
||||
### Themes
|
||||
|
||||
Built-in: `default`, `gaia`, `uncover`
|
||||
Custom: in `themes/` Verzeichnis
|
||||
|
||||
---
|
||||
|
||||
## License
|
||||
|
||||
[CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/)
|
||||
The `klausur` class adds a visual indicator (diagonal stripes) during presentation.
|
||||
@@ -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).
|
||||
File diff suppressed because it is too large.
Load diff
File diff suppressed because it is too large.
Load diff
File diff suppressed because it is too large.
Load diff
@@ -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"],
|
||||
|
||||
+22
-75
@@ -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
|
||||
COURSE_DIR="courses"
|
||||
DEV_INDEX_DIR=".dev-index"
|
||||
SLIDES_DIR="slides"
|
||||
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 "$COURSE_DIR/223015b/slides/" &
|
||||
PID_B=$!
|
||||
|
||||
sleep 3 # Stagger starts to avoid WebSocket port collision
|
||||
|
||||
PORT=$COURSE_C_PORT npx @marp-team/marp-cli --server "$COURSE_DIR/223015c/slides/" &
|
||||
PID_C=$!
|
||||
|
||||
# Wait for any process to exit
|
||||
wait
|
||||
# Wait for process to exit
|
||||
wait
|
||||
Executable
+112
@@ -0,0 +1,112 @@
|
||||
#!/usr/bin/env bash
|
||||
# Extract klausur-relevant slides from all kapitel
|
||||
# Usage: ./extract-klausur.sh <course_id>
|
||||
# Output: slides/<course>/klausurfolien.md
|
||||
|
||||
set -e
|
||||
|
||||
COURSE="${1:-223015b}"
|
||||
SLIDES_DIR="slides/$COURSE"
|
||||
OUTPUT_FILE="$SLIDES_DIR/klausurfolien.md"
|
||||
|
||||
# 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 00-intro.md or 01-*.md file found in $SLIDES_DIR"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
echo "Extracting klausur slides for $COURSE..."
|
||||
|
||||
# Extract frontmatter and styles (everything up to first <!-- _class: line after style block)
|
||||
# This gets the YAML frontmatter + <style> block
|
||||
awk '
|
||||
BEGIN { in_frontmatter = 0; in_style = 0; done = 0 }
|
||||
/^---$/ && !in_frontmatter { in_frontmatter = 1; print; next }
|
||||
/^---$/ && in_frontmatter && !in_style { in_frontmatter = 0; print; next }
|
||||
in_frontmatter { print; next }
|
||||
/<style>/ { in_style = 1; print; next }
|
||||
/<\/style>/ { in_style = 0; print; print ""; done = 1; next }
|
||||
in_style { print; next }
|
||||
done { exit }
|
||||
' "$FIRST_KAPITEL" > "$OUTPUT_FILE"
|
||||
|
||||
# Add warning comment
|
||||
cat >> "$OUTPUT_FILE" << 'EOF'
|
||||
<!--
|
||||
╔═══════════════════════════════════════════════════════════════════╗
|
||||
║ AUTO-GENERATED FILE - DO NOT EDIT MANUALLY ║
|
||||
║ ║
|
||||
║ This file is generated by: make klausur ║
|
||||
║ Source: scripts/extract-klausur.sh ║
|
||||
║ ║
|
||||
║ To update, edit the source slides and re-run make klausur ║
|
||||
╚═══════════════════════════════════════════════════════════════════╝
|
||||
-->
|
||||
|
||||
EOF
|
||||
|
||||
# Extract and copy the cover slide (first slide after frontmatter/styles, up to first ---)
|
||||
awk '
|
||||
BEGIN { past_style = 0; in_cover = 0; printed = 0 }
|
||||
/<\/style>/ { past_style = 1; next }
|
||||
past_style && !in_cover && /^[^[:space:]]/ { in_cover = 1 }
|
||||
in_cover && /^---$/ { print "---\n"; exit }
|
||||
in_cover { print }
|
||||
' "$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 klausurfolien | sort); do
|
||||
filename=$(basename "$md_file")
|
||||
kapitel_num=$(echo "$filename" | grep -oE '^[0-9]+' | sed 's/^0*//')
|
||||
|
||||
# Skip intro (kapitel 0)
|
||||
if [[ "$kapitel_num" == "0" ]] || [[ -z "$kapitel_num" ]]; then
|
||||
continue
|
||||
fi
|
||||
|
||||
# Check if file has any klausur slides
|
||||
if ! grep -q '<!-- _class: klausur -->' "$md_file"; then
|
||||
continue
|
||||
fi
|
||||
|
||||
echo " Processing Kapitel $kapitel_num..."
|
||||
|
||||
# Extract klausur slides, hide header/footer, convert * to - bullets
|
||||
awk '
|
||||
/<!-- _class: klausur -->/ {
|
||||
in_klausur = 1
|
||||
# Add header/footer hiding
|
||||
print "<!-- _header: \"\" -->"
|
||||
print "<!-- _footer: \"\" -->"
|
||||
print ""
|
||||
next
|
||||
}
|
||||
in_klausur && /^---$/ {
|
||||
print "\n---\n"
|
||||
in_klausur = 0
|
||||
next
|
||||
}
|
||||
in_klausur {
|
||||
# Skip marp directives (we add our own)
|
||||
if (/<!-- _header:/ || /<!-- _footer:/ || /<!-- _backgroundColor:/) next
|
||||
# Convert * bullets to - bullets (avoid fragments)
|
||||
gsub(/^\* /, "- ")
|
||||
gsub(/^ \* /, " - ")
|
||||
gsub(/^ \* /, " - ")
|
||||
print
|
||||
}
|
||||
' "$md_file" >> "$OUTPUT_FILE"
|
||||
|
||||
done
|
||||
|
||||
# Remove trailing --- and empty lines
|
||||
perl -i -0777 -pe 's/\n*---\n*$/\n/' "$OUTPUT_FILE"
|
||||
|
||||
# Count slides
|
||||
slide_count=$(grep -c '^---$' "$OUTPUT_FILE" 2>/dev/null || echo "0")
|
||||
|
||||
echo ""
|
||||
echo "Generated: $OUTPUT_FILE"
|
||||
echo "Total slides: $slide_count"
|
||||
+150
-44
@@ -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,13 +102,14 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
||||
font-size: 0.875rem;
|
||||
margin-top: 0.25rem;
|
||||
}
|
||||
/* Use the .termine wrapper and add a gap between cards */
|
||||
.termine {
|
||||
margin-top: 1.5rem;
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 0.75rem;
|
||||
}
|
||||
.termin-card {
|
||||
.kapitel-card {
|
||||
position: relative;
|
||||
background: #fff;
|
||||
border-radius: 12px;
|
||||
@@ -93,32 +119,35 @@ 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 */
|
||||
}
|
||||
.termin-card:hover {
|
||||
.kapitel-card:hover {
|
||||
transform: translateY(-2px);
|
||||
box-shadow: 0 4px 12px rgba(0,0,0,0.12);
|
||||
}
|
||||
.termin-link {
|
||||
.kapitel-link {
|
||||
display: block;
|
||||
padding: 1.25rem 1.5rem;
|
||||
text-decoration: none;
|
||||
color: inherit;
|
||||
grid-column: 1;
|
||||
}
|
||||
.termin-label {
|
||||
/* 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;
|
||||
color: $ACCENT_COLOR;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.05em;
|
||||
}
|
||||
.termin-title {
|
||||
.kapitel-title {
|
||||
font-size: 1.05rem;
|
||||
font-weight: 500;
|
||||
color: #1d1d1f;
|
||||
margin: 0.15rem 0;
|
||||
}
|
||||
.termin-date {
|
||||
.kapitel-date {
|
||||
font-size: 0.8rem;
|
||||
color: #86868b;
|
||||
}
|
||||
@@ -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,11 +176,11 @@ 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 */
|
||||
.termin-link::after {
|
||||
.kapitel-link::after {
|
||||
content: '';
|
||||
position: absolute;
|
||||
inset: 0;
|
||||
@@ -184,10 +213,10 @@ cat > "$BUILD_DIR/index.html" << HEADER
|
||||
color: #86868b;
|
||||
}
|
||||
@media (max-width: 600px) {
|
||||
.termin-card {
|
||||
.kapitel-card {
|
||||
grid-template-columns: 1fr;
|
||||
}
|
||||
.termin-link {
|
||||
.kapitel-link {
|
||||
padding-bottom: 0.75rem;
|
||||
}
|
||||
.btn-slides, .btn-pdf {
|
||||
@@ -198,63 +227,140 @@ 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
|
||||
|
||||
# Generate links for each termin (sorted)
|
||||
for html in $(ls "$BUILD_DIR"/2*.html 2>/dev/null | sort); do
|
||||
# Generate links for each kapitel (sorted)
|
||||
for html in $(ls "$BUILD_DIR"/[0-9][0-9]-*.html 2>/dev/null | sort); do
|
||||
filename=$(basename "$html")
|
||||
|
||||
# Extract components from filename
|
||||
date=$(echo "$filename" | grep -oE '^[0-9]{4}-[0-9x]{2}-[0-9x]{2}')
|
||||
termin_num=$(echo "$filename" | grep -oE 'termin-[0-9]+' | grep -oE '[0-9]+')
|
||||
topic_raw=$(echo "$filename" | sed -E 's/^[0-9]{4}-[0-9x]{2}-[0-9x]{2}-termin-[0-9]+-//' | sed 's/\.html$//')
|
||||
# Extract components from filename (format: NN-topic.html)
|
||||
kapitel_num=$(echo "$filename" | grep -oE '^[0-9]+' | sed 's/^0*//')
|
||||
topic_raw=$(echo "$filename" | sed -E 's/^[0-9]+-//' | sed 's/\.html$//')
|
||||
|
||||
# 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
|
||||
|
||||
# Format date
|
||||
if [[ "$date" =~ ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ ]] && [[ ! "$date" =~ xx ]]; then
|
||||
formatted_date=$(date -d "$date" "+%d. %B %Y" 2>/dev/null || echo "$date")
|
||||
# Handle kapitel number
|
||||
if [[ "$kapitel_num" == "0" ]] || [[ -z "$kapitel_num" ]]; then
|
||||
kapitel_label="Einführung"
|
||||
else
|
||||
formatted_date="Termin folgt"
|
||||
fi
|
||||
|
||||
# Handle termin number
|
||||
if [[ "$termin_num" == "0" ]]; then
|
||||
termin_label="Einführung"
|
||||
else
|
||||
termin_label="Termin $termin_num"
|
||||
kapitel_label="Kapitel $kapitel_num"
|
||||
fi
|
||||
|
||||
pdf_filename="${filename%.html}.pdf"
|
||||
|
||||
# Check if PDF exists
|
||||
pdf_link=""
|
||||
if [[ -f "$BUILD_DIR/$pdf_filename" ]]; then
|
||||
pdf_link="<a href=\"$pdf_filename\" class=\"btn btn-pdf\">PDF</a>"
|
||||
# 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="termin-card">
|
||||
<a href="$filename" class="termin-link">
|
||||
<div class="termin-label">$termin_label</div>
|
||||
<div class="termin-title">$topic</div>
|
||||
<div class="termin-date">$formatted_date</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 klausurfolien entry if it exists
|
||||
if [[ -f "$BUILD_DIR/klausurfolien.html" ]]; then
|
||||
pdf_link=""
|
||||
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="klausurfolien.html" class="kapitel-link">
|
||||
<div class="kapitel-label">Prüfung</div>
|
||||
<div class="kapitel-title">Klausurrelevante Folien</div>
|
||||
</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">
|
||||
@@ -263,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/)
|
||||
|
||||
+190
-13
@@ -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: '' -->
|
||||
|
||||
@@ -994,13 +1099,36 @@ Visueller Kontrast: Analog vs. Digital
|
||||
### Distribution: physisch (Kauf, Verleih, Kopie)
|
||||
|
||||
* **Text**
|
||||
- Bücher, Zeitungen, Zeitschriften, Lochkarten
|
||||
- Bücher, Zeitungen, Zeitschriften, Lochkarten
|
||||
* **Bild**
|
||||
- Fotografie (Negativ, Dia, Polaroid), Mikrofilm
|
||||
- Fotografie (Negativ, Dia, Polaroid), Mikrofilm
|
||||
* **Audio:**
|
||||
- Schallplatte (Vinyl, Schellack), Tonband, Musikkassette
|
||||
- Schallplatte (Vinyl, Schellack), Tonband, Musikkassette
|
||||
* **Video:**
|
||||
- Film (35mm, Super 8), VHS, Betamax
|
||||
- Film (35mm, Super 8), VHS, Betamax
|
||||
|
||||
---
|
||||
|
||||
<!-- _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.
|
||||
|
||||
---
|
||||
|
||||
@@ -1061,13 +1189,37 @@ Paradox: Gerade die Perfektion wurde zum "Problem"
|
||||
### Distribution: Datenträger (CD, USB), Download, Streaming, P2P
|
||||
|
||||
* **Text**
|
||||
- E-Book (PDF, EPUB), Dokumente (TXT, DOCX)
|
||||
- E-Book (PDF, EPUB), Dokumente (TXT, DOCX)
|
||||
* **Bild**
|
||||
- Digitalfoto (JPEG, PNG, RAW, WebP, GIF)
|
||||
- Digitalfoto (JPEG, PNG, RAW, WebP, GIF)
|
||||
* **Audio**
|
||||
- Audiodatei (MP3, FLAC, WAV, AAC, OGG)
|
||||
- Audiodatei (MP3, FLAC, WAV, AAC, OGG)
|
||||
* **Video**
|
||||
- Videodatei (MP4, MKV, AVI, WebM)
|
||||
- Videodatei (MP4, MKV, AVI, WebM)
|
||||
|
||||
---
|
||||
|
||||
<!-- _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.
|
||||
|
||||
---
|
||||
|
||||
@@ -1079,13 +1231,38 @@ Paradox: Gerade die Perfektion wurde zum "Problem"
|
||||
# Digitale Speichermedien
|
||||
|
||||
* **Optische Speicher**
|
||||
- CD, DVD, Blu-ray
|
||||
- CD, DVD, Blu-ray
|
||||
* **Magnetische Speicher**
|
||||
- Festplatte (HDD), Magnetband (LTO)
|
||||
- Festplatte (HDD), Magnetband (LTO)
|
||||
* **Flash-Speicher**
|
||||
- SSD, USB-Stick, SD-Karte
|
||||
- SSD, USB-Stick, SD-Karte
|
||||
* **Cloud-Speicher**
|
||||
- Dropbox, Google Drive, iCloud, AWS S3
|
||||
- Dropbox, Google Drive, iCloud, AWS S3
|
||||
|
||||
---
|
||||
|
||||
<!-- _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.
|
||||
|
||||
---
|
||||
|
||||
@@ -57,11 +57,6 @@ section.klausur {
|
||||
#fff 80px
|
||||
) !important;
|
||||
}
|
||||
@media print {
|
||||
section.klausur {
|
||||
background: #e3f2fd !important;
|
||||
}
|
||||
}
|
||||
section.aufgabe {
|
||||
background: #e3f2fd !important;
|
||||
}
|
||||
@@ -729,7 +724,7 @@ Die Informationstheorie (Shannon) würde sagen: Solange alle **relevante Informa
|
||||
## Überleitung
|
||||
Lass uns visualisieren, wie diese Übergänge aussehen.
|
||||
-->
|
||||
|
||||
Medien
|
||||
---
|
||||
|
||||
# Visualisierung: Von Physisch zu Digital
|
||||
File diff suppressed because it is too large.
Load diff
+82
-3
@@ -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/)
|
||||
|
||||
@@ -97,7 +129,7 @@ Hochschule der Medien Stuttgart
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Termin 3 – 23.01.2026
|
||||
# Kapitel 3 – 23.01.2026
|
||||
## Speichermedien & Schnittstellen
|
||||
|
||||
---
|
||||
@@ -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):**
|
||||
+3
-3
@@ -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/)
|
||||
|
||||
@@ -98,7 +98,7 @@ Hochschule der Medien Stuttgart
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Termin 4 – 30.01.2026
|
||||
# Kapitel 4 – 30.01.2026
|
||||
## Distribution, APIs & Zukunft
|
||||
|
||||
---
|
||||
+3
-3
@@ -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/)
|
||||
|
||||
@@ -98,7 +98,7 @@ Hochschule der Medien Stuttgart
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Termin 5 – TBA
|
||||
# Kapitel 5 – TBA
|
||||
## Vertiefung & Offene Fragen
|
||||
|
||||
---
|
||||
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
@@ -0,0 +1,619 @@
|
||||
---
|
||||
marp: true
|
||||
theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
---
|
||||
<style>
|
||||
:root {
|
||||
--color-foreground: #1a1a2e;
|
||||
--color-highlight: #1e5f8a;
|
||||
--color-dimmed: #4a4a6a;
|
||||
}
|
||||
section.invert {
|
||||
--color-foreground: #fff;
|
||||
}
|
||||
section {
|
||||
font-size: 1.7rem;
|
||||
}
|
||||
h1 {
|
||||
color: #1e5f8a;
|
||||
}
|
||||
section.invert h1 {
|
||||
color: #fff;
|
||||
}
|
||||
h2 {
|
||||
color: #1f2937;
|
||||
}
|
||||
pre {
|
||||
background: #0f0f23;
|
||||
color: #5fb3e4;
|
||||
border-radius: 8px;
|
||||
border-left: 3px solid #1e5f8a;
|
||||
}
|
||||
pre code {
|
||||
background: transparent;
|
||||
color: inherit;
|
||||
}
|
||||
code {
|
||||
background: #1a1a2e;
|
||||
color: #5fb3e4;
|
||||
padding: 0.15em 0.4em;
|
||||
border-radius: 4px;
|
||||
}
|
||||
a {
|
||||
color: var(--color-highlight);
|
||||
}
|
||||
section.klausur {
|
||||
background: repeating-linear-gradient(
|
||||
135deg,
|
||||
#e3f2fd,
|
||||
#e3f2fd 40px,
|
||||
#fff 40px,
|
||||
#fff 80px
|
||||
) !important;
|
||||
}
|
||||
@media print {
|
||||
section.klausur {
|
||||
background: #e3f2fd !important;
|
||||
}
|
||||
}
|
||||
section.aufgabe {
|
||||
background: #e3f2fd !important;
|
||||
}
|
||||
section.aufgabe footer {
|
||||
display: none;
|
||||
}
|
||||
</style>
|
||||
|
||||
<!--
|
||||
╔═══════════════════════════════════════════════════════════════════╗
|
||||
║ AUTO-GENERATED FILE - DO NOT EDIT MANUALLY ║
|
||||
║ ║
|
||||
║ This file is generated by: make klausur ║
|
||||
║ Source: scripts/extract-klausur.sh ║
|
||||
║ ║
|
||||
║ To update, edit the source slides and re-run make klausur ║
|
||||
╚═══════════════════════════════════════════════════════════════════╝
|
||||
-->
|
||||
|
||||
<!-- _class: invert -->
|
||||
<!-- _header: '' -->
|
||||
<!-- _backgroundColor: #000 -->
|
||||
|
||||

|
||||
|
||||
# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
||||
|
||||
**223015b** · Modul "Technik 1" · 1. Semester
|
||||
Digital- und Medienwirtschaft
|
||||
Hochschule der Medien Stuttgart
|
||||
|
||||
**Sommersemester 2026**
|
||||
|
||||
[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Verlustfrei vs. Verlustbehaftet
|
||||
|
||||
| | Verlustfrei (Lossless) | Verlustbehaftet (Lossy) |
|
||||
|---|---|---|
|
||||
| **Prinzip** | **Redundanz** entfernen | **Irrelevanz** entfernen |
|
||||
| **Reversibel** | Ja (Original wiederherstellbar) | Nein (Information unwiederbringlich weg) |
|
||||
| **Reduktion** | 30-50% | 80-99% |
|
||||
| **Formate** | ZIP, PNG, FLAC, GIF | JPEG, MP3, H.264/H.265 |
|
||||
|
||||
**Faustregel:**
|
||||
- Medien für Endnutzer → Lossy oft akzeptabel
|
||||
- Quellmaterial, Code, Archive → Lossless nötig
|
||||
|
||||
<!--
|
||||
REDUNDANZ: Wiederholende Muster kompakter darstellen (z.B. "AAAA" → "4×A")
|
||||
IRRELEVANZ: Für Menschen nicht wahrnehmbar (Psychoakustik, Psychovisuell)
|
||||
|
||||
KLAUSURRELEVANT:
|
||||
- Verlustfrei = Original 1:1 wiederherstellbar
|
||||
- Verlustbehaftet = Information geht verloren, aber kaum wahrnehmbar
|
||||
- Redundanz vs. Irrelevanz ist der Kernunterschied!
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Dateneinheiten
|
||||
|
||||
| Einheit | Bytes | Potenz | Beispiel |
|
||||
|---------|------:|:------:|----------|
|
||||
| **Byte** | 1 | 10⁰ | Farbwerte eines Pixels |
|
||||
| **Kilobyte (KB)** | 1.000 | 10³ | Kleiner Programmcode |
|
||||
| **Megabyte (MB)** | 1 Million | 10⁶ | Textdokument |
|
||||
| **Gigabyte (GB)** | 1 Milliarde | 10⁹ | Kinofilm in FullHD |
|
||||
| **Terabyte (TB)** | 1 Billion | 10¹² | ~12h Video in 4K |
|
||||
| **Petabyte (PB)** | 1 Billiarde | 10¹⁵ | Netflix-Gesamtarchiv |
|
||||
| **Exabyte (EB)** | 1 Trillion | 10¹⁸ | Alle E-Mails weltweit/Tag |
|
||||
| **Zettabyte (ZB)** | 1 Trilliarde | 10²¹ | Internet-Traffic 2016 |
|
||||
|
||||
<!--
|
||||
SI-Präfixe (Dezimal): 1 KB = 1.000 Bytes
|
||||
Binär (IEC): 1 KiB = 1.024 Bytes (Kibibyte)
|
||||
Windows zeigt oft binär, sagt aber "KB" → Verwirrung!
|
||||
1 TB Festplatte = ~931 GiB nutzbar
|
||||
|
||||
Eselsbrücke: "Kilo Mega Giga Tera Peta Exa Zetta Yotta"
|
||||
→ "Komm Mit Großem Tee, Peter Exte Zettelt Yachten"
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Der digitale Wendepunkt
|
||||
|
||||
| Jahr | Analog | Digital | Digital-Anteil |
|
||||
|------|--------|---------|----------------|
|
||||
| **1986** | 2,6 EB | 0,02 EB | **1%** |
|
||||
| **2002** | — | — | **50%** (Wendepunkt) |
|
||||
| **2007** | 18 EB | 277 EB | **94%** |
|
||||
|
||||
**Perspektive:**
|
||||
- 1986: "Petabyte" war ein theoretisches Konzept
|
||||
- 2025: ~181 Zettabyte jährlich produziert
|
||||
|
||||
**Magnetband lebt:** LTO-Tapes bleiben günstigstes Archivmedium
|
||||
(AWS Glacier, Film-Archive, Rechenzentren)
|
||||
|
||||
<!--
|
||||
PRÜFUNGSRELEVANT:
|
||||
- Wendepunkt 2002
|
||||
- Speichereinheiten (KB→MB→GB→TB→PB→EB→ZB)
|
||||
- Magnetband als Archivmedium
|
||||
|
||||
QUELLE: Hilbert & López (2011): "The World's Technological Capacity to Store, Communicate, and Compute Information", Science
|
||||
|
||||
METHODIK: 60 analoge + digitale Technologien untersucht (1986-2007)
|
||||
|
||||
WENDEPUNKT 2002: Erstmals mehr digital als analog gespeichert
|
||||
|
||||
ANALOG damals: Bücher, Zeitungen, Vinyl, VHS, Filmrollen, Fotos
|
||||
|
||||
DIGITAL damals: Festplatten, CDs, DVDs, frühe Flash-Speicher
|
||||
|
||||
HEUTE: LTO-9 (2021) speichert 18 TB pro Band, ~$5/TB für Cold Storage
|
||||
|
||||
VERGLEICH: SSD ~$50/TB, HDD ~$15/TB, LTO ~$5/TB
|
||||
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Analoge Medien
|
||||
### Distribution: physisch (Kauf, Verleih, Kopie)
|
||||
|
||||
- **Text**
|
||||
- Bücher, Zeitungen, Zeitschriften, Lochkarten
|
||||
- **Bild**
|
||||
- Fotografie (Negativ, Dia, Polaroid), Mikrofilm
|
||||
- **Audio:**
|
||||
- Schallplatte (Vinyl, Schellack), Tonband, Musikkassette
|
||||
- **Video:**
|
||||
- Film (35mm, Super 8), VHS, Betamax
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Digitale Medien
|
||||
### Distribution: Datenträger (CD, USB), Download, Streaming, P2P
|
||||
|
||||
- **Text**
|
||||
- E-Book (PDF, EPUB), Dokumente (TXT, DOCX)
|
||||
- **Bild**
|
||||
- Digitalfoto (JPEG, PNG, RAW, WebP, GIF)
|
||||
- **Audio**
|
||||
- Audiodatei (MP3, FLAC, WAV, AAC, OGG)
|
||||
- **Video**
|
||||
- Videodatei (MP4, MKV, AVI, WebM)
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Digitale Speichermedien
|
||||
|
||||
- **Optische Speicher**
|
||||
- CD, DVD, Blu-ray
|
||||
- **Magnetische Speicher**
|
||||
- Festplatte (HDD), Magnetband (LTO)
|
||||
- **Flash-Speicher**
|
||||
- SSD, USB-Stick, SD-Karte
|
||||
- **Cloud-Speicher**
|
||||
- Dropbox, Google Drive, iCloud, AWS S3
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Rastergrafiken
|
||||
|
||||
**Aufbau:** Liste von Pixeln mit Farbwerten (2D-Array)
|
||||
|
||||
**Speicherbedarf (unkomprimiert):**
|
||||
Breite × Höhe × Farbtiefe (in Bytes)
|
||||
|
||||
**Beispiele:** JPEG, PNG, WebP
|
||||
|
||||
| Bits (Farbtiefe) | Farben | Anwendung |
|
||||
|-----:|-------:|-----------|
|
||||
| 1 | 2 | Schwarz/Weiß (Fax) |
|
||||
| 8 | 256 | Graustufen, GIF |
|
||||
| 24 | 16,7 Mio. | True Color (Standard) |
|
||||
| 32 | 16,7 Mio. + Alpha | Transparenz |
|
||||
|
||||
<!--
|
||||
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)
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Vektorgrafiken
|
||||
|
||||
**Speicherung als geometrische Primitive:**
|
||||
- Pfade (Bézierkurven mit Kontrollpunkten)
|
||||
- Grundformen (Rechteck, Ellipse, Polygon)
|
||||
- Text (Glyphen als Outlines)
|
||||
|
||||
**SVG-Beispiel:**
|
||||
```xml
|
||||
<circle cx="50" cy="50" r="40" fill="#ff0000"/>
|
||||
```
|
||||
|
||||
<small>SVG beschreibt WAS gezeichnet werden soll, nicht WIE jeder Pixel aussieht.</small>
|
||||
|
||||
<!--
|
||||
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)
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Die Schwächen des Auges
|
||||
|
||||
**Menschen sehen:**
|
||||
- Helligkeit besser als Farbe
|
||||
- Große Flächen besser als feine Details
|
||||
- Niedrige Frequenzen besser als hohe
|
||||
|
||||
**JPEG nutzt das aus:**
|
||||
- Farbauflösung reduzieren (Helligkeit behalten)
|
||||
- Glatte Flächen effizient speichern
|
||||
- Hohe Frequenzen (feine Details) verwerfen
|
||||
|
||||
<!--
|
||||
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)
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||

|
||||
|
||||
# JPEG Schritt 1: Farbraumkonversion
|
||||
|
||||
**RGB → Y'CbCr**
|
||||
|
||||
- **Y** = Helligkeit (Luminanz)
|
||||
- **Cb** = Blau-Gelb-Anteil (Chrominanz)
|
||||
- **Cr** = Rot-Grün-Anteil (Chrominanz)
|
||||
|
||||
**Warum?**
|
||||
Y (Helligkeit) behält volle Auflösung
|
||||
Cb/Cr (Farbe) kann reduziert werden
|
||||
|
||||
<!--
|
||||
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)
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# JPEG Schritt 6: Huffman-Coding
|
||||
|
||||
**Verlustfreie Kompression der Restwerte**
|
||||
|
||||
**Idee:** Variable Bitlänge statt fester 8 Bit
|
||||
Häufige Werte → kurze Codes
|
||||
|
||||
| Zeichen | Häufigkeit | Code |
|
||||
|---------|------------|------|
|
||||
| e | 40% | `0` (1 Bit) |
|
||||
| a | 25% | `10` (2 Bit) |
|
||||
| i | 20% | `110` (3 Bit) |
|
||||
| o | 10% | `1110` (4 Bit) |
|
||||
| u | 5% | `1111` (4 Bit) |
|
||||
|
||||
<!--
|
||||
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
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Container und Codec
|
||||
|
||||
**Container = Dateiformat (z.B. MP4)**
|
||||
Die "Box", die verschiedene Streams zusammenpackt:
|
||||
- Video-Stream
|
||||
- Audio-Stream(s)
|
||||
- Untertitel
|
||||
- Metadaten
|
||||
|
||||
**Codec = Kompressionsalgorithmus (z.B. H.264)**
|
||||
Bestimmt, WIE komprimiert wird
|
||||
|
||||
<!--
|
||||
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
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# H.264 / AVC
|
||||
|
||||
**Advanced Video Coding (2003)**
|
||||
|
||||
**Warum dominant?**
|
||||
- Exzellente Kompression (~100:1 möglich)
|
||||
- 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 Artefakte)
|
||||
|
||||
<!--
|
||||
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
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# AV1: Die offene Zukunft
|
||||
|
||||
**AV1 (2018)**
|
||||
|
||||
**Alliance for Open Media:**
|
||||
Google, Netflix, Amazon, Microsoft, Apple, Mozilla...
|
||||
|
||||
**Eigenschaften:**
|
||||
- 30% besser als H.265
|
||||
- Royalty-free, Open Source
|
||||
- 8K, HDR, hohe Frame-Rates
|
||||
|
||||
**Stand 2025:**
|
||||
YouTube, Netflix nutzen AV1 für 4K/8K
|
||||
Hardware-Encoder in aktuellen GPUs
|
||||
|
||||
<!--
|
||||
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
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Wann HDD, wann SSD?
|
||||
|
||||
| Anwendung | Empfehlung |
|
||||
|-----------|------------|
|
||||
| Betriebssystem | SSD (NVMe) |
|
||||
| Anwendungen, Spiele | SSD |
|
||||
| Video-Editing (Projekte) | SSD |
|
||||
| Foto-Archiv | HDD oder SSD |
|
||||
| Backup | HDD |
|
||||
| NAS / Server | HDD (oder Mix) |
|
||||
| Cold Storage | HDD oder Band |
|
||||
|
||||
<!--
|
||||
Die Faustregel:
|
||||
- Oft genutzt, schnell gebraucht → SSD
|
||||
- Selten genutzt, viel Kapazität → HDD
|
||||
|
||||
Viele setzen auf beides:
|
||||
Kleine SSD für System + große HDD für Archiv.
|
||||
-->
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- _header: "" -->
|
||||
<!-- _footer: "" -->
|
||||
|
||||
|
||||
# Die 3-2-1-Regel
|
||||
|
||||
**3** Kopien eurer Daten
|
||||
(Original + 2 Backups)
|
||||
|
||||
**2** verschiedene Medientypen
|
||||
(z.B. SSD + HDD, oder lokal + Cloud)
|
||||
|
||||
**1** Kopie an anderem Ort
|
||||
(Offsite: Cloud, anderes Gebäude)
|
||||
|
||||
<!--
|
||||
Herkunft: Peter Krogh, "The DAM Book" (2005)
|
||||
|
||||
Warum 3 Kopien?
|
||||
- Original kann kaputt gehen
|
||||
- Backup 1 auch
|
||||
- Backup 2 = Sicherheitspuffer
|
||||
|
||||
Warum 2 Medientypen?
|
||||
- Gleiche Medien haben gleiche Schwachstellen
|
||||
- Batch-Fehler bei HDDs derselben Charge
|
||||
|
||||
Warum 1 Offsite?
|
||||
- Brand/Wasserschaden zerstört alles vor Ort
|
||||
- Ransomware verschlüsselt angeschlossene Laufwerke
|
||||
-->
|
||||
File diff suppressed because it is too large.
Load diff
File renamed without changes.
File renamed without changes.
File renamed without changes.
+426
-305
@@ -4,8 +4,8 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Grundlagen IT- und Internettechnik (223015c)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
title: "Termin 1: Geschichte, Grundlagen & HTML"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: "Kapitel 1: Geschichte, Grundlagen & HTML"
|
||||
---
|
||||
|
||||
<style>
|
||||
@@ -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 -->
|
||||
|
||||
# Termin 1 – 20.12.2025
|
||||
## 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 -->
|
||||
|
||||
File diff suppressed because it is too large.
Load diff
+4
-4
@@ -4,8 +4,8 @@ theme: gaia
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
header: "Grundlagen IT- und Internettechnik (223015c)"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – WS 2025/26"
|
||||
title: "Termin 3: Interaktivität & JavaScript"
|
||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||
title: "Kapitel 3: Interaktivität & JavaScript"
|
||||
---
|
||||
|
||||
<style>
|
||||
@@ -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/)
|
||||
|
||||
@@ -98,7 +98,7 @@ Hochschule der Medien Stuttgart
|
||||
|
||||
<!-- _class: lead -->
|
||||
|
||||
# Termin 3 – 24.01.2026
|
||||
# Kapitel 3 – 24.01.2026
|
||||
## Interaktivität & JavaScript
|
||||
|
||||
---
|
||||
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
Loaded 100 of 142 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user