ArcadeItalia.NET

non per offendere l'utente medio (per me sono chiare ovviamente ) ma mi sembra un pò macchinoso/complesso

motoschifo ha scritto: ↑11/01/2023, 20:35 Forse ho trovato il modo, ma vorrei capire se è leggibile.
Prima di ciascun valore metterò la condizione, una tra queste: UGUALE, DIVERSO DA, INTERVALLO, MAGGIORE, MAGGIORE, MINORE.
A queste di base si potrebbero aggiungere condizioni speciali, come VUOTO, NON VUOTO.
Le voci dei filtri in questo caso cambieranno, ovvero alla selezione di INTERVALLO compariranno due campi anzichè uno, alla selezione di VUOTO scomparirà tutto, ecc.
I campi però saranno tutti raggruppati per il tipo di filtro (ex. anno, serie, ecc.) e poi prima di ciascun valore si leggerà la condizione.

Per esempio potremo avere queste condizioni:
Anno=2003, Anno=2006, Anno>2010, Anno<>2013

che si legge in:
Tutti i giochi (insieme completo) con anno uguale a 2003 OR 2006 OR maggiore di 2010 AND diverso da 2013
Quindi le condizioni normali vanno in OR, quelle negate vanno in AND.

Ha senso una cosa di questo tipo? Io le leggo come query, quindi sono di parte e le trovo corrette, ma lette da persona non tecnica appaiono ancora corrette?
Se invece trattassi tutti i filtri in OR, non 2013 è sempre diverso da 2006 e quindi si escluderebbero a vicenda prendendo sempre tutto o nulla dell'insieme di partenza.

Tutte queste condizioni saranno salvabili rapidamente e con poco sforzo in ricerche dinamiche o tramutabili in liste statiche, così per poterle sfruttare più facilmente in altre condizioni.

