Serendipity und Composer

[yellowled]

Kurz gesagt, damit diskreditierst du dich!

Du Dich mit einer Antwort ohne irgendwelche sachlichen Argumente nicht?

YL

[onli]

Ist eben nur da sinnvoll, wo es Sinn macht. Mit neuen Techniken allein ist es nicht getan. Ich finde es gut, den Schwung in 2.0 nicht nur für ein neues Backend Template zu nutzen, sondern auch etwas aufzuräumen, bestimmte Teile zu überdenken, völlig Altes neu zu setzen,

Dann argumentiere bitte auch in diesem Geiste. Bis jetzt führst du hier einen Kampf - auch noch für Garvin - um irgendwelche illusionären Besitzstandsrechte und die Kontrolle des Systems. Garvins Kontrolle ist nicht in Gefahr. Ich will technische Argumente sehen, warum es keine gute Idee ist, ein System wie Composer zu benutzen.

Das inkludiert Argumente wie den Workflow, aber da kam bisher nur, dass Garvin Kontrolle entzogen würde, was schlicht nicht stimmt - weil im Zweifel die Libs immer noch im Repo liegen können; was aber keine gute Idee ist, weil manuell ein Alternativuniversum an Libs zu pflegen eine tickende Zeitbombe ist, die entweder Sicherheitslücken verursachen oder dafür sorgen wird, dass eine neue PHP-Version uns die Libs so zerschießt, dass ihre Pflege erheblichen Aufwand kostet - s9y ggf unnötig lange tot im Wasser liegt, weil die Änderungen keiner mehr übersieht. Worst-Case-Szenario, klar.

Wir beide haben bei der Smaritfizierung mehr vom bisherigen für neues kaputt gemacht, als Falks bis jetzt auch nur angesehen hat (zumindest demzufolge, was bisher online war).

S9y ist irgendwo ein schönes System, aber Code von vor 15 Jahren ist seltenst schön. Kannst du mir aus dem Stegreif beschreiben, welche Dateien in welcher Reihenfolge ausgeführt werden, wenn eine Seite aufgerufen wird? Ich nicht, dabei hab ich mich da jetzt mehrfach durchgekämpft und kenne den Code recht gut. Ich glaube, das kann keiner. Bei https://github.com/onli/dsnblog kann ich das, da kann das jeder nach 5 Minuten lesen, und das, obwohl der Code von mir ist ;)

Wenn ich das richtig verstehe, hast du mit s9y gelernt. Vielleicht tut es deswegen mehr weh und erklärt deine Tendenz, das hier alles persönlich zu nehmen. Der Code von s9y ist heutzutage kein guter Lehrer. Es ist Code von vor 10 Jahren, teilweise wortwörtlich.

PS: Die Diskussion will ich jetzt nicht bei jedem Featurevorschlag von Falk führen.

[Timbalu]

@YL Nein!
Muss ich hier wirklich begründen, warum Serendipity nicht stehengeblieben und kein Produkt von Script Kiddies ist?

[onli]

Du kannst nicht begründen, dass s9y nicht stehengeblieben ist. Du kannst dich über Skriptkiddies aufregen, aber selbst das hat von der Wortherkunft her seine Berechtigung und war eine offensichtliche Übertreibung.

Vor allem erreichst du auf diese Art nicht dein Ziel.

[yellowled]

Muss ich hier wirklich begründen, warum Serendipity nicht stehengeblieben und kein Produkt von Script Kiddies ist?

Es würde völlig ausreichen, wenn Du sachlich und technisch argumentieren könntest, anstatt auf offensichtlich übertriebene Aussagen, die niemand sonst in dieser Diskussion auf die Goldwaage legt, anzuspringen, als habe man Dich persönlich angegriffen. Das ist nicht der Fall.

YL

[Timbalu]

Ich verstehe diesen aggressiven Unterton nicht... nur weil ich darauf hinweise, dass Motiv und Argumentation für mich nicht im Einklang stehen.
@Malte
Ich vertrete hier meine eigene Meinung! Garvin darf sich selbst bzw seine Rolle hier verteidgen, sofern er das muss.
Meine Argumente waren u.a., dass diese Composer Idee darauf hinausläuft die Libs eben nicht mehr vorrätig zu haben. Und das hat mich eben (bis jetzt) nicht überzeugt, da ich es auch schätze, wenn sich jemand um die Einpflegung und Modernisierung dieser Libs persönlich kümmert und für Kompatibilität sorgt. Solange ein Neues da nicht so viel Vorteile bringt, dass man das vernachlässigen könnte, fühle ich mich hingerissen das eventuell und wie in diesem Falle zu kritisieren. Du schreibst selbst "...im Zweifel" und deutest selber an, dass dies nicht der eigentliche Zweck ist. Darauf habe ich von Anfang an hingewiesen.

