Nuova piattaforma OpenSource per il Play by Chat

20/04/2016 12:38:15

A mio avviso è inutile pensare qualcosa di nuovo, se c'è una chat e qualcuno che ha voglia di aspettare 5/7 minuti le azioni altrui tutta sta ricerca di tecnologie differenti non serve a nulla. Quello che serve ad un play by chat è già stato inventato, bisogna concentrarsi sul fare gioco il resto è fuffa.

20/04/2016 13:42:26

dyrr ha scritto: Solo un consiglio:

SASS http://sass-lang.com/ non è installabile su uno shared host dove invece sono situate il 90% delle land, per cui se si vuole usar eun preprocessore di css, consiglio di cambiare target e usare qualcosa che si possa installare anche li tipo il primo esempio che mi viene in mente csscrush http://the-echoplex.net/csscrush/

Ma perché dovrebbe essere installato sul server? Sass è un preprocessore, nei 99% dei casi viene usato lato client insieme a gulp/grunt/gui per compilarti il css.

Che senso ha farlo fare al server?

20/04/2016 13:55:47

steamdoll ha scritto: I CMS qui pubblicati ormai hanno qualche anno, non vedo perché dovrebbe essere inutile pensarne uno nuovo (o anche semplicemente diverso)

Giusto, si sta parlando di creare qualcosa di diverso, il partire con lo sviluppo oggi pone già le basi di un codice nuovo, non soggetto a tutto il "vecchiume" che si trascina (volendo o non volendo) un progetto che gira da magari 10 anni.

tuttoweb ha scritto: Personalmente lo trovo un enorme sforzo. Io ho sviluppato la mia land, utilizzando tecnologie che si trovano online e il mio knowhow. Infatti, al meglio della mia conoscenza, siamo l'unica land che usi Drupal. Ora, le tue scelte sono:
- creare una distribuzione ad hoc di un cms gia' esistente (eg. drupal)
- creare qualcosa di sana pianta per diventare il gdrcd 2.0
Nel secondo caso, il tuo team di sviluppo deve essere piuttosto lungimirante e pensare di correggere i bug che man mano salteranno fuori.

Io non ti voglio ovviamente scoraggiare, ma non so se hai ben chiaro che far tutto cio' ti impieghera' piu' di un anno di sviluppo. Io ho impiegato 8 mesi per la mia land, eppure ho scritto poco codice di sana pianta, rispetto a quello che e' l'infrastruttura su cui mi sono basato.

Non trovo corretto appoggiarsi ad un sistema che già potenzialmente fa tanto / troppe cose e costruirci sopra un sistema complesso come può essere un GDR. Giustamente tuttoweb sottolinei la "pesantezza" dello sviluppare un sistema del genere. Facendo due conti con il tempo a sola mia disposizione creare questa "piattaforma" potrebbe essere schedulata in 6/8 mesi per una prima release stabile in alpha con funzionalità limitate e almeno 12/15 mesi per una vera e propria prima release stabile e utilizzabile.

Sò esattamente il tempo che comporta sviluppare una pattaforma del genere (ho sviluppate un paio di GDR [ ora chiusi ] e di lavoro gestisco progetti di medio/grande entità) non sto mettendo in dubbio lo sforzo e l'impegno che ci vogliono e soprattutto il fatto che questo impegno non termina con il "rilascio" della prima versione stabile, come con tutti i software ci saranno sempre errori / nuovi sviluppi da fare. Ma essendo un progetto open, magari qualcuno si affeziona e inizia a darmi una mano.

20/04/2016 15:59:05

airon ha scritto: [quote]dyrr ha scritto: Solo un consiglio:

SASS http://sass-lang.com/ non è installabile su uno shared host dove invece sono situate il 90% delle land, per cui se si vuole usar eun preprocessore di css, consiglio di cambiare target e usare qualcosa che si possa installare anche li tipo il primo esempio che mi viene in mente csscrush http://the-echoplex.net/csscrush/

Ma perché dovrebbe essere installato sul server? Sass è un preprocessore, nei 99% dei casi viene usato lato client insieme a gulp/grunt/gui per compilarti il css.

Che senso ha farlo fare al server?[/quote]

Perchè anche proprio per citare grunt, grunt ha bisogno che sass sia installato sul server per compilare il css:

This task requires you to have Ruby and Sass installed. If you're on OS X or Linux you probably already have Ruby installed; test with ruby -v in your terminal. When you've confirmed you have Ruby installed, run gem install sass to install Sass.

fonte https://www.npmjs.com/package/grunt-contrib-sass ↗ https://www.npmjs.com/package/grunt-contrib-sass

In fase di sviluppo chi lavora sull'aspetto dell'html della pagina dovrebbe poter:

Accedere ai css ancora da processare,
- Fare le modifiche su quelli
- Farli compilare dal preprocessore
- Verificare che i css compilati si comportino nel modo giusto.

Per poter fare questo abbastanza in comodità css da compilare, preprocessore e css compilati sullo stesso server

20/04/2016 16:12:32 e modificato da offmbs il 20/04/2016 16:12:48

dyrr ha scritto:
In fase di sviluppo chi lavora sull'aspetto dell'html della pagina dovrebbe poter:

Accedere ai css ancora da processare,
- Fare le modifiche su quelli
- Farli compilare dal preprocessore
- Verificare che i css compilati si comportino nel modo giusto.

Per poter fare questo abbastanza in comodità css da compilare, preprocessore e css compilati sullo stesso server

