Logeon - Engine per "PbC"

03/04/2026 18:37:43 e modificato da brom87 il 03/04/2026 19:49:51

geko ha scritto: La presentazione del progetto è decisamente più che "potabile": copre in modo completo i contenuti, mantenendo un linguaggio accessibile e riservando il tecnicismo alla sola sezione Architettura tecnica.

Nel resto della discussione, il livello è volutamente meno tecnico: vengono introdotte solo alcune parole chiave, giusto come punti di riferimento.

Quando sono entrato nel tecnico?
Principalmente in uno scambio quasi 1-to-1 con un utente, nel confronto diretto tra progetti.
Capisco che questo possa aver disorientato l'utente medio su questo non posso darvi torto.
D'altra parte, mi è stato anche fatto notare in più occasioni come mancasse un certo livello di approfondimento... incluso quello tecnico.
Diciamo che trovare il "giusto mezzo" è ancora un work in progress😏

Accolgo quindi molto volentieri i feedback e i suggerimenti ricevuti, soprattutto i riferimenti all'utilizzo di tools alternativi: mi stanno aiutando a definire meglio il target.

Per quanto riguarda il confronto tra LoreForge e GDRCD, al momento non esiste una risposta netta alla domanda "perché scegliere uno rispetto all'altro?".
È un po' come chiedere perché scegliere WordPress invece di Drupal o Ghost: la scelta dipende dalle esigenze dell'utente finale e dalla sua percezione, influenzata anche dalle competenze che possiede.

C'è però una differenza sostanziale che rende il confronto, ad oggi, poco significativo: GDRCD è una piattaforma pubblica e consolidata nel tempo, mentre LoreForge non è ancora stato rilasciato.

Di conseguenza, qualsiasi paragone diretto, o l'etichettarlo come "alternativa", potrà essere fatto solo nel momento in cui LoreForge sarà effettivamente disponibile al pubblico.

Colgo l'occasione per ringraziare tutti per il contributo alla discussione e alla presentazione del progetto: il confronto è stato (ed è) estremamente costruttivo e utile.

Chiedo scusa ma ancora non leggo una risposta, solo una complessa elaborazione fatta palesemente con Chatgpt o altre IA e onestamente non mi ispira fiducia. Comunque quello che capisco oltre a questo è che non state offrendo nulla di diverso. Dipende dalle esigenze? Bene esponi quale esigenze soddisfa il tuo progetto e non quelli già esistenti... Mi spiacea non ci siamo...

Nel primo post inoltre parli di alternativa a soluzioni datate, quindi si tu per primo l'hai presentato così, ma rispondendo con IA avrai sempre contraddizioni

03/04/2026 19:53:41

È evidente che non sto utilizzando alcun agente per rispondere.

Sto semplicemente evitando di ripetere concetti già espressi più volte, anche se, a quanto pare, non sempre vengono letti con attenzione.

Alcuni punti, però, meritano di essere chiariti:

- C’è una certa tendenza ad assolutizzare le filosofie dei framework general-purpose, trattandole come standard indiscutibili, più per abitudine che per reale analisi critica.
- Si parla di "discussione seguita", ma molte delle risposte già date, su architettura e scelte progettuali, vengono ignorate o riproposte come se non esistessero.
- Nelle ultime discussioni è stato definito un "affronto" verso pacchetti storici della piattaforma, senza che il progetto sia stato ancora pubblicato: una presa di posizione piuttosto forte basata su zero evidenze concrete.
- Alcuni giudizi sono stati formulati senza aver mai visto la struttura del progetto, partendo da descrizioni volutamente ad alto livello.
- Il progetto è stato dichiarato "morto in partenza" per complessità, il che dice più sull’approccio di chi giudica che sul progetto stesso.
- Prima le risposte erano "troppo generiche", poi quando sono diventate più tecniche sono risultate "troppo complesse": difficile non notare una certa incoerenza nel tipo di critica.

Sia chiaro: il confronto è sempre ben accetto, soprattutto quando è informato e basato su elementi concreti.

Quello che ha meno valore, invece, sono le prese di posizione costruite su supposizioni, letture parziali o interpretazioni superficiali, soprattutto in un thread che nasce come presentazione e non come processo alle intenzioni.

Il progetto verrà valutato per quello che è, quando sarà visibile.

Fino ad allora, preferisco che sia LoreForge (nome ancora placeholder) a parlare, piuttosto che alimentare discussioni basate su ipotesi.

In ogni caso, il feedback utile si è visto, ed è quello che conta.

