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

Mar 20 Gen 2015 18:55:58 CET

2015-01-15 17:56 GMT+00:00 Giovanni Porcari <giovanni.porcari a softwell.it>:

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

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.

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.

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?

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

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.

-- 
.
..: -enrico-
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150120/f8d4a320/attachment-0001.html>