Pensieri malcelati

Ma perché la Webmail telecom è così pessima?

Andrea Raimondi — Tue, 16 Jan 2007 17:05:00 GMT

Se c'è una cosa che proprio odio fare è dover cancellare lo spam dalla webmail telecom.

Ogni volta è un macello e ci mette un sacco di tempo per restituirmi la pagina successiva di posta.

E' una roba assurda ed indecente, considerando che ho una linea ADSL.

Sono veramente basito.

Andrea

No ad Internet Explorer 7? Un punto di vista...

Andrea Raimondi — Sat, 13 Jan 2007 15:50:00 GMT

Mi riallaccio al post di Raffaele inerente l'idea che chi dice no per principio ad Internet Explorer 7 sia ignorante riguardo(vale a dire, non sia a conoscenza di) la struttura componentizzata di Internet Explorer e di tutte le "cose" che IE fa.

E' ciò assolutamente vero? E' solo questa l'unica possibile spiegazione? Non credo proprio, e spiego subito perché.

Raffaele stesso parla del più grande limite di Windows, cioè che molte sue parti sono basate proprio su Internet Explorer.

Perché è un limite? Molto semplicemente, perché se c'è un errore nel browser, questo si propaga a tutto il sistema ed a tutte le applicazioni che sfruttano, consapevolmente o meno, quello stesso browser.

Non è successo una volta sola che un problema di sicurezza di Internet Explorer abbia causato problemi in applicazioni terze, magari completamente scorrelate.
Può essere ok se si usa il controllo web browser, può essere ok se si usano gli oggetti HTML, è meno ok se per esempio il problema risiede in MSXML, tanto per dirne una.

Quindi, siamo sicuri che chi dice "No ad Internet Explorer 7" così, senza se e senza ma, lo faccia per "ignoranza"? O forse non è proprio il sapere certe cose che spinge a dire "NO!"?

Quanto poi al discorso che Internet Explorer cerca di installarsi "ammucciato", come dicono i siciliani, non c'è niente di nuovo.
Lo fa già lo strumento di rimozione malware per Windows, che mi viene riproposto ogni volta che faccio l'aggiornamento, anche se io gli dico espressamente di non presentarmelo più.

E' quindi corretto dire che MS cerca di imporlo? Si, secondo me è corretto dirlo.

E' giusto o no scaricarlo? Beh, qui la risposta è molto soggettiva secondo me. Anzitutto c'è da considerare che IE è storicamente pieno di problemi, non solo di sicurezza.

D'altro canto, però, è anche vera un'altra cosa e cioè che ci sono tantissimi siti che, purtroppo, funzionano solo con IE. E' dunque possibile che alcuni di quei siti vengano aggiornati per utilizzare le nuove caratteristiche di IE e quindi che sia necessario aggiornarlo.

L'unica categoria per la quale l'aggiornamento è davvero irrinunciabile, a mio avviso, risulta quella dei webdeveloper. Chiunque sviluppi anche una sola pagina web dovrebbe rassegnarsi e scaricarlo, visto che la stragrande maggioranza degli utenti lo sta adottando.

Come vedete, le cose non sono sempre così semplici quando si va ad analizzarle un pò meglio.

Infine, voglio contestare l'idea che chi dice una certa cosa lo faccia solo ed esclusivamente per ignoranza, quando non è affatto sicuro che sia così, come mi sembra di aver dimostrato.

Concludendo: io IE7 l'ho installato perché - a volte - faccio parte dei webdeveloper :) quindi per me non c'era scelta. Altri, però, potrebbero fare scelte differenti.

Saluti,

Andrea

Borland Developer Studio e dotNET

Andrea Raimondi — Thu, 19 Jan 2006 15:28:00 GMT

Eccomi qui pronto di nuovo a postare.

L'argomento, che tratterò in una serie di post, è il nuovo Borland Developer Studio 2006, uno
splendido strumento per lo sviluppo Win32 e dotNET.

