Hallo zusammen,
ich wollte mich schon länger hier registrieren, da ich eifrig mitlese.
Nun nutze ich mal die Gelegenheit, mein Open-Source Projekt hier vorzustellen:
Es ist ein Kommandozeilenprogramm zum Anzeigen und Bearbeiten von Audio-Metadaten und Tags, das unter allen gängigen Betriebssystemen als einzelne Binary laufen müsste - sprich: Runterladen und ausführen, ohne Abhängigkeiten (abgesehen vom M1 Mac, da scheint es noch Probleme zu geben). Ich habe es hauptsächlich geschrieben, um fehlende Features speziell für Hörbücher existierender Programme zu ergänzen, inzwischen hat es sich aber zu einem für mich echt brauchbaren Tool für alles Mögliche an Audio-Files gemausert.
Habe auch schon überlegt, es im Bereich Code-Review zu posten, da es noch ein recht junges Projekt ist. Ich freue mich also über jegliche Art von Feedback (Benutzung, Verbesserungsvorschläge, Code-Kommentare, etc.).
Worauf ich noch hinweisen möchte: Ich lasse das Projekt automatisch auf github über Github-Actions bauen und veröffentlichen. Falls also jemand ein Template für so etwas sucht, darf er sich gerne bedienen.
Features:
--path-pattern="audiobooks/%g/%a/%s/%p - %n.m4b"
)Langfristig plane ich noch folgende Erweiterungen:
Nutzen möchte ich dazu ffmpeg und fdkaac über eine Prozess-Integration (CliWrap).
Im Code genutzt werden:* c# 6
Würde mich sehr über Feedback jeglicher Art freuen (solange es konstruktiv ist 🙂.
Hallo sandreas,
auch wenns eine (single file) EXE als Ausgabe gibt und es per-se keine Klassenbibliothek ist, so würde ich interne Typen als internal
markieren, da dies Implementierungsdetails sind. Der Vorteil davon ist, dass diese nach belieben geändert werden können ohne das "public api" zu verletzen und entsprechend SemVer eine neue Hauptversionsnummer erfordern würde.
Sind die Implementierungsdetails internal
so könnten ein paar Optimierungen bzgl. Effizienz (CPU und Speicher / GC) durchgeführt werden.
Weiters würde ich das Projekt aufteilen, so dass für den Benutzer* die EXE (wie bisher) zur Verfügung steht
wobei die EXE selbst ein Konsument der DLL ist -- sozusagen als einfacher Wrapper / Driver um die DLL angereichert mit den Commands die im Projekt verfügbar sind.
mfG Gü
Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.
"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
Hey gfoidl,
na das nenn ich doch mal rasches und hervorragendes Feedback. Vielen Dank.
auch wenns eine (single file) EXE als Ausgabe gibt und es per-se keine Klassenbibliothek ist, so würde ich interne Typen als internal markieren, da dies Implementierungsdetails sind. Der Vorteil davon ist, dass diese nach belieben geändert werden können ohne das "public api" zu verletzen und entsprechend SemVer eine neue Hauptversionsnummer erfordern würde.
Sind die Implementierungsdetails internal so könnten ein paar Optimierungen bzgl. Effizienz (CPU und Speicher / GC) durchgeführt werden.
Wieder was gelernt. Wusste gar nicht genau, wie sich das Schlüsselwort internal auswirkt. Cool.
Weiters würde ich das Projekt aufteilen, so dass für den Benutzer ...
Das hatte ich tatsächlich sogar schon auf der Liste, allerdings ist gut, nochmal zu hören, dass das kein overengineering wäre (zumindest nicht per se...).
Und allgemein? Magst du das Projekt? Neutral oder eher "so wird das nie was"? 🙂
LG
sandreas
Hallo sandreas,
Und allgemein? Magst du das Projekt? Neutral oder eher "so wird das nie was"? 🙂
Ja ich mag das Projekt*. Schaut sehr sauber aus, auf GH-ReadMe (prüf dort mal das Encoding, sind ein paar Spezial-Zeichen dabei) sind alle nötigen Infos vorhanden so dass sich damit arbeiten lässt bzw. sofort ein Überblick gegeben ist.
Code hab ich nur überflogen, der passt soweit**. Bei den Tests noch ein paar mehr Fälle testen (v.a. Randfälle / edge-cases wie keine Tags vorhanden beim Parser, etc.).
* auch wenn ich mangels Bedarf es selbst wohl eher nicht verwenden werde, aber da du es hier so nett vorgestellt hast, hab ich es mir angeschaut 😉
** die Anmerkungen oben sind davon unberührt, das kann ja noch geändert werden und Optimierungsmöglichkeiten finden sich fast überall...
mfG Gü
Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.
"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
Ja ich mag das Projekt*. Schaut sehr sauber aus, auf GH-ReadMe
Cool... das motiviert. Das mit den Charset-Sachen ist mir aufgefallen, vermutlich ein Copy&Paste fehler. Sollte korrigiert sein 🙂
Bei den Tests noch ein paar mehr Fälle testen (v.a. Randfälle / edge-cases wie keine Tags vorhanden beim Parser, etc.).
Für die Tests kommt ein rewrite, so das ich mindestens 80% abdecke, sobald die "Experimente" mit den Libraries abgeschlossen sind. Aktuell habe ich noch ein paar Probleme mit Jint und CliWrap... aber ich glaube das hab ich bald im Griff.
Die von spectre.console antworten auf meine GH Issues seit Wochen nicht, das ist etwas frustrierend. Daher hab ich das in meine "Known Issues" bei den Release Notes gepackt 😉