Sito web Arcade Database

[motoschifo]

La parte di registrazione è terminata, l'ho riscritta usando molte più accortezze ed ho reso opzionale tutto, anche il nome. Avere dei nomi come X o Pippo o peggio ancora insulti, non mi serve a nulla.
Tutte le info extra che ho nel vecchio sito andranno poi rimosse (telefono, genere, ecc.) perchè sono informazioni che non servono più, eventualmente le reintrodurrò all'attivazione della 2FA ma in quel caso è anche più corretto richiederle.

Ho messo la riscrittura con doppio campo anche per la mail perchè non ci crederete ma arrivano parecchie mail scritte male, la gente non verifica nemmeno se mancano delle lettere (tipo gmail.co) e poi scrive arrabbiata che ho è arrivata la mail. Alcuni hanno scritto a 10 secondi di distanza dalla registrazione, immagino avessero già pronta la mail per chiedere spiegazioni, senza poi nemmeno far sapere che era tutto a posto appena confermato.
Quindi doppia digitazione mail e password, poi se vogliono fare copia/incolla perchè sono più bravi pazienza, io il mio contributo l'ho messo.

Sul versante validazioni ci sono molte più regole per evitare errori e dovrei aver previsto tutto ciò che permettono gli RFC ufficiali (5321 e 5322 se ricordo bene).
Ho aggiunto alla fine la verifiche sui domini usa e getta, realizzata dopo aver introdotto la pagina di amministrazione (già non esisteva nemmeno quella...) e i vari router url dedicati.
Per chi non lo sapesse, esistono liste di domini accertati come disposable (usa e getta) che servono per scrivere mail farlocche utili solo ad attivare l'account. Se il dominio rientra in uno di quelli, non è permesso inserirlo (e rimuoverò poi anche tutti quelli passati presenti nel sito attuale).
La lista di quei domini ora è arrivata a circa 130 mila voci, quindi non sono proprio pochi. Ma avere un utente che fa numero a me non interessa, piuttosto meglio anonimo.

Ho completato anche la parte di gestione alias/nomi gmail/googlemail, fatta qualche giorno fa ma mai controllata.

Come si vede dallo screenshot, hanno fatto la comparsa le due voci di ricerca e accando all'avatar ci sarà il tasto che porta alla pagina dedicata alle ricerche. In quella pagina ci saranno per ora 4 tipologie: macchine, software, file, testi. Devo ancora entrare nel dettaglio, ma l'idea è separare le ricerche per evitare di accentrare troppi filtri in una sola, almeno quelle diverse come file e testi, poi da lì sarà sempre possibile ottenere anche la lista in formato romset classica.
Prossimo step: gestione url e ricerca romset Mame.
Sarà un processo lungo, devo ripensare gli input e cercherò di sfruttare i filtri dinamici per alleggerire la pagina.
Oltretutto, non sto più usando jquery (evito librerie vecchie e pesanti), al suo posto sto usando un mix di template Twig e variabili in cache. Dovrebbe essere tutto quanto molto rapido nel render degli oggetti... almeno questo è l'obiettivo!

[motoschifo]

Pensavo di aver finito la pagina di registrazione, invece mi mancavano altre cosette che ho sistemato (separazione validazione/inserimento utente).
Poi mi sono fatto prendere la mano dalla formattazione di numeri e date, così ho esposto la selezione lingua un po' meglio, anzi è diventata la prima voce e al click viene aggiornata dinamicamente.
La gestiono ha richiesto parecchia attenzione, e vale anche per utenti non registrati, quindi l'ordine di importanza è questo:

1) forzatura interna (test)
2) da parametro lang=xx o language=xx, nel formato completo regionale o semplice (it_IT oppure it)
3) da url, es. /en/login, /it/login, /en-US/login
4) dall'utente, se connesso (profilo)
5) dal browser (anche qui formato regionale o compatto, con lista ordinata e peso delle voci)
6) se non risulta nulla, default inglese en_US (condizione rara perchè almeno il browser ha una lingua predefinita)

