Partkeepr: Prozess der Entwicklung neuer Versionen

Seit dem 20. Juli 2018 wurden keine Commits mehr gemacht. Ich denke also, wir diskutieren nicht über die ETA für die nächste Version, sondern über die ETA für einen neuen Hauptentwickler. Bis wir eine haben, werden wir mit Sicherheit keine Veröffentlichungen haben. Mich würde jedoch interessieren, wie der aktuelle Stand ist.

Die neuesten Projektinfos finden Sie hier: https://www.patreon.com/posts/its-end-for-me-22527966
Und im Grunde hat das Projekt keinen Betreuer mehr, aber wenn es jemand ernst nehmen will, scheint es möglich zu sein.

@christianlupus hat also recht, es ist tatsächlich ETA bis zum neuen Betreuer.

.

5 Entwickler zu haben ist wahrscheinlich mehr als nutzlos ohne solides Projektmanagement (und wahrscheinlich Finanzierung in dieser Phase), das Projekt kann mit einem oder zwei überleben, und das einzige daraus resultierende Problem kann die Entwicklungszeit sein.

Ein Thema, auf das sie hinwies, ist ziemlich klar: Problemmanagement und der Umgang mit Menschen mit schlechtem Benehmen.

Das Projekt kann glücklich mit zwei Entwicklern leben, sogar mit Gesundheitsproblemen, solange es Leute gibt, die die Problemanalyse und das Community-Management durchführen, damit sich die Entwickler auf eine Aufgabe konzentrieren können, ohne sich um die anderen Dinge kümmern zu müssen.

.

PartKeepr hätte noch ein anderes Framework verwendet, das gleiche Argument würde gelten, Symphony ist nicht wirklich ein Nischen-Framework.

Ja, es braucht jemanden, der es kennt oder bereit ist, es zu lernen, wie jedes andere Framework.

Und ja, es könnte eine Nischenanwendung sein, aber der Kontext ist zu berücksichtigen. Wenn Sie Symphonie kennen würden, wären Sie motiviert, an einem look-dead-Projekt teilzunehmen? wahrscheinlich nicht.

.

Braucht es wirklich ein fortschrittliches Standard-Framework?

Es ist nicht fortgeschrittener als ein anderes, es ist nur ein Framework, ja, Sie können ein sehr leichtes verwenden, aber am Ende des Tages haben Sie Tonnen von Erweiterungen hinzugefügt oder von Grund auf neu erstellt, um das gleiche Ergebnis zu erzielen, und sogar schlimmer, da es nicht so dokumentiert und getestet wird wie das "fortgeschrittene Standard-Framework".

Aber diese Problemumgehungen auf nette Weise zu beheben, würde eine Menge Neugestaltung erfordern, die wahrscheinlich mit dem Symphony-Framework oder anderen handelsüblichen Frameworks nicht machbar ist.

Wir sprechen hier nicht über Win32-Apps, und es sei denn, Sie haben einen POC, um zu beweisen, dass dies mit dem aktuellen Framework nicht machbar ist, dann ist es BS.
Das Rad neu zu erfinden mag manchmal funktionieren, aber das ist keine Lösung, die immer funktioniert.

Wenn Sie sagen, dass "Symphonie-Lernkurve zu steil ist", wie soll ein maßgeschneidertes Ding besser sein?

Jetzt zu schimpfen, dass "Symphonie schlecht ist und das Projekt zum Scheitern verurteilt ist, wenn wir nicht alles neu schreiben" wird das Projekt nicht weiterbringen, die Arbeit an den PRs und mit den Mitwirkenden ist es.

.

Wenn ich zum Beispiel Kategorien mit kaskadierenden Spezifikationen haben möchte, die auch auf Komponenten innerhalb einer solchen Kategorie kaskadieren (mit der Möglichkeit, sie zu überschreiben). Und dann eine schön formatierte Beschreibung aller kombinierten Spezifikationen, abhängig von der Art der Komponente. Ist etwas, von dem ich erwarten sollte, dass es in Symfony funktioniert?

Nein. Kein Framework wird das tun. Ich glaube, Sie haben ein Missverständnis darüber, was ein Rahmen ist. Die Implementierung von Kategorien ist anwendungsspezifisch, und kein generisches Framework wird dies jemals handhaben.

Ich finde Symphony oder andere Frameworks nicht schlecht. Aber im Falle, wie ich mir ein Inventory Management System wünsche, wird es sehr unwahrscheinlich, dass sie es schaffen. Das ist kein BS, sondern ein gutes Verständnis für die damit verbundene Komplexität.

Was zum Teufel hat ein Framework mit einer bestimmten Anwendung zu tun? Jedes Framework hat kein Verständnis dafür, wie eine Anwendung funktioniert. Es bietet ein Schema, eine Philosophie und ein Modell, auf dem aufgebaut werden kann.

Zusätzlicher Hinweis: Ja, ich muss noch jemandem die Zugriffsrechte auf das Depot weitergeben, ich bin leider ziemlich beschäftigt mit der Auflösung der PartKeepr UG. Ich hoffe ich komme bald dazu

.

Hallo Felicia,

Mein Verständnis von Symphony als Rahmen ist -wie gesagt- begrenzt. Aber wenn es zum Beispiel UI-Ansichten erstellt, indem es direkt aus Tabellen und Abfragen liest, ist es ziemlich schwierig, Informationen anzuzeigen, die auf fortgeschrittene Weise miteinander verknüpft sind.

