Code, Tränen und Algo Forge
11
14
Inhalt
- Zeit für ein paar interessante Geschichten
- Ein praktischer Leitfaden: Wie es in der Praxis funktioniert
- Migration von Code aus zuvor veröffentlichten Artikeln
- Entwicklung von Projekten für neue Materialien
- Das Gesicht eines Projekts: Kunst der Dokumentation
- Schlussfolgerung: Eine neue Entwicklungskultur
Zeit für ein paar interessante Geschichten
Freie, ungehemmte Emotion oder strenger Pragmatismus? Zwischen Bergen zerknüllter Entwürfe und verworfener Formulierungen konnte ich lange nicht anfangen zu schreiben. Nein, nicht einmal mit dem Schreiben, sondern mit dem Versuch, Dinge zu beschreiben, die mir praktisch unbekannt waren. Jedes Mal war alles falsch, nicht richtig und nicht ehrlich. Und jetzt habe ich beschlossen, es einfach so zu sagen, wie es ist. Nur meine Eindrücke. Persönliches und weniger Persönliches. Dies soll eine emotionale Geschichte über den Weg von etwas Vertrautem zu etwas Notwendigem sein ... Über den Weg von einfachen Archiven zu einem obskuren Repository. Die naheliegende Frage lautet natürlich: „Warum?“... Warum sollte man sich tatsächlich von dem einfachen Komfort entfernen, an den man sich lange gewöhnt hat, für etwas Komplexes und Unverständliches? Was ist der Sinn? Was ist der Nutzen?
Was hat ein gewöhnlicher Programmierer oder Fachautor davon, etwas zu erforschen und zu lernen, das in den nächsten dreihundert Jahren wahrscheinlich nicht gebraucht wird? Alles ist im Grunde so einfach: Sie haben Ihren Code geschrieben, Ihren Artikel verfasst, den Quellcode mit dem Archiv angehängt und ihn veröffentlicht. Das ist alles, wir können zur nächsten Aufgabe übergehen ...
Das ist jedoch nicht der Fall. Tatsächlich ist das etwas, womit wir uns jetzt und nicht erst später befassen sollten. Aber wir müssen aus unserem Kokon ausbrechen. Ausbrechen und sehen, dass es Dinge gibt, die das Leben viel einfacher machen als unser gemütlicher Murmeltier-Tag aus den sich ständig wiederholenden Aktionen „Code – Artikel – Archiv – Vergessen“...
Als klar wurde, dass ZIP mich nicht mehr rettete.
Eine ganze Zeit lang ging alles so weiter. Nun, es ist praktisch, nicht wahr? Alles läuft nach festen Regeln ab – schreiben Sie Ihren Code, veröffentlichen Sie Artikel und teilen Sie Ihr Wissen... Doch je mehr Artikel veröffentlicht wurden, desto weiter in die Vergangenheit rückte der Beginn dieses Weges, und desto häufiger und zahlreicher tauchten Echos aus der Vergangenheit auf.
Ich fand einen Fehler im ersten Teil der Bibliothek, während ich an etwa dem einundzwanzigsten schrieb, und es war notwendig, diesen Fehler zu korrigieren, alle Dateien vom ersten bis zum letzten Artikel in Archive neu zu verpacken und für jeden einzelnen eine erneute Veröffentlichung zu beantragen. Oder plötzlich schrieb jemand, dass er den an einen Artikel angehängten Code nicht installieren konnte, oder stellte Fragen zu den Änderungen, die von Release zu Release auftraten. Ich weiß nicht einmal mehr, wo das alles ist, in welchem Archiv, was ich dort bereits getan habe und was ich noch nicht geschafft habe... Aber ich muss auf die Leute reagieren und meine Entwicklungen weiter betreuen ... Und nun beginnt die Suche oder das Herunterladen meiner eigenen Quelldateien aus meinen eigenen Artikeln – noch dazu zwei verschiedene Versionen! – und deren Vergleich auf der Suche nach Änderungen ...
Hier begann ich, mich wie eine Geisel meiner eigenen Veröffentlichungen zu fühlen. Und ich begann zunehmend, MQL Algo Forge als eine mögliche Lösung für verschiedene Probleme im Zusammenhang mit der Unterstützung meiner Entwicklungen und Veröffentlichungen zu sehen.
Das nervigste Hindernis: Ich kannte Git überhaupt nicht.
Und hier ist das Dilemma: Ich muss meine Projekte schreiben, ich muss meine Artikel veröffentlichen, ich muss meine To-do-Liste abarbeiten und dann muss ich das alles lernen... Nein, nun ja, ich bin natürlich schon einmal mit Git in Berührung gekommen. Aber nur flüchtig und oberflächlich. Als ich eine C#-App für das Waip Squadron (Wild Priest Corps) in Elite Dangerous schrieb, habe ich eines der Geschwader-Mitglieder um Mitarbeit gebeten, um bei dem Projekt zu helfen. Er ist Programmierer und kannte das alles bereits. Also habe ich einfach Änderungen übertragen und empfangen, bevor ich mit der Arbeit begann, und nur dann, wenn er es mir sagte. Und wenn etwas (durch mich) kaputtging, hat er alles repariert. Und so, wenn ich mir vorstelle, dass ich hier allein mit meinen Projekten bin, könnte ich plötzlich etwas kaputtmachen. Und? Was werde ich tun? Was, wenn ich mit einer unvorsichtigen Bewegung einfach alles lösche? Natürlich hielt mich all das davon ab, einfach „anzufangen“.
Aber dennoch haben die Entwickler die Arbeit mit Algo Forge bereits in den Editor integriert, wenn auch nicht vollständig, aber zumindest musste ich die Hilfe für Git-Konsolenbefehle nicht ständig vor mir offenhalten und daran denken, dass ich irgendwo etwas schreiben sollte, falls ich plötzlich etwas brauche. Nun, ich gehöre nicht zu den Leuten, die mit ihren Tastaturfähigkeiten und den schwer merkbaren, kryptischen Befehlen, die sie selbstverständlich im Schlaf beherrschen. prahlen ... Im Editor sind im Kontextmenü immerhin alle grundlegenden Befehle für alle grundlegenden und notwendigen Schritte in seinem Rechtsklick-Menü integriert:
Da beschloss ich, nach und nach anzufangen, mit dem Gedanken: „Ich muss sowieso irgendwann anfangen.“
Erste Projektübertragung: Wie ich bei einfachen Dingen durcheinander geriet
Nun gut, „Gesagt, getan“, beschloss ich – und fing an. Glücklicherweise habe ich viele verschiedene Artikel veröffentlicht, noch mehr Quelldateien und keinen Mangel an Themen, aus denen ich wählen kann. Und dann häuften sich die Fragen bei mir. Glücklicherweise war mit meiner Logik alles in Ordnung, und ich musste nicht lange darüber nachdenken, welche Typen ich für verschiedene Projekte wählen sollte. Wenn es sich um ein einzelnes Skript handelt, sollte das Projekt dasselbe sein; wenn es ein Indikator ist, dann sollte es ein Indikator sein usw. Wenn es viele Dateien innerhalb eines Projekts gibt, ist es besser, ein leeres Projekt zu erstellen und alle lokalen Dateien des experimentellen Projekts in dieses neue, öffentliche zu kopieren.
Obwohl sofort Fragen aufkamen, wie zum Beispiel: Warum muss das so sein? Warum nicht zuerst ein beliebiges Projekt leer machen und dann die notwendigen Dateien hinein übertragen, von denen eine mit dem erforderlichen Programmtyp kompilierbar ist? Ich habe geübt und erkannt, dass es nur um Komfort geht. In unserem eigenen, so vertrauten und nahen Komfort. Also habe ich für mich entschieden, dass ich, wenn ich ein neues öffentliches Projekt starte und es ein ausführbares Programm ist, den erforderlichen Projekttyp wählen werde. Aber wenn es sich um Code handelt, der schon vor langer Zeit geschrieben wurde, dann ist es für mich bequemer, das Projekt leer zu lassen und dann die notwendigen Dateien hineinzuziehen. Nun, oder wenn innerhalb eines Projekts viele kompilierbare ausführbare Programme mindestens eines oder verschiedener Typen vorhanden oder geplant sind, wird all dies in ein leeres Projekt gelegt.
„Okay, ich werde es machen“, entschied ich. Und das tat ich. Ich habe glücklich Dateien über das Rechtsklick-Menü zum Projekt hinzugefügt (und fühlte mich schon wie ein Algo Forge-Guru), bin zur Webversion gegangen und habe alle Dateien in meinem neuen Projekt hinzugefügt gesehen. Bingo! Und dann dachte ich: Warum sind sie dort erschienen? Ich habe die Dateien wohl nur zum lokalen Repository hinzugefügt. Ich habe nicht auf das magische Push gedrückt. Was ist damit los? Aber dann bemerkte ich einen Kommentar zu den Commits – Hinzufügen neuer Dateien:
Hmm, okay, vielleicht haben die Entwickler es einfach so gemacht (damit jemand wie ich nicht zu lange leiden muss). Und tatsächlich sind alle meine neu hinzugefügten Dateien in der Webversion sichtbar, sie sind perfekt lesbar, und im Allgemeinen ist alles an seinem Platz, und die Dateien haben standardmäßig einen Commit-Kommentar. Wunderbar.
Aber ich wollte meinen eigenen Kommentar zu meinen neu hinzugefügten Dateien hinzufügen. Das ging so nicht. Ich wollte meinen eigenen Kommentar dort haben. Nun, ich mache einfach das Naheliegendste. Es ist bereits das unglaubliche Jahr 2026, aber die Dateien zeigen ein Jahr an, das längst vorbei ist. Also gebe ich in jeder Datei im Editor das aktuelle Jahr ein und speichere die Dateien. Aha! Auf den Dateien im Editor erschienen Symbole, die darauf hinweisen, dass die Dateien geändert wurden (
). Aber die Webversion zeigt immer noch dieselben alten Dateien.
Ich gehe zum Editor und committe die Änderungen in Git (ein Befehl per Rechtsklick: Git Commit). Wieder Bingo – die Symbole auf den Dateien im Editor sind normal geworden und haben die richtige Farbe (
). Das bedeutet meiner Meinung nach, dass sie jetzt in der Webversion identisch sind. Ich gehe dorthin und schaue nach – genau, alles hat sich wunderbar geändert – das aktuelle Jahr springt mir jetzt entgegen.
Und so erinnere ich mich an die magische Eigenschaft von Git und dementsprechend von Algo Forge: Sie können sich die Historie der an Projektdateien vorgenommenen Änderungen merken und anzeigen. Das ist einfach ein Wendepunkt – jetzt kann ich meine Projekte im Ordner „Shared Projects“ entwickeln, Änderungen committen und die gesamte Historie auf der Website sehen (ich erinnere mich daran, wie sie mich mit Fragen gelöchert haben, was ich in verschiedenen Versionen derselben Bibliothek geändert habe). Ich versuche, einen Blick darauf zu werfen, aber mir wird dort gesagt: „Dies ist eine Binärdatei, und ich werde sie dir nicht zeigen.“ Was für ein Reinfall... Und was habe ich kaputtgemacht? Die Datei selbst wird als normaler Text angezeigt – ich kann die Zeichen problemlos sehen –, aber die Änderungen werden nicht angezeigt und es heißt immer noch, es sei eine Binärdatei... Facepalm...
Diese Geschichte ging natürlich gut aus – alles hat funktioniert, aber es geschah mit der Hilfe erfahrener Kollegen, und das brennt sich für immer ins Gedächtnis ein. Was ist das Geheimnis? Das Geheimnis liegt in der aktuellen Funktion von Algo Forge: Es verarbeitet nur in UTF-8 gespeicherte Dateien korrekt. Im Editor werden Dateien jedoch standardmäßig in Unicode gespeichert. Und das ist eine sehr wichtige Nuance: Wann immer Sie mit einem öffentlichen Projekt arbeiten, egal ob neu oder aus früheren Arbeiten zusammengestellt, sollten Sie immer alle Projektdateien erneut in UTF-8 speichern, bevor Sie sie an das Repository senden. Und hier ist sie, die Änderungshistorie:
Nachdem ich das Problem mit der Anzeige der Änderungshistorie gelöst hatte, wurde mir plötzlich klar, dass eine Reihe weiterer Fragen aufgetaucht waren. Nun, die Änderungen sind jetzt sichtbar, aber was ist mit großen Bibliotheken, deren Erstellung Wochen, Monate und eine Menge Korrekturen und Verbesserungen in Anspruch nahm? Jede Version einer solchen Bibliothek wurde in einem eigenen entsprechenden Artikel beschrieben, und eine große Anzahl davon hat sich angesammelt. Und wie kann ich all das für diejenigen transparent machen, die mein Repository betrachten, damit sie die dynamische Entwicklung der Bibliothek sehen können?
Wenn ich die endgültige Version der Bibliothek in ein öffentliches Projekt hochlade, woher soll dann die Historie kommen? Ich habe sie lokal auf meinem Computer und in separaten Artikeln online... Ich erinnere mich, dass ich mich mit Logik auskenne, und ich verstehe, dass ich alles in Teilen in das Projekt hochladen muss – von der ersten bis zur letzten Version. Und jeder neue Artikel (sprich: Bibliotheksversion), oder besser gesagt die an diesen Artikel als Archiv angehängten Bibliotheksdateien müssen in das Repository übertragen werden. Dann habe ich zwar nicht die gesamte Änderungshistorie, aber zumindest die Releasehistorie wird in der Cloud sein. Gut. Was wäre, wenn es eine Möglichkeit gäbe, jedes dieser Releases als Release zu kennzeichnen? Das wäre absolut magisch – eine Historie der Bibliotheks-Releases. Darüber hinaus verweist jeder nachfolgende Artikel auf sein eigenes Bibliotheks-Release... Also habe ich mich daran gemacht, die Dokumentation zu lesen und die Benutzeroberfläche zu erkunden. Und (ein Wunder!) ich finde einen „Releases“-Tab in der Webversion von Algo Forge und darin die Möglichkeit, ein Release aus dem aktuellen Stand zu erstellen:
Bingo zum dritten Mal! Darüber hinaus kann ein Release bei seiner Erstellung beispielsweise als stabiles Release oder als Beta-Release markiert werden. Und das ist großartig.
Also sammle ich alle meine Artikel zur selben Bibliothek und fange an, den Code aus jedem Artikel nacheinander an das öffentliche Projekt zu senden (wobei ich daran denke, jede Datei erneut in UTF-8 zu speichern). Und im Repository erstelle ich jedes Mal, nachdem ich alle Dateien aus jedem nachfolgenden Artikel hinzugefügt habe, erstelle ich ein Release und markiere es als stabil. Wenn all dies abgeschlossen ist, habe ich ein Repository für diese Bibliothek mit acht Releases. Und ich kann einen Link zu jedem Release bereitstellen. Wenn Sie in diesem Fall diesem Link folgen, gelangen Sie zu der Gruppe von Dateien, die zu diesem Release gehören:
Ich könnte nicht glücklicher sein...
Wenn Sie jedoch ein Projekt von Grund auf neu erstellen müssen, müssen Sie natürlich mit einem Projekt im Ordner „Shared Projects“ beginnen, und alle Commits werden sofort in die Änderungshistorie des Projekts aufgenommen. Jede committete Revision ist Teil der Entwicklungshistorie des Projekts und wird angezeigt. Wenn wir erkennen, dass wir es in die Welt hinausschicken können, erstellen wir ein Release davon. Auf diese Weise wird jedes Projekt nach und nach seine eigene Historie und aufeinanderfolgende Releases erhalten.
Was sich als das Schwierigste herausstellte: Nicht der Code, sondern die Disziplin
Und wissen Sie was? Wenn ich Änderungen in Git committe, enthält das Submit-Fenster ein Kommentarfeld. Es ist klar, dass ich dort den Grund für die Änderung eingeben oder irgendwie erklären muss, was im Code geändert wurde... Selbst für mich, eine Person, die es gewohnt ist, ihren Quellcode fast bis ins kleinste Detail zu kommentieren, war es ziemlich stressig, mich dazu zu zwingen, Beschreibungen der Änderungen in dieses Fenster einzugeben. Nun, warum eine „erklärende Notiz“ darüber schreiben, wenn ich nur ein Komma in einem Kommentar geändert habe? Für wen? Und wozu? Das ist schrecklich. Warum sich die Mühe machen? Meine Fragen an mich. Also ließ ich das Feld leer – so geht es schneller. Und dann, als ich eine bestimmte Änderung finden musste, sah ich eine Liste leerer Commits. Nun, such nur weiter danach, mein Lieber, such nur weiter... Und dann verstand ich das. Alle Fragen wie „wer“, „warum“, „wozu“ haben direkte Antworten: für mein geliebtes Ich, um meine Listen in Ordnung zu halten und um mich nicht zu verirren. Und natürlich für meine zukünftigen Leser. Das ist schließlich Respekt vor mir selbst und vor anderen Menschen!
Das ist Disziplin. Zuallererst für mich selbst. Und dann... dann schaute ich mir die README.md an. Da wurde mir klar, dass das Kommentieren meiner Commits überhaupt kein Problem ist: Wenn Sie etwas ändern, senden Sie einen Commit – vergessen Sie aber nicht zu beschreiben, was Sie committen. Und README ist das Datenblatt, das Gesicht meines Projekts. Ich kann das gesamte Projekt darin beschreiben, sodass jeder, der die Projektseite besucht, sofort versteht, worum es geht. Es ist die Projektseite. Die Art und Weise, wie Sie es formatieren, ist die Art und Weise, wie Sie die Antwort erhalten. Wenn ich es leer lasse, erscheint das Projekt für einen Außenstehenden wie eine einfache Ansammlung von Dateien und Code mit unklarem Zweck. Nun, ich musste auch die Dokumentation für die Markdown-Auszeichnungssprache studieren. An diesem Punkt verstand ich bereits, warum ich das tat: um die Projektseite ordentlich zu gestalten. Das ist wiederum Respekt vor den Lesern. Eine Person kommt herein und sieht ein gut formatiertes Projekt, schaut sich an, worum es geht, und versteht vor allem sofort, was es ist.
Und für mich? Für mich ist README ein weiterer Grund, etwas Neues zu lernen und zu entdecken. Ja, ich muss zwar die Algo Forge-Website aufrufen, um alles zu formatieren, aber das ist kein Problem mehr. Wenn ich ein Projekt starte, beginne ich immer damit, es zu beschreiben. Jedes Mal, wenn ich eine größere Änderung vornehme, kann ich eine Notiz in der README hinterlassen. Selbst wenn all diese Notizen nicht auf der endgültigen Projektseite landen, ist dies für mich ein wunderbares Notizbuch mit meinen Aufzeichnungen. Und ich muss nicht einmal die Webversion aufrufen, um die README zu lesen – sie ist direkt im Editor perfekt lesbar. Ich muss nur die Änderungen aus dem Git dieser Datei im Projekt abrufen, dann kann ich sie im Editor-Fenster öffnen und meine Notizen lesen. Sobald ich das Projekt abgeschlossen habe, muss ich die Webversion aufrufen und die Projektseite erstellen, damit der Benutzer den Zweck leicht verstehen kann.
Was mir geholfen hat, nicht auf halbem Weg aufzugeben
Git komplett zu lernen, Dinge auszuprobieren, sie neu zu machen, bei Null anzufangen – natürlich wurde ich all dessen schnell müde. Gerade als ich dachte, alles sei klar geworden und ich könne in der neuen Realität weiterarbeiten, ging zwangsläufig wieder etwas schief. Und ich fing an zu lesen/lernen und es erneut zu versuchen. Also wurde mir schnell klar, dass ich kurz vor dem Platzen stand, und ich beschränkte mich einfach auf das Nötigste für die Durchführung meiner Projekte, bei denen bereits alles klar ist, die funktionieren und neue interessante Ergebnisse liefern. Der Rest kommt mit der Zeit. Es reicht mir zu wissen, dass jedes Projekt im Ordner „Shared Projects“ beginnt, jedes Projekt entweder einen eigenen spezifischen Typ hat oder völlig leer ist, wobei ich völlige Freiheit bei der Wahl habe, was jedoch die Bewahrung der Entwicklungs- und Bearbeitungshistorie beinhaltet.
Die Hauptsache ist, mich darauf zu trainieren, jeden neuen Tag damit zu beginnen, Änderungen von Git abzurufen. Jede Änderung muss mit einem vernünftigen Kommentar versehen werden, damit nach einer Weile klar ist, um welche Art von Änderung es sich handelt. Auf diese Weise stieg ich unmerklich auf ein neues Niveau bei der Gestaltung und Umsetzung meiner Ideen und Lösungen auf – die Dinge werden glasklar, es gibt eine Änderungshistorie sowie Zwischen- und stabile Releases. Sobald ich mich entschieden hatte, wie ich diesen Weg gehen wollte, nachdem ich das Ziel definiert hatte, wurde sofort alles bestimmt und klar – es gibt ein Ziel, es gibt einen Weg und es gibt eine Lösung.
Was erwartet eigentlich den Autor, der sich für den Umstieg entscheidet?
Lassen Sie mich Ihnen gleich sagen: Machen Sie sich keine Illusionen, dass sich alles von heute auf morgen ändert, in Schwung kommt und läuft. Nein. Wenn Sie jahrelang einfache Ordner und Archive verwendet haben, müssen Sie wahrscheinlich in einem neuen Projekt alles ein paar Mal umschreiben. Es wird eine Reihe von Versuchen und Irrtümern geben, Fragen wie „Warum brauche ich das alles, wenn es meine Arbeit nicht beschleunigt, sondern nur Probleme schafft und meine Zeit beansprucht?“ Erst allmählich werden Sie erkennen, dass es das Aufbrechen Ihrer Gewohnheiten ist, das Ihre Arbeit in der Anfangsphase verlangsamt. Und dann wird die Erkenntnis kommen, dass Projekte nach ihrer Veröffentlichung nicht mehr zusammen mit der Veröffentlichung altern.
Nun führen die Projekte ihr Eigenleben und geben auch dem bereits veröffentlichten Artikel weiterhin Aktualität. Jede Änderung am Projekt wird auch im Artikel verfügbar. Sie müssen sich keine Gedanken mehr darüber machen, wie Sie die Leser darüber informieren, dass der Code im Artikel aktualisiert wurde und sie warten sollten, bis der Artikel erneut veröffentlicht wird, anstatt ein veraltetes Archiv herunterzuladen. Alles geschieht jetzt automatisch. Indem wir unsere Gewohnheiten überwinden und zu einem Repository anstelle eines Archivs wechseln, automatisieren wir dadurch die Pflege unserer Projekte und Artikel.
Das bringt uns die so dringend benötigte Ruhe und Ordnung, sodass der volle Nutzen von Algo Forge nun sichtbar wird.
Eine Schlussfolgerung, zu der ich nicht sofort gekommen bin
Bin ich dazu übergegangen, über Probleme zu sprechen, anstatt zu vermarkten, ohne es zu merken? Nun, das liegt einfach daran, dass ich alle Vorteile eines Repositorys gegenüber statischen Archiven verstanden habe, und es wird immer schwieriger, sich an die Zeit zu erinnern, als ich mich von meinen alten Projekten gefangen fühlte, gezwungen, mich an deren Pflege zu erinnern, anstatt ruhig voranzukommen und das Repository diese Routine übernehmen zu lassen, die meine Entwicklung verlangsamt.
Im Kern dreht sich bei Algo Forge alles um Repository, Synchronisation, Versionshistorie und Dokumentation. Für mich bedeutet es auch, dass es unmöglich ist, immer darauf zu zählen, dass meine alten Archive ewig leben. Es bedeutet, dass das Prinzip „Veröffentlichen und Vergessen“ mit dem Prinzip der Notwendigkeit, eines seiner Projekte zu pflegen, in Konflikt steht. Dies bedeutet eine zusätzliche Belastung für den Autor, was eine große Ablenkung von seinen „dringenden Angelegenheiten“ darstellt. Mit Algo Forge sind meine Publikationen jetzt in Ordnung, ihre Historie ist vollkommen transparent und die Frage „Wann werde ich endlich meinen Augiasstall aus Verzeichnissen und Dateien ausmisten?“ stellt sich nicht mehr. Sie ist bereits beantwortet.
Jetzt werde ich die Frage definitiv mit „nein“ beantworten: „Möchte ich zu den früheren Publikationsprinzipien zurückkehren?“ Da ich alle Vorteile des neuen Publikations- und Pflegeprinzips sehe, kann ich nicht anders. Nicht, weil ein Archiv etwas Schlechtes wäre oder keine Daseinsberechtigung hätte. Es ist nur so, dass das Archiv im Moment praktisch ist – genau hier und jetzt, beim Publizieren. Und dann altert es mit der Publikation, und seine Pflege beginnt, Schwierigkeiten und Sorgen zu bereiten. Algo Forge erfordert jedoch beim Publizieren einen Zeit- und Arbeitsaufwand, zahlt sich aber sofort durch einfache Pflege, Transparenz der Historie und ein beruhigtes Gefühl bei der Unterstützung aus. Dies ist sehr wichtig bei der Entwicklung zukünftiger Projekte, die nicht mehr in veralteten Archiven verstauben, sondern ein Eigenleben entwickeln werden, wie es ein gutes ursprüngliches Projekt sollte.
Ein praktischer Leitfaden: So funktioniert es in der Praxis
Die gesamte Arbeit mit Algo Forge basiert auf drei einfachen Regeln, die schnell zur Gewohnheit werden. Zuerst legen wir das Fundament im Ordner „Shared Projects“, da sich hier der direkte Zugriff auf die Cloud öffnet. Dann trainieren wir die Regel für den „ersten Schritt“: Bevor wir mit der Arbeit am Code beginnen, holen wir uns die neueste Version aus dem Repository mit dem Befehl „Get updates from Git“ – das ist besonders wichtig, wenn Sie verschiedene Computer verwenden. Schließlich committen wir unsere Arbeit: Es reicht aus, einfach auf „Commit changes to Git“ zu klicken, und unsere Änderungen werden committet und in der Cloud widergespiegelt.
Die Entwickler haben diesen Prozess so weit wie möglich vereinfacht, indem sie das lokale Committen und das Senden von Code an die Cloud zu einer einzigen Aktion zusammengefasst haben. Wenn Sie dieser einfachen Abfolge folgen, schützen Sie sich für immer vor Versionsverwirrung, und Ihr Projekt ist immer in perfekter Ordnung und griffbereit.
Schauen wir uns an, wie das in der Praxis aussieht. Der gesamte Prozess der Integration Ihres Codes in Algo Forge läuft auf zwei einfache Wege hinaus: Entweder Sie hauchen Ihrem alten Code neues Leben ein oder Sie starten sofort ein neues Projekt und befolgen dabei alle Regeln.
Migration von Code aus zuvor veröffentlichten Artikeln
Stellen Sie es sich so vor: Sie arbeiten in aller Ruhe an einem neuen Projekt und plötzlich erhalten Sie eine Benachrichtigung – jemand hat einen Kommentar zu Ihrem Artikel von vor zwei Jahren hinterlassen. Ein Leser beschwert sich, dass der Code nicht kompiliert wird oder in einem neuen Terminal-Build einen Fehler verursacht. Und so beginnen Sie die mühsame Suche nach genau dieser Quelldatei auf Ihrer Festplatte. Noch schlimmer: Manchmal müssen Sie Ihren eigenen Code aus dem Artikel herunterladen, entpacken und versuchen, sich daran zu erinnern, wie alles zusammengehört, nur um eine Frage zu beantworten.
Das Verschieben solcher Materialien in ein Repository ist der beste Weg, um sich vor solchen Vorfällen zu schützen. Machen Sie Ihre vergangene Arbeit zugänglich und ordentlich, denn der Prozess selbst nimmt nicht mehr Zeit in Anspruch als das Überprüfen Ihrer E-Mails. Befolgen Sie einfach ein paar einfache Schritte, und Ihr Code wird zu einem modernen, benutzerfreundlichen und vor allem vollständig kontrollierbaren Projekt:
- Projekt erstellen
Stellen Sie sicher, dass der Login und das Passwort für Ihr mql5.com-Konto auf der Registerkarte „Community“ in den Editor-Einstellungen angegeben sind:
Klicken Sie im MetaEditor-Navigator mit der rechten Maustaste auf den Ordner „Shared Projects“ und wählen Sie „New Project". Dies ist Ihr Einstiegspunkt in das moderne Ökosystem:
- Konfigurationsauswahl:
Hier hängt alles von der Zusammensetzung des alten Archivs ab. Wenn es viele verschiedene Dateien enthält, wählen Sie „Empty Project“. Wenn Ihr Projekt jedoch nur ein einzelner kompilierter Expert Advisor oder Indikator ist, ist es besser, sofort den entsprechenden Typ im MQL-Assistenten auszuwählen. In diesem Fall erstellt der Editor die korrekte Projektstruktur, in die Sie einfach die erforderlichen Projektdateien kopieren. Allerdings müssen Sie auch bei einem leeren Projekt alle notwendigen Dateien darin ablegen.
- Cloud-Verbindung:
Geben Sie dem Projekt einen Namen in der folgenden Form: [Materialtyp]-[ID]-[Kurzthema].
Mit ID meinen wir die Artikelnummer aus der Adresse (zum Beispiel ist dies in dem Link https://www.mql5.com/de/articles/12900 die Nummer 12900).
Der endgültige Name könnte so aussehen: Article-12900-MQL5-Structs-Print.
Die Benachrichtigung unten im Assistenten, dass das Projekt auf Algo Forge gehostet wird, bestätigt sein Cloud-Format. - Dateimigration:
Kopieren Sie alle Quellcodedateien des Projekts in einem Dateimanager Ihrer Wahl in den neu erstellten Ordner. Wählen Sie in MetaEditor den Befehl „Add file/folder to Git“ für jede Datei, die sich im Repository befinden soll, oder für den Ordner selbst, wenn alle darin enthaltenen Dateien Teil des Gruppenprojekts sein sollen:
- Commit:
Klicken Sie auf „Commit changes to Git“ und das war's. Ihre alten Arbeiten wurden in ein modernes Repository verlegt, und es ist jetzt viel einfacher, sie in Ordnung zu halten.
Entwicklung von Projekten für neue Materialien
Wenn Sie gerade einen neuen Artikel planen, beginnen Sie ihn mit der richtigen Grundlage. Erstellen Sie ein Projekt direkt im Verzeichnis „Shared Projects“, ohne bis zur Veröffentlichung zu warten. Wenn Sie eine geeignete Vorlage auswählen (egal ob es sich um einen komplexen Advisor mit vielen Abhängigkeiten oder ein einfaches Skript oder einen Indikator handelt), erstellt MetaEditor automatisch die korrekte Projektstruktur.
Hier ist es wichtig, eine technische Besonderheit zu berücksichtigen: Die Ordnerstruktur im Fenster „Projects“ ist virtuell. Physisch können sich alle Ihre Quelldateien in einem einzigen Ordner auf Ihrem Laufwerk befinden, aber in der MetaEditor-Oberfläche werden sie übersichtlich auf logische Abschnitte verteilt: Programmdateien in Sources, Header in Headers und Ressourcen in Resources:
Dies geschieht zu Ihrer Bequemlichkeit, damit Sie die benötigte Datei schnell anhand ihrer Zugehörigkeit finden können, ohne sich durch reale Verzeichnisse klicken zu müssen.
Wenn Sie von der ersten Zeile Ihres Codes an so arbeiten, kommen Sie in den Rhythmus der professionellen Entwicklung. Der Prozess wird zu einer Reihe sinnvoller Schritte: Sie haben einen logischen Block geschrieben, ihn überprüft und dann sofort durch Auswahl von „Commit changes to Git“ in das Repository übertragen. Es wird empfohlen, wichtige Änderungen in Commit-Kommentaren zu beschreiben – dies ermöglicht es Ihnen, den Prozess der Dateiänderungen nachträglich zu überwachen, ohne sich merken zu müssen, was genau in dieser speziellen Version geändert wurde.
Sie legen den Kontrollbereich selbst fest: Sie können Änderungen am gesamten Projekt als Ganzes aufzeichnen oder jede Datei einzeln „committen“. Dies gibt Ihnen die Flexibilität, jederzeit zu einer beliebigen Version Ihres Codes zurückzukehren, falls eine neue Idee plötzlich zu nichts führt.
Wenn Sie schließlich mit dem Schreiben Ihres Artikels fertig sind, wird Ihr Projekt vollständig mit der Cloud synchronisiert sein und dabei privat bleiben. Es liegt an Ihnen, wann Sie es veröffentlichen: Sie melden sich einfach in der Webversion von Algo Forge an und öffnen mit einem einzigen Schalter den öffentlichen Zugriff, wodurch Ihre Arbeit genau dann für jeden sichtbar wird, wenn es bequem und erforderlich ist.
Das Gesicht eines Projekts: Kunst der Dokumentation
So, der technische Teil ist vorbei: Der Code ist debuggt, die Dateien sind synchronisiert und sorgfältig in Ordnern in Algo Forge angeordnet. Aber wenn wir jetzt zum Repository gehen, sehen wir nur eine einfache Liste von Dateien. Für die Außenwelt bleibt das Projekt eine „isolierte Ansammlung“ – ohne Projektseite, ohne Titel und ohne jegliche Erklärung. Damit Ihre Arbeit wirklich zum Leser „spricht“, braucht sie ein Gesicht. Diese Rolle übernimmt die Datei README.md, die sich im Stammverzeichnis Ihres Projekts befindet. Genau diese Datei dient als verbindendes Glied, das eine Reihe von Dateien in eine strukturierte Wissensdatenbank verwandelt.
Die README-Datei ist gewissermaßen das Schaufenster für die Darstellung Ihrer Projektseite in Algo Forge. Sie bestimmt, was ein Besucher beim Öffnen des Projekts im Browser sieht. Dies ist Ihr Markenzeichen, das vor Ihren Augen eine Ansammlung stummer Quelldateien in ein klares und lebendiges Softwareprodukt verwandelt. Sie müssen zugeben, dass ein Projekt mit einer coolen Beschreibung viel mehr Vertrauen erweckt als eine bloße Liste von Dateien.
Aber wie können Sie vermeiden, Ihre kostbare Zeit mit dem Schreiben von Dokumentationen von Grund auf zu verschwenden, wenn sie viel effektiver genutzt werden könnte? Nutzen Sie moderne Werkzeuge: Heute ist Künstliche Intelligenz Ihr bester Assistent in dieser Angelegenheit. Zögern Sie nicht, die gesamte Routinearbeit an die KI auszulagern. Geben Sie der KI einfach Ihren Code und einen Entwurf Ihres Artikels und fordern Sie sie auf, eine README-Dateistruktur in Markdown zu erstellen. Die KI wird sofort Funktionen analysieren, Schlüsselparameter hervorheben und logische Abschnitte anbieten. Das resultierende „Skelett“ muss nur noch leicht an Ihren eigenen Stil angepasst werden. Vergessen Sie nicht: Die KI ist kein Ersatz für Ihre Kreativität, sondern ein leistungsstarker Beschleuniger, der sich um das mühsame Markup innerhalb einer Datei kümmert und Ihre Zeit für die Aufgaben freimacht, die wirklich wichtig sind.
Syntax und Steuerzeichen
Nachdem die KI eine README-Dateivorlage erstellt hat, muss diese zu einer fertigen Präsentation verfeinert werden, die nicht einfach nur Funktionen auflistet, sondern auch den Nutzen Ihres Codes klar demonstriert.
Um die Datei fertigzustellen, reicht es aus, die Grundlagen der Markdown-Auszeichnungssprache zu kennen. Ihre Verwendung ermöglicht es Ihnen, Ihren Text mit einfachen Markup-Symbolen zu formatieren, wodurch es nicht mehr nötig ist, sich in die Feinheiten eines komplexen Layouts zu vertiefen. Um sich bei der Gestaltung sicher zurechtzufinden, reicht es aus, sich ein paar Grundregeln zu merken:
Damit Ihr Projekt professionell aussieht, reicht es aus, ein paar Grundlagen der Markdown-Auszeichnungssprache zu beherrschen. Es ist keine Programmierung, sondern eine Reihe einfacher Textbefehle, die Algo Forge sofort in ein schönes Layout verwandelt.
Schauen wir uns die Steuerzeichen an, die zu unseren wichtigsten Design-Werkzeugen werden:
- Überschriftenhierarchie (#):
Die Anzahl der Hash-Zeichen am Anfang einer Zeile bestimmt die Abschnittsebene.
Ein einzelnes #-Symbol erzeugt die größte Überschrift (den Projektnamen), während zwei ## oder drei ### dabei helfen, logische Unterabschnitte hervorzuheben. - Listen (- oder *):
Ein Bindestrich oder Sternchen am Zeilenanfang erstellt automatisch eine strukturierte Liste, wobei jeder Punkt mit einem grafischen Aufzählungszeichen hervorgehoben wird.
Dies ist der beste Weg, um die Programmfunktionen oder Eingabeparameter zu beschreiben. - Text hervorheben (**, *):
Um etwas hervorzuheben, werden Symbole in Paaren verwendet. Ein Wort oder eine Phrase, die in doppelte Sternchen **Text** gesetzt wird, wird halbfett dargestellt, während eine in einfache Sternchen *Text* gesetzte Phrase kursiv erscheint. - Code-Schnipsel (`):
Namen von Funktionen oder Variablen innerhalb eines Satzes müssen durch gepaarte Backticks abgesetzt werden: `OnInit`. Dies trennt technische Begriffe visuell vom normalen Text. - Code-Blöcke (```cpp):
Um ein vollständiges Code-Listing einzufügen, sollten dreifache Backticks am Anfang und am Ende des Blocks verwendet werden. Die Angabe der Kennung „cpp“ unmittelbar nach den öffnenden Backticks aktiviert das bekannte Syntax-Highlighting, das die Struktur von C++- und dementsprechend MQL5-Projekten korrekt anzeigt. - Links und Bilder ([]()):
Die Struktur [Text](Adresse) erstellt standardmäßig einen regulären anklickbaren Link.
Wenn Sie jedoch ein Ausrufezeichen ! davor setzen, interpretiert die Layout-Engine dies als „show“-Befehl und nicht als „Gehe zu“-Befehl.
In diesem Fall lädt der Browser die Datei von der angegebenen Adresse herunter und zeigt sie direkt im Text als Bild an.
Eine kurze Beschreibung (Alt-Text) wird in eckige Klammern geschrieben, und der direkte Pfad zur Bilddatei wird in runde Klammern gesetzt.
Diese „Sprache der Symbole“ verwandelt gewöhnlichen Text in eine visuelle Präsentation. Ein paar Screenshots des Trading-Panels oder ein Chart aus dem Strategietester machen das Projekt lebendig und verständlich, ohne dass unnötige Worte nötig sind. Wenn Sie nur zehn Minuten in die Erstellung einer README investieren, können Sie Ihre Dateisammlung in ein hochwertiges Produkt verwandeln, das Aufmerksamkeit erregt, noch bevor der Code geöffnet wird. Dies ist ein professioneller Ansatz: Wenn der Autor sowohl auf die Logik des Algorithmus als auch auf diejenigen achtet, die ihn studieren werden.
Allerdings gibt es hier ein wichtiges Detail: MetaEditor kann README.md zwar problemlos lesen und anzeigen, ist jedoch nicht für deren Bearbeitung konzipiert. Um sie zu schreiben, greifen wir daher auf die Webversion von Algo Forge zurück.
Dort fügen Sie in einem komfortablen Online-Editor die KI-Vorlage ein, bearbeiten den Text und passen das Erscheinungsbild Ihrer Präsentation an:
Sobald Sie auf der Website auf „Save Edits“ klicken, verschwindet Ihre Arbeit nicht – sie wird Teil des Projekts. Nun genügt es, zum MetaEditor zurückzukehren und auf die bekannte Schaltfläche „Get updates from Git“ zu klicken, damit eine aktuelle, formatierte Beschreibung direkt aus der Cloud in Ihren Editor „geflogen kommt“.
Empfohlene Dokumentationsstruktur
Es ist ratsam, sich bei der Gestaltung des Repositorys an eine universelle Struktur zu halten. Eine logische Abfolge umfasst typischerweise eine kurze Zusammenfassung des Projekts, eine Liste der Hauptfunktionen, einen Überblick über die Dateiliste sowie eine schrittweise Reihenfolge, in der sie ausgeführt werden sollten. Die Dokumentation endet mit einem Referenzblock, der Links zur theoretischen Grundlage oder Kontakte für Feedback enthält. Diese Struktur macht das Projekt für das Publikum transparent und aus Sicht des Autors vollständig.
Unten finden Sie ein Beispiel für eine typische README.md-Datei, die als Grundlage für Ihre eigenen Projekte verwendet werden kann:
#Projekt- oder Bibliotheksname Kurze Zusammenfassung: Beschreibung des zu lösenden Problems, des Hauptzwecks und der geeigneten Anwendungsbereiche (ein bis zwei Sätze). ##Wichtigste Funktionen – Auflistung der wichtigsten Funktionen oder Module. – Beschreibung einzigartiger Merkmale, wie z. B. Leistung oder plattformübergreifende Entwicklung. ##Projektaufbau Überblick über die Repository-Struktur: Für welche Aufgaben sind die Hauptverzeichnisse oder -dateien zuständig? ## Anwendungsbeispiel Nachfolgend finden Sie ein einfaches Beispiel dafür, wie die Hauptfunktion dieser Bibliothek aufgerufen wird: ```cpp #include <MyLibrary.mqh> void OnStart() { double result = MyFunction(10.5, 20.0); Print("Computing result: ", result); } ``` Verwenden Sie den Code mit Bedacht. ##Anwendungshinweise – Vorgehensweise zur Integration in andere Projekte. – Erforderliche Abhängigkeiten und externe Ressourcen. – Grundlegende Schritte zur Kompilierung und zum ersten Ausführen. ##Referenzinformationen – Links zu theoretischen Materialien oder zum Hauptartikel auf dem Portal. – Kontaktdaten für Feedback oder Links zu den Community-Diskussionen.
Wir tun README oft als eine langweilige Formalität ab, die „nur zum Schein“ ausgefüllt werden muss. Aber die Wahrheit ist, dass selbst der brillanteste Code Gefahr läuft, in einem Regal zu verstauben, wenn er nicht in ein paar Minuten verstanden werden kann. Eine gut gestaltete Datei ist nicht nur ein Text, sie ist Ihre Signatur, ein Qualitätsmerkmal und grundlegender Respekt gegenüber denjenigen, die Ihren Code studieren werden. Diese Präsentation verwandelt ein Projekt von einer bloßen Sammlung von Dateien in ein lebendiges Werkzeug, das Ihren Ruf auch noch ein oder zwei Jahre oder länger nach der Veröffentlichung des Artikels weiter aufbaut.
Schlussfolgerung: Eine neue Entwicklungskultur
Der Wechsel zu Algo Forge ist nicht nur eine Änderung der Art und Weise, wie Sie Dateien speichern; es ist ein neuer Standard für professionelle Aktivitäten. Wir bewegen uns weg von statischen ZIP-Archiven und langwierigen Neuveröffentlichungszyklen hin zu lebendigen, relevanten Projekten, die hier und jetzt unter Ihrer vollständigen Kontrolle stehen.
Für Sie als Autor bedeutet dies in erster Linie Zeitersparnis und Ordnung. Es ist nicht mehr nötig, auf dem Laufwerk nach alten Archiven zu suchen oder den Lesern wiederholt zu erklären, wie ein Projekt manuell zusammengestellt wird. Jetzt lebt Ihre Arbeit in der Cloud, und jede Korrektur kann sofort zum Repository hinzugefügt werden – mit einem einzigen Befehl aus dem MetaEditor. Keine unnötigen E-Mails, kein Warten auf Moderation und keine Änderungen am Text des Artikels selbst.
Die Einbindung solcher Werkzeuge in Ihre Praxis ist nicht nur ein Folgen von Trends, sondern ein Weg, Ihre Artikelproduktion vorhersehbarer und hochwertiger zu gestalten. Letztendlich hebt es, wenn ein Autor einen modernen Ansatz zur Code-Präsentation wählt, unweigerlich die Messlatte für qualitativ hochwertige Inhalte auf der gesamten Plattform. Dies ist ein Fall, in dem Technologie uns hilft, uns auf das Wesentliche zu konzentrieren und jeden Artikel in ein vollwertiges und langlebiges Arbeitswerkzeug für die gesamte Community zu verwandeln.
Diejenigen, die bereit sind, vollständig in die Möglichkeiten des Ökosystems einzutauchen, schauen sich bitte diese Referenzabschnitte an:
- Erste Schritte mit MQL5 Algo Forge – ein grundlegender Leitfaden für einen schnellen Start;
- Umstieg auf MQL5 Algo Forge, eine Artikelserie:
Um Theorie in die Praxis umzusetzen, habe ich beschlossen, persönlich zu testen, wie reibungslos die Migration verläuft. Also habe ich einige meiner Projekte in das Repository verschoben. Die Erfahrung hat gezeigt, dass alles genau so funktioniert, wie im Artikel beschrieben – schnell, logisch und ohne unnötigen Aufwand.
Als praktisches Beispiel für das Endergebnis können Sie sich meine Ergebnisse ansehen.
Hier ist eine Liste einiger Artikel, die ich bereits in meine Repositories übertragen habe:
- Projekt implementiert als „Single Script“ (basierend auf dem Artikel „Studieren von PrintFormat() und Anwenden von vorgefertigten Beispielen“):
Hier habe ich den Projekttyp „Script“ verwendet. Dies ist der ideale und schnellste Weg, wenn Sie ein bestimmtes Dienstprogramm übertragen müssen. - Projekt, implementiert als „Set of Scripts“ (basierend auf dem Artikel „Strukturen in MQL5 und Methoden zum Ausgeben ihrer Daten“):
In diesem Fall habe ich „Empty Project“ gewählt, um mehrere Skripte unter einer Projektseite zu sammeln. - Projekt einer Bibliothek, die auf dem MVC-Muster basiert, mit Unterversionen, die ihren Artikeln entsprechen. Es ist als „Empty Project“ implementiert, bei dem jedes Release aus seinem eigenen Artikel mit einem Commit und der Erstellung eines Releases in das Projekt zusammengeführt wird.
Alle Projekte leben jetzt in der Cloud, und ihre Pflege ist nun mit einem einzigen Klick erledigt.
Übersetzt aus dem Russischen von MetaQuotes Ltd.
Originalartikel: https://www.mql5.com/ru/articles/21732
Warnung: Alle Rechte sind von MetaQuotes Ltd. vorbehalten. Kopieren oder Vervielfältigen untersagt.
Dieser Artikel wurde von einem Nutzer der Website verfasst und gibt dessen persönliche Meinung wieder. MetaQuotes Ltd übernimmt keine Verantwortung für die Richtigkeit der dargestellten Informationen oder für Folgen, die sich aus der Anwendung der beschriebenen Lösungen, Strategien oder Empfehlungen ergeben.
Quantitative Strategien mit niedriger Handelsfrequenz in MetaTrader 5: (Teil 1) Einrichtung eines OLAP-geeigneten Datenspeichers
Integration von MQL5 mit Datenverarbeitungspaketen (Teil 8): Einsatz von Graph Neural Networks zur Erkennung von Liquiditätszonen
Eine alternative Log-datei mit der Verwendung der HTML und CSS
Der MQL5-Standardbibliotheks-Explorer (Teil 9): Verwendung von ALGLIB zur Filterung übermäßiger MA-Crossover-Signale
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Das habe ich ehrlich gesagt vergessen... Entschuldigung.
Zum Beispiel dieses Repository.
Im Editor (auf der Registerkarte mit der Liste der öffentlichen Projekte) habe ich dieses Projekt aus irgendeinem Grund nicht gefunden. Ich habe es mühsam auf der Forge-Website entdeckt, wo es als Archiv heruntergeladen werden kann.
Meiner Meinung nach ist die Variante, den Code direkt im Artikel einzufügen, für die Leser derzeit praktischer. Ein Vorteil wäre vielleicht, wenn man fehlerhaften Code neu hochladen könnte, ohne den Artikel bearbeiten zu müssen.
Wahrscheinlich ist es vorerst am besten, beide Methoden zur Einbindung von Code zu kombinieren.
Im Editor (auf der Registerkarte mit der Liste der öffentlichen Projekte) habe ich dieses Projekt aus irgendeinem Grund nicht gefunden. Mit einiger Mühe habe ich auf der Forge-Website herausgefunden, dass es als Archiv heruntergeladen werden kann.
Meiner Meinung nach ist die Variante, bei der der Code dem Artikel beigefügt wird, für die Leser immer noch praktischer. Ein Vorteil besteht vielleicht darin, dass man fehlerhaften Code neu hochladen kann, ohne den Artikel bearbeiten zu müssen.
Wahrscheinlich ist es vorerst am besten, beide Methoden zur Einbindung von Code zu kombinieren.
Man kann den Code natürlich als Archiv herunterladen. Besser ist es jedoch, einen Fork zu erstellen (für mein eigenes Projekt kann ich natürlich keinen Fork erstellen):
In diesem Fall wird auf dem lokalen Rechner ein eigener Spiegel des Projekts erstellt, in dem man eigene Korrekturen und Ergänzungen vornehmen und diese dem Autor zur Begutachtung senden kann. Er erhält den Vorschlag, kann ihn prüfen und in sein ursprüngliches Projekt übernehmen.
Das wäre dann bereits eine gemeinsame Arbeit am Projekt.
Ein hervorragender Artikel.
In den neuesten Beta-Versionen haben wir unseren Ansatz komplett geändert und darauf verzichtet, Quelldateien und Projekte im Unicode/UTF-16-Format zu speichern.
Gerade um maximale Kompatibilität mit Git und dem KI-Assistenten zu gewährleisten, der UTF-8 bevorzugt.
Gerade um maximale Kompatibilität mit Git und dem KI-Assistenten zu gewährleisten, der UTF-8 bevorzugt.