Als zusätzliche persönliche Meinung halte ich es für eine etwas überzogene Forderung, für den alleinigen Zweck von SDD einen IDE-Wechsel (KIRO) zu erzwingen.
Meiner persönlichen Ansicht nach wäre eher eine Form als Hilfswerkzeug angemessen, etwa als IDE-Erweiterung, zusätzliche Anwendung oder CLI.
Ich denke, es könnte auch für diejenigen, die sich dazu informieren, eine große Hilfe sein, wenn ihr Informationen zu SDD-Tools teilt, die ihr kennt.
Oh, genau. Auch die Spec-Driven-Methodik steckt aus meiner Sicht noch in den Kinderschuhen, und auch die Specs selbst scheinen noch in vielen Punkten weiterentwickelt werden zu müssen.
Der Austausch solcher Tools und Dokumente wirkt im aktuellen Zeitpunkt sehr wichtig.
In der Praxis ist die Docker-Kompatibilität nicht besonders gut, daher ist die Nutzbarkeit nicht so toll...
Ich bin wegen Rootless zu Podman gewechselt und dann wieder zu Docker zurückgekehrt.
Wie andere schon gesagt haben: Wenn man es mit Kubernetes nutzen will, kann man auch einfach containerd verwenden.
Wenn Docker Compose nicht gut funktioniert und der Vorteil in der guten Kubernetes-Kompatibilität liegt, frage ich mich, ob man dann nicht einfach direkt Kubernetes verwenden sollte.
Ich wollte es auch ausprobieren, aber da es nicht auf Anhieb lief und Port-Mappings unter 1024 auch nicht direkt möglich waren, nutze ich stattdessen einfach eine Kombination aus k3s und nerdctl zum Bauen von Images.
Ich mache zwar 775 ... und manchmal auch 776. 996 ... ehrlich gesagt glaube ich, um 6 Uhr zur Arbeit zu kommen, wäre für mich noch machbar, aber wenn ich erst um 21 Uhr Feierabend machen soll, wäre das echt zu hart.
Verglichen mit Korea, wo man „Montag, Dienstag, Mittwoch, Donnerstag, Freitag, Freitag, Freitag“ ruft ...
Hier bekommt man immerhin sogar einen Tag frei.
Ich möchte zwar schon länger irgendwann wechseln, aber als ich es früher ausprobiert habe, liefen im Gegensatz zu dem, was Entwickler oft sagen, zu viele docker compose-Projekte einfach nicht richtig ...
Das Problem ist, dass KI so etwas viel zu leicht erzeugt, aber eigentlich ist es auch das lieblos hingeworfene Feedback, das einen zermürbt, mehr noch als die KI selbst.
Es ist auch ein Problem des offenen Issue-/PR-Systems selbst.
Früher habe ich öfter mitleidig auf einzelne Haupt-Maintainer geblickt, die durch lieblose, doppelte Issues und Bugreports nach und nach erschöpft und verbittert wurden.
Heutzutage ist es schon ermüdend, dass sogar bei meinem mit eigenem Geld gekauften Windows bei jedem Update mithilfe von Dark Patterns versucht wird, einen dazu zu bringen, irgendwelche seltsamen Funktionen zu aktivieren.
Eigentlich fühlt sich die gesamte „AI“-Branche so an.
Es ist zwar kein autonomes Fahren, aber es wird behauptet, es sei autonomes Fahren,
und es ist zwar keine Intelligenz, aber es wird behauptet, es sei Intelligenz.
Studien kommen meist zu dem Ergebnis, dass ausreichend Ruhe und Schlaf sowohl dem Einzelnen als auch sogar dem Unternehmen zugutekommen,
aber die Wahrnehmung der Menschen ist offenbar immer noch in der Vergangenheit verhaftet.
Zur Einordnung: Die Arbeiter beim Bau der Pyramiden im alten Ägypten arbeiteten acht Stunden am Tag.
Bayesian Neural Network ist die Zukunft.
Als zusätzliche persönliche Meinung halte ich es für eine etwas überzogene Forderung, für den alleinigen Zweck von SDD einen IDE-Wechsel (KIRO) zu erzwingen.
Meiner persönlichen Ansicht nach wäre eher eine Form als Hilfswerkzeug angemessen, etwa als IDE-Erweiterung, zusätzliche Anwendung oder CLI.
Ich denke, es könnte auch für diejenigen, die sich dazu informieren, eine große Hilfe sein, wenn ihr Informationen zu SDD-Tools teilt, die ihr kennt.
Oh, genau. Auch die Spec-Driven-Methodik steckt aus meiner Sicht noch in den Kinderschuhen, und auch die Specs selbst scheinen noch in vielen Punkten weiterentwickelt werden zu müssen.
Der Austausch solcher Tools und Dokumente wirkt im aktuellen Zeitpunkt sehr wichtig.
Ich habe gerade ein SDD-Toolkit namens spec-kit gesehen und bin auch dort auf SDD gestoßen. https://github.com/github/spec-kit
China, Indonesien, das Vereinigte Königreich, Australien, ... das ist offenbar an mehr Orten ein Problem, als man denkt.
In der Praxis ist die Docker-Kompatibilität nicht besonders gut, daher ist die Nutzbarkeit nicht so toll...
Ich bin wegen Rootless zu Podman gewechselt und dann wieder zu Docker zurückgekehrt.
Wie andere schon gesagt haben: Wenn man es mit Kubernetes nutzen will, kann man auch einfach
containerdverwenden.Wenn Docker Compose nicht gut funktioniert und der Vorteil in der guten Kubernetes-Kompatibilität liegt, frage ich mich, ob man dann nicht einfach direkt Kubernetes verwenden sollte.
Ich wollte es auch ausprobieren, aber da es nicht auf Anhieb lief und Port-Mappings unter 1024 auch nicht direkt möglich waren, nutze ich stattdessen einfach eine Kombination aus k3s und
nerdctlzum Bauen von Images.Ich mache zwar 775 ... und manchmal auch 776. 996 ... ehrlich gesagt glaube ich, um 6 Uhr zur Arbeit zu kommen, wäre für mich noch machbar, aber wenn ich erst um 21 Uhr Feierabend machen soll, wäre das echt zu hart.
Verglichen mit Korea, wo man „Montag, Dienstag, Mittwoch, Donnerstag, Freitag, Freitag, Freitag“ ruft ...
Hier bekommt man immerhin sogar einen Tag frei.
Ich würde gern im 777-Modell arbeiten, aber wegen der Gesetze gibt es kein Unternehmen, das mich so arbeiten lässt. schnief
Ich möchte zwar schon länger irgendwann wechseln, aber als ich es früher ausprobiert habe, liefen im Gegensatz zu dem, was Entwickler oft sagen, zu viele
docker compose-Projekte einfach nicht richtig ...Das Problem ist, dass KI so etwas viel zu leicht erzeugt, aber eigentlich ist es auch das lieblos hingeworfene Feedback, das einen zermürbt, mehr noch als die KI selbst.
Es ist auch ein Problem des offenen Issue-/PR-Systems selbst.
Früher habe ich öfter mitleidig auf einzelne Haupt-Maintainer geblickt, die durch lieblose, doppelte Issues und Bugreports nach und nach erschöpft und verbittert wurden.
Heutzutage ist es schon ermüdend, dass sogar bei meinem mit eigenem Geld gekauften Windows bei jedem Update mithilfe von Dark Patterns versucht wird, einen dazu zu bringen, irgendwelche seltsamen Funktionen zu aktivieren.
"Wow, du hast wirklich den Kern getroffen."
Eigentlich fühlt sich die gesamte „AI“-Branche so an.
Es ist zwar kein autonomes Fahren, aber es wird behauptet, es sei autonomes Fahren,
und es ist zwar keine Intelligenz, aber es wird behauptet, es sei Intelligenz.
Studien kommen meist zu dem Ergebnis, dass ausreichend Ruhe und Schlaf sowohl dem Einzelnen als auch sogar dem Unternehmen zugutekommen,
aber die Wahrnehmung der Menschen ist offenbar immer noch in der Vergangenheit verhaftet.
Zur Einordnung: Die Arbeiter beim Bau der Pyramiden im alten Ägypten arbeiteten acht Stunden am Tag.
Soweit ich weiß, werden ähnlich wie bei Docker auch Netzwerkfunktionen unterstützt.
Gibt es denn noch Dinge, die noch nicht richtig funktionieren?
Könnten Sie vielleicht den Grund nennen?
Docker unterstützt doch keine Netzwerke.
Für einen 10x-Entwickler ist mit Hilfe von AI vielleicht ein Sprung auf etwa 12x möglich.