GdRWS - Può interessare?

GdRWS - Può interessare? [Postato il 18/07/2015 18:11:54 nel forum Programmazione]

Parto dicendo che cercherò di farla breve, però ho la tendenza a dilungarmi... siete avvisati eh 😀
(I programmatori semi e/o professionisti possono saltare la coda e leggersi solo l'ultima riga del post. E mi dovete un favore eh!)

Riflettevo sul fatto che in questo ambiente sono davvero pochi i veri programmatori che mettono le mani al codice. Perlopiù si tratta di appassionati/smanettoni che cercano di fare il possibile per offrire un qualcosa che funzioni e che venga incontro alle loro esigenze. A volte ci riescono in maniera migliore, a volte... meno.

Ci può stare. L'alternativa a questo scenario sarebbe quella di pagarsi un professionista che scrive tutto il necessario. Ma ne vale davvero la pena per un gdr? Non credo.
Ecco perché vorrei i vostri pareri su qualcosa che sta a metà strada. Qualcosa che richiede del codice da scrivere.. ma che può evitarne molto altro.

Prendiamo l'esempio più stupido: il codice per lanciare un dado. Da qualche parte dentro ogni gdr (non diceless magari) ci sarà qualcosa che assomiglia a questo:

(non scrivo php da un sacco, se non funziona perdonatemi :P )
Stupido, banale. Ma se fosse stato anche solo 30 righe più complesso sarebbe stato un problema del gestore continuare a sviluppare la propria land assicurandosi di non far mai in modo che questo pezzo di codice esploda, o che non inizi a restituire roba fuori dal range specificato.

E se invece bastasse chiamare un url? Si include nel gioco una chiamata ad un servizio generico (che inizierei a programmare io si intende) dicendo a questo servizio che ti serve un certo tipo di dado, lui ti risponde con il risultato, lo si usa come si farebbe di solito. Stop. Non serve sapere che codice va scritto per lanciare quel dado, non serve fare manutenzione.. in realtà non importa nemmeno sapere se è scritto in PHP o in altro.

Proviamo con un esempio più calzante... quanti tra tutti i gestori non programmatori sono in grado di scrivere un controllo per bloccare le mail temporanee alla registrazione? Sono anche in grado di aggiornarselo costantemente? E un sistema per aggiungere/togliere particolari indirizzi dal blocco in modo temporaneo?

Questo è un caso dove inizia ad aver senso tutto il discorso.
Mi sono preso un paio di giorni di sviluppo per far vedere quello di cui parlo. Provate a visitare questo indirizzo [Link ]
NB: Sono scritti velocemente solo come demo. Il servizio delle mail blocca solo gli indirizzi @gdr-online.com e la parte delle inclusioni/esclusioni non funziona. Prendetelo giusto come esempio

La mia domanda è:
Vi può interessare una cosa simile? Se esistesse la usereste?
Se sì, che funzionalità vorreste vederci sopra? Se no, perché?
Si possono pensare come servizi anonimi (come i due che ho mostrato adesso, sia che vengano chiamati da gdr-rosso.it sia che li chiami gdr-verde.it si comportano ugualmente), ma in realtà andando appena poco più oltre con l'immaginazione è facile capire che una cosa del genere può benissimo diventare più grossa. Può interessare i login (tipo il login by facebook che si vede di solito in giro per il web), o le bacheche, o chessòio.

È giusto un piccolo sondaggio, se non piace non mi metto nemmeno ad approfondirla come idea.

Per i programmatori: Tutto sto post enorme quando in realtà potevo dire che è un Web Wervice Restful scritto in Java(+Spring) contattabile tramite richieste POST che lavora sia in input che in ouput con oggetti JSON...

Just my

18/07/2015 20:12:34

L'idea è senz'altro interessante ma... i web service offrono un servizio, come dice il termine. Tolto il lancio del dado, cos'altro potrebbe servire ad una land che possa offrire un servizio esterno?

Normalmente i bisogni di una land sono riconducibili ad un dialogo tra layer applicativo e database. in quest'ottica un webserver potrebbe far poco a meno che non ti prefiggi di mettere anche un database "a disposizione" sotto il webserver ma non so quanto sarebbe possibile in termini di costi.

Poi oh, se ci sono situazioni e casi d'uso in cui credi che i ws si trovino utili, dimmi pure, son curioso! (è una domanda sincerissima eh, non è ironia o sarcasmo!)

I due esempi che hai portato sarebbero credo gli unici calzanti, perchè generali e, stringi stringi, utili a tutti. oltre potrebbe esserci, chessò, il meteo per esempio...

eXtramondo
Esplora la più fedele e vasta TdM d'Italia. Segui l'avventura attraverso il gioco RPG in chat o con le numerose funzionalità automatiche che offre Em!

Modificato il 18/07/2015 20:14:15 da _sway_

18/07/2015 21:00:07

Sarebbe una cosa molto utile, ma bisogna vedere che tipo di web service vuoi esternare. Ti faccio un esempio:

non userei un servizio esterno del lancio del dato per i seguenti motivi
1. troppo stupido da fare
2. la risposta non sarebbe rapida per l'utente
3. cosa accadrebbe in caso di fail del web service?

Ma per altri servizi non indispensabili per la land, lo troverei molto utile. Esempio? Il meteo. Io per la mia land ho dovuto fare un sistema pazzesco solo per aver il meteo (che non sto qui a spiegare). Se ci fosse qualcuno che "inventasse" un meteo con cognizione di causa (non prendendo a caso condizioni meteorologiche, ma prendendo in cosiderazione alcuni parametri reali o pseudoreali), sarebbe davvero utile. Ovviamente si potrebbero offrire tutta una vasta gamma di servizi centralizzati piu o meno importanti. Esempio? Generatori di nick/nomi pg, controllo su ip particolari (bot, etc.), e cosi via.

Operazione Vertigo - Gdr by Chat [Link ]

18/07/2015 21:37:47

Quoto i pro ed i contro evidenziati da spyker.

Provo ad approfondire il discorso, comunque.

Onestamente non riesco a pensare a funzioni "semplici" per le quali sarebbe preferibile il ricorso ad un servizio esterno anzichè all'intervento sul codice della propria land.

L'unico servizio "semplice" davvero utile che mi viene in mente potrebbe essere un servizio di cronjobs per i gestori che hanno la sfortuna di usare un hosting che non glieli mette a disposizione, tipo aruba modello base.

E funzionalità complesse, tanto complesse da mettere in difficoltà qualcuno che almeno un po' di programmazione lato server la mastica (e deve masticarla se ha ideato anche se in maniera vaga, il funzionamento di qualcosa che però non è in grado di tradurre in codice), probabilmente sarebbero così specifiche da essere tarate sul sistema in vigore sulla singola land e quindi da non essere interessanti come servizio offerto a una pluralità di land.

Pensando all'identikit di un gestore che non sa utilizzare la funzione mt_rand per scriversi un lanciadadi da solo mi viene in mente un solo identikit possibile: l'utilizzatore medio di gdr-cd. Non è onestamente una categoria per la quale abbia particolare simpatia e che eviterei di incentivare ulteriormente.

La colpa non è mai dello strumento (quindi non me ne vogliano i vari Faber, Blancks & co.) ma di chi lo usa. Trovo che uno strumento che ha già illuso centinaia di gestori-io-speriamo-che-me-la-cavo che progettare e realizzare un gioco di ruolo online sia poco più che installare gdr-cd con una grafica personalizzata e scrivere due paginette di ambientazione prima di correre qui a pubblicare la scheda sul portale, abbia già prodotto sufficienti danni e devastazioni all'ambiente del pbc.

Incentivare l'idea che si possa gestire una land senza conoscere una riga di codice e senza dotarsi almeno di un collaboratore che sappia scrivere due righe di codice per lanciare un dado non è una politica di promozione del pbc che susciti i miei entusiasmi.

Scusate se l'ho portata sul filosofico.

Riportandola sul tecnico mi viene in mente un ulteriore problema. La fiducia nel servizio terzo che fornisce il $result, qualunque sia e di qualunque natura sia. Qualunque rassicurazione possa dare il gestore del servizio esterno, non è paypal nè bancasella. All'utente (ossia il gestore della land) torna indietro un risultato senza alcuna garanzia del modo in cui è stato calcolato, dal momento che un'applicazione php/asp lato server viene per definizione compilata ed eseguita da un programma che non necessariamente è il prodotto del codice "pubblicato" sulla homepage del servizio.

ASoIaF - Il Grande Inverno GdR [Link ]
Not a cosplay by chat

Modificato il 18/07/2015 21:43:25 da ghennadi72

18/07/2015 22:04:58

Innanzitutto grazie delle risposte, cerco di rispondere un po' a tutti i punti principali che mi avete elencato.

 Una richiesta in GET forse sarebbe più semplice da gestire anche per l'utente finale.

True. Se parliamo di funzionalità che richiedono poche cose in input si può anche pensare di usare GET, se le request iniziano a diventare più corpose diventa drasticamente più complicato. L'ho pensata direttamente in ottica post onde evitare di dover fare due gestioni differenti (non tanto per la parte server quanto per chi dovrà fare una eventuale chiamata).

 I due esempi che hai portato sarebbero credo gli unici calzanti, perchè generali e, stringi stringi, utili a tutti. oltre potrebbe esserci, chessò, il meteo per esempio...

Anche qua, true. Però in questo caso bisogna iniziare a fare una distinzione tra servizi anonimi/con autenticazione.

Per quanto riguarda i servizi generici effettivamente non sono molte le cose che ha senso gestire. Con qualcosa di più strutturato invece si può anche pensare di spostare grossi pezzi di logica (prendi le bacheche ad esempio), lasciando sul sito solo lo scheletro per gestire il tutto.

 non userei un servizio esterno del lancio del dato per i seguenti motivi
1. troppo stupido da fare
2. la risposta non sarebbe rapida per l'utente
3. cosa accadrebbe in caso di fail del web service?

Nemmeno io. Il dado mi serviva giusto come hello world per mettere in piedi la cosa, è davvero troppo stupido.
Gli altri due punti li spiego insieme al successivo quote

 Riassumendo ed analizzando (alcuni) pro/contro:
Contro: Il codice potrebbe essere stato scritto da gente poco competente o potrebbe presentare falle di sicurezza che metterebbero a rischio non uno, ma tutti i siti web che sfruttano il servizio, finché questo non sarà riparato; come se non bastasse, che senso ha scrivere mezzo codice e sfruttare il servizio per le parti mancanti? Si va a risparmio di tempo e denaro, e lo capisco, ma è un controsenso, se pago, pago per avere tutti i sorgenti, non i 3/4.

[...]

Contro: Va considerato che il servizio potrebbe venire a mancare improvvisamente e senza preavviso alcuno, che sia per un guasto o per un altra motivazione, lasciando tutti i siti web che lo sfruttano praticamente privi delle funzionalità che si basano sul servizio. Inoltre, ci sarebbe una scarsa possibilità di personalizzazione e ci sarebbero ancor più land fotocopia e, dulcis in fundo, se c'è un bug in una parte del servizio, bisognerà aspettare "i comodi" di chi gestisce il servizio e non si potrebbe far riferimento ad un programmatore/conoscente o semplicemente non si potrà andare a smanettare direttamente con il codice ma bisognerà aspettare e aspettare. E aspettare. Anche ammesso che i problemi vengano risolti immediatamente appena verranno segnalati, il gestore medio del gdr non ha pazienza ed è maniaco del controllo, per quel che riguarda il proprio gioco (anche qui, purtroppo, cito delle esperienze personali).

Buone osservazioni che ho individuato anche io stesso fin dal principio (altrimenti non avrei mica chiesto parere).

-Rischio bug: nulla è esente da bug. Si può prevedere un buon piano di testing di ogni singolo servizio prima della sua messa in opera, per scongiurare roba troppo grave, ma se è buggato non si può far altro che aspettare il fix.

-Rischio sicurezza: nel caso in cui dovesse gestire informazioni più delicate la risposta è un po' come sopra, anche se a questo proposito mi verrebbe da domandarmi se sarebbe davvero tanto più rischioso di come lo è oggi. Ogni volta che ci iscriviamo ad un gdr stiamo comunque dando mail e password a qualcuno, persona che per quanto ne sappiamo può essere un completo ignorante in materia di sicurezza e potrebbe pure tenersi le password in chiaro sul db.

Personalmente in questo caso io da utente potrei passare sopra il rischio, perché sarebbe comunque inferiore a quello che potrei avere su moltissime altre land.

-Se il servizio è down: disagi, non esiste soluzione a questo.

-Se il servizio chiude: con le dovute precauzioni si può comunque fare in modo da passare tutto in mani di gente competente. O nel caso peggiore si fa di tutto per fornire gli strumenti di "riconversione"

-Abbassare la qualità dei giochi: su questo non concordo. Se una cosa è scritta bene e funziona a dovere non può di certo abbassare la qualità. Se non è scritta bene e non funziona bene la gente non la usa. Quindi la qualità non ne risente così tanto..

-I gestori maniaci del controllo: possono benissimo non usarlo.


Mi rendo perfettamente conto di tutti i punti, non a caso chiedo se l'idea può essere considerata o meno. Se poi qualcuno ha un'idea per sfruttare qualcosa così in modo differente ed evitando molti dei dubbi esposti, sono qua per parlarne.

Just my

18/07/2015 22:12:47

 ghennadi72 ha scritto:
L'unico servizio "semplice" davvero utile che mi viene in mente potrebbe essere un servizio di cronjobs per i gestori che hanno la sfortuna di usare un hosting che non glieli mette a disposizione, tipo aruba modello base.

Che è pur sempre un'idea.

 ghennadi72 ha scritto:
Pensando all'identikit di un gestore che non sa utilizzare la funzione mt_rand per scriversi un lanciadadi da solo mi viene in mente un solo identikit possibile: l'utilizzatore medio di gdr-cd. Non è onestamente una categoria per la quale abbia particolare simpatia e che eviterei di incentivare ulteriormente.

Certo, l'esempio della rand era un po' limite, però ho colto il ragionamento che fai. Ed è proprio qua che mi chiedo:

L'utilizzatore medio di gdrcd è l'odiato per eccellenza, ma la maggioranza dei gdr viene tirata sù proprio da loro. Quindi la maggioranza dei gdr rientrano sotto la descrizione di "Non è onestamente una categoria per la quale abbia particolare simpatia e che eviterei di incentivare ulteriormente."

Se non si cerca di migliorare questo aspetto non ci vedo molto senso nel cercare di fare meglio cose già fin troppo buone per l'ambiente..

Just my

19/07/2015 01:05:42

 darkabe ha scritto:
{cronjobs}
Che è pur sempre un'idea.

Stavo giusto per rispondere più o meno quello che ti ha già risposto spyker. Personalmente ho fatto i numeri in verticale affidandomi ad eventi attivati direttamente dagli utenti, quando ancora non avevo i cron a disposizione, per gestire certe operazioni periodiche e per quelle che dovevano essere eseguite a intervalli/orari precisi mi affidavo a un servizio esterno gratuito.

Che aveva, ovviamente, il limite di 1 solo cron al giorno. O meglio non era proprio così: trenta punti al mese, 1 cron = 1 punto = 1 giorno. Comunque ci siamo capiti: ovviamente se te ne servivano di più, dovevi pagare, perchè le sollecitazioni a cui è soggetto un server che offre cronjobs a terzi non sono leggere. Avrei fatto i salti di gioia se avessi avuto un servizio esterno che mi metteva a disposizione cronjobs multipli a gratis. Il problema è quanto costerebbe a te, però.

Di certo non si parla di acquisire un dominio e un hosting, si parla quantomeno di server virtuale o di server dedicato proprio. Coi costi conseguenti, quindi o hai soldi da regalare o sei costretto a chiedere un compenso a chiunque voglia più di un tot di cron al giorno.

Non è neanche in effetti un tipo di servizio che occorra al gestore medio, specie quello che è abituato a mettere la comunicazione mensile, o quando se ne ricorda, che sta per ripulire il database dagli account scaduti (e magari ha anche 9 bandierine verdi del Pel, ma questo è un altro discorso): può fare benissimo tutto manualmente. In genere chi ha bisogno di cronjobs con una certa frequenza ha fatto implementazioni avanzate e riscrivere la funzione tiradadi è l'ultimo dei suoi problemi.

Non è che sia impossibile ma ci ragionerei in termini di progetto imprenditoriale, non in termini di servizio gratuito per appassionati di pbc. Rischieresti il down continuo, con un hosting o un vps sovraccaricato, col risultato che bloccheresti anche i poveretti che si affidano a te per il lancio dei dadi.

Insomma, secondo me è fattibile, per i cron, ma si tratta di un investimento non da poco e di cui, se non sei figlio di qualche miliardario in vena di regalare quattrini al prossimo, dovresti pensare a come rientrare con le spese.

 L'utilizzatore medio di gdrcd è l'odiato per eccellenza, ma la maggioranza dei gdr viene tirata sù proprio da loro.

Anche la maggioranza di quelle che chiudono dopo pochi mesi, dopo aver spopolato per mesi col thread id presentazione qui, sottraendo giocatori curiosi a land che magari hanno già una loro stabilità, ed andando ad aumentare solo quell'orribile CIMITERO che pè diventato ogni pagina di ogni sottocategoria di gdr pubblicati sul portale, un elenco infinito di lapidi di gdr chiusi.

Mi chiedo spesso quanti potenziali interessati al pbc abbiano rinunciato ad interessarsi al play by chat solo perchè hanno avuto la sfiga di provare per prime due o tre land con il gene "chiusura entro 3 mesi" hardcoded già nel DNA dal concepimento frettoloso ad opera di un entusiasta che ha scaricato GDR-CD e ha deciso "anch'io gestore!", e di conseguenza avendo avuto 100% esperienze non esaltanti (per usare un eufemismo) hanno fatto l'equazione pbc = cagata pazzesca, meglio skyrim/GTA/WoW/Candy Crush.

ASoIaF - Il Grande Inverno GdR [Link ]
Not a cosplay by chat

Modificato il 19/07/2015 01:11:33 da ghennadi72

19/07/2015 15:02:12

In generale mi trovo d'accordo sulle linee di pensiero di ghennadi e spyker.

Vorrei solo aggiungere una considerazione tecnica:

 darkabe ha scritto:

 Una richiesta in GET forse sarebbe più semplice da gestire anche per l'utente finale.

True. Se parliamo di funzionalità che richiedono poche cose in input si può anche pensare di usare GET, se le request iniziano a diventare più corpose diventa drasticamente più complicato. L'ho pensata direttamente in ottica post onde evitare di dover fare due gestioni differenti (non tanto per la parte server quanto per chi dovrà fare una eventuale chiamata).

Un servizio web Restful degno di questo nome dovrebbe utilizzare i tipi di richieste HTTP in modo coerente con la specifica HTTP e la filosofia REST: richieste GET per "leggere" la servizio, richieste POST e PUT per inserire ed aggiornare dati, richieste DELETE per cancellare dati dal servizio.
Fare tutto in POST...iniziamo già male xD

---
Non chiedetemi aiuto in privato per questioni di programmazione; chiedete sul forum e eventualmente vi risponderò lì.
[Link ] - Hosting per GDR

Non puoi scrivere in questo forum 

Aggiungi discussione ai preferiti 

Segnala discussione ad un utente 

Segnala discussione ad un moderatore 

Torna al Forum "Programmazione" 

Torna alla lista dei Forum