In diesem Fall ist es vielleicht besser, nachzulesen, was Symfony bietet und was nicht, anstatt falsche Annahmen zu treffen. Es gibt keine von Symfony generierten UI-Ansichten, zumindest nicht in PartKeepr.

Die vorgeschlagenen kaskadierenden und vererbten Informationen sind schwer abzufragen und daher wahrscheinlich schwer von einem (tabellengesteuerten) Framework zu verarbeiten, oder verstehe ich die Dinge falsch?

Ja, Sie missverstehen die Dinge. Symfony bietet solche Dinge nicht an, vielleicht über ein Drittanbieter-Paket, aber auch hier verwendet PartKeepr kein solches Paket. Symfony wird hauptsächlich für die Controller-Architektur, die Serialisierungsfunktionen (die in Verbindung die API-Plattform verwenden, um JSON-LD zu generieren, das dann vom Frontend gelesen werden kann) und Doctrine für alle datenbankbezogenen Dinge verwendet.

Siehe https://wiki.partkeepr.org/wiki/Developers/Architecture

.

Hallo Felicia,

Danke für die Antwort. Ich habe viel programmiert, sogar die Webtechnologie in ihren Anfängen. Aber das fehlt ganz im Hinblick auf das Verständnis der Architektur von PartKeepr. Auch die unterschiedlichen eingesetzten Technologien sind als Windows-Entwickler kaum zu überschauen. Wie gesagt für mich ist die Lernkurve zu steil. Aber die zugrunde liegende Frage kann immer noch gültig sein. Was sind die Entwicklungsziele und können diese mit den eingesetzten Technologien erreicht werden? Egal wie sie heißen.

Gründe für die Verwendung eines Frameworks, insbesondere eines weit verbreiteten, übernommenen und gewarteten Frameworks wie Symfony2:

• Codeduplizierung vermeiden
• Zuverlässigkeit erhöhen
• Erfinde das Rad nicht neu
• Erhöhen Sie die Wartbarkeit
• Reduzieren Sie die Arbeit

Bis PartKeepr 0.1.9 verwendete es kein Framework außer Doctrine für die Persistenz (Symfony2 existierte damals noch nicht). Die Wartung war ein Albtraum.

Der Grund dafür, dass es in PartKeepr keine SQL-Injections gibt, liegt an Doctrine. Der Grund, warum es nach 0.1.9 in kurzer Zeit so viele neue Funktionen gab, war Symfony2 und die API-Plattform wegen des extrem geringen Entwicklungsaufwands. Der Grund, warum PartKeepr hinter einem Reverse-Proxy funktioniert, ohne dass ich dafür Null-Code schreibe: Symfony2. Der Grund, warum PartKeepr auf nginx ohne jegliche Code-Änderung funktioniert: Symfony2.

Wenn Sie Schwierigkeiten haben, die Funktionsweise von Symfony2 zu verstehen, kein Problem: Es gibt viele Ressourcen im Internet, die Ihnen helfen.

Wenn PartKeepr ein eigenes Framework verwenden würde, wären Sie selbst mit den grundlegendsten Funktionen sehr allein. Ich habe mir kürzlich The Bug Genie als Issue Tracker angesehen, und es verwendet überhaupt kein Framework - alles ist selbst geschrieben. Ich habe nicht weniger als 8 Pull-Requests eingereicht, um Fehler zu beheben, auf die ich während des normalen Gebrauchs gestoßen bin. Nachdem ich auf ein halbes Dutzend weiterer Fehler gestoßen war (und ich die Software über einen Zeitraum von einem Monat nur vielleicht 30 Minuten lang verwendet habe), habe ich aufgehört, sie zu verwenden.

Ich denke, Sie sind wahrscheinlich die beste Person, um die Antwort zu geben, warum dieses Projekt so wenig Entwicklungsunterstützung hatte. Und wenn es behebbar ist.

Ich kann nur vermuten: Relativ kleine Nutzerbasis und ich habe zu viele Funktionswünsche erfüllt. Bei den meisten Benutzern hat es sofort funktioniert, also warum sollten diese Benutzer anfangen, Code beizutragen?

Die Fragen, die ich mir stelle, sind: Würde ich gerne an einem gemeinsamen Projekt teilnehmen? Würde es von meiner Erfahrung profitieren? Teilen mehr Menschen meine Ziele? Wie würden die Interaktionen zwischen Entwicklern aussehen?

Es sei denn, Sie sind bereit zu lernen, wie ein Softwareprojekt und die zugrunde liegenden Technologien funktionieren, nicht viel. Sich über die Wahl des Frameworks zu beschweren und sich zu beschweren, ist ein sehr schlechter erster Schritt.

Ich werde an keiner Projekt- oder Entwicklungskoordination in diesem Projekt teilnehmen.

Ich versuche gerade, auf Symfony 3.4 zu aktualisieren. wenn ich Fortschritte mache werde ich ein Update geben

Hallo @JelleDijkhuizen
Gibt es Neuigkeiten zur Symfony 3.x-Migration? Wenn Sie daran gearbeitet haben, können Sie mir bitte mitteilen, wo ich Ihre Gabel finde? Vielen Dank im Voraus!

@martonmiklos , es sieht so aus, als ob @adlerweb versucht, PartKeepr in einem dedizierten Zweig seiner Gabel auf Symphony 4 zu aktualisieren... :-)

@ZupoLlask danke für den

Ich denke, diese Diskussion war langwierig und das Hauptproblem ist geklärt. Siehe #1059. Also schließe ich das vorerst.