GdRWS - Può interessare?

GdRWS - Può interessare? postato il 18/07/2015 18:11:54 nel forum programmazione, gdrcd, open source, hosting e modificato da darkabe il 18/07/2015 18:14:24

Parto dicendo che cercherò di farla breve, però ho la tendenza a dilungarmi... siete avvisati eh :-D
(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 http://playbychat.eu/test_services.html
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...

quota

18/07/2015 20:12:34 e modificato da _sway_ il 18/07/2015 20:14:15

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...

quota

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.

---

quota

18/07/2015 21:37:47 e modificato da ghennadi72 il 18/07/2015 21:43:25

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.

---

quota

18/07/2015 22:04:58

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

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).


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.


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



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.

quota

18/07/2015 22:12:47

Che è pur sempre un'idea.

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..

quota

19/07/2015 01:05:42 e modificato da ghennadi72 il 19/07/2015 01:11:33

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.


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.

---

quota

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:

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

---

quota

Google reCAPTCHA

Difendiamo i nostri giochi dai bot malevoli con Google reCAPTCHA!

Aperture Play by Chat

Interessante grafico sul numero di Play By Chat aperti suddivisi per anno!

Planethos GdR

Intervista allo staff di Planethos GdR il gioco di ruolo ambientato nella città di Pentos!

Star Wars e Shannara

Una concisa, ma dettagliata disamina delle analogie fra la saga di Guerre Stellari e quella di Shannara