Das ist ein anderes Fass. Wir beide haben damals Code übersetzt, damit man das Backend smartifizieren und ein Template erstellen konnte. Da sind nach den allfälligen Korrekturen kaum Fehler gewesen. Erst nach den größeren Umbauarbeiten im Javascript und im Workflow sind diese (w.h. für Neues?) für manche Kompatibilität auftreten und ich wünschte, man könnte etwas mehr Sorgfalt für das Letztere verwenden, bevor man noch mehr harte Schnitte macht.

Nein, das verstehst du nicht richtig. Ich habe nicht mit, sondern an Serendipity gelernt, was ein großer Unterschied ist. Der Ton macht die Musik. Immerhin bin ich jetzt über neun Jahre dabei (wenigstens im Forum) und vermesse mich nicht, ein wirklich gut funktionierendes System als "bäh" und "schlecht" zu titulieren, nur weil man heutzutage manches anders schreiben würde. Ich habe mich auch nie gegen fällige Modernisierungen ausgesprochen und habe sie mit Smarty 3 selber vorgenommen und durchgesetzt. Das wird Serendipity nicht gerecht! Und bsher ging ich davon aus, dass wir darin einer Meinung sind. Muss ich das revidieren?

PS. Wenn das zu anstrengend ist, mich auch überzeugen zu wollen, werde ich meine Schlüsse daraus ziehen.

[yellowled]

PS. Wenn das zu anstrengend ist, mich auch überzeugen zu wollen, werde ich meine Schlüsse daraus ziehen.

Aber das ist kein „(passiv-)aggressiver Unterton“? Hör bitte auf, selbst so zu diskutieren, wie Du es anderen – aus meiner Sicht unberechtigt – vorwirfst.

Alle hier Beteiligten haben dasselbe Ziel (S9y besser zu machen). Keiner kann dieses Ziel allein erreichen. Es hilft dem sachlichen, technischen Aspekt der Diskussion nicht, sich an einzelnen, etwas unglücklich formulierten Übertreibungen aufzuhalten.

YL

[Timbalu]

Aber das ist kein „(passiv-)aggressiver Unterton“? Hör bitte auf, selbst so zu diskutieren, wie Du es anderen – aus meiner Sicht unberechtigt – vorwirfst.

Nein, ist es und soll es nicht! Es war ein PS auf ein PS. Aber danke für die Belehrung.
Der Rest ist selbsterklärend. Reisende soll man nicht aufhalten.

[garvinhicking]

Hi!

Ich möchte mich hier ungerne um Dinge zerfleischen, daher mal mein Standpunkt/Manifest:

1. Ich möchte dass Serendipity als System den obersten Grundsatz weiterhin pflegt, die Benutzer nicht zu gängeln, sondern ihnen ein System zu bieten das regelmäßig und leicht aktualisiert werden kann, ohne spezielle Vorkenntnisse und Besonderheiten bei der Installation.

2. Ich möchte die Abwärtskompatibilität weiterhin als mit einen der wichtigsten Komponenten von Serendipity verstanden wissen. Man sollte Dinge für bestehende Plugins und Templates und Benutzeraktionen nur dann brechen, wenn das gut argumentiert wird, und es für die Benutzer ein verständliches Dokument gibt, was Sie wie und wo anpassen müssen um eine neue Serendipity-Version nutzen zu können.

3. Ich möchte keinen Aktionismus um Code einzuführen, der Serendipity in einen komponentenzustand bringt, wo das System nicht mehr lauffähig ist und er nur noch aus "angefangenen" Fragmenten besteht, die mehr Fehler enthalten als es in der Vorabversion der Fall war. Jede Änderung die in den Core-Code einfließt sollten in sich geschlossen grundsätzlich funktionabel sein, und wenn dem Code noch offene Dinge/Bugs enthalten sind, soll es klar dokumentiert sein.

Solange das gilt, kann man mit mir alles gerne grundsätzlich besprechen. Wenn der Wunsch von anderen Entwicklern besteht, diese zentralen Dinge anders zu sehen, würde ich als Entwickler und Projektleiter von Serendipity vollständig zurücktreten - wenn das der Wunsch der Mehrheit ist, kann ich das gut akzeptieren und sehe das Projekt nicht als mein Alleineigentum an. Wenn meine Wünsche und Vorstellungen sich mit den anderen Entwicklern mehrheitlich nicht mehr decken, bin ich schlicht fehl am Platz und will auch keine anderen Personen durch meine Meinung einschränken. Ich würde in so einem Fall einen Fork von s9y erzeugen und auf Basis der 1.7 Version dies weiter supporten, oder auch auf Basis der 2.0 version solange sich diese nicht mehr in den o.g. Aspekten einschränkt.

