Beiträge von cherrymint

  • Updatestruktur

    Moin,

    Ich wollte mal nachfragen wie allgemein im Moment die Planung der Updatestruktur aussieht. Soll das ähnlich wie bei Xentral sein, dass man sagt man hat feste Versionsnummern und die werden dann jeweils als Releases raus gegeben oder gibt es eventuell auch Bestrebungen den Master-Branch so sauber zu halten, dass man den theoretisch auch als nightly bzw. Rolling-Release nutzen könnte?


    Grüße

  • Verbindung mit Rest-API klappt nicht

    Kurze Nachfrage - also die API an sich ist da (Stand 20.1), aber die funktioniert noch nicht richtig?

    Ich hab auch mal versucht in meiner Testinstanz die API-Docs aufzurufen, aber das will nicht so richtig (bekomme ne 403 - bin mir aber nicht sicher ob das an meinem Apache liegt...)

  • docker compose / kubernetes Installation

    Hmm php-apache ist schon wieder Debian-Unterbau... Das geht schneller und kleiner. ;)

    Zumal meins auch nur ein Ansatz für eigene Tests ist und da fehlt auch definitiv noch der Cronjob drin!


    Sucht euch eins aus, dass euch besser gefällt:

    php.ini:

    supervisord.conf:

    Code
    [supervisord]
nodaemon=true
logfile=/dev/null
logfile_maxbytes=0
pidfile=/run/supervisord.pid

