Whiz-zarD

Wenn man Scrum falsch umsetzt, dann kommt halt murcS raus. ;) Das scheint bei euch ja der Fall zu sein. Scrum hat nicht das Ziel, dem Entwicklern Scheuklappen aufzusetzen, sondern sich mit den Kunden, in einem Dialog, auszutauschen. Das Team ist dabei interdisziplinär. Der PO soll dabei auch nicht entscheiden, wie etwas umgesetzt werden soll. Dafür ist das Team zuständig. Der PO soll nur die Prioritäten anhand des sog. business value vorgeben. Also was bringt dem Unternehmen am meisten? Er entscheidet also das was, und nicht das wie. Allerdings scheitert Scrum in den meisten Firmen, weil Scrum verlangt, dass man die Kontrolle den Teams gibt, aber gerade Manager werden dann gerne zum PO ernannt und die wollen natürlich die Kontrolle nicht abgeben und fangen dann mit Micromanagement an. Daily Meetings werden dann zu PO Status Meetings. Dazu sind sie aber nicht gedacht. Sie dienen für das Team, ihre tägliche Arbeit abzustimmen, wobei ich mich auch immer gefragt habe wozu? Ein Team kann sich auch auf kurzen Dienstwegen abstimmen. Ein Meeting ist dazu überhaupt nicht notwendig. Auch sind die Teams meist nicht interdisziplinär, sondern sind dann von anderen Teams abhängig und dadurch entsteht ein Wasserfall. Die Teams sind dann keine Scrum-Teams, sondern nur Komponenten-Teams, die Komponenten am Fließband produzieren, ohne zu wissen, für wen sie was produzieren und ob sie überhaupt das richtige produzieren. Das Video zeigt sehr gut das Problem: Why "Scrum" Isn't Making Your Organization Agile: Harmful Misconceptions About Product Owner Role Auch sind die Videos von Allen Holub sehr aufschlussreich (Er ist ein Scrum-Hasser): War is Peace, Freedom is Slavery, Ignorance is Strength, Scrum is Agile Auf Papier arbeiten wir auch nach Scrum, aber Scrum ist bei uns aus den gleichen Gründen gescheitert. Die Teams arbeiten inzwischen immer mehr nach Kanban. Wir haben auch keine interdisziplinären Teams, aber wir stimmen uns untereinander mit den anderen Teams ab, was wir brauchen und sie planen es dann bei sich ein. Die Sprints sind nahezu aufgelöst. Wir haben zwar noch Sprints, aber ob in zwei Wochen die Aufgaben fertig werden, oder in China fällt ein Sack Reis um. Das interessiert eh keinen, da wir eh nur alle drei Monate ein Release veröffentlichen. Das hat wieder eine ganze Menge Ruhe ins Unternehmen gebracht.

Keine Ahnung, wo man da wirklich anfangen soll, weil das Video doch sehr viele Mängel aufweist und Studenten und Juniors in eine falsche Richtung führt. Erstmal ist JSON nicht die Sprache, mit der moderne Systeme kommunizieren. Es ist lediglich nur eine Sprache. JSON ist nur wegen seiner relativen Kompaktheit und Lesbarkeit so verbreitet. Früher war XML sehr verbreitet (Stichwort wäre z.B. AJAX). JSON ist aber auch nur Text und daher von der Datenmenge recht groß. Bei einer UTF-8-Kodierung kann im schlimmsten Fall ein Zeichen 4 Bytes groß sein. Auch ist das Parsen von JSON nicht die schnellste Variante und je nach Anwendungsfall auch nicht optimal. Daher gibt es auch ganz andere Formate, wie z.B. Googles Protobuf, was ein komprimiertes Binärformat ist und einfach dekomprimiert als Datenblock in den Speicher gelegt werden kann, ohne dass man es Zeichen für Zeichen parsen muss. In einer Android-App, die ich mal mitentwickelt habe, haben wir uns für Protobuf entscheiden, anstatt für JSON, weil Protobuf performanter war und den Akku schonte. Das kann man momentan auch gut bei den ganzen KI-Apps sehen, wie der Akku aufgrund von JSON streaming leergelutscht wird. ChatGPT braucht z.B. mehr Akkuleistung, als Netflix. Auch finde ich den Microservice-Teil sehr problematisch. Das suggiert, als würde man heute nur noch Microservices entwickeln. Das ist aber falsch und sehr gefährlich. In den allermeisten Fällen sind Microservices wie mit Kanonen auf Spatzen schießen, da Microservices im Vergleich zu einem Monolithen, sehr viele komplexe Problematiken aufweist, die man mit einem Monolithen eben nicht hat (z.B. Orchestrieung? Was tun beim Ausfall einzelner Services? Verteilte Transaktionen? Health-Check? etc.) Alles in einem frage ich mich auch, wer die Zielgruppe sein soll? Für Anfänger und Juniors sind da viel zu viele Fachbegriffe drinnen, die auch nicht richtig eingeordnet werden. Warum wird überhaupt JSON erwähnt und warum der Schwung Richtung Microservices?