In questa serie, mi focalizzerò sullo sviluppo dotNET, in particolare una nuovissima e molto promettente tecnologia di nome Enterprise Core Objects ver. III(abbreviato ECOIII).

Essa è basata(per ora) su dotNET 1.1 SP1, poiché BDS 2006 non supporta dotNET 2.0(previsto invece per la prossima versione) e consente di avere un completo motore di persistenza e di gestione di oggetti.

BDS2K6 viene in tre edizioni diverse: Pro, Enterprise, Architect. Ognuna di esse ha un "pezzo" di ECO, tranne la Architect che ha invece *tutto*.

Vediamo come funziona ECO "concettualmente": l'idea è basata sul Model Driven Development, infatti allo scopo BDS2K6 include Together, un tool di modellazione Borland anche per Visual Studio. Esso viene esteso da ECO per supportare la modellazione di classi persistenti, quindi si ha a disposizione un insieme di elementi UML da utilizzare per la pianificazione e la modellazione del sistema-applicazione.

Quando servirà poi definire il sistema di persistenza, ecco che ECO mostra i muscoli: nelle versioni Enterprise ed Architect, infatti, è disponibile un completo framework che consente di avere indipendenza dal sistema database utilizzato(sono supportati tutti i DB attraverso i Borland Data Provider, di cui parlerò più avanti) e consente anche - in caso di cambio al modello - di evolvere il database.

La funzione di evoluzione è anche utile quando si ha un database preesistente e si vuole generare il modello(opzione disponibile), aggiungendo quindi al DB tutti i campi e le robe che servono ad ECO per
funzionare in modo corretto.

Come detto, però, ECO non è solo un motore di persistenza: è infatti disponibile un Object Control Language(OCL) tramite il quale definire, vincoli, constraints, ma anche operazioni(supponendo ad
esempio di voler caricare tutti gli elementi di classe TPersona, lo statement OCL è semplicemente
"TPersona.AllInstances").

Tra i vari metodi di serializzazione disponibili, ovviamente, c'è anche il formato XML, specificatamente SOAP - molto utile se si sviluppano Webservices oppure se si scrivono applicazioni "desktop".

E non è finita qui

Dicevo che avrei parlato dei Borland Data Provider più avanti... beh, spero che la piccola introduzione abbia suscitato un minimo di interesse, quindi ecco una piccola descrizione di cosa sono.

Posto in termini semplici, la tecnologia BDP si appoggia alla "infrastruttura" ADO.NET aggiungendo
però un pò di cose: anzitutto, c'è un sistema di connection pooling built-in(cosa che fa molto
comodo in certi ambiti) e poi... uhm... mi sa che se continuo così, questo post non finisce più ,
quindi vi rimando a questo articolo introduttivo sui BDP.

Ah, ovviamente ECO supporta anche ASP.NET 1.1(versioni ENT e ARCH), quindi potete creare dei "Webservice ECO" i quali sono quindi già "mezzi pronti", basta solo aggiungere il codice.

Si, parlo di codice, infatti ECOIII non è un C.A.S.E.: pur potendo modellare le classi da rendere persistenti, si possono aggiungere delle operazioni(metodi) e codarle "a manina" mentre ECO si occupa di tutto il resto(persistenza, distruzione, ecc).

Sfortunatamente, io dispongo solo della versione PRO, per di più da pochi giorni, quindi sto ancora imparando "bene" come realizzare i modelli e le vere potenzialità della tecnologia.

Una cosa però è degna di menzione: l'edizione Architect, oltre ad una serie di "goodies" in generale(troppa roba per elencarla in un post) contiene una parte di ECO molto interessante: è infatti possibile realizzare delle "ECO State Machines" che consentono di realizzare delle macchine a stati da usare con le classi persistenti. Molto, molto, molto carino .

Per ora finisco qui, spero di tornare presto con un altro post ed un pò di codice per mostrare come nella pratica funziona ECOIII(quindi anche con un pò di codice).

Saluti,

Andrea