[program:apache2]
command=/usr/sbin/httpd -DFOREGROUND

    Dockerfile:

    Die Dateien in einen Ordner packen und dann mit

    Code
    docker build -f ./Dockerfile -t my-repo:tag .

    bauen.

    Kleines Learning bisher:

    Man kann diesen Container hinter einen nginX-Reverse-Proxy schrauben (in meinem Fall über nginX-Reverse-Proxy-Manager) und der funkt 1a. :)

    Edit - Hinweis: Die PHP-Abhängigkeiten sind drin, weil die Dockerfile die Basis für meine Laravel-Projekte war. Kann man entweder noch eindampfen oder drin lassen.

  • docker compose / kubernetes Installation

    Kurze Frage - besteht hier noch Bedarf an einer Dockerfile? Ich hab mir mal für mich selbst eine gebaut - auf Basis von Alpine Linux selbst und nicht von einem Image einer Einzelperson, da die immer wieder das Problem haben irgendwann nicht mehr maintained zu werden. Falls gewünscht kann ich die Dockerfile gerne hochladen. :)

  • Codebase in Laravel

    Zitat von AndiPalm

    Ich glaube dann sind wir gar nicht weit voneinander entfernt.

    Eigentlich überhaupt nicht, aber Armlänge wäre schon nice, bevor es zu touchy wird... :D


    Zitat von AndiPalm

    Ich persönlich hätte von meinem Bauchgefühl z.B. jetzt zu Symfony gegriffen. Vielleicht eignet sich Laravel aber besser?!

    Hmm Symfony kenne ich bisher eher als "Sammlung nützlicher Projekte", aber nicht wirklich als "Framework" (bitte nicht ernst nehmen - es ist Ewigkeiten her das ich damit zu tun hatte). Laravel und CakePHP bauen aber teilweise auf Symfony auf (Doctrine ist zum Beispiel bei einigen drunter, wobei ich mir aber nicht sicher bin ob das mit Eloquent in Laravel wieder entfernt wurde).


    Cake hatte ich mal in der Ausbildung genutzt, aber bin danach durch Wechsel der Firma bei Laravel gelandet.

    Ich kann deswegen gerade nur wirklich sauber über Laravel Aussagen machen. Dessen größte Vorteile (meiner Meinung nach) sind:

    • Sehr flexibel
      • Eigentlich kann man das Ding als reinen Unterbau benutzen und dann oben drauf (mehr oder weniger) machen was man will.
    • Die bestehende Codebase kann man einbinden bzw. müsste es möglich sein
      • "Xentral selbst nutzt Laravel!" ist für mich jetzt nicht wirklich ein Argument, zeigt aber das sie Laravel zumindest als "wirtschaftlich sinnvoll" ansehen.
      • Wenn man sich den aktuellen Code von Xentral anschaut, dann sieht man auch das es zu funktionieren scheint.
    • Laravel hat eine sehr große Userbasis
      • Das ist unter den PHP-Frameworks so ein bisschen das was Windows auf Desktop-PCs ist...
      • Hätte halt den Vorteil, dass bei neuen Entwicklern die Chance größer ist, dass sie das Framework bereits kennen.
      • Ich hatte jetzt schon Kontakt mit ein paar anderen Laravel-Nutzern via Discord und da wird einem auch echt gut geholfen bei Problemen. (Endete dann darin, dass ich die Dokumentation von Laravel selbst erweitern durfte... :) )
    • Performance
      • Die sind gerade dran die eh schon recht gute Performance noch zu verbessern.

    Zu der Kiste mit "Wie gut ist es jeweils möglich neue Funktionen bereits auf Basis eines Frameworks zu entwickeln, gleichzeitig aber wenig Folgeanpassungen an altem Code machen zu müssen." -> Ich glaube um einen kompletten Umbau wird man in keinem Framework wirklich herum kommen. Da wäre für mich die bessere Frage: "In wie weit ist das Framework mit der bestehenden Code-Basis kompatibel, sodass man für den Übergang beides parallel laufen lassen kann?"

    Das sind nur meine 5 cent dazu - bin mal gespannt was noch von anderen eventuell kommt. :)

  • Codebase in Laravel

    Zitat von AndiPalm

    Ich möchte es nochmal so formulieren: Ja, ich möchte gerne bald eine solide Basis schaffen (z.B. mit Laravel oder Symfony). Aber wir sind bereits mit OpenXE produktiv und es läuft noch nicht alles so rund wie wir es eigentlich brauchen. Warum? Weil wir von Xentral dazu genötigt wurden und uns für das Ende mit Schrecken als ein Schrecken ohne Ende entschieden haben. Aber ich kann vor niemandem, nichtmal vor meinem IT- und Bastelherz rechtfertigen, dass ich an solchen Umbauten arbeite während wir noch keine Matrixartikel über die UI verwalten können.

    Komplett verständlich. Es geht ja auch nicht darum zu sagen, dass man jetzt und sofort loslegt, sondern das man sich jetzt mal Gedanken darüber macht ob man den Umbau machen sollte (was ja eindeutig bisher mit "Ja" beantwortet wurde) und welches Framework genutzt werden soll. Es stehen ja bereits Symfony und Laravel im Raum, aber es gibt ja noch mehr (beispielsweise CakePHP).

    Ich persönlich finde Laravel besser, weil es eine größere Userbase hat, auch auf Teile von Symfony aufbaut (beispielsweise Doctrine) womit sich ein Symfony-Entwickler recht schnell reinfinden kann und weil ich es halt nun schon seit Jahren benutze. :)

    Mein Punkt ist halt der, dass durch die jetzige Entscheidung welches Framework es werden soll, man Entwicklern die neu dazu kommen auch die Chance geben kann mit dem Umbau schon loszulegen und beides parallel laufen lassen könnte. Zumal man als Entwickler dann auch eben weiß woran man ist. Das wird Laravel? Cool - da kenne ich mich bereits aus! Das wird Cake-PHP? Okay - da muss ich mich nochmal reinlesen. Das wird Symfony? Och nööö... Eventuell war ich da etwas unklar. :)

    Und der Punkt mit "Weil wir von Xentral dazu genötigt wurden..." - ich fühle mit dir. Von den 10 grauen Haaren die ich in den letzten 5 Jahren bekommen hab, sind 8 Xentral zu verdanken. ;)

    Zitat von AndiPalm

    Wenn ich mal meine Glaskugel frage, würde sie vermutlich einen Zeitrahmen von etwa 6 Monaten ausspucken in der zumindest ich persönlich noch keine Zeit für solche Umbaumaßnahmen finden werde.

    Noch ein Grund mehr das zu nutzende Framework auf die Roadmap zu packen. Ich weiß zum Beispiel, dass ich wohl im Mai etwas Zeit haben werde und eventuell auch schon vorher. Nur ehrlich gesagt möchte ich mich nirgendwo rein committen ohne zu Wissen worauf ich mich dann am Ende einlasse. :) Wenn ich jetzt sage "Okay, ich forke das Ding mal und hol mal als ersten Schritt eine composer.json rein und mach mir die Mühe die Datenbanktabellen als Models darzustellen." und 3 Monate später wird gesagt "Wir nehmen Cake-PHP." dann waren die ganzen Stunden die ich mit dem Fork verbracht hätte für die Katz. Und da hab ich einfach keine Lust drauf - andere vermutlich auch nicht. Ich red ja nur von Planungen (halt ner Roadmap) und nicht bereits von der Umsetzung. :)

    Zitat von AndiPalm

    Wenn du als erfahrener Laravel-Entwickler aber eine Idee hast, wie man die Umstellung des aktuellen Codes auf z.B. Laravel sinnvoll angehen sollte, dann bin ich da sehr offen für. Was wären deine ersten Schritte? Was würde man damit bereits "gewinnen"?

    Okay - ohne jetzt viel Zeit in dem Code verbracht und noch keine eigenen Tests zu haben - als erstes würde ich (nachdem man Laravel mit eingebunden hat) auf die Datenbank losgehen. Namentlich würde das bedeuten die Tabellen in Models bzw. Pivot-Relations umzuwandeln und dabei schon zu schauen was man optimieren kann. Gewinnen würde man dadurch in der Hauptsache Übersicht und die ganzen rohen DB-Statements würden rausfliegen, was auch dafür sorgt das man im Code recht gut sehen kann "Wo wird das Model denn überhaupt genutzt?". Dazu könnte man auch das Observer-System von Laravel anzapfen um die ganzen Trigger die Xentral ausführt anzustubsen. Damit meine ich sowas wie "Was passiert codeseitig, wenn ein Auftrag freigegeben wird?". Danach müsste man sich halt den Teppich mal anschauen... Welche Fäden kann man ziehen und umbauen, ohne das der ganze Spaß einem entgegen kommt. :)


    Am Ende stimmen ja alle bereits zu, dass da ein Framework mal irgendwann kommen soll, nur welches wird es den nun? Der erste der sich die Mühe mal macht eins drunter zu legen trifft dann die Entscheidung? Also wenn ich jetzt sofort mit Laravel anfangen würde dann wird es das auch?

    Ich frag halt nach einem "Machtwort", denn Alex hat ja schon gesagt, dass da 4 Codegenerationen im bestehenden Code drin sind - bei der Fluktuation an Mitarbeitern die das System aufgebaut haben ist das auch kein Wunder. :)

  • Codebase in Laravel

    Zitat von Alex

    Was Deine Frage nach den Schnittstellen angeht, das Übertragungen-Modul gibt es hier meines Wissens nicht. Grundsätzlich könnte man auch überlegen, die Shopschnittstellen auszulagern, um der Dynamik gerecht zu werden.

    Oha... Dann haben wir jetzt wohl weitestgehend den Stand "Yo nice, aber solange das Ding nicht nach außen funken bzw. Gefunke von außen nicht versteht, bringt uns das nix." - zumindest jetzt von den Use-Cases her die ich betreue. Da ist Xentral eigentlich eher ne Middleware auf Steroiden (mit den entsprechenden Nebenwirkungen ;) ).

    Ich werd mal schauen was sich die nächsten Tage so bei mir ergibt und ob ich da mal was machen kann. (Sofern es mein eigenes Projekt und Familie zulassen...):thumbup:

  • Codebase in Laravel

    Zitat von Josef

    Mit einem stabilen OpenXE zu starten und dann die wichtigsten Plugins zu integrieren, dürfte zunächst mal die höchste Priorität haben.

    Viele kommen ja direkt von Xentral und sind erst mal froh, da rausgekommen zu sein, da liegt der Fokus vermutlich nicht im Wechsel auf ein anderes Framework (mit einer langen Entwicklungsphase, vielen Bugs, usw...).

    Naja - es geht ja nur um einen Framework-Unterbau für die Codebasis... Da verstehe ich nicht was das mit "von Xentral weg kommen" zu tun hat, als würde Laravel was dafür können was für Software damit gebaut wird.

    Ich verstehe allerdings wo die Meinung herkommt. :)

    Allerdings möcht ich da noch folgendes zu bedenken geben: Die wichtigsten Plugins zu migrieren ist eine gute Sache, aber es ist immer die Frage was man als "wichtig" ansieht.

    Wenn man ein Hammer ist sieht alles wie ein Nagel aus - in dem Sinne sehe ich die ShopImporter als sehr wichtig an. Doof ist aber bei denen, dass die Systeme dahinter immer weiterentwickelt und geändert werden (Shopify ist da so ein Kandidat...) und dementsprechend muss dann halt auch der OpenXE-Code angepasst werden, womit eine eh schon komplexe Codebasis nur noch komplexer wird und irgendwann blickt da kein Mensch mehr durch. Deswegen auch meine Meinung zum "eher als später". :)

    Noch ein Grund warum es gut wäre das jetzt zu klären ist das kommende Entwickler damit dann auch wissen woran sie sind, zumal man halt auch eben den Parallel-Betrieb den Xentral selbst gerade macht damit auch fahren könnte. Man muss es ja nicht sofort umsetzen, aber kann es sich wenigstens auf die Roadmap packen. :)

    Tatsächlich werd ich wohl diese Woche mal etwas Zeit nehmen und eine Testinstanz von OpenXE aufsetzen, die ich dann mit meinen Kunden mal testen werde. Ich hoffe ja das OpenXE das Replacement sein kann für das ich es im Moment halte.

    Mir fehlt hier aber als Neuling in OpenXE gerade so ein bisschen die Ausrichtung des Projekts - eben sowas wie eine Roadmap.

    Ich finde die Idee "wir nehmen Xentral und machen das Community-tauglicher" sehr gut, zumal ja (ehrlicherweise) in Xentral auch vieles richtig läuft, aber halt der Maintainer als "fragwürdig" eingestuft werden kann. Aber ich sehe halt nichts im Sinne von "Daran arbeiten wir gerade und das haben wir noch vor." - eventuell fehlt da auch noch etwas Doku? ;)

    Versteht mich bitte richtig - ich will hier niemandem Körperflüssigkeiten vor dem Karren parken. Aber es wäre schade wenn das Projekt das "alles besser machen soll" am Ende genau das gleiche wird wie das Original: Viel Hype und dann wirds dünne mit der Zeit. :)

  • Codebase in Laravel

    Okay - "Experte" ist immer so ne Sache. Eventuell hilft es ja, dass ich Schnittstellenentwickler bin, der so ziemlich alles auf Laravel baut... :D Ich hatte mal ein kleines Projekt namens "Xentral-API-Extension", was nur dazu da war einige Datenbanktabellen als Models abzubilden. Eventuell kann man damit ja anfangen. Da muss ich aber schauen wie ich das mit Arbeit, Frau und Kind vereinbaren kann.

    Ist aber halt die Frage ob das überhaupt gewünscht ist, zumal halt auch jetzt noch das Problem ist das im Code sich noch Verweise auf Klassen und Dateien befinden die gar nicht existierten (beispielsweise der Verweis auf /www/pages/uebertragungen.php in der api_uebertragungen.php).


    Da mal noch als Nebenfrage: Funkt das Übertragungen-Modul hier?


    Ich glaub halt auch, dass mit einem Framework auch die Möglichkeiten der Nutzer bedeutend besser sind. So wie es im Moment für mich aussieht (nur durch einen kurzen Blick auf das Projekt) müsste ich gerade jedes mal meinen Custom-Code neu rein schubbsen, sobald da eine Änderung ansteht. Ist halt die Frage ob man sowas lieber eher als später angeht. (Persönlich bin ich da für "eher" in dem Fall, weil man ja den kompletten Quellcode so oder so überarbeiten muss. Da hat man das gleich in einem Aufwasch...)

  • Codebase in Laravel

    Ahoi in die Runde,

    Ich bin gerade per Zufall über euer Projekt gestolpert - erstmal Respekt für die Idee! :)

    Da ich ein paar Kunden betreue die Xentral-Instanzen am Laufen haben, wollte ich mal nachfragen wie im Moment bei euch die Roadmap aussieht.

    Ich weiß das Xentral selbst gerade dabei ist seine Codebase auf Laravel neu aufzusetzen. Gibt's da bei euch auch Bestrebungen in die Richtung? Soweit ich weiß ist die Codebase der 20.3 noch ein ziemlich unperformanter Clusterf-...