a parte che se sei in sviluppo lavori su una tua macchina in locale e non sul server di produzione.

Rimane il fatto che già ad utilizzare un repository (privato o meno) e un framework, a meno che non siano state fatte delle modifiche strutturali, hai bisogno di aver installato sul server git (con accesso ssh per l'utilizzo) e composer (oltre a dover accedere per eventualmente fare varie migrazioni di database ecc ecc).

Io non ho mai trovato uno shared hosting che ti permetta di accedere via ssh per gestire git e varie.

Comunque sicuramente il server di produzione deve aver installato:
- git
- composer
- npm
- bower
- grunt / gulp

Senza contare che bisogna configurare le chiavi ssh per poter eventualmente accedere a dei repository privati.

20/04/2016 16:50:41

makberge2 ha scritto: A mio avviso è inutile pensare qualcosa di nuovo, se c'è una chat e qualcuno che ha voglia di aspettare 5/7 minuti le azioni altrui tutta sta ricerca di tecnologie differenti non serve a nulla. Quello che serve ad un play by chat è già stato inventato, bisogna concentrarsi sul fare gioco il resto è fuffa.

Sì, se ti piace scrivere un racconto a più mani.
Un po' meno se ti interessa giocare di ruolo.

20/04/2016 18:11:19

Esattamente

Per giocare a calcio basta una palla e voglia di giocare.

Ribadisco

Per giocare ai pbc basta quello che c'è ora: una chat e voglia di giocare.

20/04/2016 18:12:59

arryx ha scritto: Concordo con chi ha detto che nel panorama del gdr-pbc, gli "aspiranti gestori" con la possibilità e la voglia di acquistare perlomeno un VPS sono veramente pochi.

Alla base di un progetto ci dovrebbe essere un attento studio del proprio target, capisco il tuo voler "innovare" e portare un poco di contemporaneità nel codice che gira per i gdr. Tuttavia a parte il grande impegno di ore nello sviluppo di un nuovo strumento, io considererei anche l'effettiva domanda che c'è per qualcosa di simile. Inoltre se il prodotto finito necessiterà di una configurazione anche lato server, beh, il 99% degli aspiranti gestori getterebbero la spugna in men che non si dica. Non è proprio da tutti configurare un web server da ssh per far girare laravel ( a meno che tu non indirizzi qualcuno verso homestead ). Anche il solo entrare tramite ssh ed installare apache è oltre il target medio, chi invece è in grado di fare qualcosa di simile non credo abbia problemi a farsi la propria land, e parlando per preferenza personale, avendone il tempo preferirei 1000 volte creare tutto da 0 piuttosto che basarmi su altro.

Per non parlare del fatto che a mio modesto parere, laravel sarebbe overkill per il 99% dei progetti. L'unica cosa che mi stuzzica sarebbe creare un gdr real-time usando websocket. Quello sarebbe interessante, ma anche qui, creare un framework basato sui websocket taglierebbe fuori ancora più persone.

Certo, il target è importante, ma credo che a volte gli utilizzatori si creino una volta che il prodotto è stato creato.

Sono anche io convinto che molti degli attuali gestori non sarebbero in grado di utilizzare un sistema del genere, ma non capisco, uno sviluppatore, che per fare un GDR voglia sviluppare tutto da zero anche se ha a disposizione uno strumento con il 90% delle features già implementate.

Stiamo parlando di creare una piattaforma completamente open (probabilmente sotto licenza MIT) per aiutare gli sviluppatori a fare quello che attualmente (in pochi) si impegnano a fare, un GDR con un codice moderno e stabile.

Non sò se riuscirò a creare un gruppo di sviluppo, io inizierò sicuramente a sviluppare cercando di arrivare alla prima versione beta, se poi qualcuno vorrà utilizzare il sistema per creare una land sarò solo contento. Ma comunque spero di riuscire a portare un po' di novità tecniche in questo ambiente che, per quanto mi riguarda, è fermo almeno a 5 anni fa.

20/04/2016 18:59:32

Stiamo parlando di creare una piattaforma completamente open (probabilmente sotto licenza MIT) per aiutare gli sviluppatori a fare quello che attualmente (in pochi) si impegnano a fare, un GDR con un codice moderno e stabile.

Quello che non capisco è perchè non abbassare un po' il target delle risorse necessarie per creare questo progetto rendendo il prodotto usufruibile anche su uno shared host pur mantenendo livelli qualitativi elevati.

non so per esempio usando un codeigniter, piuttosto che un laverel, csscrush invece che sass, non per preferenze personali sul framework, ma perchè pur mantenendo una buona base sono entrambi utilizzabili anche su uno shared host senza nessun problema

20/04/2016 19:22:55

dyrr ha scritto:

non so per esempio usando un codeigniter, piuttosto che un laverel, csscrush invece che sass, non per preferenze personali sul framework, ma perchè pur mantenendo una buona base sono entrambi utilizzabili anche su uno shared host senza nessun problema

Certo, ma a questo punto mi metterei a sviluppare il clone di gdr-cd e basta... A questo punto mi aggancio a chi ci sta già lavorando e gli do una mano. Ma non darei nulla di nuovo a quegli sviluppatori, come me, che magari si vorrebbero impegnare nella costruzione di una land ma a cui gdr-cd fa talmente schifo che piuttosto costruiscono tutto da zero (impiegandoci magari 3/4 del tempo)