[Python] Gestionale come lo scrivo?(Was: Walks like Python. Runs like C).
enrico franchi
enrico.franchi a gmail.com
Gio 15 Gen 2015 18:02:34 CET
2015-01-15 15:49 GMT+00:00 Giovanni Porcari <giovanni.porcari a softwell.it>:
>
> Vedi caro Nicola tutto si riduce a quali sono i tuoi obiettivi.
> Poi metti in atto le strategie migliori per conseguirli.
> Nel mio caso il mio obiettivo primario è di avere un prodotto
> per me, da vendere ai miei clienti e per mandare avanti la mia attività.
> Avrei potuto farlo close source e finirla lì.
>
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.
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.
> Come obiettivo secondario ho quello di estendere l'uso di Genropy a
> qualche sviluppatore
> che abbia necessità paragonabili alle mie e che desideri avere una buana
> base su cui
> sviluppare gestionali.
>
> Non ho l'ambizione di avere migliaia di persone che usano il framework e
> nemmeno centinaia.
>
> Se devo raggiungere migliaia di persone allora una documentazione completa
> ed esaustiva
> è sicuramente uno strumento importante. Se ne devo raggiungere 10 allora
> il gioco per me non vale la candela.
>
> La scelta che a te non pare ragionevole invece per me lo è. Perchè non mi
> ha fatto spendere risorse
> molto preziose su un obiettivo secondario e mi ha consentito di vendere
> molto bene
> il lavoro che abbiamo fatto ai clienti finali.
Forse dipende anche dal tipo di persona che vuoi raggiungere. Conosci
sicuramente il mercato meglio di me...
*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.
L'altra parte che voglio prima di andare in produzione e' se ci sono
best-practice, roba da non fare, falsi amici.
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.
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.
> > Che parola suggestiva. Quasi un esorcismo, vero?
>
> No. Non è un esorcismo. Ma è semplicemente realistico.
> Se è vero che per una buona documentazione si spende lo stesso tempo
> che si usa per scrivere il codice, allora si tratta di anni di lavoro.
>
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.
> Per le mie risorse economiche è un tempo immenso.
>
> >
> >
> >> che dedicheremmo a fare una buona documentazione (come ad esempio
> >> quella di Django) preferiamo tenercelo per fare corsi o dare
> >> assistenza a chi è interessato.
> >
> > Entrambe attività meritorie, ma che non scalano. Pensaci: spieghi uno,
> > riceve uno; scrivi uno, leggono tanti. È tutto qua.
>
> Perfetta teoria. Immagino che tu abbia imparato ad andare in bicicletta, a
> nuotare
> o a guidare leggendo un manuale.
>
Dai, pero' come sarebbe possibile lavorare senza documentazione? Mica uno
puo' farsi fare mentoring 1:1 per ogni prodotto che usa...
> In realtà la documentazione di un prodotto complesso come un framework
> deve essere
> completa, esaustiva e a prova di scemo.
>
Oppure puo' essere ad alto livello e rigorosa, senza scendere troppo nei
dettagli. Poi un'infarinatura di docstring e gia' ci si muove.
> Ricordo con orrore a quando cercavo di imparare Twisted dalla
> documentazione.
>
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.
> Caro Nicola un framework come Django è di svariati ordini di grandezza
> più facile da spiegare. La ragione è presto detta: nasce per realizzare
> siti dinamici e si basa sul consueto modello dei template.
>
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.
> Non ne conosco molti. Ma se io ti metto a disposizione a titolo gratuito
> un framework che ti piace e ti fa guadagnare mi aspetto che in cambio tu
> mi aiuti
> a migliorarlo e mi dia una mano. Anche se detesti fare la documentazione.
>
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.
> Se invece ami i prodotti belli e fatti e ti piace pagare licenze salate
> allora è giusto che t trovi anche una documentazione bella e completa.
C'e' un tradeoff fra poco o nulla e perfezione. ;)
--
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150115/dfc06080/attachment.html>
Maggiori informazioni sulla lista
Python