Grazie a chi ha contribuito in modo costruttivo.

14/04/2026 23:18:39

Ciao a tutti!

Dopo diverso tempo dalla presentazione del progetto, di sviluppo e iterazioni, il progetto ha raggiunto una beta definitiva (versione 0.8.0) e vi lascio questo importante aggiornamento.

Nel frattempo è cambiato anche il nome:
LoreForge diventa ufficialmente Logeon.

Questa fase rappresenta un passaggio importante: il core è ormai stabile e il progetto è pronto per essere esplorato, testato e messo davvero alla prova.

Se siete curiosi di vedere cosa è stato costruito o volete seguirne l'evoluzione più da vicino:

Discord (community e aggiornamenti):
https://discord.gg/gvUvJvYVZR ↗

Repository pubblico (release 0.8.0):
https://github.com/Gekis-Geko/Logeon ↗

Documentazione (in aggiornamento):
https://logeon-studio.gitbook.io/logeon-studio-docs ↗

Se state lavorando a un PbC o state valutando nuove basi tecniche, questo potrebbe essere il momento giusto per dare un'occhiata e farsi un'idea concreta.

Feedback e confronti sono più che benvenuti!

15/04/2026 12:07:32

Quindi, per capire: allo stato attuale non è un pacchetto pronto "tipo WordPress", ma richiede comunque una fase tecnica di preparazione (composer install / generazione vendor) prima del deploy.

In questo senso sembra più orientato a chi ha un minimo di dimestichezza con ambiente di sviluppo e deploy, piuttosto che a un utente che carica i file e avvia direttamente l'installer.

Inoltre, mi pare di capire servano host un po' più delicati e performanti per mantenere l'architettura.
Da quello che leggo, se il pacchetto viene preparato in locale con vendor già incluso, l'host non ha bisogno di composer, e ok; però l'installazione e la manutenzione sembrano comunque più agevoli su hosting meno limitati, più che su quelli gratuiti o ultra-base.

... è corretto?

15/04/2026 12:26:26 e modificato da geko il 15/04/2026 23:53:03

pauraditutto ha scritto:

Ciao, ti ringrazio per la domanda.

La versione sul repository GitHub è la versione per contributori, quindi sì se utilizzi l'applicativo scaricandolo direttamente dal repository devi avere delle competenze sopra la media.

Se esplori il repository trovi una cartella: download/
In questa cartella hai due zip:
- logeon-ready-v.0.8.0.zip è la versione per chi non vuole essere contributore, già comprensivo di vendor e di tutto quello che è necessario per caricare l'applicativo e eseguire la procedura di installazione/configurazione
- logeon-source-dev-v0.8.0.zip è la versione per contributori senza vendor con cs-fixer e PHPStan oltre a tutti gli script per i test, le build i pilots etc.

Piccolo spoiler: ho inviato il pacchetto qui per essere approvato, la versione sarà logeon-ready-v.0.8.0.zip quindi pronta da: scaricare ⤍ caricare ⤍ installare/configurare

Inoltre la demo installata usando logeon-ready-v.0.8.0.zip era su Altervista, quindi, no, non richiede server con delle prestazioni elevate.

15/04/2026 14:43:03 e modificato da blancks il 15/04/2026 14:43:34

geko ha scritto:
- logeon-source-dev-v0.8.0.zip è la versione per contributori senza vendor con cs-fixer e PHPStan oltre a tutti gli script per i test, le build i pilots etc.

Sembra ci sia stata una dimenticanza nell'includere la cartella scripts, per cui di fatto per eventuali contributors non è possibile lanciare phpstan e cs-fixer con i seguenti comandi inclusi nel file composer.json:
- lint:php
- psr:check
- psr:fix

Riguardo PHPStan: ho notato che sostanzialmente il tool è stato usato insieme ad una lista di esclusione inverosimilmente lunga e ad ampio spettro.
Questa: https://github.com/Gekis-Geko/Logeon/blob/main/phpstan-baseline.neon ↗.

Lo scopo del tool dovrebbe essere proprio quello di segnalare tutte le cose che non vanno nel codice (variabili inutilizzate, errori non gestiti, keys non presenti in array etc). Se invece di correggere tali segnalazioni, man mano che si presentano, queste vengono di volta in volta aggiunte alle regole di esclusione, PHPStan viene all'effettivo impiegato soltanto di nome perché un contributor del progetto non può più contare sul tool per evitare il ripetersi di tali errori nel codice nuovo che andrà a scrivere.