Ganz konkret zum Thema Composer: Wenn wir die Libs in den s9y git code commiten habe ich keinerlei Problem damit. Composer einzusetzen ohne den Code im git zu sehen kann ich nicht akzeptieren, da ziehe ich meine Linie. Einfach aus o.g. Gründen: Derzeit kann jeder s9y von Github so beziehen und muss sich nicht auskennen mit Shellbefehlen; das Releasemanagement ist so extrem einfach. Das würde sich mit composer ohne sourcen ändern, und ich sehe wirklich keinen Vorteil dadurch. Zumal die Leute die Composer mehr vertrauen als der aktualität im s9y kern können ja weiterhin auch problemlos lokal ihren composer nutzen um die libs zu aktualisieren; so herum entstünde aus meiner Sicht wirklich kein Nachteil. Ich sehe das alles eher pragmatisch als "Profi-Programmierermäßig". Vermeidung von Redundanz in allen Ehren, aber nicht wenn man damit zum Pedanten/Prinzipienreiter wird.

Ich hatte das Serendipity-Forum hier immer als Stelle der produktiven, konstruktiven und freundlichen, offenen, engen Zusammenarbeit gesehen. Es wäre schade, wenn das hier alles so zerfleddert, wie es gerade den Anschein macht. Das stimmt mich sehr traurig.

Grüße,
Garvin

[yellowled]

Wenn der Wunsch von anderen Entwicklern besteht, diese zentralen Dinge anders zu sehen, würde ich als Entwickler und Projektleiter von Serendipity vollständig zurücktreten - wenn das der Wunsch der Mehrheit ist, kann ich das gut akzeptieren und sehe das Projekt nicht als mein Alleineigentum an.

Mein Wunsch ist das nicht.

Was mich an dieser ganzen Diskussion stört und erschreckt ist, dass jemand angegangen wird, der im Grunde nur sagt: „Hey, ich hab hier mal ein bisschen rumgemerged und denke, dass das Ergebnis dem Projekt helfen kann, sich besser zu entwickeln. Gucken wir mal, ob wir eine für alle akzeptable Lösung finden, das so zu nutzen – und wenn nicht, dann eben nicht.“ Und das wegen eines etwas flapsig formulierten Halbsatzes.

YL

[falk]

Ich hatte das Serendipity-Forum hier immer als Stelle der produktiven, konstruktiven und freundlichen, offenen, engen Zusammenarbeit gesehen. Es wäre schade, wenn das hier alles so zerfleddert, wie es gerade den Anschein macht. Das stimmt mich sehr traurig.

Lieber Garvin, es geht hier nicht um zerfleddern, es geht darum, dass wir alle S9y weiterentwickeln wollen. Ich habe bereits einige Vorschläge gemacht und bin auch dabei, Code als eigene Lib mit UnitTests umzuschreiben. Alles Sachen, die du, lieber Garvin, gerne hättest.

Das dieses Forum immer eine "Stelle der produktiven, konstruktiven und freundlichen, offenen, engen Zusammenarbeit" war kann ich nicht bestätigen. Schaue dir nur mal die Threads an, wenn Bea Hilfe brauchte.

S9y ist für mich ein Freizeitprojekt. Es ist nach wie vor das Open-Source-Projekt, zu dem ich bis jetzt am Meisten beigetragen habe. Auch ich hänge sehr an der Software. Das sich hier in den letzten Jahren nichts im Quelltext getan hat (warum sieht man ja hier) stimmt mich traurig und ich wollte das Ändern. Ich stehe dazu: Der Quelltext von S9y sieht aus wie von Script-Kiddies geschrieben. Damals war ich auch einer, inzwischen habe ich viel dazugelernt und wollte diese Erfahrungen in das Projekt einbringen um es besser, effizienter und schöner, ja für neue Programmierer sogar attraktiver zu machen. Das einige Community-Mitglieder das genau so sehen freut mich. Ich möchte allerdings mit meiner Initiative nicht dazu beitragen, das einem ohnehin kleinem Projekt noch weniger Resourcen zur Verfügung steht. Außerdem ist mir für diesen Kindergarten meine Zeit zu schade. Änderungen, die irgendwann in meinem S9y-Branch auftauchen sollten, könnt ihr gerne in S9y mergen.

"Alles ist wie immer, nur schlimmer". Bernd das Brot ist ein weißes Weißbrot.

[garvinhicking]

Hi Falk!

Ich hänge mich schon etwas an

Der Quelltext von S9y sieht aus wie von Script-Kiddies geschrieben.

