Blockierungen in der Praxis ohne Formalin blockieren

Das Blockdiagramm ist ein visuelles Werkzeug, das dazu beiträgt, einen komplexen Algorithmus in eine verständliche und strukturierte Folge von Aktionen zu verwandeln. Von der Programmierung bis zum Geschäftsprozessmanagement dienen sie als universelle Sprache für die Visualisierung, Analyse und Optimierung der komplexesten Systeme.

Stellen Sie sich eine Karte vor, auf der anstelle von Straßen Logik und anstelle von Städten – Aktionen ist. Dies ist ein Blockdiagramm-ein unverzichtbares Werkzeug für die Navigation in den verwirrendsten Prozessen.

Beispiel 1: vereinfachtes Spielstartschema
Um das Arbeitsprinzip zu verstehen, präsentieren wir ein einfaches Spielstartschema.

Dieses Schema zeigt das perfekte Skript, wenn alles ohne Fehler passiert. Aber im wirklichen Leben ist alles viel komplizierter.

Beispiel 2: Erweitertes Schema zum Starten des Spiels mit Datenladen
Moderne Spiele erfordern häufig eine Internetverbindung, um Benutzerdaten, Speichern oder Einstellungen herunterzuladen. Fügen wir diese Schritte zu unserem Schema hinzu.

Dieses Schema ist bereits realistischer, aber was wird passieren, wenn etwas schief geht?

Wie war es: Ein Spiel, das mit dem Verlust des Internets “brach”

“brach”

Zu Beginn des Projekts konnten Entwickler nicht alle möglichen Szenarien berücksichtigen. Zum Beispiel konzentrierten sie sich auf die Hauptlogik des Spiels und überlegten nicht, was passieren würde, wenn der Spieler eine Internetverbindung hat.

In einer solchen Situation würde das Blockdiagramm ihres Codes so aussehen:

In diesem Fall hat das Spiel in der Phase des Wartens auf Daten, die sie aufgrund des Fehlens einer Verbindung nicht erhielt, anstatt einen Fehler oder korrekt zu schließen. Dies führte zum “schwarzen Bildschirm” und zum Einfrieren der Anwendung.

Wie es wurde: Korrektur bei Benutzerbeschwerden

Nach zahlreichen Beschwerden der Benutzer über das Schwebewesen erkannte das Entwicklerteam, dass wir den Fehler korrigieren mussten. Sie nahmen Änderungen am Code vor, indem sie eine Fehlerverarbeitungseinheit hinzufügen, mit der die Anwendung auf den mangelnden Verbindungsmangel korrekt reagiert.

So sieht das korrigierte Blockdiagramm aus, in dem beide Szenarien berücksichtigt werden:

Dank dieses Ansatzes informiert das Spiel jetzt den Benutzer über das Problem und kann in einigen Fällen sogar in den Offline -Modus gehen, sodass Sie das Spiel fortsetzen können. Dies ist ein gutes Beispiel dafür, warum Blockdiagramme so wichtig sind.

Unsicheres Verhalten

Das Hängen und Fehler sind nur ein Beispiel für unvorhersehbare Verhalten des Programms. Bei der Programmierung gibt es ein Konzept von unsicherem Verhalten (undefiniertes Verhalten) – Dies ist eine Situation, in der der Standard der Sprache nicht beschreibt, wie sich das Programm in einem bestimmten Fall verhalten sollte.

Dies kann zu allem führen: vom zufälligen „Müll“ beim Rückzug zum Versagen des Programms oder sogar der schwerwiegenden Sicherheitsanfälligkeit. Unbestimmte Verhalten tritt häufig bei der Arbeit mit dem Gedächtnis auf, zum Beispiel mit Zeilen in der Sprache von C.

Ein Beispiel aus der Sprache c:

