[MontelLUG] Vista funziona! E anche bene!

Mer 22 Ago 2007 13:02:02 CEST

Alle lunedì 20 agosto 2007, Samuele Zanin ha scritto:
> Io conosco bene il C, al C++ ho dato solo un'occhiata quando ero infognato
> nei programmi C e cercavo un'alternativa. In seguito ho chiesto
> delucidazioni a chi diceva di conoscerlo riguardo ad alcuni aspetti critici
> che avevo con il C e mi è stato confermato che continuano ad esistere in
> C++.
>
> Dalla mia esperienza in 3 software house diverse, sviluppare un gestionale
> significa:
> a) partire con lo sviluppo una settimana dopo la data di consegna;
> b) in alcuni casi ti trovi un'analisi di 110 ore contenuta su una pagina A4
> scritta con Arial 12;
> c) quando consegni il programma al cliente di norma c'è sempre qualcosa che
> chi ha fatto l'analisi non si è capito con il cliente ed è da rifare, a
> volte anche con modifiche pesanti. Quando va bene manca solo qualche
> funzionalità;
> d) il cliente dopo qualche giorno di utilizzo ha subito in mente nuove
> implementazioni, il fatto che queste a volte implichino il ribaltare la
> logica del programma ha poca importanza;
Questi sono problemi organizzativi o di analisi o di rapporto con il cliente, 
non dipendono dal linguaggio nè dal sistema operativo.
> e) "Questo programma ha eseguito un'operazione non valida e sarà terminato.
> Se il problema persiste contattare il fornitore del programma." non è un
> bel messaggio che compare a video dopo che uno ha caricato un centinaio di
> righe di bolla e preme il pulsante per registrarla;
Assomiglia un bug, difficile vivere senza. Ma non è certo un problema di 
linguaggio. Mi ricorda VB quando ti dice "Runtime Error: 5" :-)

> Per me il successo di programmi come COBOL, Clipper/dbIV, Vb e Delphi è
> dovuto al fatto che una volta compilato sei sicuro che il programma esegue
> quello che hai scritto. Se il programma non fa quello che ti aspetti è
> perché c'è un errore di logica e non perché un'assegnazione a una variabile
> ha modificato il valore della variabile adiacente in memoria, oppure
> un'azzeramento di stringa è andato a sovrascrivere una parte di memoria
> dove c'è il codice eseguibile e quindi l'eccezione ti viene sollevata da
> un'altra parte del programma che non ha niente a che fare.
Ma se il problema sono i puntatori perchè non creare una classe che ti wrappa 
le stringhe in modo da non usare i puntatori (se non usare <string> o 
<qstring>)? Vale anche per l'azzeramento, anche se mi risulta difficile 
capire come un azzeramento di una variabile in heap o data possa essere 
vicina al text.

> Ti dico, in quei 14 mesi ne ho viste di tutti i colori e non mi sono
> scottato, ma ho riportato ustioni di 3° grado.
> Senza contare le opzioni di ottimizzazione del compilatore. Mi avevano
> detto che quando dovevo consegnare il programma al cliente era bene
> compilarlo in modalità release (più veloce e compatto). Poi dopo che al
> cliente si blocca il programma in fase di fatturazione e questo chiama
> diretto il tuo capo, il quale si mette a strillarti dientro (con tutte le
> porte degli altri uffici del piano che magicamente si chiudono
> sincronizzate) senza sentire ragioni, poi scopri che mentre la versione
> compilata in debug funziona, mentre quella in release va in eccezione e non
> si capisce il punto, stai certo che dopo la prima volta non ho più
> consegnato programmi compilati in release, ma in con tutte le informazioni
> di debug incluse, e se il programma è troppo pesante che il cliente si
> prenda un pc più potente.
Non è buona pratica inviare al cliente qualcosa di testato, ma anche questo è 
un problema organizzativo.

>
> Poi se uno si può permettere di scrivere il programma in un ambiente dove
> chi è addetto allo sviluppo fa solo quello, le date di consegna sono umane,
> oltre a te ci sono anche altre persone che fanno i test, il codice è
> scritto secondo sani principi di programmazione strutturata e non da
> profondi estimatori dei goto, allora ti posso anche credere se dici che il
> C può andare bene anche per altri tipi di applicazioni.
> Alla fin fine, un gestionale lo puoi anche scrivere in assembler, nessuno
> te lo vieta, ma vienne fuori poi.
Il c non è l'assembler. E' sicuramente una delle alternative possibili e 
sicuramente non l'unica. I problemi che però mi stai presentando però sono 
tutti organizzativi o di progettazione! Anche sviluppando in Access viene 
fuori un casino in queste condizioni.

