Fabio Carucci's WebLogs

Mi ero preparato un po’ di esempi di codice in ausilio ad una giornata di corso sui design patterns, poi però ho pensato che forse, per un fine didattico, la cosa migliore che potessi fare era di “raccontare” ai partecipanti una serie di scenari in cui poter applicare, per ciascuno, uno specifico pattern e lasciare a loro il compito di trovare un modo per risolvere il problema; dopodichè gli avrei presentato il pattern e illustrato il mio esempio di implementazione.

Mi ha meravigliato che, per un buon 70% ci sono sempre andati vicino, segno che i patterns sono soluzioni comunque vicine alla logica umana piuttosto che a quella di un guru dell’IT e, probabilmente, segno che le attività dei labs svolte negli incontri passati sono state utili per far passare le loro “menti” da un approccio procedurale ad uno object oriented.

Bravi…

Questo è un appello rivolto a qualsiasi categoria di azienda italiana che fa uso di tecnologia software e si avvale della consulenza di aziende IT per svilupparlo.

Cari Clienti, vi prego, fate capire in modo chiaro quali sono le vostre necessità e, se pensate di sapere esattamente cosa volete, se decidete quindi di scrivere da voi un documento dei requisiti, fatelo pure ma che sia solo un aiuto ulteriore per migliorare la comunicazione fra voi e i vostri consulenti IT; non fatelo solo perchè non avete voglia e tempo di “parlare”, è un grande errore perchè il risultato potrebbe non essere ciò che immaginavate.

Magari accade di rado, ma se i vostri consulenti vi forniscono dei suggerimenti sull’approccio al ciclo di sviluppo del software diversi da quelli che avete sempre utilizzato, fate il favore, rimettevi in gioco, datevi una alternativa, in fondo state pagando qualcuno per aiutarvi.

Ricordatevi che il mondo dell’IT è in continua evoluzione e qualcuno nel mondo cerca di trovare nuove pratiche che aiutino a comprendervi e sviluppare al meglio il sistema di cui avete bisogno, quindi non è detto che quello che avete imparato dieci anni fa sia la perfezione, provate il CAMBIAMENTO!

Questo appello non è a titolo personale, bensì frutto di alcune chiacchierate con persone che partecipano all’erogazione di miei corsi.

Ed è solo l’inizio…

Sono amici di un caro vecchio amico, si erano appena sposati ed erano sull'aereo caduto il 4 gennaio scorso in Venezuela.

Il titolo del post corrisponde ad un sito: stefanoefabiola.org, costruito per dare e soprattutto ricevere possibili notizie in merito alla scomparsa dell'aereo, dato che non si trovano rottami. Forse si è inabissato nel punto in cui dovrebbe esser caduto, circa 1200 metri di profondità, o forse è caduto su un'isola. Non lo sappiamo.

State ascoltando o vedendo nei TG vari le novità su questa tragedia? No, ed è per questo che serve tener viva la voce, altrimenti c'è il rischio che vengano abbandonate le ricerche per sempre.

Chissà se qualche amico che legge questo blog, magari dagli USA (visto che ricevo visite anche da là), può in qualche modo parlare con quelli di TerraServer per dare una mano agli amici e ai familiari che cercano queste persone a metter su qualcosa sulla falsa riga di ciò che è stato fatto per Jim Gray un anno fa?

Leggete il sito, grazie a tutti.

Bello questo blog, parole semplici ma piene di esperienza. E' il blog di una nonna, e non è nè una battuta nè un insulto, chi lo riempie ogni giorno è una signora di ottantasei anni, della Toscana, una insegnante in pensione, che accudisce il marito malato e si sente sola, o meglio forse si sentiva sola, poi due anni fa ha iniziato a scrivere e, qualche giorno fa, è stata intervistata da Repubblica.

Andate a vedere quanti commenti, peccato che non ha un RSS attivo...forse non sa cos'è. Però è forte lo stesso. Leggetelo.

L'eredità di Nedda

Abbiamo la necessità di implementare un client WCF che sia in grado di effettuare il download automatico dei metadati del servizio remoto e configurare un proxy che sia in grado di stabilire una comunicazione?

Utilizziamo le classi MetadataExchangeClient, MetadataSet, WsdlImporter e ServiceEndpointCollection

creiamo un oggetto MetadataExchangeClient nel quale definiamo la URI del servizio remoto e specifichiamo di voler richiedere il documento WSDL di descrizione del servizio

 MetadataExchangeClient metadataExchange = new MetadataExchangeClient

 (new Uri("http://localhost:8000/ServizioRemoto/?wsdl"),

 MetadataExchangeClientMode.HttpGet);