In breve: usato così è come non averlo, per cui non posso che domandarmi quale sia l'obiettivo dietro una tale scelta.

Se si tratta di un setup provvisorio perché in questo momento non è in previsione un lavoro di adeguamento mastodontico, come mai non aggiungerlo direttamente quando sarà momento di lavorarci in una PR dedicata fino a completo fix delle problematiche ?

15/04/2026 16:04:50 e modificato da geko il 15/04/2026 16:05:32

blancks ha scritto:

Sì, è stata una svista, ho corretto e pubblicato il necessario sul repository, grazie!

Per quanto riguarda il baseline su PHPStan non è stato introdotto per "spegnere", ma per poter iniziare ad applicarlo su un progetto che ha ancora diverse aree legacy e alcuni file core ad alto rischio, che infatti nella documentazione interna sono già trattati come zone da toccare solo con task mirati e refactor dedicati, non in modo opportunistico dentro PR generiche.

La regola da rendere esplicita per eventuali contributori è semplice: il baseline non deve crescere. Deve solo ridursi nel tempo, man mano che si affrontano i punti critici con interventi dedicati.

Aggiungerò anche un un chiarimento all'interno di CONTRIBUTING.md così che sia evidente a tutti che l’obiettivo non è "far passare verde il CI a ogni costo", ma introdurre guardrail progressivi senza aprire refactor pericolosi nei punti più sensibili del runtime e del core.

Grazie mille per la segnalazione e l'opportunità di chiarimento.

15/04/2026 16:09:03 e modificato da brom87 il 15/04/2026 16:20:15

geko ha scritto:
Se esplori il repository trovi una cartella: download/
In questa cartella hai due zip:
- logeon-ready-v.0.8.0.zip è la versione per chi non vuole essere contributore, già comprensivo di vendor e di tutto quello che è necessario per caricare l'applicativo e eseguire la procedura di installazione/configurazione
- logeon-source-dev-v0.8.0.zip è la versione per contributori senza vendor con cs-fixer e PHPStan oltre a tutti gli script per i test, le build i pilots etc.

Dato che il progetto è su github, come mai questa scelta della sottocartela e piuttosto non si sono create delle release apposite già compilate e scaricabili? Github lo consente e si eviterebbe di avere nel progetto una cartella secondo me inutile contenenti gli zip delle varie versioni e avreste anche la possibilità di mantenere nel progetto lo storico delle release rilasciate con gli opportuni changelog di versione. Non sarà definitiva ma è comunque una prima betha testabile, non è inusuale rilasciare release betha.

15/04/2026 16:31:13

brom87 ha scritto:

È solo per fare differenza tra le 2 distribuzioni, un modo "sporco" al momento di farlo.
Da GitHub scarichi la versione per contributori, quando offro anche l'opportunità di scaricare un pacchetto che è "pronto all'uso".

15/04/2026 16:40:29 e modificato da brom87 il 15/04/2026 16:53:09

geko ha scritto:
È solo per fare differenza tra le 2 distribuzioni, un modo "sporco" al momento di farlo.
Da GitHub scarichi la versione per contributori, quando offro anche l'opportunità di scaricare un pacchetto che è "pronto all'uso".

Capisco il punto, è fondamentale dare un'opzione 'chiavi in mano' a chi non vuole smanettare con le dipendenze.

Però, proprio per evitare il metodo 'sporco', potresti sfruttare la sezione Releases di GitHub. Il vantaggio è che per ogni singola versione puoi caricare due file distinti come asset:

- Carichi il pacchetto logeon-ready.zip (quello completo di tutto).
- Carichi il pacchetto logeon-source-dev.zip (quello per i contributori).

In questo modo l'utente, cliccando sulla release, trova entrambi i link pronti al download. È la soluzione ideale perché:

- Svuoti il repository: Elimini la cartella /download/ e i relativi zip dal codice sorgente, rendendo il progetto molto più leggero e standard.
- Tutto in un posto solo: Chi cerca la beta non deve navigare tra le cartelle del codice, ma trova i due download separati direttamente nella barra laterale di GitHub sotto 'Releases'.
- Storico pulito: Ogni versione avrà i suoi due pacchetti dedicati, senza creare confusione tra i file attuali di sviluppo e i vecchi zip.

Secondo me ti pulirebbe tantissimo il flusso di lavoro ed è una funzione standard offerta da Github molto usata per i progetti opensource.

Poi anche decidere di compilare la release solo per l'utente finale con assets e vendor e il developper invece di scaricare quella scarica la master del repository senza il vendor e con le cartelle di test automatici che non includi nella release...