Alla conclusione delle due giornate che ho trascorso a Milano, devo dire che quella di partecipare al corso di aggiornamento per programmatori è stata un'ottima scelta.
Sono arrivato piuttosto intimorito dall'idea di trovarmi in mezzo ad una cinquantina di programmatori professionisti certamente più aggiornati di me. Temevo di fare la figura del pesce fuor d'acqua, dell'unico a capire poco o niente.
Invece mi sono subito rincuorato rendendomi conto di poter seguire abbastanza bene la trattazione, e anche di poter attaccare discorso sia con il docente che con gli altri partecipanti senza mai sfigurare nè dover rivelare che non sono un programmatore.
Evidentemente in questi ultimi anni non mi sono poi così arrugginito come pensavo. E' vero che sono rimasto molto indietro, ma è anche vero che ho avuto l'impressione di essere ancora in tempo a rimettermi in carreggiata.
Però dovrò mettermi bene sotto a studiare, se vorrò abituarmi alle nuove tecniche e ai linguaggi di programmazione attuali.
Parliamo ora di quali prospettive si aprono per WinGuido, sulla base di ciò che ho appreso.
Innanzi tutto, direi che non ci sono più dubbi: il WinGuido che conosciamo adesso, nato originariamente in Visual Basic 4 e poi trasferito in Visual Basic 5, è destinato a scomparire.
Un linguaggio di programmazione vecchio di 10 anni, ormai, non potrà darci più di tanto: un programma con difficoltà di installazione, di esecuzione e di stabilità, inadeguato a realizzarvi funzionalità richieste da esigenze attuali che 10 anni fa non erano prevedibili.
Usando invece un linguaggio di programmazione al passo coi tempi, cioè Visual Basic 2005 che utilizza l'ambiente NET FrameWork, si potranno risolvere molti problemi e realizzare nuove funzionalità oggi impensabili.
Si apre inoltre la prospettiva di portare WinGuido anche in altri sistemi con cui NET FrameWork è compatibile: ad esempio, i palmari Pocket PC. E, forse, anche altri tipi di palmari che usino il sistema operativo Windows CE.
Si presenta persino la possibilità di arrivare, in futuro, anche al sistema operativo Linux, quando saranno stati realizzati gli ambienti che consentano di far funzionare anche in quel sistema i programmi che utilizzano NET FrameWork.
Queste sono quindi le nuove prospettive che si aprono. Come fare, però, per arrivare a realizzarle, tenendo conto che esiste già un WinGuido usato da quasi un migliaio di utenti?
La speranza di poterlo prendere così com'è, trasferirlo nel nuovo linguaggio che è Visual Basic 2005, e andare avanti nel suo sviluppo, dopo qualche piccolo lavoro di adattamento, come se niente fosse cambiato è definitivamente crollata: in base a quanto ho appreso, devo concludere che un'operazione del genere non avrebbe alcun senso.
Quella operazione, cioè, che feci anni fa per passare da Visual Basic 4 a Visual Basic 5: allora, tutto si risolse con un aggiornamento solo un po' più lungo del solito, al termine del quale gli utenti ebbero il nuovo WinGuido senza dover installare nulla e senza nemmeno notare la differenza. Io continuai a lavorare con Visual Basic 5, e da allora il vecchio Visual Basic 4 non l'ho più toccato.
Adesso, non ce la caveremo così facilmente: WinGuido dovrà essere riscritto da capo, e gli utenti dovranno installare un nuovo programma.
Prima di completare un tale lavoro di rifacimento, ci vorranno anni.
Si ripeterà, cioè, quello che già successe quando si trattò di passare dal vecchio Guido per MS-DOS al WinGuido per Windows.
Bisognerà quindi decidere come organizzarci per il passaggio dall'attuale WinGuido in Visual Basic 5 al futuro WinGuido in Visual Basic 2005.
La cosa da fare, più brutale e più risolutiva, dovrebbe essere questa: mi dedico ancora per poco tempo al WinGuido esistente per completare qualche lavoro tuttora in sospeso, quindi il WinGuido esistente viene fermato così come è arrivato, non ci metto più le mani sopra, non si fanno più aggiornamenti, e nel contempo inizio a realizzare il nuovo WinGuido e a ricostruirvi, una per una, le funzionalità di quello attuale. Quando questo lavoro sarà finito, darò notizia che è pronto un nuovo WinGuido, ve lo installate e tutto riprende come prima.
Questo sarebbe il modo per fare il lavoro più semplice e più pulito, ma comporterebbe un grosso inconveniente: doverci fermare qui, e ripartire dopo non meno di tre, quattro o cinque anni. Col rischio di fare un lavoro che, una volta completato, già si rivela vecchio, mentre magari nel frattempo gran parte degli utenti hanno abbandonato WinGuido proprio perché, non essendo stato più aggiornato, è diventato obsoleto.
Penso invece che sarà meglio cercare una soluzione che consenta di realizzare in modo graduale il passaggio dall'attuale WinGuido a quello futuro, senza dover rinunciare alla possibilità di mantenere il programma aggiornato.
La soluzione potrebbe essere quella di fare un miscuglio tra i due programmi: quello esistente e quello futuro.
Mantenendo in esercizio il programma esistente, si può cominciare a riscrivere alcune funzionalità col nuovo linguaggio, facendo nascere gradualmente il programma nuovo, e nel frattempo avere un sistema che, a seconda dei casi, prenda le funzionalità in parte dall'esistente e in parte dal nuovo.
Ad esempio: supponiamo che io rifaccio la rubrica di WinGuido col nuovo sistema. L'utente avvia WinGuido, entra nel menù principale e sceglie. Finché sceglie qualsiasi altra funzionalità, continuerà ad usare il vecchio WinGuido come prima. Ma quando sceglie la rubrica, sarà portato ad entrare nel nuovo WinGuido e ad usare la rubrica in quello.
Un tale sistema misto potrebbe durare anche per anni, man mano che le varie funzionalità vengono riscritte nel nuovo programma. Finché arriverà il giorno in cui si dirà: adesso il vecchio WinGuido in Visual Basic 5 può andare definitivamente in pensione, perché si può fare tutto con quello nuovo.
Una soluzione del genere consentirebbe un passaggio meno traumatico dal WinGuido esistente a quello futuro, senza rinunciare a mantenerlo aggiornato.
Comporterebbe, però, un maggiore impegno nell'organizzare il transitorio, proprio perché si tratterebbe di gestire un sistema più complesso formato da due programmi diversi che si interallacciano tra di loro.
Comunque, prima di capire cosa sarà meglio fare, avrò bisogno di impratichirmi, di prendere confidenza con Visual Basic 2005 e con NET FrameWork, e di acquisire nuove nozioni e informazioni.
Quindi, dateci sotto a procurare quanto necessario: libri che trattino questi argomenti, contatti con esperti della materia, possibilità di partecipare ad altri corsi, eccetera.