Per il tema invece sono previsti questi step:
1) forzatura interna (test)
2) da cookies (scelta fatta in precedenza)
3) dall'utente (che poi li salva nei cookies)
4) da browser
5) se non risulta nulla, tema automatico (quindi sistema operativo)

Ho fatto tradurre all'AI alcune lingue e non ho visto grossi problemi, ovvio che poi un giro manuale dovrà essere fatto ma in generale potrò attivare le varie lingue senza troppo sforzo.
Manca la selezione popup da avatar ma per oggi mi fermo qui.

Ieri ho anche implementato parzialmente i job schedulati di sistema e dell'utente, una novità rispetto al vecchio sito e molto importanti. In pratica funzioni speciali come export liste innescheranno la partenza di un job in background e al termine ci sarà l'avviso con popup o mail, in base alla richiesta dell'utente. Questo consentirà di gestire una coda e quindi di evitare troppe funzioni tutte insieme. Se oggi in 20 esportano un xml partono 20 export che fanno sedere il server, domani partirà un lavoro solo e 19 resteranno in coda. Questo permetterà di avere il server meno impegnato e più rapido nelle risposte.

[motoschifo]

Dopo altri giorni di lavoro sono finalmente arrivato ad un punto stabile per quanto riguarda le lingue.
Infatti mi ero accorto di un problema all'aumentare del numero di pagine/lingue che mi avrebbe complicato non poco la stesura di aggiornamenti, così ho rivisto le funzioni e raggruppato meglio i nomi per evitare conflitti.
Adesso ho fatto una prova con 10 pagine in 30 lingue e non ho rilevato alcun problema di prestazioni o di allineamento traduzioni, quindi direi che manterrò questa gestione.
Ho provato anche lingue con differente orientamento, come l'arabo, e varianti regionali (en_US / en_GB) e vengono gestite alla perfezione. Ovviamente in questo caso ci sono delle accortezze da usare, banalmente margin-left e margin-right non funzionano più perchè andrebbero invertiti. Ma basta saperlo per tempo e si corregge rapidamente.

Allego qualche screen, comunque direi che al rilascio inizierò con ita/eng e poi settimanalmente aggiungerò lingue fino a quando riuscirò ad avere traduzioni decenti con Google/AI. Da qui, pubblicherò su github per chiedere aiuto a qualche traduttore appassionato di retrogame, se mai vorrà contribuire.
Sta diventando un progettino molto interessante, e siamo appena agli inizi

[motoschifo]

Da ieri sera ad oggi ho esplorato invece la parte più interessante, quella della ricerca.
Premesso che il codice javascript vecchio è stato "buttato", mi ero scritto circa 20 mila righe js + jquery che col tempo erano diventate poco gestibili, sono quindi partito da zero (vanilla js senza jquery ne altre librerie).
Quindi ho affrontato il problema delle chiamate ajax, dei submit, del numero di pagina, infinity scrolli, action abilitate lato client/server, aggiornamento parametri, url, ecc.
Per ciascuno di questi aspetti, dopo una breve indagine, ho realizzato un piccolo pezzettino che nei prossimi giorni renderò strutturale per gestire tutte le funzioni che dovranno arrivare.

In dettaglio, la pagina viene generata lato server con i componenti minimali (layout standard con sidebar, avatar, menu, ecc.) e ci sarà un tasto "Cerca". In futuro arriveranno anche Esporta, Condividi, Opzioni, ecc. ma per ora basta quello. Il tasto ha un'azione (quelle che prima mettevo come ?ajax=funzione) che sarà gestita completamente in automatico, per esempio il tasto di ricerca gestisce l'azione/funzione server "Ricerca".
Alla pressione del pulsante o del tasto invio, ci sarà un primo submit della form con tutti i parametri impostati. Quei parametri saranno riportati nell'url, che quindi rispecchierà esattamente i filtri di ricerca.
Condividere un link sarà banale: copia e incolla.
Ecco un esempio di quando inserisco come ricerca la parola "metal": /search/machines?text=metal

