maggio 2007 - Posts
Ritorno sull'argomento per segnalare questo post di TimNG (direttamente dal team di sviluppo del linguaggio), che credo offra una buona panoramica.
Vorrei dire la mia su una questione molto dibattuta ed assolutamente attuale, dato il numero sempre crescente di strumenti software che consentono di realizzare soluzioni senza scrivere una riga di codice (no-code, appunto).
E' un discorso complesso anche perchè può essere affrontato da una miriade di punti di vista.
Estremizzando, possiamo ricondurre al tema (un po' forzosamente) anche eterne diatribe.
Ci sono, ad esempio, molti sviluppatori che esprimono un'opinione molto marcata a riguardo (sintetizzo qui una sorta di merge di diverse discussioni che ho avuto in passato, nemmeno tanto remoto):
Odio sistemi di esecuzione virtuale perchè non mi lasciano il controllo su tutti gli aspetti dell'applicazione che scrivo. Odio i meccanismi di gestione automatica della memoria perchè non so cosa fanno (a questo si può porre rimedio, però, nda :-), non so quando lo fanno, lo fanno male, io lo posso fare meglio. Uso COM, ma non uso gli smart pointer perchè voglio avere il controllo esplicito sul rilascio degli oggetti, voglio in ogni momento essere in grado di dirti esattamente il reference count (e ci becco sempre), tutto sommato non uso ATL perchè aggiunge solo complessità, mi implemento la QueryInterface a mano ogni volta, scrivo codice altamente ottimizzato. Sono la macchina.
Personalmente sono piuttosto critico rispetto a questo atteggiamento, la cui validità a mio giudizio decresce all''aumentare della complessità del sistema.
Mi viene in mente il tema di italiano che era uscito l'anno in cui mi sono diplomato (scientifico 97): "Siamo nani sulle spalle dei giganti". Anche qui forzo un po' il contesto, ma un discorso come quello quotato sopra mi sa un po' di ciecità nei confronti dei "giganti" e, a volte, di presunzione di essere in grado di "fare le cose meglio". Chiaro che la generalizzazione è sempre foriera di errori e visioni distorte, ma diciamo che il problema che si pone non è esattamente marginale.
Con queste premesse, e spostandoci di qualche livello di astrazione verso l'alto, considerate queste opinioni (sempre sintesi di discussioni raccolte in questi mesi):
Odio gli application server, odio qualsiasi cosa che abbia un pulsante "Next" in basso a destra, odio qualsiasi strumento che si usa e si configura in via amministrativa, odio le soluzioni out-of-the-box. Magari sono programmi ben fatti, pieni di funzionalità, attraenti dal punto di vista grafico, ma di 100 cose che fanno ne uso a dir tanto 10, me ne servirebbero 11 ma quella che manca non riesco a realizzarla. Lo strumento preconfezionato non si adatterà mai al mio scenario reale.
Qui sono meno critico.
Con un *importantissimo* distinguo, però.
Adottare i (cosiddetti) strumenti no-code come componenti dell'architettura di un'applicazione è una scelta che va assolutamente considerata. Ed è fondamentale, a mio giudizio, effettuare questa scelta in base ad alcuni parametri:
- Lo strumento è adatto per il mio dominio applicativo ? (sembra scontato, ma presuppone comunque una solida valutazione dello strumento in questione, cosa che non sempre viene svolta)
- Qual è il costo dello strumento ? (costo nel senso di euro, costo nel senso di tempi di apprendimento, costo nei termini di tempo di sviluppo e manutenzione ... come vedete anche qui non è esattamente banale scegliere)
- Lo strumento è realmente estensibile ?
Non ho commentato inline l'ultimo punto, perchè in realtà è quello che sta alla base di questo post.
Perchè credo sia un fattore realmente determinante e, spesso, sottovalutato.
Per estensibilità, in questo contesto, intendo la possibilità di aggiungere funzionalità non previste e non disponibili nel pacchetto, così come di modificare funzionalità esistenti, ma non perfettamente adeguate allo specifico della soluzione che si va a realizzare.
"No-Code" ?
Ma mica è un male ! Mica possiamo valutare la robustezza e la completezza di una soluzione in base al numero di righe di codice che *noi* scriviamo !!
Però No-Code != "non posso scrivere codice".
No-Code, per come la vedo io, dovrebbe essere uguale a "posso non scrivere codice". Ma anche "posso scrivere codice, se mi serve".
Gioco di parole sottile ma differenza grossa come una casa (di quelle grosse).
Quando si sottolineano i vantaggi di soluzioni no-code, uno dei punti maggiormente rimarcati è che la definizione della soluzione può essere delegata ad un power-user, che non deve necessariamente avere competenze di sviluppo, ma semplicemente essere un esperto del dominio applicativo.
Ottimo !
Però quando il power-user si blocca di fronte ad un (magari apparente) limite dello strumento, chiama il power-dev a dargli una mano, no ?
E il power-dev è mooooooolto contento se si ritrova un ambiente in cui può mettere le mani, anche in profondità, per risolvere le esigenze del suo cliente ;-)
Negli ultimi mesi sono stato impegnato (tra le altre cose :-)) su un progetto piuttosto articolato basato su SharePoint 2007, che per la maggior parte ha comportato l'utilizzo piuttosto massiccio di InfoPath 2007 e Forms Services.
E' sempre interessante utilizzare un prodotto in scenari complessi, magari dovendolo spremere o dovendo aggirare qualche limitazione. E questo è a maggior ragione fondamentale quando il discorso verte sulle "performance".
A questo proposito vi segnalo questo interessante articolo su MSDN, che prende in esame i diversi aspetti critici e propone linee guida e soluzioni per ridurre il decadimento prestazionale all'aumentare della complessità della soluzione.
Vi porto un caso reale in cui la criticità è saltata fuori in modo dirompente ed è stata risolta ... beh ... by design :-)
InfoPath non ama svisceratamente una vista con 20 DropDownList piene zeppe di elementi.
Non voglio discutere sull'usabilità di una soluzione del genere, la pongo semplicemente come postulato: 20 ddl piene di item.
Il rallentamento in alcuni casi è più che visibile, diciamo piuttosto drammatico. Se vogliamo, supera quella soglia sottile che sta fra il "è un po' lento, ma si sopravvive" e il "è troppo lento, non va bene".
In questo caso, parte della pesantezza è determinata dal rendering che il browser effettua per i controlli html SELECT.
Uovo di colombo ? Cambiamo browser !!
Prima di sparare sul pianista (ehm ... sull'autore) vi dico che, passando da IE6 a IE7, i tempi si sono ridotti del 300% circa.
Perchè ?
In IE7 il tag SELECT è renderizzato (per default, l'impostazione può essere modificata a livello di registry) come controllo intrinseco del browser, piuttosto che come wrapper alla ComboBox dei Common Controls di Windows. Con un bel boost di performance, oltre ad altri miglioramenti in questo caso non rilevanti (qui un post sul blog di IETeam).
Ovviamente la cosa risulta applicabile nel momento in cui l'utilizzo della soluzione in questione è limitato ad una intranet, in cui si ha il controllo del browser installato sui client (e l'upgrade a IE7 va ovviamente fatto a prescindere da questo).
DevCon 2004 è stata la prima conferenza tecnica alla quale ho partecipato, tre anni fa.
DevCon 2007 l'ultima, che si è conclusa oggi.
Mi è un po' difficile fare dei confronti perchè inevitabilmente sono cambiate tante cose. Non solo dal punto di vista della tecnologia.
Ho ricordi molto vividi della 3-giorni bolognese di tre anni orsono.
Mi ricordo le stesse, identiche persone che ci parlavano di Longhorn, Avalon, Indigo, WinFs (sic), Yukon.
Mi ricordo di aver aperto questo blog.
Mi ricordo anche che avevo un gusto diverso per le cose.
Mi ricordo quel periodo in generale, non solo per DevCon. Un paio di mesi prima avevo preso una decisione che ha poi condizionato il resto della mia carriera: abbandonare un (visto ora) buon lavoro da dipendente per buttarmi (letteralmente) nel poco libero mondo dei liberi professionisti.
Certo che, ripensandoci ... le cose non sono cambiate poi così tanto !
Per tre giorni gli stessi professionisti ci hanno raccontato di WCF, WPF, WF (questo mancava, però :-)). Ma anche di LINQ e di SilverLight e di IIS7 ...
Non ho aperto di nuovo questo blog. Beh in effetti è già aperto, no ?
Ho scoperto che ancora un po' di quel gusto per le cose mi è rimasto.
E per completare la simmetria anche questo è un momento in cui sto compiendo delle scelte professionali che con ogni probabilità giudicherò molto rilevanti fra un po' (quando capirò cosa sto facendo).
Ogni tanto fa piacere trovare delle linee conduttrici.
Ho sempre sostenuto che VB.NET fosse un linguaggio creato più per ragioni di mercato che per reali necessità tecnica/tecnologica.
Giudizio, a dire il vero, anche motivato (e che in parte sostengo tuttora).
Non credo, ad esempio, che l'aver incluso (o meglio dire lasciato ?) costrutti sintattici stile On Error Resume/Goto sia una scelta dovuta a ragioni di implementazione del linguaggio. C'è perchè c'era (in VB6), per agevolare la conversione ... anche se sarebbe stata una buona occasione per far passare certe brutte abitudini :-P
A dire il vero, comunque, non sono mai stato un amante (neanche un grande utente) di VB e un po' di parzialità in questo giudizio la riconosco tutta ... soprattutto nel momento in cui lo devo ritrattare :-)
Mi sono trovato ad indagare più nel profondo VB.NET in maniera abbastanza casuale.
Yet another language ? Non la penso più così radicalmente come prima.
Ha ragione Marco quando dice che conoscere bene entrambi, ora come ora, non sia solo un vezzo. E che in effetti VB e C# stanno divergendo anche e soprattutto per il target di utilizzo (qui il post a cui mi riferisco).
Però ...
Ho la sensazione che VB9+ possa essere un competitor vincente anche senza uscire dal contesto "classico" di linguaggio statico (quindi anche prima della "divergenza").
Ci sono funzionalità che il compilatore VB mette a disposizione e che possono da sole determinare una scelta, probabilmente più di quanto l'overload di operatori (per dirne una) abbia fatto con C#1.0 vs VB.NET 7.0.
Gli Xml Literals sono un esempio.
Un altro (e credo più rilevante, nel suo piccolo): mutable anonymous types.
Perchè più rilevante ?
Perchè rendere immutable gli anonymous types (come farà il team di C#) non è una caratteristica che un domani si cambia. Punto.
Molto migliore, dal mio punto di vista, la scelta del team di VB.NET (Paul Vick, qui).
Obiettivamente non ho idea di quali siano in realtà *tutti* i motivi che determinano le scelte di progettazione per linguaggi che, ricordiamocelo, sono abbastanza utilizzati ...
Però di sicuro la mia opinione di oggi è:
- Amo la sintassi di C#, forse perchè sono cresciuto da quel lato del fiume, magari perchè trovo le parentesi graffe visivamente gradevoli (sic).
- Non esordirò più dicendo "cosa volete fare, VB o C#, tanto sono uguali": magari lo restano nel contesto specifico, postilla che credo sia, ora, doveroso aggiungere.
- Sto iniziando a dimenticarmi qualche punto e virgola a fine riga ... vorrà dire qualcosa ?
P.S. Nel mentre non nascondo di aver perso di vista C++/CLI ... Domani chiedo lumi :-)
Per restare su un tema caldo, visto che si va verso lo sviluppo di applicazioni managed multipiattaforma ospitate (x es. in un browser) da un CLR trimmed con strato di supporto a linguaggi dinamici (DLR) ... parliamo un po' di debug tricks per applicazioni unmanaged :-)
Qualcosa di interessante che torna alla memoria, qualcosa di nuovo che scopro ora.
Scenario: applicazione multithreaded (pesantemente), C++, necessità di debug.
Per dirla in pratica, mentre stiamo facendo step-through del codice in esecuzione nel thread A, il thread B "passa per" un breakpoint e ... pluf ... Pensate il tutto nel contesto di un sistema complesso e odierete i debugger, i thread, Windows e il giorno in cui avete scelto il vostro lavoro.
Vogliamo impostare un breakpoint che interrompa l'esecuzione dell'applicazione solo se il codice relativo viene eseguito dal thread A ?
Il trucco che ho sempre usato è quello di dichiarare una variabile globale (*solo* in debug) ed impostarne il valore all'indirizzo contenuto in fs:[18h], che punta sempre Thread Information Block (1) del thread correntemente in esecuzione.
#ifdef _DEBUG
void* g_pTIB;
#define STORE_TIB /
_asm /
{ /
mov EAX, fs:[18h] /
mov g_pTIB, eax /
} /
#else
#define STORE_TIB
#endif
E' sufficiente, infine, impostare una condizione di hit sul breakpoint.
g_pTIB == 0x........
Ovviamente il valore di test (quello relativo thread che ci interessa monitorare) va catturato durante la fase di debug (ecco spiegato il motivo di esistere della macro STORE_TIB).
Niente male, quindi, l'aver scoperto una feature di VC++ (>= 6) che ci consente di riscrivere l'espressione condizionale come segue:
$TIB == 0x........
$TIB è uno pseudoregister.
Che possiamo, appunto, consultare in fase di debug (da una watch window oppure, come sopra, in un'espressione condizionale) e che ritorna l'indirizzo del TIB del thread corrente.
Pseudoregister ? Qui trovate un bell'articolo su codeproject che ne spiega il significato e l'utilizzo.
(1) Cos'è il TIB ? E' una struttura dati, parte del Thread Environment Block (TEB). Cos'è il TEB ? E' una struttura dati che risiede all'interno della memoria del processo (in user-mode) e che mantiene diverse info relative al thread a cui si riferisce.
Piano piano, ma le cose arrivano, no ?
Citando la fonte:
Finally we have a 64 bit PDF IFilter - surprisingly the solution is not from Adobe or Microsoft, but from a company called Foxit Software.The IFilter is compatiable with the following Microsoft products: Windows Indexing Service, MSN Desktop Search, Internet Information Server, SharePoint Portal Server, Windows SharePoint Services (WSS), Site Server, Exchange Server, SQL Server and all other products based on Microsoft Search technology
Qui, per chi l'ha persa, la segnlazione di Igor relativa all'IFilter rilasciato da Adobe. aggiornato alla versione 8, ma con supporto limitato alle piattaforme a 32 bit.
Premessa scontata: sintatticamente ci sono un bel po' si somiglianze fra C/C++ e C#. Non sono uguali. Sono molto simili, però.
Mi ricordo che uno degli errori che commettevo più di frequente, le prime volte in cui mi sono trovato a scrivere C# dopo 3 anni di C++, era questo.
Considerate questo snippet in C/C++:
// C++ Code.
SomeClass* pSomeObject = AllocateAndReturnObject();
if (!pSomeObject) {
// Error Handling Here.
}
Per chi non conosce il C/C++, la faccio breve. In C/C++ viene considerata true qualsiasi espressione diversa da zero. A partire da un intero per arrivare al valore di un puntatore (come nell'esempio sopra - per inciso NULL è un #define per 0).
Da cui l'abitudine di scrivere (provare a scrivere :-))
// C# Code.
SomeType someValue = GetSomeType();
if (someValue) { // This does not compile, since someValue is not of type Boolean.
// Should be: if (someValue != null) {}
}
Fatto 1, 2, 3 ... alla 4a volta uno si adegua.
Se volete, in C++ scrivere:
- if (pointer)
- if (pointer != NULL)
- if (pointer != 0)
è di fatto la stessa cosa.
Poichè non ci sono vincoli di sintassi, può entrare in gioco qualche considerazione stilistica.
A meno che ...
Prendete questo esempio (C++):
SomeData* pData = GetValidData();
if (pData = NULL) {
// Handle errors.
}
pData->Value = 42;
Sapete trovare l'errore ?
Avessi scritto:
SomeData* pData = GetValidData();
if (!pData) {
// Handle errors.
}
pData->Value = 42;
il funzionamento sarebbe stato lo stesso ?
Vi risparmio il cut & paste.
Nel primo snippet c'è una (volontaria) svista.
Non effettuo un test su pData ... ma un'assegnazione ed un test !!
Ho scritto "=" invece che "==", insomma.
Cosa che provoca l'assegnazione di NULL a pData, il test su pData (che però dà risultato opposto: pData vale 0, la condizione dell'if non è verificata) ed infine la dereferenziazione di un puntatore nullo. Access violation, ah ... bei tempi :-)
Sono quelle sviste che isolate in 3 righe si evidenziano subito, ma immerse in codice più complesso e articolato ti portano via ore di debug.
Ecco perchè, nonostante stilisticamente sia a mio giudizio peggiore, si scrive spesso:
if (NULL == pData)
In questo caso la svista non c'è. Ma se ci fosse stata, il compilatore ci avrebbe segnalato l'errore, perchè avremmo tentato di assegnare un valore ad una costante !
E in C# ?
Evidentemente la cosa non si pone, dal momento in cui sono valutate solamente le espressioni booleane !
Questo codice:
if (csValue = null)
generà un'errore in fase di compilazione (a meno di non aver ridefinito l'operatore di conversione implicita a Boolean !).
Siamo quindi protetti dalle nostre sviste, se volete.
E quindi liberi di adottare una convenzione di codifica più ... intuitiva.
Way Cool :-)
Igor e Paolo organizzano la prima SharePoint Conference in Italia.
19 e 20 settembre, date bloccate a doppia mandata ... e butto le chiavi :-)
Qui l'annuncio di Igor.
Online la registrazione dello speech di Anders Hejlsberg al MIX07, su LINQ manco a dirlo.
Data != Objects, impedance mismatch, limiti della programmazione imperativa, "the WHAT" vs. "the HOW", se non diciamo "HOW" qualcuno è più libero di prendere le decisioni al posto nostro (leggi ottimizzazioni, multicore, PLINQ, ...).
Non segnalo questo video solo per gli argomenti (cioè, anche, ma non solo, ecco). Ma per una frase che ha scatenato una risata in platea e anche a me.
All'inizio della demo, codice old-style (bontà sua a chiamarlo old), mega "sbattimento" per effettuare operazioni di manipolazione delle collection in memoria (tipo grouping), e, beh ...
"Don't try this at home !"
Yep ;-)
Che poi ... ok ... è un casino ... ma cosa dovrebbe dire chi tiene una conferenza top-level, che tratta anche argomenti in "preview" ? Siete pronti ad un'ondata di domande, vero ? ;-)
Fate conto di essere stati in vacanza per una settimana (esistono ancora le vacanze ?). Tornate e vi dicono che nel mentre che voi eravate sotto una palma con daikiri nella mano destra e sigarozzo nella sinistra qualcuno ha annunciato un paio di movimenti in casa Microsoft.
(in ordine non cronologico, sorry ... e sorry anche per i link che mancano, goto google plz :-))
- SilverLight. (The CLR goes x-platform. Mamamma ...)
EntityFramework- Jasper
- Astoria
- Dynamic Language Runtime
- IronRuby
- BizTalk Services (Internet Service Bus)
Ma solo perchè non si contano gli update a prodotti già annunciati:
- Orcas Beta 1 (+ relative Express)
- .NET Fx 3.5 Beta 1
- LonghornServer Beta 3
Nonchè quelli che non ho nominato perchè è tardi / non ricordo / non conosco /non ho letto.
Il sondaggio a questo punto dice:
- Siete presi dall'entusiasmo, scaricate *tutti* i package disponibili e li installate sul vostro pentium III. Che non si accende più, ma è stato per una buona ragione. Vi dimenticate che è il vostro unico computer, che conteneva i vostri dati di lavoro, che uno dei package ha inspiegabilmente corrotto la struttura di NTFS. Prendete una settimana di malattia per ripristinare il tutto, giustificandola come morbo tropicale preso dall'amaca.
- Siete presi dall'entusiasmo, scricate *tutti* i package, create 18 macchine virtuali e passate una settimana in casa ad installare a martellate. Vi dimenticate che dovevate tornare al lavoro. Vi danno per dispersi ai tropici, e non si può dar loro torto, dal momento che tornate con la barba lunga peggio di Robinson Crusoe. Però avete aggiunto altri 129 HelloWorld alla collezione, anche se per farlo avete dovuto far spazio e dimenticarvi di come si fa lo split di una System.String.
- Siete presi dall'entusiasmo. Iniziate il download e nel frattempo leggete qualcosa. L'entusiasmo rimane, ma inizia ad essere accompagnato da un po' di sconforto (accidenti, avere il tempo, avere studiato prima, ...). Al terzo download andate a dormire con tanti sogni pronti ... uno su tutti: imparare tutto.
- Siete presi da una sensazione mista di entusiasmo e sconforto. Non leggete nulla perchè se non si studia non si sa di cosa siamo ignoranti. Andate a dormire con un sogno pronto: sentirsi all'altezza.
- Siete presi dallo sconforto. L'entusiasmo neanche vi sfiora. Ci risiamo, solita storia. Vi sentite schiacchiati dalle informazioni. Andate a dormire con un sogno pronto: di svegliarvi con davanti un monitor a fosfori verdi, CGA, Dos 3 e quel sano rumore di stampanti ad aghi.
- Jasper ? Astoria ? Cheeeee ? Ma va là ... ma pensate che a quell'amaca gliene freghi qualcosa ?
La mia risposta ?
Quella a sentimento sarebbe la 2.
Ma non ho un secondo libero ora. Voterei 3.
Però quoto (ok, mi autoquoto, sborrone ...) la 4: se non si studia non si sa di cosa siamo ignoranti !