auf. Das ist herabwürdigend für die Leute die schon jahrelang Code beigetragen haben, und die wie ich durchaus den Unterschied kennen zwischen "einfach und funktional und pragmatisch und historisch gewachsen und funktionierend" und "generalstabsmäßig geplant".

Wenn Du ein ZF2-basiertes Blogsystem haben willst mit ORM-Mapping, offenem Event-System und ähnlichem, eher entwickler-orientiertem Backend dann ganz ehrlich: Erstell ein neues, unabhängiges Blogsystem. Ich glaube damit bist Du besser beraten, da Du dich dann auch um keine Kompatibilitätssachen kümmern musst und überall auf "Best practice" statt "Best user compliance" setzen kannst. Kann man ja dann Zerendipity nennen.

Grüße,
Garvin

[mattsches]

Zum Thema

Der Quelltext von S9y sieht aus wie von Script-Kiddies geschrieben.

... den Unterschied kennen zwischen "einfach und funktional und pragmatisch und historisch gewachsen und funktionierend" und "generalstabsmäßig geplant".

möchte ich sagen: Da werden Skript-Kiddies doch ziemlich überschätzt! Ich würde einen Programmierer ohne Probleme einstellen, der ein Projekt wie S9y als Referenz-Quellcode vorzeigen kann. Das ist natürlich heute nicht mehr State-of-the-Art, aber vor ein paar Jahren waren viele der in S9y verwendeten Konzepte woanders durchaus noch nicht üblich (und sind es teilweise heute auch noch nicht).

PHP macht gerade einen ziemlichen Sprung nach vorn, und gerade die modernen Frameworks setzen auch viele moderne Konzepte ein, was aber auch gestiegene Komplexität mit sich bringt und die Lernkurve deutlich steiler macht. Ich bin PHP-Autodidakt und hätte heute wahrscheinlich ganz schön zu kämpfen. Glücklicherweise darf ich heute beruflich Projekte mit Symfony2 u.ä. umsetzen, und das macht auch Spaß.

Einige Leute hier im Forum könnten bestimmt innerhalb kurzer Zeit ein Blogsystem programmieren, das diese modernen Konzepte verwendet, hohe Testabdeckung hat, und vermutlich nur unter PHP 5.4+ läuft (wegen der Traits ). Ich habe in den letzten Jahren einige diese Projekte gesehen, die mir vom Code her super gefallen haben. Deren Problem: Die hatten eine Userbase von ca. 1.

Ja, S9y ist "historisch gewachsen", aber gerade deswegen hat es immer noch vergleichsweise viele Nutzer (Anm.: nicht so viele wie WP, aber schon mal deren Quellcode angesehen?). Was bringt das perfekt entworfene und umgesetzte System, wenn es niemand nutzt?

Ich persönlich kann damit Leben, wenn wir Composer einsetzen, aber die Libs trotzdem im Repo haben. Vielleicht ist das ja auch nur eine Übergangslösung, z.B. falls GitHub irgendwann das Feature entwickelt, vor der Erstellung der Archive automatisiert ein composer install auszuführen; oder wir passen unseren Git-Workflow an und pflegen einen dedizierten DEV-Branch ohne die Libs, aber im Master sind sie mit drin. Da fällt uns schon eine Lösung ein, mit der "beide Seiten" leben können.

Ich finde die Herausforderung interessant, S9y unter Beibehaltung von Stabilität und Rückwärtskompatibilität weiterzuentwickeln. Ich will nicht, dass sich die ohnehin schon nicht große Entwicklergemeinde spaltet und es zukünftig Serendipity und Zerendipity gibt (siehe mein Post hier).

Ach ja, und ich will nicht, dass Garvin aufhört. Das hat persönlich Gründe, die hier objektiv keine Rolle spielen sollten. Aber das hat auch den Grund, dass ich nicht weiß, wer seinen Job zukünftig übernehmen sollte. Ich kann Garvins Argumentation nachvollziehen, bin zwar nicht seiner Meinung, aber ich kann mit dem vorgeschlagenen Kompromiss leben.

[garvinhicking]

Matttsches,

das hast Du schön und deutlich weniger dramatisierend geschrieben als ich, und bist damit auch näher an meiner intendierten Meinung als ich selbst. Danke für diese bessere Formuiierung.

[mattsches]

Ich will jetzt diese Diskussion nicht wieder anfeuern, sondern will nur auf ein GitHub-Repo hinweisen, auf das ich gestern gestoßen bin und das genau das Problem mit Composer und downloadbaren Archiven angeht:

https://github.com/sonata-project/compo ... ve-creator

Ist vielleicht für den einen oder anderen auch jenseits von S9y interessant, befindet sich allerdings noch in einer sehr frühen Phase ...