Una volta eseguito il form submit, lato server sarà effettuata la ricerca e saranno forniti i dettagli da aggiornare pronti per il render, ovvero già in html formattato. Sarà quindi sempre il server a gestire questo aspetto, almeno inizialmente. Una volta ricevuta la pagina, eventuali azioni speciali potrebbero modificare questi blocchi (es. aggiungo il gioco tra i preferiti) e sarà a quel punto il client a modificare parzialmente gli oggetti (il minimo indispensabile, direi aggiungere/togliere classi html non di più).

Scorrendo con il mouse la lista, arrivati verso la fine partirà una seconda ricerca che caricherà la seconda pagina, e così via fino a quando ci saranno pagine disponibili.
Gli elementi già caricati non saranno toccati da modifiche, un eventuale menu aperto rimarrà aperto.
I filtri a video, se vengono cambiati, non rispecchieranno ne l'url ne la ricerca, ma occorrerà premere nuovamente il pulsante Cerca (o invio).
In questo modo il comportamento è coerente e prevedibile, non genera artefatti (tipo caricare blocchi parziali) e l'utente può usare quel link in sicurezza. Alcuni siti ad esempio se cambi un parametro e poi carichi la terza pagina, usano quel filtro anche se hanno già caricato due pagine, quindi il risultato diventa incoerente.

L'url però gestisce anche le lingue, quindi potrebbe arrivare con parametri come "?lang=it", ¨?language=fr", "/en-gb/search/machines", ecc. In questo caso il backend dirotta la pagina verso la versione neutra (es. /search/machines) e mantiene tutti i parametri impostati. Quindi la condivisione del link in altra lingua non modifica la lingua che ho scelto sul mio pc, cosa che ad esempio il sito di oggi fa. Per le api si applica un discorso diverso, la lingua dovrà essere sempre passata come parametro o come url (anche questo problema risolto rispetto ad oggi).

Questo sistema, all'apparenza semplice, se approfondito e gestito per siti ad alto traffico e multilingua è decisamente complesso. Il fatto di aver messo le basi per questi componenti mi mette al riparo da chiamate continue al server, spesso inutili, o da incongruenze nella lettura dei parametri.

Metto lo screen ma si tratta di un test con nome/titolo del gioco, giusto per capire se il sistema regge sotto stress. Però mi ricorda molto i primi esperimenti del sito che avevo fatto poco più di 10 anni fa (vedi allegato).
La cosa inizia a farsi molto interessante.

[motoschifo]

Piccolo aggiornamento sulle lingue, giusto per completezza.
Dopo essermi letto ogni possibile documento per gestire al meglio le lingue di tutto il mondo, ho deciso di migliorare ulteriormente l'attuale gestione introducendo la modifica dei font per una dozzina di lingue: in quei casi, il font di default cambia perchè curve e ideogrammi sono resi meglio e la distribuzione dei caratteri è più uniforme in testi lunghi.
Avrei potuto ignorare queste cose, ma le differenze in effetti erano apprezzabili (in meglio).
Ho anche scoperto che le icone che indicano una direzionalità vanno invertite di verso nelle lingue che si leggono da destra a sinistra, tutte le altre no. Cercherò di ricordarmelo quando sceglierò le icone giuste.

[motoschifo]

Si procede con la scelta dei filtri, che ho gestito in maniera più moderna tipo quello che fanno ElasticSearch o MongoDB.
Non ho nulla da mostrare come screenshot ma la logica sarà questa: anzichè lavorare con centinaia di parametri della form, che poi mi obbligano a fare altrettante centinaia di variabili diverse, potrò agilmente lavorare su un filtro già preparato con campi/operatori/valori. Questo genererà una prequery (ne parlerò più avanti) che poi genererà la query vera e propria.
Ecco un esempio di filtro con condizioni and/or annidate:

Codice: Seleziona tutto

$filters = [
  'and' => [
     ['genre', 'eq', 'platform'],
     ['year', 'between', [1900, 1995]],
     [
        'or' => [
          ['title', 'like', $search],
          ['romset', 'like', $search],
        ]
     ]
  ]
];