Vielleicht solltest du dich mal richtig mit der aktuellen Technik, die gerade rund um die LLMs entstehen, beschäftigen. Das ist inzwischen schon weit aus mehr, als "Schreibe mir ein Algorithmus, der X und Y kann." oder "Was macht diese Codezeile?". Es entstehen komplett automatisierte Workflows, die über die Codegenerierung weit hinaus gehen. Die werden in Zukunft ein wichtiger Bestandteil in den Firmen sein und werden alle Firmenbereiche treffen. Vor allem Entwickler müssen nicht nur wissen, wie man mit diesen Werkzeugen umgeht, sondern wie man solche Werkzeuge auch in die zu entwickelnde Software integriert. Wir z.B. experimentieren, ob wir nicht zusammen mit dem Product Owner und der KI User Stories schreiben, die dann automatisch in Azure DevOps eingetragen werden und dann ein Trigger angestoßen wird, der diese User Stories an eine KI weitergibt. Die KI soll dann die User Story entwickeln, testen und dann ein Pull Request erstellen. Wir wissen aber selber nicht, ob das klappen wird. Es kann zwar sein, dass die KI-Blase noch platzen wird und alles "back to the roots" geht, aber bis dahin sollten LLMs, Agents und weiß der Geier, was da noch alles kommen mag, ein wichtiger Bestandteil der Ausbildung werden. Ich denke, dass wir hier gerade einen Paradigmenwechsel erleben, wie wir in Zukunft mit Software umgehen werden, was tatsächlich den Gedanken der Digitalisierung näher kommt. Ich muss ehrlich sein, dass ich es auch extrem schwierig finde, wirklich kognitiv bei der Sache zu sein, wenn ich den generierten Code reviewen muss, aber das ist bei Code von Arbeitskollegen auch nicht anders und verstehen tue ich auch nicht alles, was die anderen Kollegen entwickeln. Ich muss mich also darauf verlassen, dass sie wissen, was sie da tun und Fehler machen wir alle. Und ganz ehrlich: Wer versteht denn noch seinen eigenen Code nach ein paar Wochen? Es ist doch jetzt schon so, dass die meiste Zeit bei einem Entwickler mit dem Lesen von Code drauf geht und nicht mit dem Schreiben und das wird in Zukunft noch mehr werden. Ich persönlich sehe nur die Problematik, dass ein Entwickler trotzdem das Wissen und die Erfahrung braucht, um das LLM richtig instruieren zu können, damit nicht nur das fachlich richtige rauskommt, sondern auch das technisch richtige, damit man den Code versteht. Ich habe z.B. in unserer Fachdomäne über die Jahre eine Architektur entwickelt, die immer nach Schema F läuft, die auch von unseren Junior-Entwicklern schnell verstanden werden kann, da z.B. Vererbungen nicht erlaubt sind. Sowas muss man der KI mitteilen. Das erlernt man aber erst mit Erfahrung und viel ausprobieren. Eine KI wird daher (derzeit) nicht den Entwickler ersetzen (können), aber ein Entwickler muss sich mit der KI auseinandersetzen, ansonsten wird er tatsächlich ersetzt.

Anstatt groß rumzuheulen, könntest du ja mal nennen, was für dich eine Fancy IT-Landschaft wäre. Aber ich denke, viel mehr als heiße Luft wird von dir eh nicht mehr kommen. Und offenbar haben deine Eltern bei deiner Erziehung komplett versagt...

Welchen Mehrwert versprichst du dir dadurch? Tools, wie z.B. OBS Studio braucht ihr sowieso, um mehrere Audio- und Videoquellen zusammen zuführen. Da bietet es sich auch an, einfach bei OBS Studio den API-Key für die jeweilige Plattform einzutragen und den Stream zu starten. Dann braucht die Kneipe nur noch ein internetfähges Gerät mit einem Browser. Alles andere wäre in deinem Fall Overkill. Wenn du nicht möchtest, dass andere den Stream finden können, dann kannst du z.B. auf Youtube den Stream auf Privat setzen. Dann ist der Stream nur erreichbar, wenn man dazu auch die URL kennt. Ob das auch auf Twitch funktioniert, weiß ich nicht. Die Frage ist auch, wieso sich auf eine Kneipe beschränken? Es gibt z.B. so viele Musiker auf Twitch, die Live Musik machen und nebenbei auch mit den Zuschauern reden und das gibt es alles schon vor Corona. Wenn wir schon bei japanischen Musikern sind, das Duo Moumoon gibt seit 2006 (oder so) über Youtube am Vollmond ein Livekonzert. Inzwischen aber wohl unregelmäßiger (naja, nach fast 20 Jahren verständlich). Für was?

