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

[Giovanni Porcari]

> Il giorno 20/gen/2015, alle ore 18:55, enrico franchi <enrico.franchi a gmail.com> ha scritto:
...snip...
> > 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.
> 
> Ok... ma il mio punto non e' su quanto siano fighi gli uni o gli altri. E si, e' vero... e' un mondo che non conosco.
> Non scrivo gestionali, non ho mai lavorato in quel mondo. Conosco persone che ci lavorano o ci hanno lavorato (e anche qui, a tutti i livelli)... ma non e' casa mia.
> 
> Quello che volevo dire io e' che fra la documentazione del secolo e una manciata di pagine ben pensate c'e' una differenza di sforzo immensa. Eppure, spesso, la manciata di pagine e' abbastanza per fare partire il circolo virtuoso.
> 
> Sperare che parta da solo, invece, e' generalmente inefficace.

No guarda non è che non ci sia documentazione. Ce n'è tanta in rst, anche dentro ai sorgenti di genropy.
Ci sono le docstring e ci sono vari documenti su vari aspetti della programmazione web con genropy.
Però la qualità è molto modesta e non è nemmeno aggiornatissima. Per questo dico che non c'è.
Nella mia testa una cattiva documentazione fa più danni di nessuna documentazione.

Se per caso hai un'oretta da buttare via prova ad andare su sandbox.genropy.org e guardati la dozzina
di pagine sull'interfaccia. Quella è documentazione come la intendo io: ti prende per mano
e ti fa capire la logica che sta dietro e ti guida passo dopo passo. Se appena ci riesco farò allo stesso modo
la documentazione SQL.

> 
> Ma davvero... basta pochissimo. Spesso se valuti il ROI di un'azione salta fuori che facendo una frazione del lavoro hai tipo l'80-90% del ritorno. Ecco... questo e' uno di quei casi, a mio avviso. Con relativamente poco sforzo, potresti ottenere tantissimo.
> 
> Certo... io quel mondo non lo conosco. Non so se la documentazione e' inefficace (perche' tanto non viene letta) e l'unica speranza e' un corso di formazione mirato (pero', managgia!). Diciamo che alla fine dei conti mi stupirebbe che fosse un mondo *davvero* cosi' diverso. Alla fine sono convinto che le spinte verso l'alto e verso il basso ci siano in qualunque ambito.
> 

Ci sono poi gli screencast di francesco: anche qui lo sviluppatore viene guidato passo dopo passo
con gli screencast e la relativa pagina di spiegazione a partire dall'installazione fino
alla scrittura di un applicazione di fatturazione completa. Non è forse tecnicamente descrivibile
come documentazione ma comunque chiunque abbia provato, per quanto ne so, è riuscito a fare tutto.

> 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.
> 
> E sono sicuro che sia un'ottima risposta! Figuriamoci. 
> 
> 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.
> 
> Scusa, ma cosa c'entra Qt adesso? 
> 

C'entra perchè, se avrai la pazienza di dare un occhio alle famose lezioncine di interfaccia,
esiste una nutritissima collezione di widget che usi da python, un sistema di eventi lato 
client e uno store da cui i widget attingono.  Se guardi il codice di applicativi
genropy e applicativi in wx o qt non ci sono molte differenze. Per questo ti dico
la metafora template HTML e costruzione lato server è davvero lontana dalla nostra 
metodologia. 

> 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.
> 
> Ma penso che sia inevitabile... poi ribadisco, ognuno conosce il suo mondo.
> 
> 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.
> 
> Ah... interessante. Si credo di capire. Ma non pensi di stare un po' sottovalutando queste persone?


>  
> 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.
> 
> Si beh... semplificando in modo un po' riduzionista si. 
> 
> Cioe'... e' vero che da un punto di vista sufficientemente alto Django e' un affare che ti fa pagine HTML dinamiche con una GUI smazzata in Javascript. Ma questo e' vero per *ogni* prodotto web. Cioe', la grana e' talmente grossa che non riesci a distinguere nulla: ovvero anche la distinzione che fai sotto dalla distanza a cui stai guardando Django va persa. Anche Genropy alla fine della fiera ti genera pagine HTML con pezzi di Javascript. Come Django, PHP, Rails.
No, su questo no concordo :).
Sono certo che *ogni* prodotto tradizionale funziona così.
Ma in altri casi, come nel nostro, la metafora è completamente diversa.
Noi, all'atto della richiesta di una pagina, rendiamo una paginetta HTML minimale (di fatto sempre la stessa) la quale fa costruire
nel browser un client scritto in javascript che instaura un canale con una sua controparte nel server. Questa 'macchina' metà
in python e metà in javascript crea i widget, li popola dinamicamente, riceve i risultati delle query e inserisce i dati 
nei widget opportuni, cambia al volo le proprietà dei widget stessi a seconda della business logic.
Una pagina tradizionale vive poche decine di secondi. Una pagina di genropy per gestire un archivio clienti
può essere richiesta alle 9 di mattina e chiusa alle 6 di sera. L'unica cosa che avrà dovuto transitare nella
giornata saranno i dati. 
Sempre per darti un'idea di quanto sia differente ed integrato, senza che lo sviluppatore debba fare nulla,
quando è visualizzata una griglia di dati da una tabella del db, qualora ci siano inserimenti, aggiornamenti
o cancellazioni in quella tabella, il client provvede in modo trasparente a verificare se l'aggiornamento
va ad impattare sulla vista corrente e provvede ad effettuare nella pagina gli aggiornamenti opportuni.

