hellerKopf

Just google. Microsoft hat tolle Seiten die PowerShell erklären. Nennt sich Dokumentation. Und auch zu den LINUX shells gibt es Tutorial. teilweise auf english. PowerShell TutorialsGolem PowerShell-Tutorial Sehr guter praxisnaher Einstieg mit Übungen und Videos. Gut geeignet, wenn du systematisch lernen willst. ZAIOS PowerShell Grundlagen Kürzere, übersichtliche Tutorials zu Cmdlets, Prozessen, Diensten, Dateien usw. PowerShell Tutorial Deutsch #01 (YouTube) Einstiegsvideo mit Fokus auf Automatisierung und Administration. Bash / Linux ShellInteraktive TutorialsLearnShell.org (Deutsch) Direkt im Browser Bash-Code ausprobieren. Sehr gut für Anfänger. LearnShell.org (Englisch) Die englische Version ist oft etwas aktueller. Strukturierte Bash-Kursebin-bash.de Deutsches Tutorial speziell für Linux- und Bash-Einsteiger. Sehr verständlich aufgebaut. Linuxize Bash Scripting Fundamentals Umfangreiche moderne Tutorial-Reihe zu Bash-Skripting. The Bash Academy Sehr tiefgehender Kurs mit Fokus auf saubere Shell-Skripte und Linux-Kommandos. 8gwifi Bash Tutorial Viele praktische Beispiele und fortgeschrittene Themen wie awk, sed, Regex und Fehlerbehandlung. Und jede Menge andere Quellen, auch auf youtube.

Benutzt jemand Perfomance-Monitore oder Leistungsüberwachung an Office Plätzen? Macht Ihr Messungen, wenn User sich beschweren?

Viel RAM scheint auch keine Garantie für eine sachliche Diskussion zu sein. EOT (0x04)

Dann reden wir aber nicht vom "Office PC" für den durchschnittlichen Sachbearbeiter im Büro.

Mit geht es um eine einfache Feststellung: Mehr RAM bringt nichts, wenn die Anwendung davon keinen Gebrauch macht. Da schreien dann User nach RAM, was Ihren (vielleicht, alten) 32bit Anwendungen nichts bringen kann. Aber auch 64bit Excel läuft nicht mehr rund, wenn man Millionen Zellen mit Formeln und bedingter Formatieren im Sheet hat. Laut MS kommt Excel bei etwa 20 GB RAM Verbrauch ins Trudeln.

@SailorMoon Ernsthaft. Welche Grenzen sind das. Was geht trotz 1TB RAM nicht zufriedenstellend?

Welche Grenzen? Trotz 1 TB immer noch Tippfehler in Word?

Ist das Problem nicht die subjektive Wahrnehmung der User? Viele glauben, dass ein Kfz mit 300 PS bei 120 Km/h viel schneller ist, als eines mit nur 150 PS.

Das ist ja die eigentliche Frage, vollkommen unabhängig vom Projektthema. Die Frage ist aber die gleiche, die ich mit natürlichen Intelligenzen zu beantworten habe: „Kann man die Architektur so präzise definieren, dass die Entwickler gar nicht falsch arbeiten können?“ oder "Wie präzise muss ich die Vorgaben definieren, damit die Entwickler ausreichend gut arbeiten?" Und genau da ist dann der Unterschied. Entwickler bringen Kreativität und Erfahrung mit. Mangelnde Vorgaben werden oft durch den Entwickler ergänzt. Je nach Qualität der menschlichen Entwickler werden Fehler in Architekturvorgaben und Rules ausgeglichen. Eine KI wird das nicht machen, wenn man keine entsprechende Aufforderung formuliert.

Genau hier sehe ich auch die Herausforderung. Die hitzige Diskussion, ob KI .... ersetzen kann, vernachlässigt vollkommen den 'Maßstab' nach dem man dies beurteilen kann. Der Junior könnte mir auch alle 20 Punkte zu RAII (nur als Beispiel) aufzählen. Aber auch beim Senior bin ich nicht sicher, ob er alle Punkte berücksichtigt. Und ob KI/LLM alle seine Punkte auch berücksichtigt, muss ich aufwendig nachprüfen.