poi creiamo un oggetto MetadataSet in cui scarichiamo i metadati utilizzando il metodo GetMetadata() della classe MetadataExchangeClient

 MetadataSet metadataSet = metadataExchange.GetMetadata();

 creiamo un oggetto WsdlImporter dal MetadataSet che contiene il documento WSDL comprensivo degli endpoints

 WsdlImporter importer = new WsdlImporter(metadataSet);

e inseriamo gli endpoints nell'apposita collection ServiceEndpointCollection mediante il metodo ImportAllEndpoints() della classe WsdlImporter

 ServiceEndpointCollection endpoints = importer.ImportAllEndpoints();

 infine, all'interno di un ciclo For..Each configuriamo una variabile proxy per ogni endpoint trovato

 foreach (ServiceEndpoint ep in endpoints)

{

 IInterfacciaServizio proxy = new ChannelFactory<IInterfacciaServizio>(ep.Binding, ep.Address).CreateChannel();

 ((IChannel) proxy).Open();

 // codice di elaborazione del servizio

 ((IChannel) proxy).Close();

} 

da notare che ChannelFactory è in grado di generare il proxy basandosi in maniera identica a ciò che riflette il contratto del servizio remoto, quindi se un metodo è dichiarato sincrono l'oggetto proxy avrà la stessa identica implementazione del metodo.

Questo post nasce da una domanda posta da un mio PartnerClienteCollega.

Il titolo è provocatorio, non credo sia possibile metterli a confronto, credo invece più adeguato valutare le esigenze e decidere, conoscendone i vantaggi e i limiti, di adottare l'uno anzichè l'altro.

MOSS 2007 è un ambiente Web-based dotato di un backend scalabile in cui è possibile effettuare ricerche di informazioni, quindi ideale per condividere in azienda;

Groove 2007 è un rich client, installato su ogni pc, per piccoli team, quindi ideale per decentralizzare la collaborazione.

MOSS 2007 permette di sviluppare applicazioni con workflow mediante Windows Workflow Foundation;

Groove 2007 facilita la comunicazione diretta per la maggior parte mediante il peer-to-peer (si, esatto), permette di lavorare disconessi per poi riconnettersi in un secondo momento e sincronizzare il lavoro eseguito offline.

MOSS 2007 va utilizzato da aziende che devono fare attività di searching di dati condivisi, deploy di portali, sviluppo di business forms e processi di workflow;

Groove 2007 va utilizzato da team che hanno bisogno di condividere non un portale ma un banco di lavoro per frequenti scambi di informazioni.

Ora però, anche per rispondere al mio PartnerClienteCollega, vediamo alcuni limiti di Groove rispetto a MOSS.

La fonte dei dati seguenti è un post pubblicato sul blog del team TechNet di Groove: http://blogs.technet.com/groove/default.aspx

Sono passati diverse settimane da quando ho scritto l'ultimo post del mio blog, finalmente ho trovato un attimo di tempo; durante la scrittura di quel post pensavo di mettermi a scrivere una activity che potesse far navigare la user interface di un software, fortunatamente qualcuno mi ha fermato dicendomi che era già stato scritto e in effetti, facendo una breve ricerca ho trovato una serie di link a codice simile a ciò che avevo in mente, quindi lungi da me clonare l'acqua calda.

Giro pagina. Per un mio cliente ho consigliato di implementare (e lo sto facendo), in un prodotto, la gestione della cache e ho scelto l'application block scritto in oggetto del post; in rete ho trovato diversi siti e blog che parlano di ciò, non credo che ai miei lettori possa interessare la "mia" introduzione o la "mia" spiegazione perciò mi limiterò a descrivere dettagli tecnici secondo la mia esperienza in proposito.

Nel già citato application block vi è, tra le altre, una classe denominata ExpirationTask che, una volta istanziata, rappresenta un singolo task per gestire ciò che, inserito in cache, è scaduto.

Se si vuole dare una occhiata all'interno della nostra cache e rimuovere tutti gli elementi scaduti è possibile invocare il metodo SweepExpiredItemsFromCache passandogli come parametro un HashTable di oggetti CacheItems da rimuovere.

Occorre però prima aver marcato come expired gli elementi nella HashTable, quindi MarkAsExpired(HashTable object).

Se vi interessa l'argomento trovate l'articolo a questo link

Buona lettura

powered by IMHO 1.3