JSON hat einen geringeren Overhead gegenüber XML, was schon mal die Dateigröße reduziert und das ist der Vorteil von JSON. JSON verzichtet auch bewusst auf die Validierung, um leichtgewichtig zu bleiben, da es eben bei JavaScript seine Anwendung fand und JavaScript nun mal schwach typisiert ist. Wer wirklich eine Validierung braucht, der sollte sich mal JSON-Schema anschauen. Mit JSON-Schema kann man auch beliebig komplexe Datenmodelle validieren. Es gehört aber nicht zum Standard, sondern ist was eigenständiges. Es wird durch eine Community entwickelt und nicht durch ein Konsortium mehrerer Firmen (wie das W3C). Auch darf man nicht vergessen, dass JSON, als Datenaustauschformat, erst seit ca. 10 Jahren wirklich im Gespräch ist. Dadurch hat es also eher historische Gründe, warum XML verwendet wird, anstatt JSON. Früher, als man im Web noch Ajax als Technik benutzte, um Daten asyncron auf einer Webseite auszutauschen, hat man ja auch noch XML verwendet.

Nein. Das ist auch nicht der Sinn eines Studiums. Bei einem Studium geht es in erster Linie und das Erlernen der Grundlagen der Informatik und wissenschaftliche Methodiken, damit man überhaupt in dem Bereich wissenschaftlich arbeiten kann. Fachinformatiker für Systemintegration ist aber ein praktischer Beruf. Hochschulen für Angewandte Wissenschaften (damals hießen sie Fachhochschulen) sind zwar praktischer veranlagt, als Universitäten, aber auch da geht es mehr um die Grundlagen der Informatik (z.B. Aufbau von Betriebssystemen, Prozessorarchitektur, Algorithmen und Datenstrukturen, etc. ) und weniger um praktisches Wissen, das ein FISI benötigt. Ein Netzwerk mit diversen Tools und Anforderungen wird man da nicht aufsetzen.

Und das ist genau das, wo ich nicht so richtig weiß, wie man das Projekt einordnen sollte. Ehrlich gesagt, sehe ich die Hauptaufgabe beim Schreiben des Systemprompts und drumherum noch zwei API-Aufrufe. Ich sehe wirklich nicht, wieso einige meinen, dass das Projekt überambitioniert wäre. Ich würde davon ausgehen, dass der Azubi schon weiß, wie die Microsoft Graph API und Jira-API funktioniert. Man würde ja nicht so ein Projekt machen, wenn man von all den Dingen keinerlei Ahnung hat und sich tagelang einarbeiten muss. Es wirkt sogar eher so, als ob man den Punkt: nur zusätzlich eingefügt hat, damit man auch irgendwas mit Datenbank gemacht hat. Allerdings muss man auch sagen, dass die Benutzung von LLMs noch in der Findungsphase stecken. Niemand weiß so recht, wofür man die LLMs wirklich benutzen kann und wofür nicht. Daher würde ich dieses Projekt auch noch als Versuch sehen, weil sich jeder erhofft, die Entwicklung zu beschleuinigen. Ob aber so ein Prototyp reicht, die 80 Stunden zu füllen, weiß icht nicht.

Ich hab Rechtschreibfehler entdeckt. Wo er überall auftritt, kann ich nicht sagen. Zumindest er mir bei den Gruppen aufgefallen:

Es hat schon seinen Grund, wieso selbst die Meta-Mitarbeiter davon nicht überzeugt sind. ;) So ein Teil will niemand freiwillig 8 Stunden am Stück tragen. Wenn man nicht von Motion Sickness betroffen ist, ist eine VR-Brille dennoch unhandlich, schwer und man schwitzt dadrunter.

https://www.govdata.de/

