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:
Just my
Pagine: 1
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...
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 motivi1. troppo stupido da fare2. la risposta non sarebbe rapida per l'utente3. 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.
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.
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.
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...
non userei un servizio esterno del lancio del dato per i seguenti motivi1. troppo stupido da fare2. la risposta non sarebbe rapida per l'utente3. cosa accadrebbe in caso di fail del web service?
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).
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.
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.
19/07/2015 01:05:42
darkabe ha scritto: {cronjobs}Che è pur sempre un'idea.
L'utilizzatore medio di gdrcd è l'odiato per eccellenza, ma la maggioranza dei gdr viene tirata sù proprio da loro.
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).
---Non chiedetemi aiuto in privato per questioni di programmazione; chiedete sul forum e eventualmente vi risponderò lì.[Link ] - Hosting per GDR
Discussione seguita da: » darkabe