<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-01-15 15:49 GMT+00:00 Giovanni Porcari <span dir="ltr"><<a href="mailto:giovanni.porcari@softwell.it" target="_blank">giovanni.porcari@softwell.it</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
</span>Vedi caro Nicola tutto si riduce a quali sono i tuoi obiettivi.<br>
Poi metti in atto le strategie migliori per conseguirli.<br>
Nel mio caso il mio obiettivo primario è di avere un prodotto<br>
per me, da vendere ai miei clienti e per mandare avanti la mia attività.<br>
Avrei potuto farlo close source e finirla lì.<br></blockquote><div><br></div><div>Chiaramente. Ma non credo che sia quello il punto di Nicola. Credo che quello che vuole farti notare e' che per ottenere una buona diffusione di Genropy (cosa che puo' interessarti o meno a vari livelli di priorita') la documentazione e' una parte importante.</div><div><br></div><div>Ora penso che siamo tutti d'accordo se diciamo che per te la diffusione del prodotto "fuori" da quello che fai per mangiare e' un bel successo personale, ma non e' la tua priorita'. E di conseguenza allochi risorse all'outreach del prodotto fino ad un certo punto. Che va *benissimo*. Pero' va anche benissimo dire, a mio avviso, che uno degli scogli per una diffusione maggiore sia quello.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Come obiettivo secondario ho quello di estendere l'uso di Genropy a qualche sviluppatore<br>
che abbia necessità paragonabili alle mie e che desideri avere una buana base su cui<br>
sviluppare gestionali.<br>
<br>
Non ho l'ambizione di avere migliaia di persone che usano il framework e nemmeno centinaia.<br>
<br>
Se devo raggiungere migliaia di persone allora una documentazione completa ed esaustiva<br>
è sicuramente uno strumento importante. Se ne devo raggiungere 10 allora il gioco per me non vale la candela.<br>
<br>
La scelta che a te non pare ragionevole invece per me lo è. Perchè non mi ha fatto spendere risorse<br>
molto preziose su un obiettivo secondario e mi ha consentito di vendere molto bene<br>
il lavoro che abbiamo fatto ai clienti finali.</blockquote><div><br></div><div>Forse dipende anche dal tipo di persona che vuoi raggiungere. Conosci sicuramente il mercato meglio di me...</div><div><br></div><div>*Io* per dire odio i video corsi et similia, e preferisco documentazione scritta (altri cercano disperatamente videocorsi). Idem, i corsi 1:1 o 1:10 non mi interessano (sono molto piu' veloce da solo). Generalmente trovo anche la documentazione scritta nella maggior parte dei progetti grosso modo inutile.. quello che a me serve in generale e' la filosofia del prodotto e come interagiscono i pezzi. Per i dettagli non ho problemi a guardare il codice. Un briciolo di docstring giusto per orientarsi e fine... Altri richiedono altri tipi di documentazione.</div><div><br></div><div>L'altra parte che voglio prima di andare in produzione e' se ci sono best-practice, roba da non fare, falsi amici.</div><div><br></div><div>Per intenderci... Apache ha tantissima documentazione, ma io la trovo quasi completamente inutile perche' e' troppo dispersiva e in genere non mi dice quello che voglio sapere. </div><div><br></div><div>Quindi anche li... documentazione vuole dire tutto e niente. Probabilmente per fare un paio di pagine ad alto livello che spiegano come ragionano i componenti (roba ottimamente rivendibile anche per discutere con un cliente che vuole acquistare un prodotto da voi) e un minimo di docstring non ci vuole uno sforzo enorme, ma puo' essere sufficiente per fare partire una community.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Che parola suggestiva. Quasi un esorcismo, vero?<br>
<br>
</span>No. Non è un esorcismo. Ma è semplicemente realistico.<br>
Se è vero che per una buona documentazione si spende lo stesso tempo<br>
che si usa per scrivere il codice, allora si tratta di anni di lavoro.<br></blockquote><div><br></div><div>Mi sembra una stima irragionevole. Ci sono certamente progetti per cui e' vero. Credo che la maggior parte dei prodotti open abbiano un rapporto 10:1 fra codice e documentazione a dir tanto.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Per le mie risorse economiche è un tempo immenso.<br>
<span class=""><br>
><br>
><br>
>> che dedicheremmo a fare una buona documentazione (come ad esempio<br>
>> quella di Django) preferiamo tenercelo per fare corsi o dare<br>
>> assistenza a chi è interessato.<br>
><br>
> Entrambe attività meritorie, ma che non scalano. Pensaci: spieghi uno,<br>
> riceve uno; scrivi uno, leggono tanti. È tutto qua.<br>
<br>
</span>Perfetta teoria. Immagino che tu abbia imparato ad andare in bicicletta, a nuotare<br>
o a guidare leggendo un manuale.<br></blockquote><div><br></div><div>Dai, pero' come sarebbe possibile lavorare senza documentazione? Mica uno puo' farsi fare mentoring 1:1 per ogni prodotto che usa...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In realtà la documentazione di un prodotto complesso come un framework deve essere<br>
completa, esaustiva e a prova di scemo.<br></blockquote><div><br></div><div>Oppure puo' essere ad alto livello e rigorosa, senza scendere troppo nei dettagli. Poi un'infarinatura di docstring e gia' ci si muove. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ricordo con orrore a quando cercavo di imparare Twisted dalla documentazione.<br></blockquote><div><br></div><div>Boh... a me sembrava fattibile. Fra docs ed esempi ci si muoveva. Semmai il problema era che c'erano intere parti che non erano praticamente documentate, quello si. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>Caro Nicola un framework come Django è di svariati ordini di grandezza<br>
più facile da spiegare. La ragione è presto detta: nasce per realizzare<br>
siti dinamici e si basa sul consueto modello dei template.<br></blockquote><div><br></div><div>Ma sei *sicuro*? Perche' e' vero che l'hello world di Django mi aspetto che sia piu' semplice da scrivere e da capire, oggettivamente il numero di features e soprattutto di punti di estensione e' veramente alto. Ma comunque Django "tutto compreso" e' un progetto piu' *grosso* (scusa se dico l'ovvio) e mi sembra strano dire che sia molto piu' facile da spiegare.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Non ne conosco molti. Ma se io ti metto a disposizione a titolo gratuito<br>
un framework che ti piace e ti fa guadagnare mi aspetto che in cambio tu mi aiuti<br>
a migliorarlo e mi dia una mano. Anche se detesti fare la documentazione.<br></blockquote><div><br></div><div>Storicamente non ha mai funzionato. Specie per la documentazione. Un conto e' se uno usa le tue cose ti trova i bachi te li fixa e contribuisce indietro... quello si. Ma una volta che *lui* ha imparato... lo stesso discorso che fai per te vale per lui: ti aiutera' con i bachi, magari ti dara' features che a lui servono e si e' implementato. Questo si.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Se invece ami i prodotti belli e fatti e ti piace pagare licenze salate<br>
allora è giusto che t trovi anche una documentazione bella e completa.</blockquote><div><br></div><div>C'e' un tradeoff fra poco o nulla e perfezione. ;) </div><div><br></div></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>