Das ist ein Punkt, wo ich gerne tiefer gehen will. Verglichen werden kann: Ich fordere die Regeln von einem frisch Ausgebildeten, einem Junior (2 Jahre BE) und einem Senior. Ich nenne die Anforderung genauso in den Anweisungen an die KI. Das Ergebnis sollte sein zu erkennen, auf welchem Level beginnt die KI besser zu sein, als der humane Mitarbeiter. Dann erfolgt das Tuning. Wie muss ich die Anforderung formulieren, damit KI den Junior ersetzt und ab wann ist die KI dem Senior gleich. Ich habe das für zwei Systeme gemacht, die sich untereinander schon geringfügig unterscheiden. Was mir die drei Arten von Mitarbeiter geantwortet hätten und welche Memory-Leak-Rate diese verursachen, versuche ich gerade vor Ort zu ermitteln. Die LLM haben auf "Nutze RAII" wie folgt reagiert: LLM1 LLM2 Übereinstimmung/Ergänzung 1. Ressourcen an Objektlebensdauer binden Ressourcen werden im Konstruktor erworben und im Destruktor freigegeben. ✅ Übereinstimmung 2. Kein manuelles new/delete im Anwendungscode Vermeide new/delete; nutze Smart Pointer oder Container. ✅ Übereinstimmung 3. Kein manuelles malloc/free in modernem C++ Kein manuelles Speichermanagement; nutze Standardbibliothek. ✅ Übereinstimmung 4. Destruktor gibt die Ressource zuverlässig frei Destruktor gibt Ressourcen frei, auch bei Ausnahmen. ✅ Übereinstimmung 5. Destruktoren dürfen keine Exceptions werfen Nicht explizit erwähnt, aber implizit durch Ausnahmesicherheit abgedeckt. ⚠️ Ergänzung: 6. Ressourcenbesitz eindeutig modellieren Konsistente Ownership-Semantik (z. B. unique_ptr, shared_ptr). ✅ Übereinstimmung 7. Rule of Zero bevorzugen Nutzung von Standardtypen, die Ressourcen selbst verwalten. ✅ Übereinstimmung 8. Falls eigene Ressourcenklasse nötig: Rule of Five beachten Eigenen RAII-Wrapper erstellen, inkl. Move-Semantik. ✅ Übereinstimmung (implizit durch Move-Semantik) 9. Kopierbarkeit bewusst entscheiden Move-Semantik für Ownership-Übertragung; Kopieren oft gelöscht. ✅ Übereinstimmung 10. Locks per RAII verwalten Nutzung von std::lock_guard, std::scoped_lock. ✅ Übereinstimmung 11. Dateien per RAII verwalten Nutzung von std::fstream oder eigenen Wrappern. ✅ Übereinstimmung 12. Transaktionen und Rollbacks absichern Nicht explizit erwähnt. ❌ Fehlend 13. Frühe Returns müssen sicher sein RAII stellt sicher, dass Ressourcen auch bei return/throw freigegeben werden. ✅ Übereinstimmung (implizit) 14. Keine „Cleanup“-Blöcke am Funktionsende Aufräumlogik gehört in Destruktoren. ✅ Übereinstimmung 15. Rohpointer nur als beobachtende Pointer verwenden Rohe Zeiger nur für Nicht-Ownership; Ownership durch RAII-Typen. ✅ Übereinstimmung 16. Scope bewusst klein halten Nicht explizit erwähnt. ⚠️ Ergänzung: Wichtiger Punkt, 17. Initialisierung vollständig und gültig machen Konstruktoren sollten Objekte in gültigen Zustand versetzen. ✅ Übereinstimmung (implizit) 18. Keine halbgültigen Objekte bevorzugen Keine init()-Methoden; Objekte sollten nach Konstruktion gültig sein. ✅ Übereinstimmung (implizit) 19. Qt-spezifisch: Ownership beachten Qt’s Eltern-Kind-Mechanismus und QScopedPointer/QSharedPointer. ✅ Übereinstimmung 20. Qt-spezifisch: Smart Pointer passend wählen Nutzung von std::unique_ptr, QSharedPointer etc. ✅ Übereinstimmung

Was erwartest du genau zu erfahren? Die Grenzen hängen davon ab, wo du die Grenzen ziehst. Ein aussagekräftiger Vergleich zwischen KI-generierter und menschlicher Softwareentwicklung erfordert: Quantitative Metriken (z. B. Entwicklungszeit, Fehlerrate, Testabdeckung) für objektive Daten. Qualitative Metriken (z. B. Code-Design, Entwicklerzufriedenheit) für subjektive Bewertungen. Langfristige Studien zur Bewertung von Wartbarkeit und Skalierbarkeit und kontextspezifische Analysen (z. B. Projektgröße, Teamdynamik, Domänenkomplexität). Mir scheinen bestimmte Beobachtungen sehr nützlich zu sein, um zu einer Bewertung zu kommen. Die Qualität der KI-Ausgabe hängt stark von den Prompt-Guardrails ab. Testet du, welche Formulierungen mehr oder weniger gut arbeiten? Wenn sowas wie Best-Practice-to-generate herauskommt, würde ich das unterstützen.

Da findet man was bei einigen IHK, z.B.: https://www.ihk.de/berlin/ausbildung/infos-fuer-ausbildungsbetriebe/der-betriebliche-ausbildungsplan-5724006

Hattest du einen Kurs zur Erlangung des AEVO Scheins? In den Schulungsunterlagen dazu ist der Prozess der Umsetzung ganz gut beschrieben

Aus den bisherigen Beiträgen erkenne ich : "Datev macht krank!"