Hm, ich dachte eigentlich, dass in Golang sarama eher bevorzugt wird ...
Kafka-Clients sind aber komplizierter als man denkt – bei Broker-Ausfällen oder Ausnahmen
ist es sehr komplex, alle Fälle abzudecken ...
Früher habe ich über die Anfangsphase des Falls etwas ausführlicher geschrieben:
Auslöser des Falls war 1999 die Entscheidung, ein Renten- und Leistungszahlungssystem, dessen Zuverlässigkeit die Post angezweifelt und deshalb verworfen hatte, von der britischen Regierung dennoch für das Upgrade des bestehenden Postsystems zu verwenden, bei dem Transaktionen noch auf Papier erfasst wurden.
Dieses elektronische Kassensystem namens Horizon hatte von Anfang an viele Probleme. Es wurden Abweichungen zwischen den in Horizon erfassten Bargeldbeständen und dem tatsächlich vorhandenen Bargeld festgestellt, woraufhin verunsicherte Poststellenleiter begannen, beim Horizon-Kundencenter anzurufen.
Der Fehler „Dalmellington“ ließ den Bildschirm einfrieren, wenn Nutzer bestätigen wollten, ob Bargeld entgegengenommen worden war; in dieser Situation wurde bei jedem Drücken der Eingabetaste stillschweigend verbucht, dass das Bargeld angenommen worden sei.
Der Fehler „Calendar Square“ führte aufgrund eines Fehlers in der zugrunde liegenden Datenbank zu doppelten Transaktionen...
Was war die Ursache? Es gab wohl mehrere, aber besonders auffällig sind 1) Personalmangel, 2) der blinde Glaube an die Fehlerfreiheit von Software und 3) die Bürokratie.
Personalmangel
Laut David McDonnell, der an der Entwicklung beteiligt war, „gab es acht Leute im Entwicklungsteam; zwei waren sehr fähig, zwei waren durchschnittlich, aber man konnte mit ihnen zusammenarbeiten, und die übrigen drei bis vier waren nicht in der Lage, professionellen Code zu schreiben, sodass sie ihre Arbeit nicht richtig erledigen konnten.“
Im Kern ist das Problem gewissermaßen ein Verrenkungsakt, um innerhalb des auf Web-„Dokumenten“ basierenden HTTP-Protokolls ein app-ähnliches Web zu bauen.
Die Meinung war daher: Wenn man dafür Funktionen auf App-Ebene braucht, warum nicht ein neues Protokoll und Framework speziell für Apps schaffen?
So wie auf Smartphones keine reinen nativen Programme laufen, sondern gewissermaßen sandboxed Apps, wäre das dann eine Struktur, die auf Browser-Ebene ausgeführt wird.
Natürlich müssten Offenheit und Standardisierung dem vorausgehen, damit es nicht in Richtung ActiveX abgleitet.
Alles gut, aber wenn man das benutzt, kann man WireGuard auf dem System nicht steuern. Wenn man es unabhängig von den Tunneln verwenden möchte, muss man es in eine VM auslagern.
Auch wenn es sich um ein app-ähnliches Web handelt, denke ich, dass man sich zumindest in die Richtung des im Fazit Genannten bewegen sollte. Wenn man viel JavaScript verwendet, wird es aus Sicht des Clients schwergewichtig.
Tatsächlich fehlt es nicht einmal an Frameworks, mit denen sich das so umsetzen lässt. Schon bei Next.js ist das grob möglich, wenn man den Einsatz von Client Components auf das Notwendige minimiert. Und im Rails-Umfeld, das jemand anderes erwähnt hat, gibt es mit Hotwire (https://hotwired.dev/) ein Framework-Set für app-ähnliche Webanwendungen (Turbo, Stimulus usw.), mit dem man dem vom Autor genannten Fazit sehr nahekommen kann.
Wegen der OpenAI-Übernahme hat Claude die Bereitstellung der Lizenz für die neueste Version eingestellt, sodass man in Windsurf, wenn man Modelle der Claude-4.x-Version nutzen will, die API direkt teuer kaufen muss. Wird Claude zurückkehren?
Im Unterschied zu Korea, wo die Entwicklungskultur von der Führungsebene über Planer bis zu den Entwicklern nach unten weitergegeben wird, gibt es im Westen kein Konzept, das dem koreanischen Planer entspricht, und Entwickler sind dort teilweise aktiv an der Produktplanung beteiligt. Auch westliche PMs entsprechen den koreanischen Planern nicht vollständig, so wie ein Cover Letter und ein Selbstvorstellungsschreiben keine völlig deckungsgleichen Konzepte sind. Natürlich gibt es auch bei Spielen, die stark von kreativen Projekten geprägt sind und bei denen Spaß und Gameplay wichtig sind, im Westen im Vergleich zu Asien flachere Hierarchien, aber auch dort verläuft die Entscheidungsweitergabe vom Director zu den Entwicklern.
Das ist viel zu beängstigend.
Dass böswillig festgehaltene Aufzeichnungen
Erinnerungen und Erfahrungen verdrängen, zu Beweisen werden
und uns bedrohen können.
Es gibt doch gar nicht so viele Browser, die die Leute verwenden, aber warum gibt es dann so viele Frameworks? Wäre es nicht am besten, wenn die Unternehmen, die die Browser betreiben, ein optimales Framework entwickeln und es gemeinsam mitverwalten würden? Wie lange soll dieser Teufelskreis noch weitergehen?
Diejenigen, die so etwas empfehlen, sollten sich schämen.
Für Menschen, die bereits in einer dystopischen Zensurgesellschaft leben, ist das eine reichlich verfrühte Debatte.
Hm, ich dachte eigentlich, dass in Golang
saramaeher bevorzugt wird ...Kafka-Clients sind aber komplizierter als man denkt – bei Broker-Ausfällen oder Ausnahmen
ist es sehr komplex, alle Fälle abzudecken ...
Früher habe ich über die Anfangsphase des Falls etwas ausführlicher geschrieben:
Auslöser des Falls war 1999 die Entscheidung, ein Renten- und Leistungszahlungssystem, dessen Zuverlässigkeit die Post angezweifelt und deshalb verworfen hatte, von der britischen Regierung dennoch für das Upgrade des bestehenden Postsystems zu verwenden, bei dem Transaktionen noch auf Papier erfasst wurden.
Dieses elektronische Kassensystem namens Horizon hatte von Anfang an viele Probleme. Es wurden Abweichungen zwischen den in Horizon erfassten Bargeldbeständen und dem tatsächlich vorhandenen Bargeld festgestellt, woraufhin verunsicherte Poststellenleiter begannen, beim Horizon-Kundencenter anzurufen.
Der Fehler „Dalmellington“ ließ den Bildschirm einfrieren, wenn Nutzer bestätigen wollten, ob Bargeld entgegengenommen worden war; in dieser Situation wurde bei jedem Drücken der Eingabetaste stillschweigend verbucht, dass das Bargeld angenommen worden sei.
Der Fehler „Calendar Square“ führte aufgrund eines Fehlers in der zugrunde liegenden Datenbank zu doppelten Transaktionen...
Was war die Ursache? Es gab wohl mehrere, aber besonders auffällig sind 1) Personalmangel, 2) der blinde Glaube an die Fehlerfreiheit von Software und 3) die Bürokratie.
Laut David McDonnell, der an der Entwicklung beteiligt war, „gab es acht Leute im Entwicklungsteam; zwei waren sehr fähig, zwei waren durchschnittlich, aber man konnte mit ihnen zusammenarbeiten, und die übrigen drei bis vier waren nicht in der Lage, professionellen Code zu schreiben, sodass sie ihre Arbeit nicht richtig erledigen konnten.“
https://x.com/KayKiwoongKim/status/1825209040575873330
Im Kern ist das Problem gewissermaßen ein Verrenkungsakt, um innerhalb des auf Web-„Dokumenten“ basierenden HTTP-Protokolls ein app-ähnliches Web zu bauen.
Die Meinung war daher: Wenn man dafür Funktionen auf App-Ebene braucht, warum nicht ein neues Protokoll und Framework speziell für Apps schaffen?
So wie auf Smartphones keine reinen nativen Programme laufen, sondern gewissermaßen sandboxed Apps, wäre das dann eine Struktur, die auf Browser-Ebene ausgeführt wird.
Natürlich müssten Offenheit und Standardisierung dem vorausgehen, damit es nicht in Richtung ActiveX abgleitet.
Die Meinungen zu „langweilig“ sind ja interessant, haha. Wenn man es anders ausdrücken wollte, was wäre gut? Vorhersehbar, gewöhnlich?
Ist das nicht eine völlig andere Geschichte als das, worüber Sie sprechen?
Ich bin mir nicht ganz sicher, was Sie mit dem letzten Punkt meinen, den Sie als idealistische Plattform bezeichnet haben.
Letztlich geht es doch um die Zeit, als man native Programme herunterladen und dort ActiveX verwenden musste.
Die Übersetzung von
boringmit „langweilig“ trifft die eigentliche Bedeutung leider überhaupt nicht.boringnessist eine der Go-Designphilosophien.Werdet ihr schon wieder reingelegt~
Zum bequemen Einsatz per Klick ist es wohl nicht ganz einfach.
Grok 4 ist jetzt das führende KI-Modell
Simon Willisons Rezension zu Grok 4
Grok durchsucht, was Elon Musk auf X zum Israel-Palästina-Konflikt sagt
Alles gut, aber wenn man das benutzt, kann man WireGuard auf dem System nicht steuern. Wenn man es unabhängig von den Tunneln verwenden möchte, muss man es in eine VM auslagern.
Auch wenn es sich um ein app-ähnliches Web handelt, denke ich, dass man sich zumindest in die Richtung des im Fazit Genannten bewegen sollte. Wenn man viel JavaScript verwendet, wird es aus Sicht des Clients schwergewichtig.
Tatsächlich fehlt es nicht einmal an Frameworks, mit denen sich das so umsetzen lässt. Schon bei Next.js ist das grob möglich, wenn man den Einsatz von Client Components auf das Notwendige minimiert. Und im Rails-Umfeld, das jemand anderes erwähnt hat, gibt es mit Hotwire (https://hotwired.dev/) ein Framework-Set für app-ähnliche Webanwendungen (Turbo, Stimulus usw.), mit dem man dem vom Autor genannten Fazit sehr nahekommen kann.
Wegen der OpenAI-Übernahme hat Claude die Bereitstellung der Lizenz für die neueste Version eingestellt, sodass man in Windsurf, wenn man Modelle der Claude-4.x-Version nutzen will, die API direkt teuer kaufen muss. Wird Claude zurückkehren?
Im Unterschied zu Korea, wo die Entwicklungskultur von der Führungsebene über Planer bis zu den Entwicklern nach unten weitergegeben wird, gibt es im Westen kein Konzept, das dem koreanischen Planer entspricht, und Entwickler sind dort teilweise aktiv an der Produktplanung beteiligt. Auch westliche PMs entsprechen den koreanischen Planern nicht vollständig, so wie ein Cover Letter und ein Selbstvorstellungsschreiben keine völlig deckungsgleichen Konzepte sind. Natürlich gibt es auch bei Spielen, die stark von kreativen Projekten geprägt sind und bei denen Spaß und Gameplay wichtig sind, im Westen im Vergleich zu Asien flachere Hierarchien, aber auch dort verläuft die Entscheidungsweitergabe vom Director zu den Entwicklern.
Die angestrebten Entwicklungsphilosophien unterscheiden sich eben stark voneinander.........
Offenbar ist auch KI nicht fair.
Das ist viel zu beängstigend.
Dass böswillig festgehaltene Aufzeichnungen
Erinnerungen und Erfahrungen verdrängen, zu Beweisen werden
und uns bedrohen können.
Es gibt doch gar nicht so viele Browser, die die Leute verwenden, aber warum gibt es dann so viele Frameworks? Wäre es nicht am besten, wenn die Unternehmen, die die Browser betreiben, ein optimales Framework entwickeln und es gemeinsam mitverwalten würden? Wie lange soll dieser Teufelskreis noch weitergehen?