Per questo sostengo che il modello e sensibilmente diverso e si avvicina ad un desktop.
Rendere totalmente trasparente tutto il dialogo tra client e server per emulare un desktop
è qualcosa di abbastanza complesso e che va spiegato molto bene per non generare incomprensione.

> 
> Questo se vuoi vedere le cose cosi' ad alto livello da non entrare nella specificita'. Se poi vuoi entrare nella specificita' a tal punto da dire che:
> 
> 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.
> 
> Allora a questo livello anche Django non e' solo un coso che serve pagine HTML dinamiche con un po' di colla JS.
> 
> Non so se e' chiaro il mio punto... niente contro nessun prodotto. Solo che vanno descritti allo stesso livello di astrazione, se no non e' che si ottenga molto.
> 
> 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.
> 
> Si, forse... ma se tanto l'interlocutore non conosce il web... 

> > 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.
> 
> Possibile. Non ne ho *davvero* idea. Comunque, io stavo parlando del fatto che la documentazione non si auto-scrive e la gente che usa il prodotto in generale non ha quintali di voglia di scriverla. Come questo sia relativo ai libri (del Beri o meno) non mi e' chiaro.
> 
> Tornando a libri vs. documentazione... non ne ho idea. Davvero. Io vedo che qua, nonostante tutto, preferiscono la documentazione perche' e' gratuita. Parliamo esclusivamente di libri "introduttivi" su una *tecnologia/prodotto* (non su un *concetto*). Sui forum italiani invece vedo spessissimo richieste di libri, specialmente introduttivi e in Italiano. Quindi potrebbe anche essere una cosa che dipende molto dal contesto....
> 
> Comunque se hai voglia di immolare un annetto di vita a scrivere un libro su Genropy.... un sacco di gente ti sara' grata. Ma appunto, io mi limitavo a dire che anche un effort molto modesto potrebbe ripagare parecchio... quindi decisamente scrivere un libro e' fuori scala come effort.
> 

Le tue osservazioni Enrico sono molto giuste ed è sempre stata mia intenzione cercare di trovare quel 'minimo indispensabile'
necessario. Purtroppo il tempo è veramente pochissimo e cerchiamo di fare il possibile per produrre quel minimo di documentazione cui alludi.

Come al solito i tuoi interventi sono precisi e pertinenti e ti ringrazio del tempo che hai speso per rispondermi.
Se poi avrai quella famosa oretta per vedere le lezioni su sandbox.genropy.org mi piacerebbe sentire cosa ne pensi.

Buona serata :)

G