[Python] Gestionale come lo scrivo?(Was: Walks like Python. Runs like C).

[Giovanni Porcari]

> Il giorno 15/gen/2015, alle ore 18:02, enrico franchi <enrico.franchi a gmail.com> ha scritto:
> 
> 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.

Certo e concordo. Per una buona diffusione è assolutamente indispensabile fornire una documentazione completa
e probabilmente dei libri per spiegare la filosofia e guidare il principiante.
Nel mondo del gestionale ci sono numerosissime software house che hanno discrete capacità commerciali e che non hanno ancora effettuato 
il passaggio dei loro gestionali a web. Li conosco. Vengo da quel mondo. Che non è quello che trovo qui, non c'è gente come te o Nicola
o Manlio o molti altri che non sto ad elencare e che hanno sicuramente una competenza informatica di grande spessore.

Devo dire che è pieno di sviluppatori che hanno tirato avanti con Visual Basic e le cui conoscenze informatiche sono
di livello molto modesto. Io stesso in parte mi annovero nella categoria dato che la mia formazione (ingegneria chimica)
e la mia età, mi hanno di fatto costretto ad imparare da solo quello che so. E le mie lacune in termini informatici
sono immense (so che Nicola apprezzerà l'aggettivo).

Però, dal punto di vista del software gestionale, di quello che il cliente finale vuole, delle mille fesserie
che fanno gli impiegati con un gestionale men che perfetto ho una grande esperienza.

Per questo mi rivolgo non ai super esperti che di certo hanno lavori molto più interessanti e stimolanti
per le mani ma a quella platea di artigiano del software, a quegli orfani del Visual Basic ai nostalgici
del clipper per dire loro che se vogliono una base per costruire un gestionale web che consenta loro
di offrire una contabilità completa e di integrarla con procedure specifiche allora Genropy potrebbe essere una possibile risposta.


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

Allora metti insieme la documentazione di SqlAlchemy, quella di reportlab, quella di QT o wx
e ti fai una vaga idea delle cose di cui dovremmo parlare. E dovremmo farlo bene e con esempi.

Inoltre ci sono parecchi sottosistemi, dalla gestione delle mail in ingresso e in uscita,
la gestione degli utenti, dei privilegi, la programmazione lato server, le best practices.

Non è roba che si fa in poco tempo se si vuole fare autoconsistente. Certo è che
se ci si accontenta di un qualcosa di abbastanza succinto allora potrebbe essere vero.

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

Guarda, in qualche ora di impegno e senza nessun aiuto da parte mia
uno sviluppatore di cui ho una stima immensa e che probabilmente ci legge
è riuscito a studiarsi il nostro demone interprocesso di sessione 
e mi ha commentato :

"Il demone di sessione e' splendido, risolve in modo elegante una marea di
problematiche, e' la cosa su cui mi sono soffermato di piu' stanotte."

Mentre sulla GUI mi scriveva :
"Le gui sono fantastiche, prendono a schiaffi qualsiasi cosa abbia mai
visto (compreso xul di mozilla). Qualsiasi operatore che abbia usato un
gestionale classico fosse costretto a passare a un app genropy sono sicuro
che non avrebbe di che lamentarsi (anzi). Cosa che difficilmente si puo'
dire quando si fa' passare un cliente a un gestionale web based."

Questo per dire che è comunque un codice leggibile e maneggiabile da
gente esperta. Il mio target di documentazione invece è lo sviluppatore
di basso livello per cui o gli dai la pappa fatta oppure hai buttato via il tuo tempo.


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

Ricordo quando ho scoperto smalltalk e la programmazione ad oggetti era
un qualcosa che nessuno ma proprio nessuno usava e conosceva.
Avevo ordinato Smalltalk negli Stati Uniti e all'epoca non era così 
facile avere importare prodotti informatici direttamente da lì.
Era accompagnato da un bellissimo libro che cercava di spiegare il concetto
di programmazione ad oggetti e diceva che la cosa più importante era quella di 
capire che era un modo diverso di pensare.

La stessa cosa vale nel paragone Django - Genropy. Spiegare Django
a chi conosce prodotti simili è abbastanza facile. Di fatto servi una pagina
HTML costruita dinamicamente. Praticamente tutto avviene in Python lato server
e la GUI te la smazzi di jquery in javascript.

Con Genropy NON servi pagine HTML e il codice Python che scrivi di fatto
configura un client scritto in javascript che gestisce in modo estremamente
complesso e sofisticati la GUI.

Spiegare un paradigma diverso è di sicuro più difficile perchè non ti offre
il modo di costruire su quanto il tuo interlocutore già conosce per analogia.


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

Guarda che fanno molto di più per la diffusione di Django i libri come
quello che ha scritto il buon Marco Beri che la documentazione.

Comunque giuro sulla grande tartaruga che sostiene il mondo che prima o poi
scriveremo una buona documentazione.
Se poi continuerete a snobbare la mia 'creatura' allora manderò tutti a ciapà i ratt.


Ciao e grazie per i tuoi commenti sempre graditissimi :)

G.