> > La portabilità è una bella gatta da pelare: in pratica si hanno poche
> > alternative se si vuole mantenerla:
Java non ha problemi.

> L'importante è che ci sia il supporto quanto più completo per l'hardware
> dei server.
> Poi per i client, quando c'è il supporto per scheda di rete e video 2d per
> me va più che bene.
> Con le stampanti non ci ho mai sbattuto la testa.
Hp butta fuori driver per tutti!

> Qui dipende secondo me da che obiettivo ha la software house. Se sviluppa
> software su commissione, li penso che sia proprio come dici tu, basta che
> il cliente paghi, poi gli si consegnano i sorgenti e buona notte.
> Se invece lo scopo della sh è quello di sviluppare un proprio software da
> commercializzare, e questo software dovrà rimanere sul mercato n anni con
> costanti aggiunte ecc., allora penso che la scelta della tecnoligia da
> utilizzare sia molto più oculata e non basata sulla moda corrente.
> Oltretutto bisognerà sviluppare in modo da rendersi il meno vulnerabili
> possibili a cambiamenti possibili (es. driver per l'accesso ai dati).
E' proprio in questo ambito che Linux e l'open source in generale secondo me è 
più interessante. Scegliendo di programmare in open source:
* fai una scelta innovativa che ti può portare ad avere un vantaggio 
competitivo rispetto agli altri
* entri in una comunità di utilizzatori che hanno i tuoi stessi problemi e che 
quindi probabilmente utilizzeranno la tecnologia per lungo tempo.
* sei in grado di risolverti i problemi da solo anche se nessuno ti da 
assistenza perchè hai tutto quello che ti serve (sorgenti)
* entri in una comunità di utilizzatori che ti possono offrire assistenza, non 
sei dipendente da aziende che possono decidere di non supportare più un 
prodotto dall'oggi al domani
* ti liberi da logiche di licenze per l'utilizzo; cosa succede se aumentano il 
canone di utilizzo della tal libreria o del tal ambiente di sviluppo? Paghi.

> > Io invece penso che nell'ambito aziendale ormai abbiamo ottime
> > possibilità! Ora come ora si stà tornando a termiali stupidi (per
> > quanto graficamente capaci) e server (o cluster) intelligenti.
> > In questo ambito io sceglierei di utilizzare terminali con linux per:
> > * non pagare costi di licenze
> > * stabilità
> > * possibilità di aggiornamenti automatici non invasivi
> > * possiblità di assistenza remota (anche solo via console)
> > * capacità di supporto per hw obsolescenti
> > * automatizzazione del collegamento con server di terminale grafico
> > * sicurezza
> > * azzerato il costo di manutenzione causato dai virus
> > Come server può essere utilizzato sia linux (per il software tipo
> > webmail, openoffice tramite vnc o rdp etc.) sia winzozz (per
> > Exchange, db, gestionali sempre tramite rdp o cytrix).
>
> Il costo della licenza di win sulla macchina allo stato attuale sei
> costretto a pagarlo, in molti casi assemblarti un pc costa più che
> prenderne uno con già il so. preinstallato.
Falso, si trovano i pc con linux. Secondo se devi compare 200 o 300 pc hai la 
forza per non pagare le licenze, basta chiedere e te li danno non installati.

> L'unico costo in meno che si 
> avrebbe forse sarebbe quello delle licenze antivirus e di eventuali
> rimozioni di virus.
E il downtime.

> Per contro però dovrei comunque comprare altrettante 
> licenze di terminal server senza contare che dovrei avere un server molto
> ben carrozzato sul quale far girare i vari applicativi.
Il costo del server non è un problema, ti assicuro, con le capacità attuali di 
calcolo dei processori paghi di più la doppia alimentazione e gli hard disk 
per il raid che la capacità di calcolo. Le licenze terminal server sono 
gratis su win 2000 server. Sulle versioni successive ti conviene prendere la 
licenza per utenti limitati. E poi se proprio non vuoi usare le licenze puoi 
provare con Linux e wine :-)

> C'è anche da dire 
> che dall'esperienza che ho alcuni utenti si trovano abbastanza impacciati
> ad avere il gestionale su terminal server, mentre ad esempio la posta e gli
> altri applicativi sul desktop locale.
Si può creare sul desktop dell'utente un file nome.rdp con le proprietà della 
connessione. Win lo vede come un normale programma e se ci fai doppio click 
si apre. Inoltre con RDP5 (Windows 2003) puoi impostare un programma come 
root (al posto di explorer.exe). Chi usa il programma da un client terminal 
server vede solo la finestra del programma che può ridimensionare, 
minimizzare etc. Non si accorge nemmeno che usa terminal server.