[OT](~) It was bound to happen...

Andrea Raimondi — Sat, 29 Oct 2005 02:14:00 GMT

Ebbene, finalmente si è "congelato l'inferno" e posto il mio primo OT qui . Che poi, in realtà, è OT fino ad un certo punto - visto che comunque di informatica si tratta(ed ecco il perché della tilde, il famoso "circa", messo tra parentesi fuori dal tag per consentire comunque il filtering).

Riguardo il fatto che prima o poi sarebbe accaduto, non c'era alcun dubbio, almeno per me.

Questo post di Marco Birzaghi parla di una chiosa finale di Beppe Grillo(o Grullo ?) in un post di quest'ultimo.

Un pò di chiarimenti, diciamo così, preliminari: sono d'accordo che la scelta di un sistema dovrebbe essere tecnica oltre che pratica, senza guardare "cui prodest" a meno che non vi siano motivi specifici.
E' altrettanto vero, però, che una posizione di monopolio - anche se solo "di fatto" - è sempre un male, per il semplice motivo che impedisce agli altri di partecipare lealmente(e soprattutto, economicamente) alla "competizione".

Marco poi espone un commento che, a suo dire, riflette le sue stesse opinioni, per poi lanciarsi in una
filippica, mi si passi il termine, "contro" i progetti OpenSource. Si, lo so, non dice "l'OpenSource è male", ma lascia intendere che dell'OpenSource in quanto tale non ci si può fidare.

Chissà com'è, però, quando io dico delle cose su argomenti che magari non conosco proprio benissimo(e succede...) allora mi si dice "eh ma tu parli senza conoscere", però quando poi lo fanno gli altri... nessuno fiata.

Perché magari il nostro Marco non si è accorto, passando in edicola, che esistono tante riviste su Linux e probabilmente non ha mai provato a scrivere una URL come questa oppure questa.
Magari gli sarà anche sfuggito, ma si sa, non tutti conoscono i segreti di Google, che scrivendo "documentazione linux" e premendo "Mi sento fortunato" si finisce sul sito ZioBudda.net nella sezione(dici il caso...) documentazione.