Stellen Sie sich vor, der Entwickler hat die Linie in den Puffer kopiert, aber vergessen, das Ende des Null -Symbols (\ 0`) zu addieren, das das Ende der Linie markiert.

So sieht der Code aus:

#include 

int main() {
char buffer[5];
char* my_string = "hello";

memcpy(buffer, my_string, 5);

printf("%s\n", buffer);
return 0;
}

Erwartete Ergebnis: “Hallo”
Das wirkliche Ergebnis ist unvorhersehbar.

Warum passiert das? Die Funktion “printf`) mit dem Spezifizierer%S` erwartet, dass die Linie mit einem Nullsymbol endet. Wenn er nicht ist, wird sie die Erinnerung außerhalb des hervorgehobenen Puffers weiter lesen.

Hier ist das Blockdiagramm dieses Prozesses mit zwei möglichen Ergebnissen:

Dies ist ein klares Beispiel dafür, warum die Blockdiagramme so wichtig sind: Sie lassen den Entwickler nicht nur über die ideale Ausführungsweise nachdenken, sondern auch über alle möglichen Fehler, einschließlich solcher Probleme mit niedrigem Niveau, was das Endprodukt viel stabiler und zuverlässiger macht.

Pixel perfekt: Mythos oder Realität in der Ära der Deklarativität?

In der Welt der Schnittstellenentwicklung gibt es ein gemeinsames Konzept – “Pixel perfekt in der Lodge” . Es impliziert die genaueste Reproduktion der Konstruktionsmaschine auf das kleinste Pixel. Lange Zeit war es ein Goldstandard, insbesondere in der Ära eines klassischen Webdesigns. Mit der Ankunft der deklarativen Meile und dem schnellen Wachstum der Vielfalt der Geräte wird das Prinzip von “Pixel Perfect” jedoch zunehmend kurzlebiger. Versuchen wir herauszufinden, warum.

Imperial Wysiwyg vs. Deklarativer Code: Was ist der Unterschied?

Traditionell wurden viele Schnittstellen, insbesondere der Desktop, mit imperativen Ansätzen oder wysiwyg (was Sie sehen, was Sie erhalten) von Herausgebern erstellt. In solchen Tools manipuliert der Designer oder Entwickler direkt mit Elementen und platziert sie auf Leinwand mit Genauigkeit zum Pixel. Es ähnelt der Arbeit mit einem Grafikeditor – Sie sehen, wie Ihr Element aussieht, und Sie können es definitiv positionieren. In diesem Fall war die Leistung von “Pixel Perfect” ein sehr reales Ziel.

Die moderne Entwicklung basiert jedoch zunehmend auf deklarativen Meilen . Dies bedeutet, dass Sie dem Computer nicht sagen, dass er “diese Schaltfläche hier einstellen”, sondern beschreiben, was Sie bekommen möchten. Anstatt die spezifischen Koordinaten des Elements anzuzeigen, beschreiben Sie beispielsweise seine Eigenschaften: “Diese Schaltfläche sollte rot sein, 16px -Eindringlinge von allen Seiten haben und in der Mitte des Behälters stehen.” Freiimvorki wie React, Vue, Swiftui oder Jetpack komponieren nur dieses Prinzip.

Warum “Pixel Perfect” für viele Geräte nicht mit einer deklarativen Meile funktioniert

Stellen Sie sich vor, Sie erstellen eine Anwendung, die auf dem iPhone 15 Pro Max, Samsung Galaxy Fold, iPad Pro und einer 4K -Auflösung gleich gut aussehen soll. Jedes dieser Geräte hat eine unterschiedliche Bildschirmauflösung, Pixeldichte, Parteien und physische Größen.

Wenn Sie den deklarativen Ansatz verwenden, entscheidet das System selbst unter Berücksichtigung aller Parameter, wie Sie Ihre beschriebene Schnittstelle auf einem bestimmten Gerät anzeigen. Sie setzen die Regeln und Abhängigkeiten, nicht die harten Koordinaten.

* Anpassungsfähigkeit und Reaktionsfähigkeit: Das Hauptziel der deklarativen Meilen ist es, adaptive und reaktionsschnelle Schnittstellen zu erstellen. Dies bedeutet, dass sich Ihre Schnittstelle automatisch an die Größe und Ausrichtung des Bildschirms anpassen sollte, ohne die Lesbarkeit zu brechen und aufrechtzuerhalten. Wenn wir auf jedem Gerät „Pixel Perfect“ beantragen möchten, müssten wir unzählige Optionen für dieselbe Schnittstelle erstellen, was die Vorteile des deklarativen Ansatzes vollständig ausgleichen wird.
* Pixeldichte (DPI/PPI): Die Geräte haben eine unterschiedliche Pixeldichte. Das gleiche Element mit der Größe von 100 “virtuellen” Pixeln auf einem Gerät mit hoher Dichte sieht viel kleiner aus als bei einem Gerät mit niedrigem Dichte, wenn Sie die Skalierung nicht berücksichtigen. Deklarative Rahmenbedingungen werden von physischen Pixeln abstrahiert und arbeiten mit logischen Einheiten.
* Dynamischer Inhalt: Inhalt in modernen Anwendungen ist häufig dynamisch – sein Volumen und die Struktur können variieren. Wenn wir hart auf die Pixel gerissen würden, würde jede Änderung des Textes oder des Bildes zum “Zusammenbruch” des Layouts führen.
* Verschiedene Plattformen: Zusätzlich zur Vielfalt der Geräte gibt es verschiedene Betriebssysteme (iOS, Android, Web, Desktop). Jede Plattform verfügt über eigene Design, Standardsteuerungen und Schriftarten. Ein Versuch, auf allen Plattformen eine absolut identische Pixel -Perfect -Schnittstelle zu erstellen, würde zu einem unnatürlichen Typ und einer schlechten Benutzererfahrung führen.

Die alten Ansätze gingen nicht verschwunden, sondern entwickelten

Es ist wichtig zu verstehen, dass der Ansatz zu Schnittstellen keine binäre Wahl zwischen “imperativ” und “deklarativ” ist. Historisch gesehen gab es für jede Plattform ihre eigenen Werkzeuge und Ansätze zur Erstellung von Schnittstellen.

* Native Schnittstellendateien: Für iOS waren es XIB/Storyboards für Android-XML-Markierungsdateien. Diese Dateien sind ein Pixel-Perfekt-Wysiwyg-Layout, das dann wie im Editor im Radio angezeigt wird. Dieser Ansatz ist nirgendwo verschwunden und entwickelt sich weiter und integriert sich in moderne deklarative Rahmen. Zum Beispiel haben Swiftui in Apple und Jetpack in Android auf dem Pfad eines rein deklarativen Code eingeschaltet, behielten gleichzeitig die Möglichkeit, ein klassisches Layout zu verwenden.
* Hybridlösungen: häufig in realen Projekten wird eine Kombination von Ansätzen verwendet. Beispielsweise kann die Grundstruktur der Anwendung deklarativ implementiert werden und für spezifische, die eine genaue Positionierung von Elementen, niedrigere Level, imperative Methoden erfordern, oder native Komponenten, die unter Berücksichtigung der Einzelheiten der Plattform entwickelt wurden.

vom Monolith zur Anpassungsfähigkeit: Wie die Entwicklung von Geräten eine deklarative Meile bildete

Die Welt der digitalen Schnittstellen hat sich in den letzten Jahrzehnten enorme Veränderungen verändert. Von stationären Computern mit festen Genehmigungen kamen wir in die Ära des exponentiellen Wachstums der Vielfalt der Benutzergeräte . Heute sollten unsere Bewerbungen gleich gut funktionieren:

* Smartphones aller Formfaktoren und Bildschirmgrößen.
* Tablets mit ihren einzigartigen Ausrichtungsmodi und einem getrennten Bildschirm.
* Laptops und Desktops mit verschiedenen Monitorengenehmigungen.
* TVS- und Medienzentren , kontrolliert remote. Es ist bemerkenswert, dass selbst für Fernseher, deren Bemerkungen mit einem Minimum an Schaltflächen, oder umgekehrt, mit vielen Funktionen überladen sind, selbst für die Schnittstellen so einfach sind, dass der Code keine spezifische Anpassung für diese Eingabefunktionen benötigt. Die Schnittstelle sollte “als ob für sich selbst” funktionieren, ohne eine zusätzliche Beschreibung des “Wie” mit einer bestimmten Fernbedienung zu interagieren.
* Smart Watches und Wearable -Geräte mit minimalistischen Bildschirmen.
* Virtual Reality Helme (VR) , die einen völlig neuen Ansatz für eine räumliche Schnittstelle erfordern.
* Augmented Reality Device Devices (AR) , die Informationen über die reale Welt anwenden.
* Automobilinformationen und Unterhaltungssysteme .
* Und sogar Haushaltsgeräte : Von Kühlschränken mit sensorischen Bildschirmen und Waschmaschinen mit interaktiven Displays bis hin zu intelligenten Öfen und Systemen des Smart House.

Jedes dieser Geräte verfügt über eigene Merkmale: physikalische Dimensionen, Parteienverhältnisse, Pixeldichte, Eingabemethoden (Touchscreen, Maus, Controller, Gesten, Stimmbefehle) und vor allem die Feinheiten der Benutzerumgebung . Beispielsweise erfordert ein VR Shlesh ein tiefes Eintauchen und eine Smartphone-schnelle und intuitive Arbeit unterwegs, während die Kühlschrankschnittstelle für schnelle Navigation genauso einfach und groß sein sollte.

Klassischer Ansatz: Die Belastung für die Unterstützung einzelner Schnittstellen

In der Zeit der Dominanz von Desktops und der ersten mobilen Geräte war das übliche Geschäft die Erstellung und Unterstützung von von einzelnen Schnittstellendateien oder sogar eines vollständig separaten Schnittstellencodes für jede Plattform .

* Die Entwicklung unter iOS erforderte häufig die Verwendung von Storyboards oder XIB-Dateien in Xcode, das Code auf Objective-C oder Swift schreibt.
* Für Android wurden die XML -Markierungsdateien und der Code auf Java oder Kotlin erstellt.
* Web -Schnittstellen haben HTML/CSS/JavaScript eingeschaltet.
* Für Anwendungen c ++ auf verschiedenen Desktop -Plattformen wurden ihre spezifischen Frameworks und Tools verwendet:
* In Windows waren dies MFC (Microsoft Foundation Classes), Win32 -API mit manuellen Zeichnungselementen oder Verwendung von Ressourcendateien für Dialogfenster und Steuerelemente.
* Kakao (Objektiv-C/Swift) oder die alte Kohlenstoff-API zur direkten Kontrolle der grafischen Grenzfläche wurden in macOS verwendet.
* In Linux/UNIX-ähnlichen Systemen wurden häufig Bibliotheken wie GTK+ oder QT verwendet, die ihre Widgets und Mechanismen zum Erstellen von Schnittstellen bereitstellten, häufig über XML-ähnliche Markierungsdateien (z.

Dieser Ansatz sorgte für eine maximale Kontrolle über jede Plattform, sodass Sie alle spezifischen Funktionen und nativen Elemente berücksichtigen können. Er hatte jedoch einen großen Nachteil: Duplizierung von Bemühungen und enorme Kosten für Unterstützung . Die geringste Änderung des Designs oder der Funktionalität erforderte die Einführung eines Rechts auf mehrere unabhängige Codebasen. Dies wurde zu einem echten Albtraum für Entwicklerteams, verlangsamte die Ausgabe neuer Funktionen und erhöhte die Wahrscheinlichkeit von Fehlern.

deklarative Meilen: Eine einzelne Sprache für Vielfalt

Als Reaktion auf diese schnelle Komplikation erschien die deklarativen Meilen als dominantes Paradigma. Framws wie React, Vue, Swiftui, Jetpack Compose und andere sind nicht nur eine neue Art, Code zu schreiben, sondern eine grundlegende Verschiebung des Denkens.

Die Hauptidee des deklarativen Ansatzes : Anstatt das System zu sagen, wie man jedes Element zeichnet (imperativ), beschreiben wir „was“ wir sehen wollen (deklarativ). Wir setzen die Eigenschaften und den Zustand der Schnittstelle, und das Framework entscheidet, wie Sie sie am besten auf einem bestimmten Gerät anzeigen können.

Dies wurde dank der folgenden wichtigen Vorteile möglich:

1. Abstraktion aus den Details der Plattform: deklarative Fraimvorki sind speziell so konzipiert, dass sie die Details mit niedrigem Level für jede Plattform vergessen. Der Entwickler beschreibt die Komponenten und ihre Beziehungen auf einer höheren Abstraktionsebene unter Verwendung eines einzelnen, übertragenen Codes.
2. Automatische Anpassung und Reaktionsfähigkeit: Freiimvorki Übernehmen Sie die Verantwortung für die automatische Skalierung , ändern Sie das Layout und die Anpassung von Elementen in verschiedene Größen von Bildschirmen, Pixeldichte und Eingabemethoden. Dies wird durch die Verwendung flexibler Layoutsysteme wie Flexbox oder Grid und Konzepte erreicht, die “logischen Pixeln” oder “DP” ähneln.
3.. Dies vereinfacht den Testprozess und bietet vorhersehbarere Benutzererfahrung.
V. Die Teams können sich auf Funktionalität und Design konzentrieren und nicht auf wiederholte Umschreiben derselben Schnittstelle.
5. Freiimvorki kann aktualisiert werden, um neue Technologien zu unterstützen, und Ihr bereits geschriebener Code erhält. Diese Unterstützung ist relativ nahtlos.

Schlussfolgerung

Die deklarative Meile ist nicht nur ein Modetrend, sondern auch die notwendige evolutionäre Stufe , die durch die schnelle Entwicklung von Benutzergeräten verursacht wird, einschließlich der Sphäre des Internet der Dinge (IoT) und intelligente Haushaltsgeräte. Es ermöglicht Entwicklern und Designern, komplexe, adaptive und gleichmäßige Schnittstellen zu erstellen, ohne in endlosen spezifischen Implementierungen für jede Plattform zu ertrinken. Der Übergang von der imperativen Kontrolle über jedes Pixel zur deklarativen Beschreibung des gewünschten Zustands ist eine Erkenntnis, dass in der Welt der zukünftigen Schnittstellen flexibel, übertragen und intuitiv unabhängig davon, welcher Bildschirm angezeigt wird.

Programmierer, Designer und Benutzer müssen lernen, wie man in dieser neuen Welt lebt. Die zusätzlichen Details des Pixel Perfect, das auf ein bestimmtes Gerät oder eine bestimmte Auflösung ausgelegt ist, führen zu unnötigen Zeitkosten für die Entwicklung und Unterstützung. Darüber hinaus funktionieren solche harten Layouts möglicherweise nicht auf Geräten mit nicht standardmäßigen Schnittstellen wie begrenzten Eingangsfernsehern, VR- und AR-Verschiebungen sowie anderen Geräten der Zukunft, von denen wir heute noch nicht einmal wissen. Flexibilität und Anpassungsfähigkeit – Dies sind die Schlüssel zur Schaffung erfolgreicher Schnittstellen in der modernen Welt.

Warum tun Programmierer auch mit neuronalen Netzwerken nichts?

Heute werden überall neuronale Netze verwendet. Programmierer verwenden sie, um Code zu generieren, andere Lösungen zu erläutern, Routineaufgaben zu automatisieren und sogar ganze Anwendungen von Grund auf neu zu erstellen. Es scheint, dass dies zu einer Erhöhung der Effizienz, der Verringerung der Fehler und der Beschleunigung der Entwicklung führen sollte. Aber die Realität ist viel prosaischer: Viele gelingt es immer noch nicht. Die neuronalen Netze lösen keine wichtigen Probleme – sie beleuchten nur die Tiefe der Unwissenheit.

Vollständige Abhängigkeit von LLM anstatt zu verstehen

Der Hauptgrund ist, dass sich viele Entwickler vollständig auf LLM verlassen und die Notwendigkeit eines tiefen Verständnisses der Werkzeuge ignorieren, mit denen sie arbeiten. Anstatt Dokumentation zu studieren – eine Chat -Anfrage. Anstatt die Gründe für den Fehler zu analysieren – kopieren Sie die Entscheidung. Anstelle von architektonischen Lösungen – die Erzeugung von Komponenten gemäß der Beschreibung. All dies kann auf oberflächlicher Ebene funktionieren, aber sobald eine nicht standardmäßige Aufgabe entsteht, ist die Integration in ein echtes Projekt oder die Notwendigkeit einer Feinabstimmung erforderlich, alles bröckelt.

Mangel an Kontext und veralteten Praktiken

Die neuronalen Netzwerke generieren den Code verallgemeinert. Sie berücksichtigen die Einzelheiten Ihrer Plattform, der Version von Bibliotheken, Umgebungsbeschränkungen oder architektonischen Lösungen des Projekts nicht. Was generiert wird, sieht oft plausibel aus, hat aber nichts mit dem realen, unterstützten Code zu tun. Selbst einfache Empfehlungen funktionieren möglicherweise nicht, wenn sie zur veralteten Version des Frameworks oder zur Verwendung von Ansätzen angehören, die seit langem als unwirksam oder unsicher anerkannt werden. Modelle verstehen den Kontext nicht – sie stützen sich auf Statistiken. Dies bedeutet, dass Fehler und Antipatttern, die im offenen Code beliebt sind, immer wieder reproduziert werden.

Redundanz, Ineffizienz und Mangel an Profilerstellung

Der generierte KI ist oft überflüssig. Es enthält unnötige Abhängigkeiten, doppelte Logik, fügt unnötig Abstraktionen hinzu. Es stellt sich eine ineffektive, schwere Struktur heraus, die schwer zu unterstützen ist. Dies ist besonders akut in der mobilen Entwicklung, wo die Größe der Bande, die Reaktionszeit und der Energieverbrauch von entscheidender Bedeutung sind.

Das neuronale Netzwerk führt keine Profilerstellung durch, berücksichtigt nicht die Einschränkungen der CPU und der GPU und kümmert sich nicht um die Speicherlecks. Es wird nicht analysiert, wie effektiv der Code in der Praxis ist. Die Optimierung ist immer noch handgefertigt und erfordert eine Analyse und Untersuchung. Ohne sie wird die Anwendung langsam, instabil und ressourcenintensiv, auch wenn sie aus Sicht der Struktur „rechts“ aussehen.

Verwundbarkeit und eine Bedrohung für die Sicherheit

Vergessen Sie die Sicherheit nicht. Es sind bereits Fälle bekannt, in denen Projekte, die teilweise oder vollständig mit LLM erstellt wurden, erfolgreich gehackt wurden. Die Gründe sind typisch: Die Verwendung unsicherer Funktionen, mangelnde Überprüfung der Eingabedaten, Fehler in der Logik der Autorisierung, Lecks durch externe Abhängigkeiten. Das neuronale Netzwerk kann einen gefährdeten Code generieren, nur weil es in offenen Repositorys gefunden wurde. Ohne die Teilnahme von Sicherheitsspezialisten und eine vollständige Überarbeitung werden solche Fehler leicht zu Eingabepunkten für Angriffe.

Das Gesetz ist Pareto und die Essenz der Fehler

Das Pareto -Gesetz arbeitet eindeutig mit neuronalen Netzwerken zusammen: 80% des Ergebnisses werden aufgrund von 20% der Anstrengungen erzielt. Das Modell kann eine große Menge Code generieren, die Grundlage des Projekts erstellen, die Struktur verbreiten, Typen anordnen, Module verbinden. All dies kann jedoch veraltet sein, mit aktuellen Versionen von Bibliotheken oder Frameworks nicht kompatibel sein und eine erhebliche manuelle Überarbeitung erfordern. Die Automatisierung funktioniert hier eher als Entwurf, der überprüft, verarbeitet und an bestimmte Realitäten des Projekts angepasst werden muss.

Vorsichtsoptimismus

Trotzdem sieht die Zukunft ermutigend aus. Konstante Aktualisierung von Trainingsdatensätzen, Integration in die aktuelle Dokumentation, automatisierte Architekturprüfungen, Einhaltung von Design- und Sicherheitsmustern – all dies kann die Spielregeln radikal ändern. Vielleicht können wir in ein paar Jahren den Code wirklich schneller, sicherer und effizienter schreiben und sich als echter technischer Co -Autor auf LLM verlassen. Aber vorerst – leider – muss viel manuell überprüft, umgeschrieben und modifiziert werden.

Neuronale Netze sind ein leistungsstarkes Werkzeug. Aber damit er für Sie und nicht gegen Sie arbeitet, benötigen Sie eine Basis, ein kritisches Denken und eine Bereitschaft, die Kontrolle jederzeit zu übernehmen.

Vibe-Core-Tricks: Warum LLM immer noch nicht mit festem, trockenem und sauberem funktioniert

Mit der Entwicklung von großsprachigen Modellen (LLM) wie Chatgpt verwenden immer mehr Entwickler sie, um Code, Designarchitektur und Beschleunigung der Integration zu generieren. Bei der praktischen Anwendung wird jedoch spürbar: Die klassischen Prinzipien der Architektur – solide, trocken, sauber – verstehen Sie die Besonderheiten der LLM -Codgendation schlecht.

Dies bedeutet nicht, dass die Prinzipien veraltet sind – im Gegenteil, sie arbeiten perfekt zur manuellen Entwicklung. Aber mit LLM muss der Ansatz angepasst werden.

Warum LLM nicht mit architektonischen Prinzipien fertig werden kann

Kapselung

Die Zusammenfassung erfordert das Verständnis der Grenzen zwischen Teilen des Systems, Kenntnissen über die Absichten des Entwicklers sowie den strengen Zugriffsbeschränkungen. LLM vereinfacht häufig die Struktur, macht Felder ohne Grund öffentlich oder dupliziert die Implementierung. Dies macht den Code anfälliger für Fehler und verstößt gegen die architektonischen Grenzen.

Abstracts und Schnittstellen

Entwurfsmuster wie eine abstrakte Fabrik oder Strategie erfordern eine ganzheitliche Sicht des Systems und das Verständnis seiner Dynamik. Modelle können eine Schnittstelle ohne klaren Zweck erstellen, ohne die Implementierung zu gewährleisten, oder gegen die Verbindung zwischen Schichten verstoßen. Das Ergebnis ist eine überschüssige oder nicht funktionsfähige Architektur.

trocken (Donolt wiederholt sich)

LLM bemüht sich nicht, den sich wiederholenden Code zu minimieren – im Gegenteil, es ist für sie einfacher, Blöcke zu duplizieren, als allgemeine Logik zu erstellen. Obwohl sie auf Anfrage auf Anfrage eingerichtet werden können, neigen Modelle neigen dazu, „selbstfassende“ Fragmente zu erzeugen, auch wenn dies zu Redundanz führt.

saubere Architektur

Clean impliziert eine strenge Hierarchie, Unabhängigkeit von Frameworks, gerichtete Abhängigkeit und minimale Verbindung zwischen Schichten. Die Erzeugung einer solchen Struktur erfordert ein globales Verständnis des Systems – und LLM arbeiten auf der Ebene der Wahrscheinlichkeit von Wörtern, nicht auf architektonischer Integrität. Daher ist der Code unter Verstoß gegen die Anweisungen der Abhängigkeit und eine vereinfachte Aufteilung in Ebenen gemischt.

Was funktioniert besser bei der Arbeit mit LLM

Nass statt trocken
Der nasses (zweimal alles schreiben) ist praktischer bei der Arbeit mit LLM. Die Duplikation von Code erfordert keinen Kontext aus dem Modell der Aufbewahrung, was bedeutet, dass das Ergebnis vorhersehbar ist und einfacher zu korrekt ist. Es reduziert auch die Wahrscheinlichkeit von nicht offenen Verbindungen und Fehler.

Darüber hinaus hilft die Duplikation, den kurzen Speicher des Modells zu kompensieren: Wenn ein bestimmtes Logikfragment an mehreren Stellen gefunden wird, berücksichtigt LLM es mit größerer Wahrscheinlichkeit mit weiterer Generation. Dies vereinfacht die Begleitung und erhöht den Widerstand gegen “Vergessen”.

einfache Strukturen anstelle von Kapselung

Vermeiden Sie eine komplexe Kapselung und stützen sich auf die direkte Übertragung von Daten zwischen den Teilen des Codes und können sowohl die Generation als auch das Debuggen erheblich vereinfachen. Dies gilt insbesondere für eine schnelle iterative Entwicklung oder Schaffung von MVP.

vereinfachte Architektur

Eine einfache, flache Struktur des Projekts mit einer minimalen Menge an Abhängigkeiten und Abstraktionen liefert während der Erzeugung ein stabileres Ergebnis. Das Modell passt einen solchen Code leichter an und verletzt die erwarteten Verbindungen zwischen den Komponenten.

SDK -Integration – Manuell zuverlässig


Die meisten Sprachmodelle werden auf veralteten Dokumentationsversionen geschult. Bei der Erstellung von Anweisungen zur Installation von SDK werden daher häufig Fehler angezeigt: veraltete Befehle, irrelevante Parameter oder Links zu unzugänglichen Ressourcen. Praxis zeigt: Es ist am besten, offizielle Dokumentation und manuelle Abstimmung zu verwenden und LLM eine Hilfsrolle zu hinterlassen – beispielsweise eine Vorlagencode oder eine Anpassung von Konfigurationen zu generieren.

Warum funktionieren die Prinzipien noch – aber mit manueller Entwicklung

Es ist wichtig zu verstehen, dass die Schwierigkeiten von festem, trockenem und sauberem Zusammenhang die Codhegeneration durch LLM betreffen. Wenn der Entwickler den Code manuell schreibt, demonstrieren diese Prinzipien weiterhin seinen Wert: Sie reduzieren die Verbundenheit, vereinfachen die Unterstützung und erhöhen die Lesbarkeit und Flexibilität des Projekts.

Dies liegt an der Tatsache, dass menschliches Denken anfällig für die Verallgemeinerung ist. Wir suchen nach Mustern, wir bringen wiederholte Logik in einzelne Entitäten und erstellen Muster. Wahrscheinlich hat dieses Verhalten evolutionäre Wurzeln: Reduzierung der Anzahl der Informationen spart kognitive Ressourcen.

LLM handelt anders: Sie erleben keine Lasten aus dem Datenvolumen und streben nicht nach Einsparungen. Im Gegenteil, es ist für sie einfacher, mit doppelten, fragmentierten Informationen zu arbeiten, als komplexe Abstraktionen aufzubauen und aufrechtzuerhalten. Aus diesem Grund ist es für sie einfacher, mit dem Code ohne Kapselung fertig zu werden, mit wiederholenden Strukturen und minimaler architektonischer Schwere.

Schlussfolgerung

Großsprachenmodelle sind ein nützliches Instrument in der Entwicklung, insbesondere in den frühen Stadien oder beim Erstellen eines Hilfscode. Es ist jedoch wichtig, den Ansatz an sie anzupassen: die Architektur zu vereinfachen, die Abstraktion zu begrenzen, komplexe Abhängigkeiten zu vermeiden und bei der Konfiguration von SDK nicht auf sie zu verlassen.

Die Prinzipien von fester, trocken und sauber sind immer noch relevant, aber sie haben den besten Effekt in den Händen einer Person. Bei der Arbeit mit LLM ist es vernünftig, einen vereinfachten, praktischen Stil zu verwenden, der es Ihnen ermöglicht, einen zuverlässigen und verständlichen Code zu erhalten, der leicht manuell abschließen kann. Und wo LLM vergisst – die Duplizierung von Code hilft ihm, sich zu erinnern.

Portierung der Surreal Engine C++ auf WebAssembly

In diesem Beitrag beschreibe ich, wie ich die Surreal Engine-Spiel-Engine auf WebAssembly portiert habe.

Surreal Engine – eine Spiel-Engine, die die meisten Funktionen der Unreal Engine 1 implementiert, berühmte Spiele auf dieser Engine – Unreal Tournament 99, Unreal, Deus Ex, Undying. Es bezieht sich auf klassische Engines, die hauptsächlich in einer Single-Threaded-Ausführungsumgebung arbeiteten.

Anfangs hatte ich die Idee, ein Projekt zu übernehmen, das ich nicht in angemessener Zeit abschließen konnte, und so meinen Twitch-Followern zu zeigen, dass es Projekte gibt, die selbst ich nicht schaffen kann. Während meines ersten Streams wurde mir plötzlich klar, dass die Aufgabe, Surreal Engine C++ mit Emscripten auf WebAssembly zu portieren, machbar ist.

Surreal Engine Emscripten Demo

Nach einem Monat kann ich meine Gabel- und Motorbaugruppe auf WebAssembly demonstrieren:
https://demensdeum.com/demos/SurrealEngine/

Die Steuerung erfolgt wie im Original über die Tastaturpfeile. Als nächstes plane ich, es für die mobile Steuerung (Tachi) anzupassen und dabei die richtige Beleuchtung und andere grafische Funktionen des Unreal Tournament 99-Renderings hinzuzufügen.

Wo soll ich anfangen?

Das erste, was ich sagen möchte, ist, dass jedes Projekt mit Emscripten von C++ nach WebAssembly portiert werden kann. Die Frage ist nur, wie vollständig die Funktionalität sein wird. Wählen Sie ein Projekt, dessen Bibliotheksports bereits für Emscripten verfügbar sind; im Fall von Surreal Engine haben Sie großes Glück, denn Die Engine verwendet die Bibliotheken SDL 2, OpenAL – Sie sind beide auf Emscripten portiert. Allerdings kommt als Grafik-API Vulkan zum Einsatz, was aktuell nicht für HTML5 verfügbar ist, an der Implementierung von WebGPU wird gearbeitet, befindet sich aber ebenfalls im Entwurfsstadium und es ist auch unbekannt, wie einfach die weitere Portierung von Vulkan auf WebGPU sein wird , nachdem es vollständig standardisiert ist. Daher musste ich mein eigenes grundlegendes OpenGL-ES/WebGL-Rendering für die Surreal Engine schreiben.

Erstellung des Projekts

System in Surreal Engine erstellen – CMake, was auch die Portierung vereinfacht, weil Emscripten stellt seinen nativen Buildern – emcmake, emmake.
Die Surreal Engine-Portierung basierte auf dem Code meines neuesten Spiels in WebGL/OpenGL ES und C++ namens Death-Mask. Dadurch war die Entwicklung viel einfacher, ich hatte alle notwendigen Build-Flags und Codebeispiele dabei.

Einer der wichtigsten Punkte in CMakeLists.txt sind die Build-Flags für Emscripten, unten ist ein Beispiel aus der Projektdatei:


-s MAX_WEBGL_VERSION=2 \

-s EXCEPTION_DEBUG \

-fexceptions \

--preload-file UnrealTournament/ \

--preload-file SurrealEngine.pk3 \

--bind \

--use-preload-plugins \

-Wall \

-Wextra \

-Werror=return-type \

-s USE_SDL=2 \

-s ASSERTIONS=1 \

-w \

-g4 \

-s DISABLE_EXCEPTION_CATCHING=0 \

-O3 \

--no-heap-copy \

-s ALLOW_MEMORY_GROWTH=1 \

-s EXIT_RUNTIME=1")

Das Build-Skript selbst:


emmake make -j 16

cp SurrealEngine.data /srv/http/SurrealEngine/SurrealEngine.data

cp SurrealEngine.js /srv/http/SurrealEngine/SurrealEngine.js

cp SurrealEngine.wasm /srv/http/SurrealEngine/SurrealEngine.wasm

cp ../buildScripts/Emscripten/index.html /srv/http/SurrealEngine/index.html

cp ../buildScripts/Emscripten/background.png /srv/http/SurrealEngine/background.png

Als nächstes bereiten wir den Index vor .html , das den Projektdateisystem-Preloader enthält. Zum Hochladen ins Web habe ich die Unreal Tournament Demo-Version 338 verwendet. Wie Sie der CMake-Datei entnehmen können, wurde der entpackte Spielordner zum Build-Verzeichnis hinzugefügt und als Preload-Datei für Emscripten verlinkt.

Hauptcodeänderungen

Dann war es notwendig, die Spielschleife des Spiels zu ändern, man kann keine Endlosschleife ausführen, das führt zum Einfrieren des Browsers, stattdessen muss man emscripten_set_main_loop verwenden, über diese Funktion habe ich in meiner Notiz von 2017 geschrieben „< a href="https://demensdeum.com /blog/ru/2017/03/29/porting-sdl-c-game-to-html5-emscripten/" rel="noopener" target="_blank">SDL C++-Spiel auf HTML5 (Emscripten) portieren“
Wir ändern den Code zum Beenden der while-Schleife in if, zeigen dann die Hauptklasse der Spiel-Engine, die die Spielschleife enthält, im globalen Bereich an und schreiben eine globale Funktion, die den Spielschleifenschritt vom globalen Objekt aus aufruft :


#include <emscripten.h>

Engine *EMSCRIPTEN_GLOBAL_GAME_ENGINE = nullptr;

void emscripten_game_loop_step() {

	EMSCRIPTEN_GLOBAL_GAME_ENGINE->Run();

}

#endif

Danach müssen Sie sicherstellen, dass in der Anwendung keine Hintergrundthreads vorhanden sind. Wenn ja, dann bereiten Sie sich darauf vor, diese für die Single-Thread-Ausführung neu zu schreiben, oder verwenden Sie die phtread-Bibliothek in Emscripten.
Der Hintergrund-Thread in Surreal Engine wird zum Abspielen von Musik verwendet. Vom Haupt-Engine-Thread kommen Daten über den aktuellen Titel, die Notwendigkeit, Musik abzuspielen, oder dessen Fehlen. Anschließend erhält der Hintergrund-Thread über einen Mutex einen neuen Status und beginnt mit der Wiedergabe neuer Musik , oder pausiert es. Der Hintergrundstream wird auch zum Puffern von Musik während der Wiedergabe verwendet.
Meine Versuche, die Surreal Engine für Emscripten mit pthread zu erstellen, waren erfolglos, da die SDL2- und OpenAL-Ports ohne pthread-Unterstützung erstellt wurden und ich sie nicht aus Gründen der Musik neu erstellen wollte. Daher habe ich die Funktionalität des Hintergrundmusik-Streams mithilfe einer Schleife auf die Single-Threaded-Ausführung übertragen. Durch das Entfernen von pthread-Aufrufen aus dem C++-Code habe ich die Pufferung und Musikwiedergabe in den Hauptthread verschoben, damit es keine Verzögerungen gibt, ich habe den Puffer um einige Sekunden erhöht.

Als nächstes werde ich spezifische Implementierungen von Grafik und Sound beschreiben.

Vulkan wird nicht unterstützt!

Ja, Vulkan wird in HTML5 nicht unterstützt, obwohl alle Marketingbroschüren die plattformübergreifende und breite Plattformunterstützung als Hauptvorteil von Vulkan darstellen. Aus diesem Grund musste ich meinen eigenen grundlegenden Grafikrenderer für einen vereinfachten OpenGL-Typ schreiben – ES, es wird auf mobilen Geräten verwendet, enthält manchmal nicht die modischen Funktionen des modernen OpenGL, lässt sich aber sehr gut auf WebGL portieren, was genau das ist, was Emscripten implementiert. Das Schreiben des grundlegenden Kachel-Renderings, des BSP-Renderings für die einfachste GUI-Anzeige und des Renderns von Modellen und Karten wurde in zwei Wochen abgeschlossen. Dies war vielleicht der schwierigste Teil des Projekts. Es liegt noch viel Arbeit vor uns, die volle Funktionalität des Surreal Engine-Renderings zu implementieren, daher ist jede Hilfe von Lesern in Form von Code und Pull-Requests willkommen.

OpenAL unterstützt!

Das große Glück ist, dass Surreal Engine OpenAL für die Audioausgabe verwendet. Nachdem ich eine einfache Hallo-Welt in OpenAL geschrieben und sie mit Emscripten in WebAssembly zusammengestellt hatte, wurde mir klar, wie einfach alles war, und ich machte mich an die Portierung des Sounds.
Nach mehreren Stunden des Debuggens stellte sich heraus, dass die OpenAL-Implementierung von Emscripten mehrere Fehler aufweist. Beispielsweise gab die Methode beim Initialisieren des Lesens der Anzahl der Monokanäle eine unendliche Zahl zurück, und nachdem versucht wurde, einen Vektor unendlicher Größe zu initialisieren, C++ stürzt mit der Ausnahme vector::length_error ab.

Wir haben es geschafft, dies zu umgehen, indem wir die Anzahl der Monokanäle auf 2048 fest codiert haben:


		alcGetIntegerv(alDevice, ALC_STEREO_SOURCES, 1, &stereoSources);



#if __EMSCRIPTEN__

		monoSources = 2048; // for some reason Emscripten's OpenAL gives infinite monoSources count, bug?

#endif



Gibt es ein Netzwerk?

Surreal Engine unterstützt derzeit kein Online-Spielen, das Spielen mit Bots wird unterstützt, aber wir brauchen jemanden, der KI für diese Bots schreibt. Theoretisch können Sie mithilfe von Websockets ein Netzwerkspiel auf WebAssembly/Emscripten implementieren.

Schlussfolgerung

Abschließend möchte ich sagen, dass die Portierung der Surreal Engine aufgrund der Verwendung von Bibliotheken, für die es Emscripten-Portierungen gibt, sowie meiner bisherigen Erfahrung bei der Implementierung eines Spiels in C++ für WebAssembly recht reibungslos verlief auf Emscripten. Nachfolgend finden Sie Links zu Wissensquellen und Repositories zum Thema.
M-M-M-MONSTER TÖTEN!

Außerdem, wenn Sie dem Projekt helfen möchten, vorzugsweise mit WebGL/OpenGL ES-Rendering-Code, dann schreiben Sie mir per Telegram:
https://t.me/demenscave

Links

https://demensdeum.com/demos/SurrealEngine/
https://github.com/demensdeum/SurrealEngine-Emscripten

https://github.com/dpjudas/SurrealEngine

Flash Forever – Interceptor 2021

Recently, it turned out that Adobe Flash works quite stably under Wine. During a 4-hour stream, I made the game Interceptor 2021, which is a sequel to the game Interceptor 2020, written for the ZX Spectrum.

For those who are not in the know – the Flash technology provided interactivity on the web from 2000 to around 2015. Its shutdown was prompted by an open letter from Steve Jobs, in which he wrote that Flash should be consigned to history because it lagged on the iPhone. Since then, JS has become even more sluggish than Flash, and Flash itself has been wrapped in JS, making it possible to run it on anything thanks to the Ruffle player.

You can play it here:
https://demensdeum.com/demos/Interceptor2021

Video:
https://www.youtube.com/watch?v=-3b5PkBvHQk

Source code:
https://github.com/demensdeum/Interceptor-2021

CRUD-Repository

In dieser Notiz beschreibe ich die Grundprinzipien des bekannten klassischen CRUD-Musters und die Implementierung in der Swift-Sprache. Swift ist eine offene, plattformübergreifende Sprache, die für Windows, Linux, macOS, iOS und Android verfügbar ist.

Es gibt viele Lösungen zur Abstraktion von Datenspeicherung und Anwendungslogik. Eine solche Lösung ist der CRUD-Ansatz, ein Akronym für C– Erstellen, R -Lesen, U – Update, D– Löschen.
Typischerweise wird dieses Prinzip durch die Implementierung einer Schnittstelle zur Datenbank implementiert, in der Elemente mithilfe einer eindeutigen Kennung, beispielsweise einer ID, manipuliert werden. Für jeden Buchstaben CRUD – wird eine Schnittstelle erstellt. Erstellen (Objekt, ID), Lesen (ID), Aktualisieren (Objekt, ID), Löschen (Objekt, ID).
Wenn ein Objekt eine ID in sich selbst enthält, kann das ID-Argument in den Methoden (Create, Update, Delete) weggelassen werden, da das gesamte Objekt zusammen mit seinem Feld – Ausweis. Aber für – Für das Lesen ist eine ID erforderlich, da wir anhand der ID ein Objekt aus der Datenbank abrufen möchten.

Alle Namen sind fiktiv

Stellen wir uns vor, dass eine hypothetische AssistantAI-Anwendung mit dem kostenlosen EtherRelm-Datenbank-SDK erstellt wurde. Die Integration war einfach, die API war sehr praktisch und als Ergebnis wurde die Anwendung auf den Markt gebracht.
Plötzlich beschließt der SDK-Entwickler EtherRelm, es kostenpflichtig zu machen und legt den Preis auf 100 US-Dollar pro Jahr und Anwendungsbenutzer fest.
Was? Ja! Was sollen die Entwickler von AssistantAI jetzt tun, da sie bereits 1 Million aktive Benutzer haben! 100 Millionen US-Dollar zahlen?
Stattdessen wird beschlossen, die Übertragung der Anwendung in die plattformeigene RootData-Datenbank zu evaluieren. Nach Angaben der Programmierer wird eine solche Übertragung etwa sechs Monate dauern, wobei die Implementierung neuer Funktionen in der Anwendung nicht berücksichtigt ist. Nach einigem Überlegen wurde beschlossen, die Anwendung vom Markt zu nehmen und sie auf einem anderen kostenlosen plattformübergreifenden Framework mit integrierter BueMS-Datenbank neu zu schreiben. Dadurch wird das Problem mit der kostenpflichtigen Datenbank gelöst und die Entwicklung auf anderen Plattformen vereinfacht.
Ein Jahr später wurde die Anwendung in BueMS umgeschrieben, doch dann beschließt der Framework-Entwickler plötzlich, sie kostenpflichtig zu machen. Es stellt sich heraus, dass das Team zweimal in die gleiche Falle getappt ist; ob es beim zweiten Mal wieder herauskommt, ist eine ganz andere Geschichte.

Abstraktion zur Rettung

Diese Probleme hätten vermieden werden können, wenn Entwickler eine Abstraktion von Schnittstellen innerhalb der Anwendung verwendet hätten. Zu den drei Säulen von OOP – Polymorphismus, Kapselung, Vererbung, vor nicht allzu langer Zeit haben sie ein weiteres – Abstraktion.
Mit der Datenabstraktion können Sie Ideen und Modelle allgemein und mit einem Minimum an Details beschreiben und gleichzeitig genau genug sein, um spezifische Implementierungen zu implementieren, die zur Lösung von Geschäftsproblemen verwendet werden.
Wie können wir den Datenbankbetrieb abstrahieren, sodass die Anwendungslogik nicht davon abhängt? Wir verwenden den CRUD-Ansatz!

Ein vereinfachtes UML CRUD-Diagramm sieht so aus:

Beispiel mit einer fiktiven EtherRelm-Datenbank:

Beispiel mit einer echten SQLite-Datenbank:

Wie Sie bereits bemerkt haben, ändert sich beim Wechseln der Datenbank nur die CRUD-Schnittstelle, mit der die Anwendung interagiert. CRUD ist eine Implementierung des GoF-Musters – Adapter, weil Damit passen wir Anwendungsschnittstellen an beliebige Datenbanken an und kombinieren inkompatible Schnittstellen.
Worte sind leer, zeig mir den Code
Um Abstraktionen in Programmiersprachen zu implementieren, werden Schnittstellen/Protokolle/abstrakte Klassen verwendet. All dies sind Phänomene der gleichen Art. In Interviews werden Sie jedoch möglicherweise gebeten, den Unterschied zwischen ihnen zu benennen. Ich persönlich denke, dass dies nicht viel Sinn macht, weil Der einzige Verwendungszweck besteht darin, eine Datenabstraktion zu implementieren, andernfalls dient es dazu, das Gedächtnis des Befragten zu testen.
CRUD wird oft im Rahmen des Repository-Musters implementiert. Das Repository kann jedoch die CRUD-Schnittstelle implementieren oder auch nicht, alles hängt vom Einfallsreichtum des Entwicklers ab.

Stellen Sie sich einen ziemlich typischen Swift-Code für das Book-Struktur-Repository vor, der direkt mit der UserDefaults-Datenbank arbeitet:


struct Book: Codable {
	let title: String
	let author: String
}

class BookRepository {
	func save(book: Book) {
    		let record = try! JSONEncoder().encode(book)
    		UserDefaults.standard.set(record, forKey: book.title)
	}
    
	func get(bookWithTitle title: String) -> Book? {
    		guard let data = UserDefaults.standard.data(forKey: title) else { return nil }
    		let book = try! JSONDecoder().decode(Book.self, from: data)
    		return book
	}
    
	func delete(book: Book) {
    		UserDefaults.standard.removeObject(forKey: book.title)
	}
}

let book = Book(title: "Fear and Loathing in COBOL", author: "Sir Edsger ZX Spectrum")
let repository = BookRepository()
repository.save(book: book)
print(repository.get(bookWithTitle: book.title)!)
repository.delete(book: book)
guard repository.get(bookWithTitle: book.title) == nil else {
	print("Error: can't delete Book from repository!")
	exit(1)
}

Der obige Code scheint einfach zu sein, aber zählen wir die Anzahl der Verstöße gegen das DRY-Prinzip (Do not Repeat Yourself) und die Kohärenz des Codes:
Konnektivität zur UserDefaults-Datenbank
Konnektivität mit JSON-Encodern und -Decodern – JSONEncoder, JSONDecoder
Verbunden mit der Book-Struktur, aber wir benötigen ein abstraktes Repository, um nicht für jede Struktur, die wir in der Datenbank speichern, eine Repository-Klasse zu erstellen (DRY-Verletzung)

Ich sehe diese Art von CRUD-Repository-Code ziemlich oft, er kann verwendet werden, aber eine hohe Kopplung und Duplizierung des Codes führt dazu, dass seine Unterstützung mit der Zeit sehr kompliziert wird. Dies macht sich besonders bemerkbar, wenn Sie versuchen, zu einer anderen Datenbank zu wechseln, oder wenn Sie die interne Logik der Arbeit mit der Datenbank in allen in der Anwendung erstellten Repositorys ändern.
Anstatt Code zu duplizieren, halten Sie die Kopplung hoch – Schreiben wir ein Protokoll für das CRUD-Repository und abstrahieren so die Datenbankschnittstelle und die Anwendungsgeschäftslogik unter Berücksichtigung von DRY und implementieren eine geringe Kopplung:

    typealias Item = Codable
    typealias ItemIdentifier = String
    
    func create<T: CRUDRepository.Item>(id: CRUDRepository.ItemIdentifier, item: T) async throws
    func read<T: CRUDRepository.Item>(id: CRUDRepository.ItemIdentifier) async throws -> T
    func update<T: CRUDRepository.Item>(id: CRUDRepository.ItemIdentifier, item: T) async throws
    func delete(id: CRUDRepository.ItemIdentifier) async throws
}

Das CRUDRepository-Protokoll beschreibt Schnittstellen und zugehörige Datentypen für die weitere Implementierung eines bestimmten CRUD-Repositorys.

Als nächstes schreiben wir eine spezifische Implementierung für die UserDefaults-Datenbank:

    private typealias RecordIdentifier = String
    
    let tableName: String
    let dataTransformer: DataTransformer
    
    init(
   	 tableName: String = "",
   	 dataTransformer: DataTransformer = JSONDataTransformer()
    ) {
   	 self.tableName = tableName
   	 self.dataTransformer = dataTransformer
    }
    
    private func key(id: CRUDRepository.ItemIdentifier) -> RecordIdentifier {
   	 "database_\(tableName)_item_\(id)"
    }
   	 
    private func isExists(id: CRUDRepository.ItemIdentifier) async throws -> Bool {
   	 UserDefaults.standard.data(forKey: key(id: id)) != nil
    }
    
    func create<T: CRUDRepository.Item>(id: CRUDRepository.ItemIdentifier, item: T) async throws {
   	 let data = try await dataTransformer.encode(item)
   	 UserDefaults.standard.set(data, forKey: key(id: id))
   	 UserDefaults.standard.synchronize()
    }
    
    func read<T: CRUDRepository.Item>(id: CRUDRepository.ItemIdentifier) async throws -> T {
   	 guard let data = UserDefaults.standard.data(forKey: key(id: id)) else {
   		 throw CRUDRepositoryError.recordNotFound(id: id)
   	 }
   	 let item: T = try await dataTransformer.decode(data: data)
   	 return item
    }
    
    func update<T: CRUDRepository.Item>(id: CRUDRepository.ItemIdentifier, item: T) async throws {
   	 guard try await isExists(id: id) else {
   		 throw CRUDRepositoryError.recordNotFound(id: id)
   	 }
   	 let data = try await dataTransformer.encode(item)
   	 UserDefaults.standard.set(data, forKey: key(id: id))
   	 UserDefaults.standard.synchronize()
    }
    
    func delete(id: CRUDRepository.ItemIdentifier) async throws {
   	 guard try await isExists(id: id) else {
   		 throw CRUDRepositoryError.recordNotFound(id: id)
   	 }
   	 UserDefaults.standard.removeObject(forKey: key(id: id))
   	 UserDefaults.standard.synchronize()
    }
}

Der Code sieht lang aus, enthält aber eine vollständige konkrete Implementierung eines CRUD-Repositorys mit loser Kopplung, Details unten.
Typalias wurden zur Selbstdokumentation des Codes hinzugefügt.
Schwache Kopplung und starke Kopplung
Die Loslösung von einer bestimmten Struktur (Struktur) wird mithilfe des generischen T implementiert, das wiederum die Codable-Protokolle implementieren muss. Mit Codable können Sie Strukturen mithilfe von Klassen konvertieren, die die Protokolle TopLevelEncoder und TopLevelDecoder implementieren, beispielsweise JSONEncoder und JSONDecoder. Bei Verwendung von Basistypen (Int, String, Float usw.) ist es nicht erforderlich, zusätzlichen Code zum Konvertieren von Strukturen zu schreiben.

Die Entkopplung von einem bestimmten Encoder und Decoder erfolgt mithilfe der Abstraktion im DataTransformer-Protokoll:

	func encode<T: Encodable>(_ object: T) async throws -> Data
	func decode<T: Decodable>(data: Data) async throws -> T
}

Durch die Implementierung eines Datentransformators haben wir eine Abstraktion der Encoder- und Decoder-Schnittstellen implementiert und eine lose Kopplung implementiert, um die Arbeit mit verschiedenen Arten von Datenformaten sicherzustellen.

Das Folgende ist der Code für einen bestimmten DataTransformer, nämlich für JSON:

	func encode<T>(_ object: T) async throws -> Data where T : Encodable {
    		let data = try JSONEncoder().encode(object)
    		return data
	}
    
	func decode<T>(data: Data) async throws -> T where T : Decodable {
    		let item: T = try JSONDecoder().decode(T.self, from: data)
    		return item
	}
}

War es möglich?

Was hat sich geändert? Jetzt reicht es aus, ein bestimmtes Repository zu initialisieren, um mit jeder Struktur zu arbeiten, die das Codable-Protokoll implementiert, wodurch die Notwendigkeit entfällt, Code zu duplizieren und eine lose Kopplung der Anwendung zu implementieren.

Ein Beispiel für ein Client-CRUD mit einem bestimmten Repository, UserDefaults ist die Datenbank, JSON-Datenformat, Client-Struktur, außerdem ein Beispiel für das Schreiben und Lesen eines Arrays:


print("One item access example")

do {
	let clientRecordIdentifier = "client"
	let clientOne = Client(name: "Chill Client")
	let repository = UserDefaultsRepository(
    	tableName: "Clients Database",
    	dataTransformer: JSONDataTransformer()
	)
	try await repository.create(id: clientRecordIdentifier, item: clientOne)
	var clientRecord: Client = try await repository.read(id: clientRecordIdentifier)
	print("Client Name: \(clientRecord.name)")
	clientRecord.name = "Busy Client"
	try await repository.update(id: clientRecordIdentifier, item: clientRecord)
	let updatedClient: Client = try await repository.read(id: clientRecordIdentifier)
	print("Updated Client Name: \(updatedClient.name)")
	try await repository.delete(id: clientRecordIdentifier)
	let removedClientRecord: Client = try await repository.read(id: clientRecordIdentifier)
	print(removedClientRecord)
}
catch {
	print(error.localizedDescription)
}

print("Array access example")

let clientArrayRecordIdentifier = "clientArray"
let clientOne = Client(name: "Chill Client")
let repository = UserDefaultsRepository(
	tableName: "Clients Database",
	dataTransformer: JSONDataTransformer()
)
let array = [clientOne]
try await repository.create(id: clientArrayRecordIdentifier, item: array)
let savedArray: [Client] = try await repository.read(id: clientArrayRecordIdentifier)
print(savedArray.first!)

Während der ersten CRUD-Prüfung wurde eine Ausnahmebehandlung implementiert, bei der das Lesen des Remote-Elements nicht mehr möglich ist.

Datenbank wechseln

Jetzt zeige ich Ihnen, wie Sie Ihren aktuellen Code in eine andere Datenbank übertragen. Als Beispiel nehme ich den SQLite-Repository-Code, den ChatGPT generiert hat:


class SQLiteRepository: CRUDRepository {
    private typealias RecordIdentifier = String
    
    let tableName: String
    let dataTransformer: DataTransformer
    private var db: OpaquePointer?

    init(
   	 tableName: String,
   	 dataTransformer: DataTransformer = JSONDataTransformer()
    ) {
   	 self.tableName = tableName
   	 self.dataTransformer = dataTransformer
   	 self.db = openDatabase()
   	 createTableIfNeeded()
    }
    
    private func openDatabase() -> OpaquePointer? {
   	 var db: OpaquePointer? = nil
   	 let fileURL = try! FileManager.default
   		 .url(for: .documentDirectory, in: .userDomainMask, appropriateFor: nil, create: false)
   		 .appendingPathComponent("\(tableName).sqlite")
   	 if sqlite3_open(fileURL.path, &db) != SQLITE_OK {
   		 print("error opening database")
   		 return nil
   	 }
   	 return db
    }
    
    private func createTableIfNeeded() {
   	 let createTableString = """
   	 CREATE TABLE IF NOT EXISTS \(tableName) (
   	 id TEXT PRIMARY KEY NOT NULL,
   	 data BLOB NOT NULL
   	 );
   	 """
   	 var createTableStatement: OpaquePointer? = nil
   	 if sqlite3_prepare_v2(db, createTableString, -1, &createTableStatement, nil) == SQLITE_OK {
   		 if sqlite3_step(createTableStatement) == SQLITE_DONE {
       		 print("\(tableName) table created.")
   		 } else {
       		 print("\(tableName) table could not be created.")
   		 }
   	 } else {
   		 print("CREATE TABLE statement could not be prepared.")
   	 }
   	 sqlite3_finalize(createTableStatement)
    }
    
    private func isExists(id: CRUDRepository.ItemIdentifier) async throws -> Bool {
   	 let queryStatementString = "SELECT data FROM \(tableName) WHERE id = ?;"
   	 var queryStatement: OpaquePointer? = nil
   	 if sqlite3_prepare_v2(db, queryStatementString, -1, &queryStatement, nil) == SQLITE_OK {
   		 sqlite3_bind_text(queryStatement, 1, id, -1, nil)
   		 if sqlite3_step(queryStatement) == SQLITE_ROW {
       		 sqlite3_finalize(queryStatement)
       		 return true
   		 } else {
       		 sqlite3_finalize(queryStatement)
       		 return false
   		 }
   	 } else {
   		 print("SELECT statement could not be prepared.")
   		 throw CRUDRepositoryError.databaseError
   	 }
    }
    
    func create<T: CRUDRepository.Item>(id: CRUDRepository.ItemIdentifier, item: T) async throws {
   	 let insertStatementString = "INSERT INTO \(tableName) (id, data) VALUES (?, ?);"
   	 var insertStatement: OpaquePointer? = nil
   	 if sqlite3_prepare_v2(db, insertStatementString, -1, &insertStatement, nil) == SQLITE_OK {
   		 let data = try await dataTransformer.encode(item)
   		 sqlite3_bind_text(insertStatement, 1, id, -1, nil)
   		 sqlite3_bind_blob(insertStatement, 2, (data as NSData).bytes, Int32(data.count), nil)
   		 if sqlite3_step(insertStatement) == SQLITE_DONE {
       		 print("Successfully inserted row.")
   		 } else {
       		 print("Could not insert row.")
       		 throw CRUDRepositoryError.databaseError
   		 }
   	 } else {
   		 print("INSERT statement could not be prepared.")
   		 throw CRUDRepositoryError.databaseError
   	 }
   	 sqlite3_finalize(insertStatement)
    }
    
    func read<T: CRUDRepository.Item>(id: CRUDRepository.ItemIdentifier) async throws -> T {
   	 let queryStatementString = "SELECT data FROM \(tableName) WHERE id = ?;"
   	 var queryStatement: OpaquePointer? = nil
   	 var item: T?
   	 if sqlite3_prepare_v2(db, queryStatementString, -1, &queryStatement, nil) == SQLITE_OK {
   		 sqlite3_bind_text(queryStatement, 1, id, -1, nil)
   		 if sqlite3_step(queryStatement) == SQLITE_ROW {
       		 let queryResultCol1 = sqlite3_column_blob(queryStatement, 0)
       		 let queryResultCol1Length = sqlite3_column_bytes(queryStatement, 0)
       		 let data = Data(bytes: queryResultCol1, count: Int(queryResultCol1Length))
       		 item = try await dataTransformer.decode(data: data)
   		 } else {
       		 throw CRUDRepositoryError.recordNotFound(id: id)
   		 }
   	 } else {
   		 print("SELECT statement could not be prepared")
   		 throw CRUDRepositoryError.databaseError
   	 }
   	 sqlite3_finalize(queryStatement)
   	 return item!
    }
    
    func update<T: CRUDRepository.Item>(id: CRUDRepository.ItemIdentifier, item: T) async throws {
   	 guard try await isExists(id: id) else {
   		 throw CRUDRepositoryError.recordNotFound(id: id)
   	 }
   	 let updateStatementString = "UPDATE \(tableName) SET data = ? WHERE id = ?;"
   	 var updateStatement: OpaquePointer? = nil
   	 if sqlite3_prepare_v2(db, updateStatementString, -1, &updateStatement, nil) == SQLITE_OK {
   		 let data = try await dataTransformer.encode(item)
   		 sqlite3_bind_blob(updateStatement, 1, (data as NSData).bytes, Int32(data.count), nil)
   		 sqlite3_bind_text(updateStatement, 2, id, -1, nil)
   		 if sqlite3_step(updateStatement) == SQLITE_DONE {
       		 print("Successfully updated row.")
   		 } else {
       		 print("Could not update row.")
       		 throw CRUDRepositoryError.databaseError
   		 }
   	 } else {
   		 print("UPDATE statement could not be prepared.")
   		 throw CRUDRepositoryError.databaseError
   	 }
   	 sqlite3_finalize(updateStatement)
    }
    
    func delete(id: CRUDRepository.ItemIdentifier) async throws {
   	 guard try await isExists(id: id) else {
   		 throw CRUDRepositoryError.recordNotFound(id: id)
   	 }
   	 let deleteStatementString = "DELETE FROM \(tableName) WHERE id = ?;"
   	 var deleteStatement: OpaquePointer? = nil
   	 if sqlite3_prepare_v2(db, deleteStatementString, -1, &deleteStatement, nil) == SQLITE_OK {
   		 sqlite3_bind_text(deleteStatement, 1, id, -1, nil)
   		 if sqlite3_step(deleteStatement) == SQLITE_DONE {
       		 print("Successfully deleted row.")
   		 } else {
       		 print("Could not delete row.")
       		 throw CRUDRepositoryError.databaseError
   		 }
   	 } else {
   		 print("DELETE statement could not be prepared.")
   		 throw CRUDRepositoryError.databaseError
   	 }
   	 sqlite3_finalize(deleteStatement)
    }
}

Oder der CRUD-Code des Repositorys für das Dateisystem, der ebenfalls von ChatGPT generiert wurde:


class FileSystemRepository: CRUDRepository {
	private typealias RecordIdentifier = String
    
	let directoryName: String
	let dataTransformer: DataTransformer
	private let fileManager = FileManager.default
	private var directoryURL: URL
    
	init(
    	directoryName: String = "Database",
    	dataTransformer: DataTransformer = JSONDataTransformer()
	) {
    	self.directoryName = directoryName
    	self.dataTransformer = dataTransformer
   	 
    	let paths = fileManager.urls(for: .documentDirectory, in: .userDomainMask)
    	directoryURL = paths.first!.appendingPathComponent(directoryName)
   	 
    	if !fileManager.fileExists(atPath: directoryURL.path) {
        	try? fileManager.createDirectory(at: directoryURL, withIntermediateDirectories: true, attributes: nil)
    	}
	}
    
	private func fileURL(id: CRUDRepository.ItemIdentifier) -> URL {
    	return directoryURL.appendingPathComponent("item_\(id).json")
	}
    
	private func isExists(id: CRUDRepository.ItemIdentifier) async throws -> Bool {
    	return fileManager.fileExists(atPath: fileURL(id: id).path)
	}
    
	func create<T: CRUDRepository.Item>(id: CRUDRepository.ItemIdentifier, item: T) async throws {
    	let data = try await dataTransformer.encode(item)
    	let url = fileURL(id: id)
    	try data.write(to: url)
	}
    
	func read<T: CRUDRepository.Item>(id: CRUDRepository.ItemIdentifier) async throws -> T {
    	let url = fileURL(id: id)
    	guard let data = fileManager.contents(atPath: url.path) else {
        	throw CRUDRepositoryError.recordNotFound(id: id)
    	}
    	let item: T = try await dataTransformer.decode(data: data)
    	return item
	}
    
	func update<T: CRUDRepository.Item>(id: CRUDRepository.ItemIdentifier, item: T) async throws {
    	guard try await isExists(id: id) else {
        	throw CRUDRepositoryError.recordNotFound(id: id)
    	}
    	let data = try await dataTransformer.encode(item)
    	let url = fileURL(id: id)
    	try data.write(to: url)
	}
    
	func delete(id: CRUDRepository.ItemIdentifier) async throws {
    	guard try await isExists(id: id) else {
        	throw CRUDRepositoryError.recordNotFound(id: id)
    	}
    	let url = fileURL(id: id)
    	try fileManager.removeItem(at: url)
	}
}

Ersetzen Sie das Repository im Client-Code:


print("One item access example")

do {
	let clientRecordIdentifier = "client"
	let clientOne = Client(name: "Chill Client")
	let repository = FileSystemRepository(
    	directoryName: "Clients Database",
    	dataTransformer: JSONDataTransformer()
	)
	try await repository.create(id: clientRecordIdentifier, item: clientOne)
	var clientRecord: Client = try await repository.read(id: clientRecordIdentifier)
	print("Client Name: \(clientRecord.name)")
	clientRecord.name = "Busy Client"
	try await repository.update(id: clientRecordIdentifier, item: clientRecord)
	let updatedClient: Client = try await repository.read(id: clientRecordIdentifier)
	print("Updated Client Name: \(updatedClient.name)")
	try await repository.delete(id: clientRecordIdentifier)
	let removedClientRecord: Client = try await repository.read(id: clientRecordIdentifier)
	print(removedClientRecord)
}
catch {
	print(error.localizedDescription)
}

print("Array access example")

let clientArrayRecordIdentifier = "clientArray"
let clientOne = Client(name: "Chill Client")
let repository = FileSystemRepository(
	directoryName: "Clients Database",
	dataTransformer: JSONDataTransformer()
)
let array = [clientOne]
try await repository.create(id: clientArrayRecordIdentifier, item: array)
let savedArray: [Client] = try await repository.read(id: clientArrayRecordIdentifier)
print(savedArray.first!)

Die Initialisierung von UserDefaultsRepository wurde durch FileSystemRepository mit den entsprechenden Argumenten ersetzt.
Nachdem Sie die zweite Version des Client-Codes ausgeführt haben, finden Sie im Dokumentenordner ein Verzeichnis „Clients Database“, das eine Datei eines in JSON serialisierten Arrays mit einer Client-Struktur enthält.

Datenspeicherformat wechseln

Jetzt bitten wir ChatGPT, einen Encoder und Decoder für XML zu generieren:

	let formatExtension = "xml"
    
	func encode<T: Encodable>(_ item: T) async throws -> Data {
    	let encoder = PropertyListEncoder()
    	encoder.outputFormat = .xml
    	return try encoder.encode(item)
	}
    
	func decode<T: Decodable>(data: Data) async throws -> T {
    	let decoder = PropertyListDecoder()
    	return try decoder.decode(T.self, from: data)
	}
}

Dank der in Swift integrierten Typen wird die Aufgabe für ein neuronales Netzwerk elementar.

Ersetzen Sie JSON durch XML im Client-Code:


print("One item access example")

do {
	let clientRecordIdentifier = "client"
	let clientOne = Client(name: "Chill Client")
	let repository = FileSystemRepository(
    	directoryName: "Clients Database",
    	dataTransformer: XMLDataTransformer()
	)
	try await repository.create(id: clientRecordIdentifier, item: clientOne)
	var clientRecord: Client = try await repository.read(id: clientRecordIdentifier)
	print("Client Name: \(clientRecord.name)")
	clientRecord.name = "Busy Client"
	try await repository.update(id: clientRecordIdentifier, item: clientRecord)
	let updatedClient: Client = try await repository.read(id: clientRecordIdentifier)
	print("Updated Client Name: \(updatedClient.name)")
	try await repository.delete(id: clientRecordIdentifier)
	let removedClientRecord: Client = try await repository.read(id: clientRecordIdentifier)
	print(removedClientRecord)
}
catch {
	print(error.localizedDescription)
}

print("Array access example")

let clientArrayRecordIdentifier = "clientArray"
let clientOne = Client(name: "Chill Client")
let repository = FileSystemRepository(
	directoryName: "Clients Database",
	dataTransformer: XMLDataTransformer()
)
let array = [clientOne]
try await repository.create(id: clientArrayRecordIdentifier, item: array)
let savedArray: [Client] = try await repository.read(id: clientArrayRecordIdentifier)
print(savedArray.first!)

Der Client-Code wurde in nur einen Ausdruck JSONDataTransformer geändert -> XMLDataTransformer

Gesamt

CRUD-Repositorys sind eines der Entwurfsmuster, die zur Implementierung einer losen Kopplung von Anwendungsarchitekturkomponenten verwendet werden können. Eine weitere Lösung – unter Verwendung von ORM (Object-Relational Mapping), kurz gesagt, ORM verwendet einen Ansatz, bei dem Strukturen vollständig auf die Datenbank abgebildet werden und dann Änderungen an Modellen in der Datenbank angezeigt (zugeordnet (!)) werden sollen.
Aber das ist eine ganz andere Geschichte.

Eine vollständige Implementierung von CRUD-Repositorys für Swift ist verfügbar unter:
https://gitlab.com/demensdeum/crud-example

Swift wird übrigens schon lange außerhalb von macOS unterstützt; der Code aus dem Artikel wurde vollständig unter Arch Linux geschrieben und getestet.

Quellen

https://developer.apple.com/documentation/combine/topleveldecoder
https://developer.apple.com/documentation/combine/toplevelencoder
https://en.wikipedia.org/wiki/Create,_read,_update_and_delete

dd Ein-/Ausgabefehler

Was sollten Sie tun, wenn Sie beim Kopieren einer normalen Festplatte mit dd unter Linux einen Ein-/Ausgabefehler erhalten?

Situevina ist sehr traurig, aber lösbar. Höchstwahrscheinlich haben Sie es mit einer ausgefallenen Festplatte zu tun, die fehlerhafte Blöcke enthält, die nicht mehr verwendet, beschrieben oder gelesen werden können.

Überprüfen Sie eine solche Festplatte unbedingt mit S.M.A.R.T., da Ihnen höchstwahrscheinlich Festplattenfehler angezeigt werden. Dies war in meinem Fall der Fall; die Anzahl der fehlerhaften Blöcke war so groß, dass ich mich von der alten Festplatte verabschieden und sie durch eine neue SSD ersetzen musste.

Das Problem bestand darin, dass diese Diskette ein voll funktionsfähiges System mit lizenzierter Software enthielt, die für die Arbeit erforderlich war. Ich habe versucht, partimage zum schnellen Kopieren von Daten zu verwenden, aber plötzlich habe ich festgestellt, dass das Dienstprogramm nur ein Drittel der Festplatte kopiert. Dann endet es entweder mit einem Segfault oder mit einem anderen lustigen Sishny/Sipplusplus-Witz.

Als nächstes habe ich versucht, die Daten mit dd zu kopieren, und es stellte sich heraus, dass dd ungefähr an die gleiche Stelle wie partimage gelangt und dann ein Eingabe-/Ausgabefehler auftritt. Gleichzeitig haben alle möglichen lustigen Flags wie conv=noerr, skip oder etwas anderes überhaupt nicht geholfen.

Aber die Daten konnten mit einem GNU-Dienstprogramm namens ddrescue problemlos auf eine andere Festplatte kopiert werden.

После этого мои волосы стали шелковистыми, вернулась жена, дети и собака перестала кусать диван.

Большим плюсом ddrescue является наличие встроенного прогрессбара, поэтому не приходится костылять какие-то ухищрения навроде pv и всяких не особо красивых флажков dd. Также ddrescure показывает количество попыток прочитать данные; еще на вики написано что утилита обладает каким-то сверх алгоритмом для считывания поврежденных данных, оставим это на проверку людям которые любят ковыряться в исходниках, мы же не из этих да?

https://ru.wikipedia.org/wiki/Ddrescue
https://www.gnu.org/software/ddrescue/ddrescue_ru.html