> Terminal server lo vedo bene al momento attuale solo per utenti in sedi
> remote rispetto al db server o per applicativi con installazioni
> impegnative.
> Fin tanto che l'installazione del programma consiste solo nel copiare un
> link e lanciare un paio di file .reg, nel mio caso conviene l'installazione
> client per client.
Su questo non sono per nulla d'accordo. Innanzitutto ti devi spostare, poi 
devi occupare il pc di un altro per tutto il tempo dell'installazione, poi 
tutte le macchine sono diverse e possono avere dll che rompono i cicci etc.
Adesso come adesso, obiettivamente, avere programmi da installare sul client 
non è economicamente conveniente!

> Per il discorso della "manomissione dei client" da parte degli utenti vedo
> che in genere dopo che stanno senza il pc per mezza giornata per la pulizia
> e la strillata del loro capo dopo che ha visto la fattura, questo
> costituisce un ottimo deterrente contro l'installazione di porcherie.
Si ma intanto per ogni ufficio hai speso:
* il tempo di downtime di chi ha causato il problema
* la fattura per la sistemazione
* il tempo del cazziatone del capo

Quando poi c'è un nuovo assunto devi ricominciare tutto da capo.
Poi non è detto che il danno venga fatto in malafede.
>
> > Ci sono dei progetti molto interessanti, ovviamente general pourpose.
> > In questo ambito il problemi fondamentali sono due:
> > a) mancanza di pressione commerciale
> > b) spinte derivanti dal ruolo in azienda
> >
> > Il primo problema è ovvio. Se uno non se li va a cercare non saprà mai
> > dell'esistenza e delle capacità  dei sw gestionali opensource su
> > linux. Invece, quelli commerciali su Win hanno frotte di
> > agenti/commerciali che spingono dalla mattina alla sera (è il loro
> > lavoro) per vendere i loro prodotti.
> >
> > Il secondo problema si basa sul fatto che le persone tendono,
> > logicamente, ad assumere le decisioni più convenienti per loro.
> > Chi in azienda decide che sistema operativo o sw utilizzare, ha due
> > scelte: 1) sceglie il prodotto leader del mercato
> > 2) sceglie un'alternativa in base al rapporto prestazioni/costi
> >
> > Nel primo caso un eventuale insuccesso del progetto non è a lui
> > addebitabile, in quanto ha fatto la scelta sicuramente migliore, per
> > quanto non abbia risposto alle aspettative.
> > Nel secondo caso invece si assume la responsabilità di un eventuale
> > insuccesso, perchè se le cose vanno male la colpa è sua che ha fatto
> > una scelta "creativa" o "innovativa". Se invece va bene diventa un
> > "mago" del software.
> > Ma per fare la seconda scelta ci vogliono le palle e bisogna sapere
> > di cosa si stà parlando in prima persona.
>
> Purtroppo quest'ultima ipotesi raramente funziona in quanto in azienda
> difficilmente c'è qualcuno che ha una visione dettagliata di tutti i
> settori. Spesso succede nelle migrazioni da altri software che si pianifica
> il tutto, si parla con i vari responsabili in modo da includere e sistemare
> tutte le funzionalità. Poi si parte e c'è sempre qualcuno che ha il caso
> sfigato tutto per i cavoli suoi di cui solo tizio sapeva dell'esistenza.
Problema di analisi che vale anche per Windows.

>
> > Non sono d'accordo. Il C forse ma il C++ è tutto un'altro linguaggio.
> > Solo il nome e la compatibilità con il vecchio C li accomuna in
> > qualche modo.
>
> Sul C++ non mi esprimo direttamente, in quanto avevo cominciato solo a
> leggere un manuale, poi per fortuna sono partito per naia e ho abbandonato
> quel posto.
> Ho provato a chiedere invece a persone che usavano il C++ se alcuni dei
> problemi che avevo con il C sono stati risolti e la risposta è stata
> negativa (non so  se il motivo sia perché loro non avevano mai affrontato
> il problema e la risposta sia stata più o meno a casaccio).
> Bisognerebbe mettersi qui a discutere di persona se non non se ne viene più
> fuori.
Il c++ è di verso in quanto di da la classe string per gestire le stringhe 
senza usare i char* e perchè ti permette di strutturare l'applicazione con 
una modellazione ad oggetti. Stà al programmatore però usare questi due 
strumenti.