Lato front-end si potrà creare un filtro usando uno o più campi e uno o più operatori, dovrò cercare di renderlo facilmente comprensibile e semplice da modificare, mentre lato back-end potrò evitare di fare parsing e logiche complesse, penserà a tutto un normale deserializzatore json.
I nomi dei campi sql non saranno mai esposti, così come operatori e valori, quindi problemi come sql injection sono risolti in partenza senza sforzo.

Teoricamente l'operatore potrebbe a sua volta essere un intero filtro avanzato (o ricerca custom) quindi la cosa si evolverà ancora di più quando introdurrò ricerche/liste pubbliche e prequery parziali (usate soprattutto per motivi prestazionali).
In pratica le ricerche più usate, o quelle che coinvolgono i filtri più comuni, potrebbero essere messi i una lista temporanea per snellire il carico e poi su questa lista aggiungere i filtri non presenti.
Ma è presto parlarne ora, diciamo che questa gestione filtri mi piace molto ed è decisamente più potente rispetto a quella di prima.

Intanto un altro piccolo aggiornamento sulle lingue: ho messo le mani avanti ed ho esplorato la traduzione tramite AI. Come semilavorato è molto buono, sicuramente da affinare, ma sono in grado di preparare un elenco di termini da tradurre da dare in pasto ad una AI e poi copia/incollare il risultato in un file, che sarà processato e che smisterà/aggiornerà tutti i termini trovati. Questo contemporaneamente per qualsiasi lingua, come può avvenire all'aggiunta di una form o di una pagina. Quindi mi basterebbero un paio di copia/incolla (e build/rilascio) per aggiornare in un colpo solo tutti i termini mancanti in tutte le lingue gestite.
Non credo che ci siano oggi molti sistemi come questo, anche se per me è quasi scontato averlo dovendo gestire tante lingue insieme. Eppure mi sono dovuto fare manualmente un sacco di funzioni e di utility, non esiste nulla di "standard" già pronto.

[motoschifo]

Per curiosità ho chiesto a Claude cosa ne pensa, sembra che gli sia piaciuto.
È riuscito a capire quasi tutto il sorgente che gli ho mandato, almeno in quello è stato bravo.
I suggerimenti che mi ha dato non mi servono perchè non uso quel tipo di query (regex, sound like e json), mi sembrano più da framework, ma anche qui ha dimostrato inventiva.

[motoschifo]

Primo test di render del quadro del gioco, giusto per capire quali elementi/accostamenti fare.
Come icone utilizzo Google Icons e Google Symbols, come colori devo stare attento ai temi dark quindi sto limitando a poche tonalità.
Ricorda molto la vecchia ricerca ma dopo diverse prove ho visto che è quella più funzionale, mentre non farò le altre modalità che forse nessuno ha mai usato (mosaico, tabella, elenco).
Quindi ho svecchiato il layout e rifatto l'icona dello stato (in realtà è un gradiente non è un'icona). Completano fino a 3 icone laterali:
- se clone
- se mamecab, arcade, mechanical, device o bios (in questo ordine)
- se usa chd

La pagina parte piccola e se la ricerca supera i 10 elementi si espande fino a tutto lo schermo. Questo sistema, unito ad una leggera animazione, aiuta a sfruttare tutto lo schermo anche su display molto grandi, e permette di non avere un contenuto piccolo a sinistra poco leggibile. Dovrei aver trovato il giusto compromesso per evitare mal di mare dovuti a campi improvvisi di layout.

Metto anche i due vecchi layout per un confronto diretto.
Appena sistemato qualche dettaglio passerò alla gestione e creazione di tutti i filtri; dovrei riuscire a semplificare notevolmente sia la parte utente (scelgo quali filtri applicare) sia quella backend (processo i filtri selezionati). Userò molto probabilmente un sistema a badge/tag in cui tutti i filtri applicati saranno visibili e potrò rimuoverli o modificarli con un click. La selezione di un filtro invece sarà il vero punto critico e dovrò cercare di raggruppare per tipologie come in parte fatto sul nuovo MameShrink.