Qualora però tutto ciò non fosse possibile farlo perché magari il modem non si installa, allora la casalinga di Voghera potrà, scrivendo a qualcuna di quelle riviste che trova in edicola, scoprire che esistono i Linux User Group e scoprire(per uno strano scherzo del destino, la città non l'ho scelta io, ma lui ) che proprio a Voghera ce n'è uno(il cui sito però sembra al momento irraggiungibile, altrimenti avrei postato il link).
Ecco che lì potrà trovare tutto l'aiuto che serve(il modem è uno dei problemi più comuni) e risolvere, anche magari per farsi aiutare ad installarlo e configurarlo correttamente(ed i conflitti hardware si risolvono...).

Infine, se proprio si vule provarlo prima di installarlo, esistono le distribuzioni Live, avviabili da CD senza fare(in alcuni casi) proprio niente. Vorrei anche far notare, giusto "en passant", che è molto comodo avere delle distro avviabili perché nella stragrande maggioranza dei casi sono un toccasana per computer che ad esempio non si avviano oppure per i quali non si conosce la password di Administrator e bisogna recuperare qualche file importante. Questo però con Windows non si può fare, non perché sia impossibile tecnicamente - ma solo perché Microsoft non lo consente, e siccome tutti i diritti sono suoi nessuno può modificarlo legalmente affinché la cosa funzioni. Come detto, sarebbe comodo, però non siamo liberi di farlo, perché Windows è un prodotto proprietario! Ecco, l'ho detto!

Riguardo agli sviluppatori Linux che "se ne lavano le mani"(parole tue, Marco), sarebbe bello avere qualche esempio, qualche fonte, sai perché le parole hanno un peso un pò diverso quando vengono supportate da una fonte rispetto a quando questo non succede.

Altro aspetto, invece, è la semplicità di Windows o Mac. Posso testimoniare in prima persona in quanto utente di entrambi i sistemi(si, sto usando un Mac da... uhm... Giugno in modo continuativo, inoltre mi è capitato di usarlo abbastanza spesso nell'ultimo anno e mezzo).
Ovviamente, Windows lo conosco e lo "capisco"(nel senso di conoscerne il punto di vista, diciamo) molto meglio di Mac - tuttavia secondo me sono tutt'altro che facili, specialmente Windows.

Però, a questo punto vale la pena fare qualche esempio Windows. Prendiamo il desktop: create due cartelle, con questi nomi: "Questa è' una cartella con un nome supermegaiperstratosfericamente lungo" e "Questa è una cartella con un nome lungo" . Noterete che sul desktop non c'è modo di distinguerle, specialmente se contengono molti files di tipo non omogeneo e non "riconosciuti" da Windows. Mac consente, invece, ad esempio, di colorare le cartelle in modi diversi, quindi anche se hanno dei nomi simili, quando sono colorate in modo differente si distinguono.

Quanto ai problemi hardware... provate ad usare un modem TRUST USB in Windows e poi ne riparliamo. Si tratta del primo esempio che mi è venuto in mente(visto che l'ho sperimentato personalmente ed anche qualche persona che conosco di vista) ma certamente ce ne sono altri.

Cosa voglio dire con questo? Voglio dire semplicemente che un numero verde non sempre risolve i problemi, voglio anche dire che non sempre un supporto comunitario è inefficace, per questo basta constatare come lavorano gli MVP: qualcuno mette in discussione la loro preparazione? Mi pare proprio di no, e questo medesimo discorso vale anche per Linux(anche se non ci sono MVP... oppure è proprio quello il problema? Scusate, ma non resisto quando si tratta di teorie di complotto ).

Torniamo alla documentazione: certo, per alcuni progetti non ce n'è proprio, per altri è abbastanza scarsa, però nemmeno nel software proprietario le cose vanno molto meglio: vogliamo parlare di certe API di Windows dove la documentazione dice una cosa, ma il funzionamento è diverso?
Purtroppo - su due piedi - non me ne viene in mente qualcuna, comunque ci sono e non sono poche.
Quello che però voglio sottolineare non è l'imprecisione di per se, quanto piuttosto che su progetti così spaventosamente grandi(Windows, Linux, alcuni altri) è normale che sia così!

Ancora riguardo a chi lascia a piedi gli utenti. Scusate, non so voi, ma io sarà una quindicina d'anni che uso DOS prima e Windows poi, e da Windows 95 in poi ci sono sempre stati gli updates, le patch, tanto che in MS sono arrivati perfino a scrivere un programma che tiene traccia delle patch installate(non so come si può avere, so che esiste però) e cose simili. Mi sono sempre chiesto quanto tempo noi passiamo a riavviare Windows. Voi ve lo siete chiesti? Allora, diciamo che una buona parte delle patch richiede il riavvio. Diciamo che in un mese escono 10 patch. Diciamo che ogni riavvio richiede DUE minuti. Sono esattamente 240 minuti all'anno. 4 ore. Però, di media, probabilmente un singolo riavvio richiede più tempo(per "riavvio", intendo l'intervallo di tempo che passa da quando si preme "riavvia" a quando il computer è pronto per essere utilizzato). Ultima nota riguardo questo, io non sto considerando le installazioni dei programmi e le formattazioni , che anche sono cose relativamente frequenti.

Fate un pò di conti. Allora, chi è che davvero ferma la produttività e gli cascano le ruote?

Quindi per piacere, non diciamo cose "a caso" solo perché non abbiamo il tempo di riflettere.
Questo(è ovvio) vale anche per me, perché anche io alle volte sono ehm... sanguigno

Vediamo... penso di aver detto tutto... uhm... ah, no!

Quando però si dice che l'open source non è un modello di business conveniente, sono solo parzialmente d'accordo. Qualora si abbiano dei capitali ed una certa struttura dietro, può essere un modello altrettanto valido. Ovvio, poi, che se si è da soli, le cose cambiano. Cambiano perché è chiaro che il singolo non può competere con una "struttura" anche piccola. Come esempi, però, non vi porterò nè IBM nè SUN, ma... MOSAICO .
Si tratta di una piccola società(rispetto ai mastodonti) che ha un prodotto OpenSource(beh... quasi... io non lo considero OpenSource visto che fa uso di componenti commerciali per il reporting e manco economici) comunque con sorgente liberamente scaricabile. E "funziona", nel senso che sono diversi anni che hanno fatto questa scelta e sono ancora in attività, forse poi non gli va male - no?

Ah, qualche tempo fa, qualche giorno, ho ricevuto un commento ad un mio post dove si dice che io ce l'avrei con Microsoft. Questo non è vero, nel senso che io non ce l'ho con Bill Gates in quanto tale, piuttosto non mi piacciono i monopoli e Microsoft lo è, nei fatti, anche se io sono "nato" come sviluppatore in ambienti MS ed ho scoperto Linux troppo tardi(fino al 1995 non ho avuto internet).

Sempre Marco(eh... oggi ci sei capitato te... ) dice di non capire la "conoscenza libera"... vuoi un esempio? UGI è conoscenza libera, non protetta da copyrights, a codice aperto. Non avrebbe senso questo spazio se qualcuno postasse dicendo "HEY! Ho trovato la soluzione al problema $X, però per vedere come ho risolto devi spedirmi a casa 1000 euro che mica te lo dò gratis!"
Adesso è più chiaro?

Ancora, c'è una frase che mi è piaciuta particolarmente ed è questa:" Prima di fidarmi do sempre un occhio al codice per capire se lo leggo facilmente ed è fatto con criterio ;-p ". Ecco, qui sta una delle chiavi di lettura dell'Open Source: puoi vedere il codice che usi e decidere se fa per te oppure no,
correggerlo se non funziona ed usarlo modificato. Senza che nessuno venga a dirti assolutamente nulla!

Sarei davvero curioso di conoscere qualcuno che è riuscito a correggere qualche API di Windows, oppure a realizzare una patch per il medesimo, a parte MS(unica depositaria dei codici sorgenti).

Ho scritto questo articolo perché penso che quel post abbia parecchi spunti di riflessione, mi piacerebbe avere vostri commenti al riguardo.

Buona notte,

Andrea

P.S. Più tardi disinstallo IMHO 1.2 ed installo la 1.3 .
P.P.S. Sto preparando un articolo introduttivo a Delphi.NET e Windows Forms, poi ne farò uno su Delphi.NET e VCL.NET .

Gestire le eccezioni

Andrea Raimondi — Wed, 12 Oct 2005 18:57:00 GMT

Le eccezioni vanno sempre gestite? Secondo me, non sempre. Il perché è presto detto:

Perché non tutti i progetti sono uguali: un progetto che deve essere usato da un programmatore, per esempio, potrebbe non gestire alcune eccezioni, o semplicemente mostrare un messaggio di avvenuta eccezione
Perché finché si è in fase di sviluppo o test, si potrebbero non considerare casi "specifici" oppure non accorgersi di certi errori finché non è troppo tardi(penso ad esempio ai casi non troppo comuni ma nemmeno da probabilità 1 su 1 miliardo )

Cosa fare però nel codice di gestione, quando abbiamo deciso che un pezzo di codice va "protetto"? Ecco, anche qui, le mie idee "variano" rispetto alla media, penso. Lo dico perché io credo fermamente nel fatto che se capita un'eccezione in un blocco di codice, nel codice di gestione ne vada sollevata un'altra. Di proposito. Si, capito bene . Di proposito, sollevare una nuova eccezione.

Immagino le facce, quindi vedo di spiegarmi: supponiamo che la nostra applicazione si connetta ad un database(si, lo so, l'esempio è originalissimo ). Qualora succeda "qualcosa" che genera un'eccezione(server spento, ad esempio), cosa dovrebbe vedere l'utente? Secondo me dovrebbe vedere che l'applicazione $MI_CONNETTO_AL_DATABASE non riesce a collegarsi al DB, ma questo non vuol dire che debba sapere che la connessione è fallita. Quindi si gestisce l'eccezione della connessione, per poi sollevarne una "personalizzata" che verrà gestita - a sua volta - e mostrerà qualcosa all'utente finale.

So che può sembrare un modo strano di programmare, ma ha un suo scopo, specialmente se questo discorso lo si vede in termini di WebServices. In questo contesto specifico, secondo me, le eccezioni personalizzate sono ancora più importanti rispetto al resto delle applicazioni, cui comunque questo tipo di programmazione si può applicare.

Ultima cosa, a questo riguardo: le eccezioni personalizzate possono, ovviamente, anche portare ulteriori dati personalizzati, elaborati al momento della gestione delle eccezioni, rendendo dunque possibile anche prendere "contromisure" oppure informare l'utente in modo più corretto ed esaustivo.

Ultimissima cosa, giurin giurello, poi chiudo : potrebbe essere interessante sviluppare(se non c'è già negli Application Blocks di MS, ma anche se c'è... ) un framework opensorcio per la visualizzazione delle eccezioni... qualche interessato?

Mi piacerebbe molto sapere cosa ne pensate voi sia delle eccezioni che del progetto.

Ciao,

Andrea

Alice non è più nel paese delle meraviglie...

Andrea Raimondi — Thu, 21 Jul 2005 18:44:00 GMT

Igor Damiani non è l'unico rimasto scottato da Tin.IT .
Abbiamo avuto, in famiglia, un abbonamento Alice per diversi anni ormai ed il 15 Luglio ha smesso di funzionare, ricominciando oggi da poco tempo.

Inutile dire che le 48 ore sono passate e superate da un bel pezzo, eppure nessuno viene a telefonare per chiedere scusa del disagio.

Vabbeh... che dire... non ci sono parole.

Andrea

Quello che non ti aspetti... da chi non ti aspetti... "dotNET strategy is at a standstill", confessed Ballmer

Andrea Raimondi — Wed, 29 Jun 2005 18:54:00 GMT

http://www.zdnet.com.au/news/software/0,2000061733,39199269,00.htm

Commenti?

Programmazione difensiva(2)

Andrea Raimondi — Mon, 06 Jun 2005 18:14:00 GMT

Un'altra tecnica molto comoda quando si parla di "defensive programming" è la cosiddetta "programmazione funzionale".

Vediamo lo stesso programma di prima, però adattato a questa nuova tecnica.

Program Programma;

const ErrEmptyStrValue = 1;

function ReadString(Label : String;var S : String;var ErrOut: Integer) : Boolean;
begin
write(Label+': ');
readln(S);
Result := S <> '';
if Not Result then
ErrOut := ErrEmptyStrValue;
end;

function GetFirstName(var S: String;var ErrOut : Integer);
begin
Result := ReadString('First name',S,ErrOut);
end;

procedure GetLastName(var S : String;var ErrOut: Integer);
begin
Result := ReadString('Last name',S,ErrOut);
end;

var FName,LName : String;
ErrorOut : Integer;

begin
if GetFirstName(FName,ErrorOut) then
begin
     if GetLastName(LName,ErrorOut) then
     begin
      write('First name is '''+FName+' '' and Last name is '''+LName+'''');
     end;
end;
end.

Qui adesso abbiamo un programma che controlla che ogni funzione sia "true" prima di proseguire.
Inoltre, dotando le funzioni di un parametro ErrOut, possiamo usare un tipo Boolean e relegare la
gestione dell'errore in altri punti. Nel caso specifico, non gestiamo l'errore nel corpo principale
soltanto perché si tratta di un programma dimostrativo e perché ad ogni modo in un programma di
questa complessità usare la programmazione funzionale è - imho - fuori luogo, oltre che
tremendamente noioso .

Comunque il concetto di base è semplice: valori TRUE o FALSE a seconda dei casi, più una
variabile di supporto per la gestione corretta degli errori in altri punti. Oggi useremmo probabilmente una
eccezione per cose del genere, ma il concetto non cambia poi molto.

Il vantaggio principale di questo stile di programmazione è che sai *sempre* dove stai se qualcosa non và, il che non fà male di sicuro .

Saluti,

Andrea

dotNET sotto un altro punto di vista

Andrea Raimondi — Sun, 05 Jun 2005 20:23:00 GMT

Si parla tanto, tantissimo di dotNET e di come sia una gran bella tecnologia. Bene, penso sia arrivato il momento di guardarla anche da altri punti di vista. Il mio è quello di uno che, di base, è abbastanza informato anche se non si è ancora addentrato in tutti i meandri di dotNET. Spero non ci siano informazioni sbagliate, quindi dico quello che so sperando che sia giusto .

Cominciamo dal fatto che dotNET esiste anche per altre piattaforme, più precisamente Mono, che è standard e tutte 'ste robe qui.

Non so se qualcuno ci ha fatto caso, ma MS cerca a tutti i costi di uscire con dotNET2 mentre i ragazzi di Mono stanno ancora cercando di arrivare a finire la corrispondenza alla 1.1 di dotNET. Questo la dice lunga su quanto sia "completo" il port e quanto MS sia disponibile a che dotNET sia multipiattaforma. Qualcuno potrebbe quindi chiedersi il perché della decisione di Microsoft di standardizzare C# ed il CLR.
La mia opinione è che sia stata una mossa geniale, oltre che un grandioso specchietto per le allodole: una standardizzazione non significa necessariamente dover seguire lo standard e Microsoft ha dimostrato più volte di essere allergica agli standard, perfino i suoi medesimi(vedi pasticcio con le typelibraries di Office, tanto per citare l'esempio più conosciuto, oppure perfino le incompatibilità di dotNET 1.1 SP1). Inoltre, Visual Studio ha la fetta più grossa di mercato su dotNET, questo è indubbio, quindi la stragrande maggioranza di coloro che vorranno usare dotNET lo faranno con VS.
Perché il designer WinForms è stato incluso nel framework? Semplice, perché non è su quello che si basano i proventi di Visual Studio, ma sulla vendita del prodotto in se e sui servizi accessori. Ancora una volta, un modo per Microsoft di attrarre persone e dare una parvenza di non monopolio(rendendo ad esempio possibile la realizzazione di SharpDevelop). Dunque, qui mi pare adesso sia chiaro, no?

Passiamo ad un altro punto fondamentale: Microsoft dice che dotNET risolverà il problema dell'inferno delle DLL(altrimenti noto come DLL Hell). In cosa consiste questo ecc. Il risultato era un malfunzionamento generalizzato delle applicazioni coinvolte.problema? Nel fatto che un certo(alto, molto alto) numero di sviluppatori non ha fatto "le cose perbene"(cit) e quindi alcune DLL andavano a sovrascriverne altre, senza alcuna accortezza per i numeri di versione, generando malfunzionamenti di ogni sorta e specie.
Dunque, lo strumento "principe" per la risoluzione di questo problema in dotNET è l'uso dello strong naming. Come funziona? Semplicemente, si "firma" un assembly con un certificato che attesta che l'assembly ha la versione X.Y e che quindi tutte le applicazioni che fanno riferimento a quella versione di quell'assembly sanno che è lui. Parte fondamentale di questo processo è la Global Assembly Cache, GAC per gli amici, che appunto conserva gli assembly più utilizzati. Cosa succede, però? Nonostante sia possibile registrare degli assembly nella GAC, Microsoft sconsiglia questa pratica a quanto ho capito.
Ergo, strong naming ti saluto. Inoltre, so che non ce n'è bisogno ma lo dico lo stesso, è normale che se non vengono rispettate le regole di base di "civile convivenza" tra gli assembly e compagnia, qualcosa di molto, molto, molto brutto dovrà succedere prima o poi, vi pare?

Adesso invece, occupiamoci della "portabilità": qui il discorso deve prendere una ramificazione dicotomica. Il problema è che bisogna distinugere tra lato server e lato client. Non solo, ma anche tra diverse versioni del Framework, perché ormai ci avviamo alla 2.0 ed il numero sta crescendo in modo preoccupante. Il perché di questa mia preoccupazione lo vediamo dopo. Occupiamoci intanto del fattore portabilità sul lato client. Voi mettereste il motore di una macchina moderna dentro ad una vecchia 500? Non penso proprio. Però è, in poche parole, quello che vorrebbero fare con dotNET ed i varii Windows(9x,ME, ecc). Capite bene che non solo mi sembra un'idea abbastanza peregrina di concetto(ed infatti nessuno osa ammetterlo pubblicamente), ma anche, a mio parere, praticamente irrealizzabile, vista la frequenza dei crash di Windows 98, tanto per dirne uno. Non mi si venga per favore a dire che non ce ne sono più, perché non è semplicemente vero. Una mia cara amica ha Windows ME. Un altro amico ha 98. Ce ne sono molti di più di quanti molti di noi spererebbero, mi sa, e non soltanto in ambito aziendale.

Ho voluto affrontare il tema della portabilità in maniera dicotomica perché la questione della "compatibilità" delle varie versioni del framework tra loro è un fattore importante. Molto importante. Stando a questo articolo, le cose non sono rosee per dotNET2, per i motivi riportati. "Certo, comunque in caso di problemi si può sempre usare il framework 1.1 side-by-side", viene detto. Sicuro, aggiungo io, tanto non abbiamo mica altri programmi da far girare sul sistema no - oltre alle applicazioni dotNET. Facendo un rapido conto e mantenendosi su una media di 20MB a framework e considerando il caso peggiore(1.0, 1.1 SP1 e 2.0), soltanto di base ci portiamo dietro la bellezza di 60 MB. Naturalmente, non è finita qui, perché oltre al CLR dobbiamo anche portarci i vari assembly che, vale la pena ricordarlo, sono DLL. Già, sono DLL, però non condividono lo spazio di memoria. Quindi per ogni applicazione avremo un caricamento di tutte le DLL. Tanti auguri.

Altro da aggiungere? Direi di si... spesso si dice che esiste NGEN, un tool capace di preconvertire il codice IL in codice nativo... già... ne vogliamo parlare? Questo articolo, fà chiaramente intendere come stanno veramente le cose, al di là della propaganda e non sono cose da poco. Il perché è presto detto: nell'articolo si dice(testualmente):" The downside, of course, is that whenever the runtime (for example via a Service Pack) or one of the dependencies of your ngen images changes (version upgrade or patch), your ngen image becomes invalid". Capito? Quindi, non solo valgono soltanto per il computer per il quale vengono generate, ma anche soltanto fino al prossimo update di una qualsiasi cosa che in qualche modo modifichi lo stato del sistema inerentemente all'immagine considerata. Credo che sia abbastanza ovvio che sia così, perché è chiaro che se cambia qualcosa magari cambiano gli indirizzi e così via, però fà anche capire che il trade-off nella maggior parte dei casi, almeno dal mio punto di vista, non è accettabile.

Bene, per ora mi fermo qui, anche se avrei molte altre cose da dire... però prima preferisco aspettare i commenti .

Buona Domenica,

Andrea

Anche io uso IMHO :-)

Andrea Raimondi — Sat, 04 Jun 2005 14:53:00 GMT

Ottimo, pare che finalmente non dovrò più smadonnare .

Questo è soltanto "buono", come dire... grassie Boschin!

Qualcuno può dirmi in che linguaggio è scritto IMHO? Non fatemi scaricare i sorgenti, su...

Buona giornata