In letzter Zeit hatte ich wohl eher mehr Streit wegen Leuten, die Fans eines bestimmten Tech-Stacks oder einer Architektur sind und so reden, als würde etwas Schlimmes passieren, wenn man diesen Tech-Stack oder diese Architektur nicht einführt. Man sollte das je nach Situation anwenden; etwas, das ausnahmslos gut ist, scheint es nicht zu geben.

Verteilte Systeme wie Flink müssen für HA typischerweise 2–3 Racks vorhalten; durch die Anbindung an Kubernetes scheint HA hier sichergestellt worden zu sein. Allerdings muss man sich am Ende doch auch Gedanken über die Ressourcen der Kubernetes-Worker-Nodes machen. Da frage ich mich, ob dafür Nodes konfiguriert wurden, auf denen nur Flink läuft (bei hoher Flink-Last dürfte es wohl Probleme geben, wenn ein Worker-Node ausfällt).
Aus dieser Perspektive: Welche Vorteile hat der Einsatz von Kubernetes?

Wenn man in Flink außerdem Window-Funktionen verwendet, bleiben die Daten in dieser Zeit im Speicher, sodass SQL-Joins funktionieren. Unter Trade-off-Gesichtspunkten frage ich mich daher, ob Flink wirklich eine gute Wahl ist. Wenn ein immer größer werdendes SQL + Job mit der Zeit abstürzt, ist das schon eine enorme Sache ...

Ich überlege ebenfalls, wie man in Situationen, in denen bereits an der obersten Data Source Joins notwendig sind, das auf Application-Ebene herunterziehen und verarbeiten könnte, statt Flink zu verwenden.

Eine großartige Diskussion.

Wenn ich so darüber nachdenke, habe ich Johns philosophy of sw design auch Juniors empfohlen, aber clean code nicht wirklich.

Der Originalbeitrag wurde offenbar gelöscht. Sehen Sie ihn im Webarchiv an.

https://web.archive.org/web/20250225151227/…

Wow, ich habe gerade die GitHub-App aktiviert, die PR-Reviews macht. Ich bin gespannt, wie sie ist.

Alles gut, aber der große Nachteil ist, dass man in Korea jemanden braucht, der im Ausland lebt, wenn man ihn kaufen will...
Angeblich blockieren sie auch Weiterleitungsdienste ziemlich strikt.

Es heißt, das sei schlicht docx direkt nachempfunden.
Als MS damals aus doc docx machte, ist man ja genauso vorgegangen.

Ich denke, wichtig ist, nicht bloß blind irgendwelchen Schlagzeilen zu folgen, sondern den Kontext gut zu verstehen und entsprechend anzuwenden.

Hm … ob die Entwicklung damit wirklich typsicherer wird als mit TS, das würde mich schon interessieren.

2021-02 Modulares Notebook Framework Laptop vorgestellt
2021-07 Auslieferung des Framework Laptop gestartet und Reviews veröffentlicht
2021-10 Marktplatz für das modulare Notebook Framework veröffentlicht
2022-01 Modulares Notebook Framework veröffentlicht Open Source Firmware
2022-05 Neu aufgerüstetes Framework Laptop angekündigt
2022-09 Modulares Notebook Framework kündigt gemeinsam mit Google die Chromebook-Edition an
2024-01 Review des Framework Laptop 16

Hm, sogar Chromebooks wurden aufrüstbar gemacht, aber ausgerechnet beim Desktop sind die Upgrade-Möglichkeiten eingeschränkt.

Ich denke auch, dass es bis zum Erscheinen von Hangul 97 eine hervorragende Software war.

Vielen Dank für den guten Artikel. Ich möchte Dateien, die auf AWS erzeugt werden (zum Beispiel Berichte), gern als HWP erstellen, aber es ist schwierig, weil es an einschlägigen Referenzen mangelt. Derzeit nutze ich Word. Falls Sie hilfreiche Unterlagen oder Links als Referenz kennen, würde ich mich über einen Hinweis freuen.

Vielleicht sollte sich das Training der KI einfach auf PDFs konzentrieren, und bei Hangul wäre es nicht besser, einfach einen guten PDF-Konverter zu bauen? 😄

Im Vergleich zu MS Word oder LibreOffice war Hangeul viel praktischer, um Dokumente in genau der gewünschten Form zu erstellen. Für die Verteilung kann man sie ja als PDF bereitstellen.

Natürlich empfinde ich das wohl auch deshalb so, weil ich an Hangeul gewöhnt bin.

Soweit ich zuvor gehört hatte, ist hwpx einfach die Binärdatei von hwp, die in XML ausgeschrieben und dann als ZIP verpackt wurde.
Trotzdem lässt es sich zumindest lesen, also ...

Dateiformat von Han/Geul-Dokumenten: Ein Blick auf die Struktur des HWP-Formats

Ich denke, Selbsthilfebücher zum Coden sind für Anfänger ohne eigene Vorstellungen von Technologie oder Implementierung durchaus in Ordnung, aber je mehr Erfahrung man sammelt, desto geringer wird ihr Nutzen. Es gibt weder eine absolute Wahrheit, die zu jedem Projekt und jeder Umgebung passt, noch lassen sich allgemeine Regeln auf jede Situation anwenden. Wie bei Ratgebern in anderen allgemeinen Bereichen scheint es besser zu sein, mit etwas Abstand an solche Empfehlungen heranzugehen, nur die zur jeweiligen Situation passenden Ratschläge anzuwenden und ihnen nicht blind zu folgen.

Man darf nicht vergessen, dass Clean Code kein Ziel, sondern ein Mittel ist.

Die Entwicklung von Frontends auf Go-Basis ist effektiver als erwartet. Es gibt gute Gründe dafür, dass die Zahl der Use Cases zunimmt.