Ich persönlich hasse es, mit einer KI zu arbeiten. Das hat nichts mit Wert auf Nachdenken zu tun, sondern schlicht und ergreifend, weil da überwiegend Müll auskommt. Viel Müll. Ich verprobe im Unternehmen gerade das Arbeiten mit KI-Agenten und es ist zum Heulen. Bei Kompilierfehlern wird einfach der Code gelöscht. Bei Authorisierungsproblemen mit unseren internen Nuget-Feeds, will er einfach mal dubiose Powershell-Skripte runterladen und ausführen, oder die Nuget-Config wird einfach mal gelöscht. Da bringt es mir auch nichts, wenn ich vorher gefragt werde, ob ich der Aktion zustimme, wenn ich nicht weiß, was dieses Powershell-Skript macht. Einige Tools verstehen auch z.B. nicht, dass wir Windows verwenden und nicht Linux und deswegen grep nicht funktioniert. Selbst bei Trivialanwendungen, wie z.B. die Ausgabe der Fibonacci-Reihe auf der Konsole wird so viel Müll produziert. Beim Unittest wird die Logik dann einfach mal kopiert. Man muss auch der KI auch Kontext mitgeben, ansonsten macht sie, was sie will, aber bloß nicht zu viel Kontext, sonst fängt sie an zu halluzinieren. Es ist so, als würde man einen beratungsresistenten Azubi betreuen, der einfach nichts dazu lernt und in jedem neuen Chat von Vorne anfängt. Wer will sich denn wirklich sowas tagtäglich 8 Stunden lang geben? Der generierte Code ist auch so viel, sodass man kognitiv komplett überfordert ist und sich denkt: "Ach, passt schon." und es einfach abnickt. Das habe ich jetzt schon bei einigen Mitarbeitern erlebt. Auch was andere Themenbereiche außerhalb des Codes aussieht, sieht es mMn nicht besser aus. Unser PO hat angefangen, User Stories per KI zu schreiben. Das sind riesige Texte ohne Inhalt. Woher soll der Inhalt auch kommen, wenn der Prompt gerade mal aus zwei Zeilen Text besteht? Ja, die KI könnte dann automatisch User Stories im Ticketsystem anlegen, aber ich habe das Gefühl, dass die Kontrolle, ob die Tickets vollständig angelegt worden sind, die gewonnene Zeit wieder vernichtet. Man mutiert zum Kindergärtner digitaler Kleinkinder, die zu viel Macht haben und das finde ich fürchterlich. Interessant finde ich auch diese Studie, die herausfand, dass lediglich nur 250 schädliche Dokumente reichen, um ein LLM stark zu schädigen. Egal, wie groß das LLM dahinter ist. Ein Botnetz, das Github-Repositories erstellt und sich gegenseitig mit Sterchen pusht, reicht also schon völlig aus: A small number of samples can poison LLMs of any sizeAnthropic research on data-poisoning attacks in large language models

Ich verstehe nur nicht, welche Diskussion du hier wirklich anstoßen willst. Diese Diskussion führt man schon seit über 10 Jahren und es wird dazu wohl auch keine neuen Erkenntnisse mehr geben, weil schon alles gesagt wurde, was man dazu sagen kann. 2014 hat das EuGH entschieden, dass die Vorratsdatenspeicherung gegen die EU-Grundrechte verstößt. 2018 hat das EGMR (Europäische Gerichtshof für Menschenrechte) entschieden, dass die Massenüberwachung des brittischen Geheimdienstes gegen die Menschenrechtskonvention verstößt. Klar, versuchen Politiker, es immer so hinzubiegen, dass eine anlasslose Massenüberwachung nötig und wichtig sei, aber sie sind schon mehrmals damit auf die Nase gefallen, und wahrscheinlich werden sie damit auch irgendwann durchkommen. Es ist nun mal ein sehr schwieriges Thema und es ist egal auch, in welche Richtung das Urteil gefällt wird. Verlierer sind immer die, die eigentlich in Ruhe leben wollen und schon versuchen, sich an die Gesetze zu halten. Es ist nun mal so, wie die Prinzen es mal treffend formulierten: "Du musst ein Schwein sein, in dieser Welt."

Ich hab das Projekt mal nachgebaut und den Code benutzt. Bei mir funktioniert es. Inwiefern meinst du, dass du das Projekt als .exe speicherst? Beim Kompilieren wird ja schon eine .exe erstellt. Führst du noch das dotnet publish Kommando in der Kommandozeile aus, oder was genau meinst du?

Stürzt die Anwendung auch ab, wenn du die Anwendung über Visual Studio startest? Wenn ja, dann würde ich mal alle Exceptions aktivieren (Debuggen -> Fenster -> Ausnahmeeinstellungen) und dann die Anwendung starten. Unter WinForms werden nämlich einige Exceptions "geschluckt", die dann eben nicht sichtbar werden. Die Bilder haben aber keinerlei Relevanz, weil sie deinen Code nicht zeigen und wir daher nicht sehen können, was da passiert.