[motoschifo]

non avendo creato un sito di test, ho fatto una registrazione di qualche secondo per rendere l'idea del lavoro svolto ad oggi

[motoschifo]

Week-end molto proficuo, ho smarcato tre "grossi" problemi che ho sempre avuto con i file e la cache dei browser (gestita malissimo, anzi non gestita proprio sull'internet moderno).
Aspetto secondario per alcuni, fondamentale per altri, è quando mettere i file in cache e quando rinnovarli a seguito di un cambiamento.

Nel futuro sito la gestione è allo stato dell'arte, ovvero:
- tutti gli asset statici (js, css) hanno un codice diverso in caso di modifica al file singolo, non per tutti
- tutti gli asset variabili (immagini, file, binari, liste) usano la funzione del web server per marcare la modifica, e nei browser moderni supportano l'header che evita il download se identico all'ultimo controllo
- tutti i file speciali hanno la loro gestione tramite handler php che ne gestirà limiti e diritti
- il browser elimina dalla cache tutti i file non più validi, ovviamente relativi a questo sito e non di tutti quelli presenti in cache

In questo modo avrò parecchi vantaggi:
- i file javascript e gli stili css saranno sostanzialmente statici e mai più scaricati, se non la prima volta o quando effettivamente cambiano (es. a ridosso di un aggiornamento potrebbero cambiare 10 volte, poi mai più). In questo caso l'elaborazione non arriva mai ne a php ne sul database, ma rimane al web server apache
- i file generici di immagini legati ai romset possono gestire il flag di "cambiato" e quindi apache e il browser si fanno carico del problema, ovvero cpu e memoria risparmiati in quanto non interviene php. Il database non viene disturbato nemmeno qui, altre risorse risparmiate
- i file speciali o richiesti tramite link e che non hanno corrispondenza diretta su disco (es. /emulators/mame/0.279/gamelist.xml non esiste ma viene ricostruito dal link), sfruttano php ed eventualmente database per fornire tutto quanto; anche qui nel caso è gestita la cache che evita il download, oppure viene innescata un'elaborazione sul momento come l'export di una lista
- al termine di tutta questa logica, può intervenire il browser e cancellare gli stili non più usati

Normalmente questa gestione non la vedo pensata nemmeno su siti grossi, figuriamoci su siti piccoli e creati per hobby. Il caso più classico è aggiungere un suffisso al nome (es. /css/stile.css?release=123) per forzare il download, ma i file precedenti rimangono tutti (dalle versioni 1 alle 122 non saranno mai più consultati).
Come conseguenza di questo, mi aspetto un utilizzo di cpu e ram notevolmente ridotti, ovvero più capacità del server di rispondere prontamente alle richieste nelle ore più trafficate.

Come conseguenza è sorta l'esigenza di un quarto router di "download", ovvero avrò classi per gestire pagine utente, api, pagine di amministrazione ed ora anche download.
I router, per chi non è tecnico, servono per separare il traffico ed evitare di rovinare codice in altri punti a fronte di modifiche su classi comuni. Per es. fai una modifica all'area di download o admin e non va più la lista dei giochi.

In aggiunta ho messo una funzione per caricare le immagini nella pagina di ricerca solo quando effettivamente mostrate a video. Oggi essendo link <img> vengono caricate tutte, dopo avremo il download di una riga per volta ogni volta che sposteremo la pagina verso il basso. Anche questo contribuisce a limitare la banda usata se non strettamente necessario, quindi riduce l'overhead del server che rimane pronto per richieste di altri utenti (o api).

Credo di aver fatto un lavoro molto valido ad oggi, sto coprendo man mano tutti i vari aspetti al meglio delle mie possibilità, e mi sta pure piacendo...
L'unico vero problema è che gestire queste cose richiede non solo tempo ma anche uno schema mentale e non sempre sono propenso a fare questi algoritmi complicati, specialmente in tarda serata

[motoschifo]

Da alcuni giorni sono fermo sui filtri, è complesso gestire un filtro avanzato e modulare con operatore.
Vorrei fare qualcosa simile al prototipo di qualche anno fa, che nel suo "piccolo" funzionava molto bene.

new-filters-1-prototype.png

Sono passato per un contenuto "prepend/append" in modo da legare l'input ad un operatore, ma non mi convince. Molto bello esteticamente, appena aggiungo condizioni complesse (in, not in, between) già ci sono problemi perchè vedrei tanti input uno dopo l'altro, con il pulsante X di chiusura e con quello di aggiunta filtro.
L'elenco degli operatori è indicativa, un testo avrà solo alcuni di questi, un numero anche, ecc. Li ho messi tutti quanti per fare delle prove di carico.

new-filters-2.png

new-filters-1.png

Una terza variante è quella con i tasti colorati, non mi piace per niente ma era giusto tentare anche strade diverse.

new-filters-3-alternate.png

La complessità è dovuta al fatto che javascript non è usabile, nel senso che solo il server conosce il filtro (traduzioni, valori ammessi, condizioni, elenchi, ecc) e solo lui lavora la parte html con il render. Javascript si limita a coordinare i vari pezzi, quindi il tasto "+" clona un blocco, il tasto "X" lo elimina, ecc.

Manca ancora la parte di selezione filtro, ma un pezzo alla volta faremo tutto..
Complice il caldo e il poco tempo a disposizione, per il momento non vedo la luce ma magari è dietro l'angolo che mi aspetta.

[pucci]

Da alcuni giorni sono fermo sui filtri, è complesso gestire un filtro avanzato e modulare con operatore.
Vorrei fare qualcosa simile al prototipo di qualche anno fa, che nel suo "piccolo" funzionava molto bene.

new-filters-1-prototype.png

Sono passato per un contenuto "prepend/append" in modo da legare l'input ad un operatore, ma non mi convince. Molto bello esteticamente, appena aggiungo condizioni complesse (in, not in, between) già ci sono problemi perchè vedrei tanti input uno dopo l'altro, con il pulsante X di chiusura e con quello di aggiunta filtro.
L'elenco degli operatori è indicativa, un testo avrà solo alcuni di questi, un numero anche, ecc. Li ho messi tutti quanti per fare delle prove di carico.

new-filters-2.png

new-filters-1.png

Una terza variante è quella con i tasti colorati, non mi piace per niente ma era giusto tentare anche strade diverse.

new-filters-3-alternate.png

La complessità è dovuta al fatto che javascript non è usabile, nel senso che solo il server conosce il filtro (traduzioni, valori ammessi, condizioni, elenchi, ecc) e solo lui lavora la parte html con il render. Javascript si limita a coordinare i vari pezzi, quindi il tasto "+" clona un blocco, il tasto "X" lo elimina, ecc.

Manca ancora la parte di selezione filtro, ma un pezzo alla volta faremo tutto..
Complice il caldo e il poco tempo a disposizione, per il momento non vedo la luce ma magari è dietro l'angolo che mi aspetta.

Praticamente stai implementando quelli che io chiamavo insiemi quando fai un pipe tra i filtri legandoli con IN, NOT IN, BETWEEN

Inviato dal mio LE2113 utilizzando Tapatalk

[motoschifo]

Non sono propriamente insiemi perchè le condizioni puoi legarle solo con AND, mentre l'intera riga sarà in OR. Ma arriveranno anche quelli.
La parte più complessa è rappresentarli e far capire cosa sono senza dover diventare troppo tecnici o stravolgere troppo la pagina.
Confido una volta smarcati i filtri di introdurre i veri "insiemi" e quindi le operazioni classiche di intersezione, unione, ecc.
Purtroppo sono in alto mare con i filtri per ora, sto provando diverse soluzioni ma la complessità è alta. C'è una piccola lucina in fondo al tunnel e mi sto aggrappando a quella per uscirne.