Come l'anno scorso, eccovi il reportage del Delphi Day, l'evento organizzato da Wintech Italia, l'azienda che sostiene la community Delphi&Dintorni, con la collaborazione di Borland Italia, giunto alla sua quarta edizione.
Questo reportage è da ritenersi una semplice “cronaca parziale” senza pretese di esaustività: è complesso raccontare tutto ciò che avviene al Delphi Day, che si propone prima di tutto come un'occasione aperta e gratuita di incontro tra sviluppatori, un pretesto per attribuire un volto agli indirizzi di posta elettronica che ogni giorno popolano i gruppi di discussione dedicati a Delphi...e dintorni, appunto.
Dopo l'arrivo al Park Hotel di Piacenza e il consueto processo di registrazione, la platea è seduta e Marco Cantù “apre le danze” mostrando alcune slide in cui vengono riepilogate le aziende grazie alle quali l'evento può avere luogo, con gli indirizzi e i riferimenti per entrare in contatto e l'incentivo a contribuire economicamente allo sviluppo e al sostegno dei gruppi di discussione; seguono poi indicazioni sul modo in cui verrà affrontato il programma della giornata.
Cantù mostra uno scorcio di alcuni file PDF del nuovo libro “Mastering Borland Delphi 2005”, da poco inviato in stampa; il rilascio definitivo, stando alle ultime notizie riportate sul sito personale di Marco (http://www.marcocantu.com), è previsto per i primi di luglio.
La giornata si apre con la prima sessione, presentata da Marco Cantù e dedicata ai dieci anni di vita dell'ambiente di sviluppo cui è dedicato e intitolato l'evento.
Viene visualizzata su grande schermo una carrellata di “chicche” che mostrano l'evolversi di Delphi, iniziando dalla sua prima comparsa nella preview pubblica alla Borland Conference di Orlando (Florida) del 1994.
Le caratteristiche di Delphi si percepivano dagli argomenti trattati nella conferenza dell'epoca, quali la presenza di un ambiente RAD (Rapid Application Development) basato su linguaggio Pascal e la possibilità di scrivere componenti riutilizzabili. Tali potenzialità sono riportate anche sugli appunti scritti da Cantù in quella occasione e ancora oggi caratterizzano inequivocabilmente il prodotto.
Per la gioia del pubblico, Cantù ha mostrato inoltre su grande schermo alcuni supporti multimediali usati per il rilascio delle prime versioni beta e anteprime del prodotto, foto di conferenze dell'epoca (con stand di società ormai scomparse o assorbite), dépliant e articoli e divertenti video promozionali tra cui il celebre promo ispirato all'OktoberFest (il filmato è reperibile all'interno dei CD “Companion Tools” di Delphi7 e versioni precedenti).
I “reperti storici” si trovano sul sito di Marco Cantù, nella pagina appositamente allestita per il decimo compleanno di Delphi (http://www.marcocantu.com/delphibirth/default.htm).
Concludendo la sessione, Marco ha usato una “versione d'epoca” di Delphi, la 1.0, ancora a 16 bit, eseguita su Microsoft Windows 3.1 all'interno di una macchina virtuale, per sviluppare un'applicazione dimostrativa disponendo un controllo TEdit, un TMemo e un TButton sul form principale; ad ogni pressione del pulsante, il contenuto della casella di testo veniva aggiunto al Memo. E' stato interessante notare come alcune finestre di dialogo del prodotto siano rimaste pressoché immutate nel tempo, sebbene l'editor del codice fosse ancora immaturo e privo di qualsiasi feature tra quelle che oggi conosciamo, quali Code Completion, Code Insight e così via.
Con qualche escamotage, il progetto dimostrativo è stato salvato all'interno di un floppy disk virtuale e caricato successivamente all'interno di Delphi2005; selezionando la piattaforma “target”, Win32 o .NET, il progetto costruito con Delphi1 è stato correttamente caricato e compilato senza alcun problema!
Il progetto dimostrativo non era certo complesso, ma va precisato che un simile traguardo di compatibilità all'indietro del codice sorgente non è stato raggiunto da alcun ambiente di sviluppo concorrente, nonostante le transizioni affrontate da una piattaforma all'altra, prima da 16bit a 32bit, poi da 32bit a .NET.
Un'attenta compatibilità con il “passato” in generale, soprattutto a livello di codice sorgente, e il mantenimento degli elementi chiave che hanno decretato il successo di Delphi sono prerogative di Borland per l'evoluzione del prodotto, come vedremo nella cronaca della sessione successiva relativa al futuro (prossimo) di Delphi.
Gabriele Giacomelli, Sales Engineer di Borland Italia, mostra la “roadmap” di Delphi relativa al futuro prossimo e...soggetta a modifiche senza preavviso.
La curiosità attorno a questa sessione era quasi palpabile, data l'incertezza latente che permea gli sviluppatori a causa del percorso di trasformazione, ancora relativamente oscuro, del sistema operativo Windows e della sua influenza diretta sull'evoluzione di Delphi.
Giacomelli presenta una “timeline” che mostra l'evoluzione di Delphi nel corso degli anni, a partire dal suo precursore Turbo Pascal fino ai giorni nostri e oltre, includendo le tecnologie annunciate quali il sistema operativo Longhorn, i suoi componenti Avalon e Indigo, nonché la versione 2.0 del .NET Framework, attualmente in beta.
A questo proposito, Gabriele ha affermato che l'intenzione di Borland è quella di impegnarsi nel mantenimento delle tecnologie esistenti, con un'apertura verso quelle future per le quali il supporto arriverà solo a seguito della loro concreta affermazione.
Nonostante il panorama tendenzialmente incerto e l'impossibilità contrattuale di fornire alcune informazioni ritenute “delicate”, Gabriele Giacomelli ha comunque descritto alcune delle “feature” che saranno probabilmente fruibili nella prossima versione di Delphi, che reca il nome in codice di DeXter.
In DeXter, sembra che ci siano buone probabilità all'introduzione del supporto al .NET CompactFramework di Microsoft per lo sviluppo di applicazioni in grado di funzionare su dispositivi mobili quali PocketPC 2003 e SmartPhone 2003. A tal proposito, una “technology preview” del compilatore Delphi.NET per CompactFramework dovrebbe essere disponibile a breve per il download sul sito BDN (http://bdn.borland.com).
Esso sarà utilizzabile direttamente in Delphi2005, in modo del tutto simile alla “Delphi for .NET Preview” rilasciata per Delphi7 a suo tempo e sarà una valida anteprima che, necessariamente, presenterà alcune limitazioni tipiche delle “technology preview”.
Il compilatore farà uso soltanto della libreria Windows Forms, escludendo – per il momento – soluzioni basate su VCL. Siccome le classi del .NET CompactFramework sono un sottoinsieme di quelle incluse nella libreria Windows Forms, è senz'altro d'obbligo compiere manutenzioni e correzioni sul codice generato da Delphi per una comune applicazione Delphi.NET per Windows Forms affinché sia possibile procedere alla compilazione. Inoltre, occorre anche precisare che le funzionalità di un'applicazione .NET CompactFramework sono comunque molto limitate rispetto ad una tradizionale applicazione desktop.
Gabriele Giacomelli ha mostrato poi il funzionamento del compilatore ed eseguito un'applicazione ottenuta con esso all'interno di un apposito emulatore.
La seconda rilevante novità di DeXter è l'integrazione di C++Builder, la conferma reale e definitiva di quanto promesso mesi fa con la “lettera aperta” agli sviluppatori che appartengono a questa comunità.
C++Builder abiterà nel nuovo IDE di Delphi e beneficerà delle nuove “feature” offerte dall'IDE, anche se, probabilmente, ci saranno alcune limitazioni dovute alla novità di questa introduzione. La “personality” C++Builder sarà basata sulla libreria VCL e, tra le caratteristiche certe, avremo l'uniformità nello sviluppo visuale con la controparte VCL Win32 per Delphi, le nuove funzionalità del Project Manager e soprattutto del nuovo Code Editor, quali la “visualizzazione storica” (History View), attualmente presente anche in Delphi2005, la possibilità di “collassare” ed espandere alcune parti del codice (Code Folding) e l'editing sincronizzato (Sync Edit).
C++Builder godrà anche delle facilitazioni fornite dai tool di supporto allo sviluppatore come CaliberRM e StarTeam per una maggiore produttività, individuale e di gruppo, rispettando le direttive previste da ALM (Application Lifecycle Management).
Gabriele Giacomelli mostra un'anteprima funzionale del nuovo ambiente creando un'applicazione dimostrativa; è possibile vedere una dimostrazione del tutto simile sul sito BDNtv (http://bdn.borland.com/article/0,1410,33085,00.html), che consente di visionare parzialmente il nuovo ambiente DeXter di cui abbiamo parlato sino ad ora.
Infine, Gabriele presenta la nuova versione del plugin per CaliberRM, che supporta le versioni più recenti dei server CaliberRM e fornisce un'interfaccia molto simile a quella dell'attuale programma client vero e proprio, ma non più “read only” e in grado di supportare pienamente le caratteristiche principali del client standard di CaliberRM.
La “technology preview” del plugin CaliberRM è già disponibile per il download, riservato agli utenti registrati, sul sito BDN (http://bdn.borland.com/article/0,1410,33077,00.html).
In conclusione, la prossima versione di Delphi, “codename” Borland DeXter, diventerà l'ambiente di sviluppo definitivo per la piattaforma Microsoft Windows e incorporerà le principali tecnologie esistenti su tale piattaforma, supportando i linguaggi Delphi (Win32), C++ (Win32), Delphi.NET e C#; consentirà inoltre il “porting” di progetti ottenuti con le versioni precedenti di Delphi e C++Builder coadiuvando, laddove necessario, la loro migrazione sulla piattaforma .NET in armonia con le attuali specifiche ALM elaborate dalla stessa Borland.
Il momento del “coffee break” è forse uno dei momenti che preferisco per prendere un po' d'aria (troppo condizionata, quest'anno), tentare di “svegliarmi” con un caffè e chiacchierare su quanto si è visto nelle ore precedenti.
Sarebbe divertente girare un documentario sul fenomeno “targhette”, dato che tutti i partecipanti, muniti di dolce e caffè, si aggirano per il corridoio dell'hotel sbirciando con disinvoltura le targhette altrui nel tentativo di leggerne il nome, ma senza farsi notare.
Prima della ripresa, la Sala Convegni è stata suddivisa in due parti per poter ospitare le successive sessioni tecniche che trattavano argomenti in parallelo; ovviamente, di seguito riporto i dettagli delle sole conferenze che ho deciso di seguire.
Gabriele Giacomelli presenta una sessione tecnica relativa al framework ECO II, già trattato l'anno scorso da Jason Vokes (in lingua inglese).
Lo sviluppo di applicazioni che accedono ai dati utilizzando componenti basati su DataSet e controlli “data aware” non consentono, generalmente, un approccio orientato agli oggetti in senso stretto. Per sfruttare i principi della OOP in questo frangente, gli sviluppatori hanno a loro disposizione due soluzioni: creare un proprio framework implementando tutte le classi di supporto necessarie per mantenere le istanze delle classi e persisterle sul dispositivo di storage selezionato, oppure...ricorrere ad uno strumento pronto all'uso e maturo.
ECO II è un “MDA (Model Driven Architecture) development framework” che consente allo sviluppatore di creare le proprie classi “business class” partendo da un modello concettuale realizzato in linguaggio UML, creare istanze di tali classi, estrarre le istanze che corrispondono a criteri prestabiliti per eseguire elaborazioni o visualizzarne i dati nell'interfaccia utente, eseguire una mappatura per rendere tali istanze “persistenti” su una base dati, che sia un semplice file XML o un database SQL avanzato.
ECO II è disponibile per lo sviluppo di applicazioni basate su .NET Framework con le librerie Windows Forms e Web Forms (ASP.NET), esclusivamente per i possessori dell'edizione “Architect” di Delphi2005.
Il modello delle classi si realizza attraverso l'editor visuale basato su tecnologia Together ed il codice viene generato automaticamente da ECO in maniera duale, ovvero le modifiche a tale modello si riflettono direttamente sul codice generato da ECO e viceversa. Le classi appartenenti al modello ereditano da antenate del framework che forniscono metodi e proprietà di supporto che, uniti a quelli forniti dall'ECOSpace di riferimento utilizzato per istanziarle, consentono di utilizzare tutte le feature offerte quali il supporto alla persistenza, le funzionalità di caching e di “undo/redo”, la gestione delle transazioni, commit e rollback parziali o totali e il supporto al linguaggio OCL per l'estrazione di dati a scopo di visualizzazione tramite il consueto meccanismo di “data binding” che consente di collegare controlli visuali a sorgenti di dati, con maggiori benefici utilizzando i DBWebControls distribuiti da Borland.
ECOII è in grado di persistere le istanze delle classi di business potenzialmente all'interno di qualsiasi base dati tramite un meccanismo di “mapping” indipendente e personalizzabile; ad esempio, se vogliamo persistere le classi in un database SQL, il supporto al mapping consente di specificare i costrutti SQL in grado di compiere inserimenti, modifiche ed eliminazioni alle tabelle dati, rispecchiando la struttura gerarchica delle classi modellate in precedenza.
Con questo approccio si concentrano gli sforzi nella realizzazione di un modello valido per le classi di oggetti da manipolare, separando egregiamente le fasi di modellazione, memorizzazione e presentazione dei dati. Ovviamente, in quanto strumento di una certa complessità, non è adatto a tutti gli ambiti di utilizzo, come semplici applicazioni, ma è senz'altro un valido aiuto nella realizzazione di progetti di proporzioni medio/grandi.
E' un compito davvero arduo riassumere in poco spazio e brevemente quanto osservato dal vivo nella presentazione tecnica di Giacomelli su ECO II. Come suggerito dallo stesso Gabriele, per “toccare con mano” le interessanti caratteristiche di questa tecnologia, la mossa più azzeccata è quella di scaricare brochure, documenti e video multimediali dal sito Borland (http://bdn.borland.com/article/0,1410,33061,00.html), nonché la versione “trial” di Delphi 2005 Architect (aggiornata con l'Update Pack 3) e verificare personalmente ciò che ECO II consente di fare.
Infine, Gabriele ha anticipato il possibile rilascio di ECO III nella prossima versione di Delphi, rivolta soprattutto a un ulteriore incremento delle performance del framework.
Protagonista di questa presentazione tecnica, condotta da Marco Cantù, è la libreria VCL.NET per lo sviluppo di applicazioni Delphi basate sul .NET Framework di Microsoft.
Marco ha chiarito il ruolo di questa libreria, introdotta nella versione 8 di Delphi, addentrandosi nei meandri tecnici della sua costituzione, evidenziando le differenze con la libreria parallela di Microsoft Windows Forms e, infine, analizzando i motivi della sua esistenza.
Vediamo innanzitutto l'organizzazione interna della libreria. Essa è suddivisa in due parti principali: la RTL (Runtime Library), che contiene classi e routine fondamentali, e la VCL intesa come l'insieme dei controlli visuali e componenti principali, inclusi quelli per l'accesso ai dati, già familiari agli sviluppatori Delphi.
Alcune delle classi che compongono la RTL sono semplici “alias” a classi analoghe presenti nella FCL (Framework Class Library), la libreria base del .NET Framework, mentre altre rappresentano un “wrapper”, un contenitore che incapsula al suo interno una classe della suddetta FCL. Attraverso l'uso dei Class Helper, già affrontati nel Delphi Day dello scorso anno, i progettisti della VCL hanno cercato di “iniettare” nelle classi mappate direttamente su classi della FCL i metodi conosciuti da chi sviluppa assiduamente con la libreria VCL per Win32.
Ma come si colloca VCL.NET rispetto a Windows Forms? VCL.NET può essere considerata una libreria parallela a Windows Forms ma, nonostante alcuni punti di contatto, costituisce un universo indipendente; ad esempio, quanto rappresentato dalla classe TForm non ha nulla a che vedere con la classe Form del namespace “System.Windows.Forms”, se non una semplice somiglianza a livello di comportamento e una discreta familiarità nei nomi dei metodi e delle proprietà.
Perché la libreria VCL.NET è stata realizzata in questo modo? Lo scopo di Borland è stato quello di ottenere una buona integrazione con le classi che costituiscono la libreria base del .NET Framework e, nel contempo, mantenere estremamente elevata la compatibilità del codice sorgente basato sulla libreria VCL (Win32), facilitando così il riutilizzo e il porting di codice già esistente.
Marco Cantù ha successivamente approfondito il discorso delle differenze architetturali tra VCL.NET e Windows Forms, aiutandosi con alcune semplici applicazioni create a puro titolo esemplificativo, anche per valutare le performance generali di entrambe le librerie. Ha sottolineato, a questo proposito, come il codice intermedio (IL) non dia necessariamente risultati prestazionali inferiori rispetto al codice nativo.
Entrambe le librerie sono ricondotte, in ultima istanza, alla chiamata di funzioni API Win32 del sistema operativo sottostante. Una delle sostanziali diversità è data dal fatto che, a livello grafico, VCL.NET chiama funzioni GDI, mentre Windows Forms si appoggia alla libreria GDI+, un'estensione che aumenta le possibilità in termini di disegno sul video introducendo gradienti, trasparenze e altre peculiarità ma che risulta più lenta rispetto alla limitata GDI.
Gran parte della libreria Windows Forms è costituita da codice gestito, mentre VCL.NET fa uso continuo e reiterato delle funzioni API di Windows, ricorrendo frequentemente ai servizi di P/Invoke (Platform Invoke) del .NET Framework e passando quindi da ambiente “gestito” ad ambiente “non gestito”, con tutti i controlli e le operazioni di “marshalling” necessarie, attività che influisce negativamente sulle performance di VCL.NET rispetto a Windows Forms.
La valutazione delle performance, quindi, è un compito particolarmente delicato e difficile, soprattutto considerando la mancanza di “linearità”, dovuta alla presenza del Garbage Collector che altera ogni esecuzione degli applicativi per il .NET Framework.
Entrando nel merito
delle caratteristiche della libreria Windows Forms, è
possibile affermare generalmente che sia del tutto simile alla
libreria VCL.NET: anch'essa contiene form, controlli visuali e
componenti aventi proprietà e metodi con nomi affini. Non
esiste un DFM: i valori delle proprietà vengono assegnate
direttamente tramite codice, contenuto all'interno di un metodo
specifico (InitializeComponents) gestito dal “designer”
dell'ambiente di sviluppo.
Vi sono alcune convenzioni che
potrebbero risultare fuorvianti da parte di chi sviluppa componenti
con la libreria VCL: ad esempio, gli eventi sono generalmente privi
del prefisso “On” che viene invece utilizzato nel nome
del metodo responsabile della loro esecuzione.
La libreria Windows Forms vanta alcune peculiarità non presenti nella VCL, quali il supporto a Unicode, la presenza di proprietà incorporate per l'accessibilità (sfruttate da software esterni o dal sistema operativo stesso), la presenza di un'area apposita in cui riporre i componenti (che non disturbano la progettazione del form che li contiene, come avviene normalmente con la libreria VCL), una diversa gestione del meccanismo di “data binding”, supportato da quasi tutti i controlli e disponibile anche per classi non strettamente legate al trattamento di basi di dati, quali semplici ArrayList, HashTable e così via. Infine, come già anticipato precedentemente, Windows Forms basa su GDI+ il tracciamento grafico dei controlli; trattandosi comunque di una tecnologia Win32, per liberare quanto prima le risorse occupate, è necessario “distruggere” gli oggetti GDI+ attraverso il metodo Dispose.
La libreria VCL.NET vanta anch'essa un discreto numero di esclusive qualità: per cominciare, la dotazione di componenti e controlli visuali è più ricca rispetto a quella offerta dalla libreria Windows Forms. Al contrario di Windows Forms, VCL possiede i componenti ActionList ed ActionManager per la gestione delle “azioni”, che ritengo personalmente uno strumento indispensabile nella progettazione di applicazioni; inoltre, Windows Forms non possiede nulla di equivalente al Data Module, non è possibile referenziare componenti e controlli che si trovano in moduli esterni (“cross module reference”), non esiste la possibilità di visualizzare dati a design time, il concetto di TGraphicControl è assente (ciascun controllo WinForms alloca un proprio handle di Windows, consumando risorse preziose), è possibile importare controlli Windows Forms in un'applicazione VCL ma non si può fare il contrario e, ultimo aspetto ma non per questo meno importante, la libreria VCL include il codice sorgente!
In conclusione,
tentiamo di rispondere alla seguente domanda: “che senso ha la
libreria VCL nel mondo .NET”?
Precisato che Borland non
considera “morta” questa libreria, tutt'altro... essa
consente sempre più la portabilità di codice sorgente
da Win32 a .NET e viceversa (con modifiche che si possono considerare
“puntuali” ma non architetturali), permette di sfruttare
le conoscenze già acquisite per sviluppare nuove applicazioni
gestite, possiede tutte le funzionalità già disponibili
in ambiente Win32 (inclusi i nuovi controlli visuali introdotti in
Delphi2005 e *tutte* le tecnologie conosciute per l'accesso ai dati,
con la possibilità di interagire addirittura con ADO.NET
attraverso un apposito “bridge”), è in grado di
garantire soprattutto una certa indipendenza dall'evoluzione delle
tecnologie WinForms e Avalon, il cui futuro rimane ancora oggi
piuttosto imprevedibile...insomma, è una valida alternativa!
Durante le “tavole rotonde” e l'ultimo break, ho disertato la Sala Convegni per sistemare alcune cose sul progetto nel mio notebook da presentare al concorso “Delphi & Dintorni Best Tech”. :-)
Riassumo brevemente
i tratti salienti del concorso: si trattava di presentare una
“tecnica Delphi”, cioè un modo particolare,
originale o inedito di affrontare un determinato problema con Delphi,
fornendo la propria soluzione e alcune righe di codice per
esemplificare.
Gli autori delle proposte giudicate migliori dal
comitato organizzatore avevano la possibilità di relazionare
al pubblico del Delphi Day la propria soluzione e ricevere un premio.
Sono state presentate, in ordine di apparizione, la mia soluzione riguardante la creazione di applicazioni organizzate “a pagine” (con un discreto imbarazzo poiché non sono così abituato ad avere un pubblico!), la soluzione di David Guadagnini costituita da un controllo grafico per la rappresentazione in “coordinate mondo” e, infine, la soluzione di Alessandro Bruzzone che consisteva nella gestione delle form di un'applicazione attraverso una ToolBar, vincitrice del primo premio in palio: una copia di Delphi 2005 edizione Architect.
Sul sito Delphi&Dintorni (http://www.delphiedintorni.it) sono pubblicati i “tip” che hanno partecipato al concorso con i nomi dei rispettivi autori, nonché tutte le slide di ciascuna sessione del Delphi Day, comprese quelle contenenti i dati statistici dell'accesso e della fruizione dei gruppi ospitati, illustrati e commentati da Cantù al termine delle presentazioni del concorso.
Il ricco programma del Delphi Day si è concluso con il “Keynote Borland” tenuto da Gabriele Giacomelli e riguardante SDO (Software Delivery Optimization), la nuova “vision” di Borland in merito al processo di sviluppo del software, basata sull'ottimizzazione delle cooperazioni e delle interazioni tra le diverse figure che partecipano al ciclo di vita del software stesso, considerando quindi che il team di sviluppo non rappresenta l'unico elemento della catena che contribuisce alla creazione e al mantenimento di un prodotto software.
Gabriele ha precisato che, trattandosi di una visione, quindi di un traguardo, ancora non esistono strumenti che supportano attualmente SDO; tuttavia, l'evoluzione dei prodotti Borland si muoverà sempre più verso il panorama tracciato da SDO, integrando nuovi linguaggi, nuove librerie e nuove piattaforme.
Potranno ottenere il massimo e beneficiare pienamente dei vantaggi di questa “linea di condotta” tutti gli sviluppatori che saranno in grado di imporsi una metodologia e un processo tra quelli supportati, utilizzando così in modo proficuo e con un preciso criterio gli strumenti che Borland mette loro a disposizione, ispirati alla visione SDO.
Per maggiori informazioni, è possibile consultare l'apposita sezione presente sul sito Borland (http://www.borland.com/us/company/software_delivery.html).
Al termine della giornata, è stato concesso uno spazio relativamente ampio alle consuete “domande e risposte” in merito agli argomenti affrontati nell'arco della giornata, con possibili divagazioni.
Dopo un primo momento di silenzioso imbarazzo, è stata posta una domanda (interessante) sullo stato di Kylix; Gabriele Giacomelli ha precisato che, attualmente, il progetto Kylix ha subito una battuta d'arresto in attesa che giungano tempi migliori in cui rilanciare, in qualche modo, questo ambiente di sviluppo che, purtroppo, non ha raggiunto i risultati previsti e soddisfatto le aspettative che Borland si era posta.
Successivamente, sono piovute alcune lamentele su Delphi2005 e sulla sua presunta “inutilizzabilità”; Gabriele ha fatto notare quanto un simile aggettivo si possa considerare tendenzialmente eccessivo poiché non sentito dalla maggior parte degli sviluppatori che attualmente fanno uso di Delphi2005; Gabriele ha aggiunto che ciò non toglie, ovviamente, che vi siano correzioni da apportare ai package che costituiscono l'IDE, sebbene l'applicazione di ben tre Update Pack consecutivi abbiano comunque garantito il pieno funzionamento complessivo di tutte le feature promesse.
Un altro “coro di proteste” si è levato in seguito all'annuncio dell'intenzione da parte di Borland di chiudere il supporto tecnico per Delphi7; provvidenziale è stata la domanda di Marco Cantù: “chi ha usufruito del supporto tecnico Borland?” alla quale nessuno ha risposto alzando la propria mano, ponendo fine alla diatriba.
Gabriele Giacomelli ha poi approfittato del momento di libero confronto per ribadire che il feedback degli sviluppatori Delphi, le critiche e i suggerimenti sono elementi importanti, ben accetti e sempre tenuti in considerazione, anche quando gli automatismi del sito “Quality Central” sembrano far pensare il contrario.
Concludo il mio
secondo reportage del Delphi Day con rinnovata soddisfazione per la
quarta edizione dell'evento che quest'anno mi ha coinvolto in modo
più diretto, soprattutto per la partecipazione al concorso,
un'iniziativa che ho trovato davvero emozionante e stimolante (oltre
al fatto di “gongolare” per la vittoria del libro di
Cantù) e per il contatto diretto con i partecipanti ai gruppi
di discussione con cui scambio quotidianamente pareri, tecnici e
non.
Una nota di particolare merito va alla bontà dei
contenuti prettamente tecnici delle presentazioni che più di
una volta mi hanno convinto a cambiare punto di vista in merito a
determinate questioni tecniche che, alla fine, mi hanno consentito di
operare scelte migliori nella mia attività di sviluppatore
Delphi. :-)
Si
ringrazia
Antonio Sanguigni
(a.k.a. “guastatore”)
per
la revisione