premetto che non ho letto tutto il thread e quindi non è che sono aggiornatissimo...ma mi baso solo sugli ultimi punti.
Io che non sono un SWista ne un tecnico informatico ci ho messo un po' a focalizzare, non nell'immediato, ma alla lunga è abbastaza chiaro....ma se punti/guardi alla massa (l'utente genericomedio-basso delle salegiochi anni80-90 praticamente ) non ci capirebbe moltissimo secondo me

per intenderci semplicemente sintetizzando.....il bresciano generico medio per OR intende le guarnizioni in gomma dette Oring

Faccio qualche esempio pratico per spiegare meglio.
Mettiamo di voler cercare Pacman nel catalogo giochi del Mame.

Lo si può cercare semplicemente dal nome:
oppure si aggiunge il filtro "Anno" (va selezionata, nella maniera più facile che riuscirò a trovare, da una lista a menu):

oppure posso cercare per più anni (sono indeciso ma ho qualche valore in mente):
Oppure ho solo un periodo e sono sicuro che non sia di un certo anno:
tutti questi filtri, combinati, danno una condizione con AND/OR/NOT mescolati su più livelli, quindi i valori multipli saranno in OR, quelli sui campi andranno in AND e quelli con condizioni speciali tipo "diverso da" andranno in AND (altrimenti non otterrei risultati congruenti.
È grossomodo quello che viene fatto dai motori di ricerca, dove la maggior parte delle persone mette una parola, chi è più esperto indica opzioni (keyword, dominio, formato file, ecc) e chi vuole il massimo indica molte opzioni e varianti.
Il mio dubbio iniziale non era relativo alla complessità dietro le quinte, quella c'è ma la gestisco io, quanto alla chiarezza che può risultare all'utente e quindi capire se indicando due volte un anno nel filtro capisco che voglio cercare per uno oppure per l'altro.

Secondo me è chiaro, ma sto cercando metodi alternativi per pulire la grafica e renderla meno pesante.
Quello però che non posso/voglio fare è gestire due pagine diverse di ricerca, uno dedicato ad utenti occasionali ed uno ad utenti esperti.
Per questo motivo la prima riga è sempre visibile a tutti, e forse diventeranno due (nel caso di utenti connessi ci saranno le ricerche salvate). Ma oltre non posso andare, nel senso che non posso indicare più filtri perchè risulterebbe contenuto inutile per chi non li usa e poco utile per chi lo vuole usare su più valori insieme (i filtri in alto infatti non possono essere indicati più volte).

Unita questa gestione, sto cercando il modo di rendere i filtri "preferiti" e quindi mostrarli sempre ad ogni ricerca (salvando i dati nei cookies). Così facendo, se uso spesso anno e romset, li avrò a disposizione comodamente senza doverli cercare in una lunga lista.


Sto anche valutando di unire i dati, quindi non avere l'etichetta "Dal" prima del valore ma tutto dentro alla lista, così da rendere un solo input e facilitare la lettura a schermo.
Ecco un esempio non funzionante ma per rendere l'idea:

@motoschifo era molto chiaro anche prima

resto cmq perplesso sull'usabilità da parte dell'utente medio di filtri and/or/union e quant'altro

motoschifo ha scritto: ↑11/01/2023, 20:35 Per esempio potremo avere queste condizioni:
Anno=2003, Anno=2006, Anno>2010, Anno<>2013

che si legge in:
Tutti i giochi (insieme completo) con ((anno uguale a 2003 OR 2006 OR maggiore di 2010) AND diverso da 2013)
Quindi le condizioni normali vanno in OR, quelle negate vanno in AND.

Ha senso una cosa di questo tipo? Io le leggo come query, quindi sono di parte e le trovo corrette, ma lette da persona non tecnica appaiono ancora corrette?
Se invece trattassi tutti i filtri in OR, "NOT 2013" è sempre diverso da 2006 e quindi si escluderebbero a vicenda prendendo sempre tutto o nulla dell'insieme di partenza.

non hai alternatiVe a questo "((anno uguale a 2003 OR 2006 OR maggiore di 2010) AND diverso da 2013)"
ma sinceramente non è così "intuitivo"

Ricerche complesse richiedono conoscenza, non so quanto sia semplificabile.

@motoschifo Il "nome semplificato" che vedo su adb lo hai "creato" tu ? Oppure esistono metadati con queste info ?

cybermat ha scritto: ↑13/01/2023, 0:24 @motoschifo Il "nome semplificato" che vedo su adb lo hai "creato" tu ? Oppure esistono metadati con queste info ?

Si l'ho inserito io per avere un nome generico a fronte di sigle e cloni vari.
Ne abbiamo parlato tempo fa qui: viewtopic.php?p=355870#p355870

cybermat ha scritto: ↑13/01/2023, 0:24 Ricerche complesse richiedono conoscenza, non so quanto sia semplificabile.

@motoschifo Il "nome semplificato" che vedo su adb lo hai "creato" tu ? Oppure esistono metadati con queste info ?

è quello che uso nello scraping per "accorpare", utilissimo

Sto arrivando al termine della mia "ricerca" di avere un filtro personalizzabile e facile da usare.
Come layout al momento siamo a questo punto, anche se nulla di quello che c'è sullo schermo funziona (si tratta sempre di esperimenti, l'implementazione richiederà tempo).



In sostanza ho pulito la lista dei filtri disponibili e siamo arrivati a circa 140 elementi. Per ciascuno di questi elementi sarà possibile applicare un'operazione (es. uguale a, diverso da) e se supportato anche più di un valore (es. uguale a 1950, diverso da 2000, maggiore di 1999, inizia per "pac", contiene "man", ecc.)

Oggi alcuni filtri sono presenti in più varianti (uguale a, da/a, ecc) e generavano un po' di confusione e di contenuto extra/inutile. Inoltre non avevo modo di includere tante altre operazioni senza appesantire l'interfaccia rendendola inutilizzabile. Inoltre mi ero fermato nell'aggiungere filtri proprio perchè erano troppi dati da mostrare a video.

I dati utilizzeranno componenti nativi e quindi molto comodi da selezionare anche tramite smartphone.

Le operazioni saranno interpretate dal sistema come detto sopra nei post precedenti, quindi la "complessità" di quanto viene mostrato a video dipenderà dalla conoscenza tecnica dell'utente, ovvero se non ha capito come funzionano gli basterà non aggiungerne di altri ed usare quando presente di base.

Come ultima cosa, ho pensato di predisporre un pannello di ricerca "base", sempre visibile o comunque facilmente raggiungibile, che è simile a quello che c'è oggi sul sito (non conterrà tutti i filtri ma circa una decina). Questo permetterà a chi non se ne intende di continuare ad usare il sito come ha sempre fatto.
Per chi invece vorrà di più, sarà possibile passare al filtro avanzato in cui appunto saranno indicati i filtri che vediamo nello screenshot.
Questa opzione sarà salvata nei cookies, quindi potrò passare da una all'altra modalità e sperimentare così qualcosa di più avanzato.
Nel passaggio da filtri base a filtri avanzati posso tentare di mantenere i dati inseriti, nel passaggio contrario invece non sarà possibile in quanto la parte base non permette tutte le operazioni previste.

Le operazioni a disposizione sono queste e vengono mostrate in base al tipo di filtro coinvolto:

• Uguale a
• Diverso da
• Minore di
• Minore o uguale a
• Maggiore di
• Maggiore o uguale a
• Contiene
• Non contiene
• Inizia per
• Non inizia per
• Finisce per
• Non finisce per
• Presente in
• Non presente in

al momento non voglio gestire operazioni speciali senza valore come "valorizzato" o "non valorizzato" ma non escludo di poterlo fare in futuro.

Comunque credo di essere arrivato a buon punto, i filtri stanno assomigliando a quello che mi ero immaginato anni fa.
Spero di riuscire ad implementare tutto ciò che ho scritto qui, e soprattutto di renderlo fruibile nel migliore dei modi.

GIà che stai facendo tutti questi lavori al sito (che apprezzo moltissimo) mi manderesti l'elenco delle macchine prive di immagini (escluso le SL)? Avrei intenzione di colmare le llacune, onde evitare che una ricerca effettuata su ADB mostri niente come risultato.
Inoltre vorrei sapere se in futuro tali ricerche più complesse saranno estese alle liste software.

@motoschifo @AntoPISA

che coppia ragazzi!!!

AntoPISA ha scritto: ↑13/01/2023, 16:43 GIà che stai facendo tutti questi lavori al sito (che apprezzo moltissimo) mi manderesti l'elenco delle macchine prive di immagini (escluso le SL)? Avrei intenzione di colmare le llacune, onde evitare che una ricerca effettuata su ADB mostri niente come risultato.
Inoltre vorrei sapere se in futuro tali ricerche più complesse saranno estese alle liste software.

Puoi cercarle usando i filtri avanzati (Extra / Immagini) e scegliere quale delle immagini considerare tra tutte quelle supportate:
Senza immagine del gioco
Senza immagine del titolo
Ovviamente puoi aggiungere tutti i filtri che vuoi, l'importante è togliere quelli che potrebbero dare fastidio (tipo ultima release e solo mamecab).

Prima di un eventuale aggiornamento dovrò rivedere ogni pagina del sito, è cambiata la struttura interna quindi anche la ricerca software list dovrà usare quel tipo di condizioni.

Grazie per i link alle ricerche (che probabilmente tempo fa mi avevi già dato), appena ho un po' di tempo controllo.

Sono sempre più vicino al risultato, nello specifico ho potuto pensare ad una gestione migliore usando dei blocchi per inserire le condizioni in AND (quindi condizioni tutte valide tra di loro) e in OR (almeno una valida).
Per esempio qualcosa del genere:


Non sono ancora ad un punto finale perchè questo tipo di gestione "rompe" completamente gli schemi di oggi, ossia sono costretto a non usare più i parametri che usavo prima e così dovrò in qualche modo gestire ugualmente la compatibilità con il passato e la gestione lato browser.
In pratica gestire link del tipo /mame-search?game_year=1980&genre=100

In realtà non potranno essere composti in quel modo perchè non riuscirei a gestire tutte le casistiche, e la rottura sta proprio qui.
Per spiegarla a chi non è tecnico, diciamo che quando viene servita una pagina web esiste la lista dei parametri in ingresso (es. 'game_year' con valore '1980' e 'genre' con valore '100') ed oggi da quella lista genero una ricerca sul database. Il problema sta proprio nel fatto che la lista nel mio caso potrebbe avere più valori uguali e per ciascun valore potrebbe avere una diversa operazione sul dato (uguale, maggiore, ecc).
Fino a questo momento ho gestito la cosa cambiando il nome, nella maniera standard in cui fanno tutti i siti, ovvero gestire fino a 10 nomi diversi per ciascun parametro (game_year_maggiore, game_year_maggiore_uguale, game_year_diverso, genre_diverso, ecc.)
Questo però porta alla moltiplicazione di tutti i filtri (150 oggi, 200 domani) per le 10 operazioni, ovvero 2000 variabili diverse. Troppe da gestire senza incontrare problemi.
La strada che sto percorrendo ora è che la lista dei parametri viene processata da una routine che la trasforma nei nuovi, passati poi al client (quindi la pagina è vuota) che a sua volta richiama il server con i parametri corretti per poter effettuare la ricerca (contenuto dinamico).
Così facendo avrei una pagina di ricerca molto pulita e leggera a prescindere dal numero di filtri (poche migliaia di byte rispetto al quasi milione di byte di oggi), un preprocessore che si occupa di trattare i dati e trasformarli in parametri corretti (solo la prima volta che la pagina viene aperta) ed una richiesta dati che potrebbe mettere in cache la composizione finale.
In altre parole, la richiesta delle pagine 2 e 3 non andrebbe a riprocessare tutti i parametri (lavoro inutile se sono uguali a prima) e avrei una risposta molto più rapida (come succede oggi che ho milioni di richieste).

Sono entrato nel tecnico ma si rende necessario per capire e spiegare le varie scelte che sto effettuando.

La grafica non mi piace ancora comunque, sto cercando di gestire il multivalore in maniera più chiara.
Se questo tipo di rappresentazione funziona bene, potrei gestire per qualsiasi filtri supportato un elenco di operazioni e valori multipli senza alcuno sforzo aggiuntivo rispetto alla gestione singola, e tutto ciò consentirebbe in pratica di farsi le proprie ricerche con la massima libertà possibile.
Che poi è lo scopo primario di questa riscrittura, quello secondario è ridurre il carico sul server che già oggi fa fatica a rispondere a tutti.

Sto effettuando delle ricerche (semplici) su ADB e la risposta del sito è lentissima. E' normale Michele?

Gli accessi sono aumentati, il server è sempre pieno di richieste e ci sono momenti in cui non risponde proprio.
La revisione che sto facendo dovrebbe alleggerire anche il carico complessivo, nel frattempo non ho soluzioni immediate quindi l'unica è riprovare.
Se vedo che non si stabilizza posso interrompere gli scraper ma preferirei non arrivare a tanto.

Oggi ho visto che il server si è "seduto" per le tante richieste, unite anche alle elaborazioni pesanti che sto cercando di migliorare riscrivendo tutto il sito. Ma questo arriverà più avanti.

Ho quindi fatto qualche indagine per capirne la causa ed ho visto che il recupero info da programmi esterni (scraping) non è gestito bene.
In poche ore di attività ho visto 300 mila richieste di giochi diversi (a volte lo stesso gioco dallo stesso ip, forse un errore di programmazione di qualcuno o un programma lanciato più volte).
Io ho scritto dappertutto che è consigliato, quando possibile, unire le richieste e magari ottenere dati su più giochi insieme e limitare il numero di connessioni totali allo stretto necessario, ma vedo che in pratica nessuno lo fa.
Così ho deciso in futuro di chiudere dei pezzi e limitare l'accesso ad un massimo giornaliero per indirizzo ip.

Oggi sto solo raccogliendo dati, ma il prossimo aggiornamento introdurrà questo tetto massimo di richieste per giornata.
Potrei impostarlo inizialmente a 30 mila e ridurlo poi man mano fino a 5 mila.
Ad esempio un set completo del Mame, ammesso che uno voglia averlo tutto (e già questo è discutibile, dato che si dovrebbe cercare sempre di andare per upgrade progressivi), "costa" fino a 50 mila richieste. Accodandole per gruppi di 400 giochi alla volta si ottiene un valore prossimo al centinaio, che è molto più gestibile e mi viene da dire anche più veloce per chi lo utilizza.
Quindi, anzichè scandagliare tutto ogni volta, bastarebbe gestire la data di ultima richiesta, farne al massimo 1 al giorno (quindi cache sul client) e unire tutte le richieste in uscita in poche chiamate cumulative.

Non ho deciso i dettagli, l'idea è questa e nei prossimi giorni dovrò lavorare al database per manutenzione ordinaria quindi il tutto rallenterà un pochino più del solito.
In ottica futura sto comunque rendendo le pagine e le elaborazioni molto più leggere (o meglio più "intelligenti") per avere meno carico possibile sul server e sul database. In pratica, con l'hardware attuale, si dovrebbe vedere un bel salto in qualità e velocità anche all'aumentare degli utenti. Ma di questo ne riparliamo a natale... spero...

motoschifo ha scritto: ↑04/02/2023, 20:58 Oggi ho visto che il server si è "seduto" per le tante richieste, unite anche alle elaborazioni pesanti che sto cercando di migliorare riscrivendo tutto il sito. Ma questo arriverà più avanti.

Ho quindi fatto qualche indagine per capirne la causa ed ho visto che il recupero info da programmi esterni (scraping) non è gestito bene.
In poche ore di attività ho visto 300 mila richieste di giochi diversi (a volte lo stesso gioco dallo stesso ip, forse un errore di programmazione di qualcuno o un programma lanciato più volte).
Io ho scritto dappertutto che è consigliato, quando possibile, unire le richieste e magari ottenere dati su più giochi insieme e limitare il numero di connessioni totali allo stretto necessario, ma vedo che in pratica nessuno lo fa.
Così ho deciso in futuro di chiudere dei pezzi e limitare l'accesso ad un massimo giornaliero per indirizzo ip.

Oggi sto solo raccogliendo dati, ma il prossimo aggiornamento introdurrà questo tetto massimo di richieste per giornata.
Potrei impostarlo inizialmente a 30 mila e ridurlo poi man mano fino a 5 mila.
Ad esempio un set completo del Mame, ammesso che uno voglia averlo tutto (e già questo è discutibile, dato che si dovrebbe cercare sempre di andare per upgrade progressivi), "costa" fino a 50 mila richieste. Accodandole per gruppi di 400 giochi alla volta si ottiene un valore prossimo al centinaio, che è molto più gestibile e mi viene da dire anche più veloce per chi lo utilizza.
Quindi, anzichè scandagliare tutto ogni volta, bastarebbe gestire la data di ultima richiesta, farne al massimo 1 al giorno (quindi cache sul client) e unire tutte le richieste in uscita in poche chiamate cumulative.

Non ho deciso i dettagli, l'idea è questa e nei prossimi giorni dovrò lavorare al database per manutenzione ordinaria quindi il tutto rallenterà un pochino più del solito.
In ottica futura sto comunque rendendo le pagine e le elaborazioni molto più leggere (o meglio più "intelligenti") per avere meno carico possibile sul server e sul database. In pratica, con l'hardware attuale, si dovrebbe vedere un bel salto in qualità e velocità anche all'aumentare degli utenti. Ma di questo ne riparliamo a natale... spero...

noooooooooooooooo

resto sempre piu' convinto che la soluzione sia diversificare, un unregistred castrato , un registred e un donatore, trattare in egualmodo il tipo che scrapa da una distro da un utente dei AI sarebbe un peccato.

tutte le distro fanno richieste 1 a 1 (anche il gotscraper aime), ma mettere insieme 400 titoli e gestire il result non è cosi lineare, interruzioni a metà e quant'altro. ma quello che ad esempio faccio col gotscrpaer e NON andare online da te se hai già le info in locale perchè scaricate 1 volta, quindi questo dovrebbe evitare che chi ha già un set completo (per dire), all'uscita di una nuova versione i titoli da cercare saranno davvero pochi.

tra l'altro ho aggiunto oramai da un pò i cloni, per cui se un gioco è il clone di un'altro e i media sono gli stessi, duplica quelli locali piu' che scaricarli

my 2 cents

Non ho modo di capire chi è utente "serio" e chi no, perchè per registrarsi al sito basta una mail e comunque è tutto libero.
L'unica discriminante che posso usare è il numero di richieste per indirizzo IP: se sono troppe, devi separare in più giorni il tuo lavoro e dare spazio agli altri.
Eventualmente poi si potrà pensare di limitare solo in caso di troppe richieste totali, quindi se il server è scarico anche 200 mila richieste non danno fastidio, oppure di accodare ciò che va oltre con attese forzate (es. max 1 ogni tot secondi).

Normalmente abbiamo poco più di 1 milione di richieste (api) al giorno. Sicuramente in futuro saranno aumenteranno e non voglio arrivare alla saturazione completa.
Fare dalle 20 alle 40 mila chiamate (per utente) solo per avere un titolo o un'immagine aggiornata mi sembra un po' eccessivo, considerando che questa cosa impedisce poi agli altri utenti di visitare il sito o li rallenta, facendo rallentare tutto il sistema tra l'altro.

Vedrò i numeri che otterrò nei prossimi giorni, non è un sistema infallibile ma sicuramente permette di liberare il sito e consentire la navigazione.

I software di scraping li fanno i programmatori, se uno programma male non vedo perchè debbano rimetterci tutti gli altri.
Poi non è che da domani chiudo i rubinetti, sarà un passaggio graduale come sempre e chi vuole aggiornare o chi ha bisogno di aiuto può sempre scrivermi per venirne a capo senza impazzire.
Magari scopro che facendo un'api diversa e specifica risparmio tempo macchina, oppure posso predisporre già dei file pronti che non necessitano di usare la cpu (una sorta di scraping già fatto e pronto da scaricare). Insomma i modi per migliorare ci sono, però quello di oggi non è il sistema corretto per la mole di dati che abbiamo e quindi va cambiato