<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-01-15 17:56 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"><br>
> Il giorno 15/gen/2015, alle ore 18:02, enrico franchi <<a href="mailto:enrico.franchi@gmail.com">enrico.franchi@gmail.com</a>> ha scritto:<br>
<span class="">><br>
> 2015-01-15 15:49 GMT+00:00 Giovanni Porcari <<a href="mailto:giovanni.porcari@softwell.it">giovanni.porcari@softwell.it</a>>:<br>
><br>
> 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>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
<br>
> 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.<br>
><br>
> Forse dipende anche dal tipo di persona che vuoi raggiungere. Conosci sicuramente il mercato meglio di me...<br>
><br>
> *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.<br>
><br>
> L'altra parte che voglio prima di andare in produzione e' se ci sono best-practice, roba da non fare, falsi amici.<br>
><br>
> 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.<br>
><br>
> 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.<br>
<br>
</span>Certo e concordo. Per una buona diffusione è assolutamente indispensabile fornire una documentazione completa<br>
e probabilmente dei libri per spiegare la filosofia e guidare il principiante.<br>
Nel mondo del gestionale ci sono numerosissime software house che hanno discrete capacità commerciali e che non hanno ancora effettuato<br>
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<br>
o Manlio o molti altri che non sto ad elencare e che hanno sicuramente una competenza informatica di grande spessore.<br></blockquote><div><br></div><div>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.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Sperare che parta da solo, invece, e' generalmente inefficace.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Per questo mi rivolgo non ai super esperti che di certo hanno lavori molto più interessanti e stimolanti<br>
per le mani ma a quella platea di artigiano del software, a quegli orfani del Visual Basic ai nostalgici<br>
del clipper per dire loro che se vogliono una base per costruire un gestionale web che consenta loro<br>
di offrire una contabilità completa e di integrarla con procedure specifiche allora Genropy potrebbe essere una possibile risposta.<br></blockquote><div><br></div><div>E sono sicuro che sia un'ottima risposta! Figuriamoci. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Allora metti insieme la documentazione di SqlAlchemy, quella di reportlab, quella di QT o wx<br>
e ti fai una vaga idea delle cose di cui dovremmo parlare. E dovremmo farlo bene e con esempi.<br></blockquote><div><br></div><div>Scusa, ma cosa c'entra Qt adesso? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Inoltre ci sono parecchi sottosistemi, dalla gestione delle mail in ingresso e in uscita,<br>
la gestione degli utenti, dei privilegi, la programmazione lato server, le best practices.<br>
<br>
Non è roba che si fa in poco tempo se si vuole fare autoconsistente. Certo è che<br>
se ci si accontenta di un qualcosa di abbastanza succinto allora potrebbe essere vero.<br></blockquote><div><br></div><div>Ma penso che sia inevitabile... poi ribadisco, ognuno conosce il suo mondo.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Questo per dire che è comunque un codice leggibile e maneggiabile da<br>
gente esperta. Il mio target di documentazione invece è lo sviluppatore<br>
di basso livello per cui o gli dai la pappa fatta oppure hai buttato via il tuo tempo.<br></blockquote><div><br></div><div>Ah... interessante. Si credo di capire. Ma non pensi di stare un po' sottovalutando queste persone?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
La stessa cosa vale nel paragone Django - Genropy. Spiegare Django<br>
a chi conosce prodotti simili è abbastanza facile. Di fatto servi una pagina<br>
HTML costruita dinamicamente. Praticamente tutto avviene in Python lato server<br>
e la GUI te la smazzi di jquery in javascript.<br></blockquote><div><br></div><div>Si beh... semplificando in modo un po' riduzionista si. </div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Con Genropy NON servi pagine HTML e il codice Python che scrivi di fatto<br>
configura un client scritto in javascript che gestisce in modo estremamente<br>
complesso e sofisticati la GUI.<br></blockquote><div><br></div><div>Allora a questo livello anche Django non e' solo un coso che serve pagine HTML dinamiche con un po' di colla JS.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Spiegare un paradigma diverso è di sicuro più difficile perchè non ti offre<br>
il modo di costruire su quanto il tuo interlocutore già conosce per analogia.<br></blockquote><div><br></div><div>Si, forse... ma se tanto l'interlocutore non conosce il web...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> 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.<br>
><br>
<br>
</span>Guarda che fanno molto di più per la diffusione di Django i libri come<br>
quello che ha scritto il buon Marco Beri che la documentazione.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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....</div><div><br></div><div>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.</div><div><br></div></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>