>
> > I puntatori per lavorare sulle stringhe li usi in modo trasparente
> > con classi tipo <string.h> o <qstring.h>.
> > Se poi il progetto delle classi è fatto bene è facile evitare anche i
> > memory leak e i SIGSEGV.
> > I puntatori li puoi anche in C++ usare solo quando ti servono.
>
> Il problema è proprio questo. Spesso ti tocca mettere le mani su programmi
> fatti da altri e non è detto che questi abbiano rispettato i principi di
> una sana programmazione. Se il linguaggio non ti lascia fare cazzate già
> dall'inizio è un buon punto di partenza.
> Per capirci dovrei farti vedere alcuni sorgenti che però per vari motivi
> non posso spedire.
Se metti mani su cose fatte da altri non si parla più di migrazione o 
confronto win/lin. Usi quello che trovi e ti smazzi le cazzate degli altri.
>
> > E' certo che quando si programma in C++ le classi che tu disegni
> > vanno a rappresentare un modello. Se le condizioni a contorno o una
> > maggior definizione delle specifiche vanno ad "intaccare" il modello
> > è sempre necessario tirarsi su le maniche e modificare il modello,
> > quindi modificare le classi, in modo che rappresentino le nuove
> > condizioni.
> > Procedere come spesso si usa patchando il sw porta sempre ad avere un
> > sw che non ci appartiene perchè non sappiamo più come funziona.
> > E allora sì non si capisce nulla tra puntatori e variabili globali.
>
> Nelle due esperienze precedenti di lavoro si andava al rattoppo sul
> rattoppo all'ennesima potenza come diceva Daneel Olivaw.
> Dove sono adesso meno ma ogni tanto succede.
Sono sempre problemi organizzativi se il rattoppo supera certe soglie. Ma lì 
la discussione non è più win/lin, ma software project management.

>
> > Per quanto riguarda Java penso che ti sbagli del tutto. Non è molto
> > diverso da .NET per quanto riguarda l'architettura. Sicuramente nei
> > suoi primi anni di vita ha patito la pesantezza della RM e la
> > limitatezza delle funzionalità ma penso che questo tempo sia finito.
> > Con la JRE 1.6 sono stati fatti passi da gigante. Se poi la paura è la
> > gestione della garbage collection, basta avere l'accortezza di
> > impostare a null i puntatori alle classi che non ti servono più.
>
> Java non l'ho potuto sperimentare di persona. Avevo la collega di fianco
> che ci ha programmato dei terminali, mi sembra con il jdk 1.4.
> Nulla da dire sulla sintassi/costrutti del linguaggio. Il problema
> principale era dato dalla lentezza e dalla mancanza di controlli grafici
> (es. griglie) adatte agli scopi che servivano.
> Da quello che mi diceva, se servivano dei controlli grafici personalizzati
> bisognava scriverseli in C++.
No puoi farli benissimo in Java. Per la lentezza, come dicevo è molto 
migliorato. Inoltre il numero di librerie che si trovano in rete senza 
cercare molto è impressionante. La sun dà librerie ufficiali all'avanguardia. 
Poi c'è il progetto apache.
>
> > L'attrattiva c'è, ma non stà nei linguaggi e nelle librerie.
> > L'alternativa è nell'informazione che hai disponibile. Ricordati che
> > se quando hai un problema puoi googlare e trovare la soluzione bell'
> > e pronta è solo grazie alla comunità open source. Inoltre se stai
> > usando una libreria di qualcun'altro puoi studiarla, capire come
> > funziona ed anche modificarla in base a quello che ti serve. Ad
> > esempio nell'azienda dove lavoro si usava una libreria open source
> > per aprire svg da qualche mega. Andando a vedere il sorgente della
> > libreria sono state disabilitate alcune funzionalità non necessarie e
> > si sono ridotti i tempi di apertura da 20 secondi a 2!
>
> Infatti non ho mai detto nulla contro l'open source, nei miei programmi,
> quando ho bisogno di qualche libreria/componente prendo (e impongo ai
> colleghi) di prendere quelli che hanno il sorgente. Mi è già capitato più
> di qualche volta di aver a che fare con componenti bacati e che sono
> riuscito a sistemare avendo i sorgenti.
> L'unica cosa da fare è appena avrò un po' di tempo cominciare a scaricare i
> vari ambienti e provare ad approfondire e vedere fin dove ci si può
> spingere.
>
Facci sapere i risultati!!!

> Ringrazio tutti per la "chiacchierata", mi scuso ancora per il ritardo con
> il quale ho risposto (maledetta Telecom!!! mi offro volontario per test di
> connettività tramite ponti radio :-)), alcune idee mi si sono chiarite,
> altri dubbi rimangono... vedremo tra qualche tempo come proseguirà la
> storia.
Grazie a te per aver fatto partire una delle più belle discussioni fatte in 
ML!

-- 

Alessandro Galli
Alias Hirfuin Mantombroso
alessandro.galli a gmail.com
http://www.montellug.it   
http://krdm.sourceforge.net/
--
José Ortega y Gasset: 
 La scienza consiste nel sostituire
 un sapere che sembrava ormai certo, con una teoria, ovvero
 con qualcosa di problematico.