Di .NET e di altre amenita'

February 2006 Blog Posts

Scrivere un provider per Monad (MSH) #2: Inizializzare i drive

Continuo la serie di post che ha riscosso un inatteso successo tornando a parlare di Monad e dei suoi provider. Come promesso la precedente puntata ecco finalmente un po' di codice che spiega come implementare un provider che risponda ad un device fittizio che chiameremo sql:\ ottenendo il risultato di consentirci di navigare lo schema del database come se fosse un filesystem.

Per chiarire l'obbiettivo che ci poniamo innanzitutto proviamo a spiegare in che modo avverrà la navigazione all'interno di SqlServer. Se pensiamo ad un database server Sql, possiamo individuare una sorta di gerarchia riconducibile ad un path analogo a quello del filesystem. Al primo livello avremo il server, poi il database, poi ancora le tabelle ed infine i campi che compongono una singola tabella. La scelta in effetti è arbitraria in quanto è evidente che si sarebbe potuto scegliere un diverso modo di ordinare gli oggetti, ma allo scopo del post, quanto appena descritto è più che sufficiente.

Quindi scrivendo il seguente path dovremmo poter raggiungere i campi della tabella Employees nel database Northwind del server locale:

sql:\(local)\Northwind\Employees

Per ottenere questo risultato il primo passo da compiere è quello di creare una classe, che chiameremo SqlCmdletProvider che eredita da NavigationCmdletProvider. Questa classe dovrà inoltre essere decorata dall'attributo CmdletProviderAttibute oltre naturalmente a implementare l'unico metodo astratto di tale classe. Ecco un breve spezzone di codice:

using System;
using System.Management.Automation;
using System.Management.Automation.Provider;

[CmdletProvider("SqlCmdletProvider", ProviderCapabilities.None)]
public class SqlCmdletProvider : NavigationCmdletProvider
{
    
protected override bool IsValidPath(string path)
    {
        
return true;
    }
}

Dovremo naturalmente ricordarci di importare i namespace di Monad, e di referenziare i relativi assembly che troveremo nella directory di installazione. Ora il nostro provider compila, ma anche ammettendo di installarlo scopriremo che non è in grado di compiere alcuna azione. In particolare manca la possibilità di "agganciarsi" al drive fittizio sql: come richiesto dai requisiti che abbiamo espresso poco fa. E' qui che entrano in gioco la serie di metodi virtuali, esposti dalla classe NavigationCmdletProvider, facendo l'override dei quali si potranno iniziare ad ottenere i comportamenti richiesti. Per poter assegnare il drive sql: al nostro provider dovremo sovrascrivere il metodo InitializeDefaultDrives() il quale dovrà tornare una collection dei drive cui il nostro provider fa capo; Eccone l'implementazione:

protected override Collection<System.Management.Automation.DriveInfo> InitializeDefaultDrives()
{
    Collection<System.Management.Automation.DriveInfo> drives = 
               new Collection<System.Management.Automation.DriveInfo();

    drives.Add(
        
new System.Management.Automation.DriveInfo(
            "sql",
            
this.ProviderInfo,
            "\\", 
            "Sql MSH Navigation Provider", 
            
null));

    
return (drives);
}

Come già detto questo metodo informerà il runtme di quali drive fanno capo al nostro provider. Una volta installato il provider potremmo assicurarci che esso risponda correttamente lanciando la cmdlet get-provider per ottenere quelo che segue:

MSH C:\> get-provider

Name                 Capabilities                                      Drives
----                 ------------                                      ------
SqlCmdletProvider    None                                              {sql}
Alias                ShouldProcess                                     {Alias}
Environment          ShouldProcess                                     {Env}
FileSystem           Filter, ShouldProcess                             {C, D, E, F, G}
Function             ShouldProcess                                     {Function}
Registry             ShouldProcess                                     {HKLM, HKCU}
Variable             ShouldProcess                                     {Variable}
Certificate          ShouldProcess                                     {cert}

Tra i provider installati è elencato anche il nostro e se proviamo a scrivere "cd sql:\" il nostro provider accetterà il percorso specificato così come qualunque altro dato che nel metodo IsValiPath() abbiamo ritornato semplicemente true.

Ora, prima di chiudere il post e lasciarvi per la prossima puntata, è opportuno che spieghi come si fa ad installare il provider in Monad. In effetti questa è la parte se volete più oscura alla qualeho trovato una sola soluzione, ma sospetto che ve ne siano altre che mi sono bellamente sfuggite. Quello che ho fatto io è stato di compilare una nuova shell includendo l'assembly del mio provider ottenendo così un nuovo eseguibile compatto che supporta anche il mio provider; Ecco la linea di comando MSH che ho utilizzato per lo scopo:

make-shell -out sqlshell.exe -namespace MonadProvider -reference MonadProvider.dll

Questo comando, che fa parte el set di Monad in sostanza prende la shell msh.exe, e vi allega il provider referenziato (che comunque dovrà sempre essere presente sotto forma di assembly). Essa poi restituisce un nuovo exe (sqlshell.exe) che può essere distribuito assieme al proprio provider ma che ne racchiude le funzionalità esposte. Mi sembra una bella feature, se pensiamo ad esempio a tool appositamente creati per la manutenzione di particolari ambienti, però mi sarei aspettato anche la possibilità di installare, magari in un file di configurazione il provider senza dover passare per una compilazione. Sono fermamente convinto che questa possibilità ci sia, e di essermi fermato troppo presto nella ricerca. Appena ne so qualcosa evidentemente sarete i primi a saperlo.

powered by IMHO 1.3


per leggere il post originale o inviare un commento visita il seguente indirizzo: Scrivere un provider per Monad (MSH) #2: Inizializzare i drive

Scrivere un provider per Monad (MSH) #1

In questi giorni, dato che la beta di Vista ancora nicchia, per non so bene quale motivo, mi sono preso la briga di impiegare il mio già scarso tempo a disposizione, mettendo il naso nella beta di Monad, cui mi sono iscritto. Monad, per chi non lo sapesse è la nuova shell di Microsoft che dovrebbe debuttare con l'uscita del nuovo sistema operativo Vista, probabilmente entro la fine di quest'anno, sotto il nome di MSH.

Devo dire che sono molto affascinato da Monad, che pur presentandosi con un'interfaccia molto linux-like, dopo una breve esplorazione si rivela un ambiente di una flessibilità e potenza ineguagliabili, tanto da far impallidire facilmente anche il più sfegatato bash-ista. Prima di introdurvi al codice che voglio presentare, che in questi ho scritto per Monad, vale la pena che vi delucidi su cosa rende così potente e singolare un ambiente che a prima vista altro non è che la "solita" linea di comando.

In effetti, dopo aver digerito il primo impatto con la console, la cosa giusta da fare è di rivolgersi alla rete per cercare di capire qual'è il principio attorno cui si impernia il funzionamento di monad, perchè senza averne compreso la logica è del tutto inutile provare a trarne qualcosa di utile, dato che invariabilmente si rimarrà impigliati nell'errata interpretazione che la riga di comando impone. Monad infatti è un ambiente in tutto e per tutto ad oggetti che ha la capacità di estendere il comune concetto di "piping" che molti conoscono grazie alle shell Unix, su una dimensione ulteriore, si potrebbe dire "tridimensionale" quale sono gli oggetti di .NET. Per chiarirlo facciamo subito un piccolo esempio pratico; Aprite una console msh e scrivere quanto segue:

(get-process iexplore).Kill()

Ok, so bene che si tratta di uno scherzo un po' scemo, ma è molto significativo. Vediamo di spiegarlo in due parole; get-process è la cmdlet che restituisce l'elenco dei processi attivi, alla quale è possibile applicare un filtro per nome processo. In questo modo monad troverà tra tutti i processi quello che si chiama "iexplore" e su di esso chiamerà il metodo Kill(), con l'ovvio risultato di chiuderlo.

Converrete con me che questo approccio è davvero fantastico. Se si considera che qualunque cosa venga restituita da Monad è un oggetto di .NET è del tutto evidente che come tale è possibile manipolarlo con la massima libertà. Questo infatti vale allo stesso modo che per i processi attivi, anche per i file e le directory del filesystem che generano degli oggetti di tipo DirectoryInfo e FileInfo che chi ha già usato System.IO conosce bene. Se poi consideriamo che come unix insegna una shell ha sia uno stout che uno stin ecco che appare evidente che i medesimi oggetti che vengono generati da un comando di MSH possono essere passati in input ad un altro comando MSH che li potrà manipolare a piacimento. E' questo il meccanismo del "piping" che mentre in unix/linux si ferma tipicamente al semplice testo ASCII, in monad assume questa consistenza tridimensionale dell'oggetto .NET.

Ma la domanda legittima che ci si dovrebbe porre a questo punto è: ma chi è che genera questi oggetti?

In effetti potrebbe apparire a prima vista che gli oggetti restituiti in output da un comando siano "generati" dal comando stesso, ma non è esattamente così; I comandi di monad infatti sono dei "Verbs", che per essere eseguiti hanno la necessità di un provider che ne interpreti l'input e ne restituisca di conseguenza l'output. Dicendo questo mi sto in effetti muovendo su un terreno un po' scosceso, infatti quanto dico è frutto semplicemente delle mie sperimentazioni e potrebbe essere inficiato dalla limitatezza delle stesse, ma non credo di allontanarmi di molto dalla verità. In effetti i provider in Monad ci sono è sono qualcosa di molto importante, basti pensare che per l'accesso al filesystem esiste un FileSystemProvider che risponde ai comandi più comuni che si possono dare ad un filesystem.

La cosa eccezionale è che questi provider si possono scrivere in .NET con il framework 2.0 è come naturale non appena ne ho scoperto l'esistenza mi ci sono buttato a capofitto per capire come sfruttarli e ho scritto un po' di codice che vi presenterò in un paio di post.

Va detto innanzitutto che un provider per Monad è una classe .NET che estende una classe base, nel mio caso NavigationCmdletProvider e che implementa una serie di interfacce accessorie che consentono di estenderne ulteriormente le funzionalità. Così, nel caso del FileSystemProvider abbiamo che esso eredita dalla NavigationCmdletProvider che gli consente di usare i comandi "cd" e "dir" o per dirla con Monad "set-location" e "get-childitem". Lo stesso provider inoltre implementa l'interfaccia IContentCmdletProvider che gi permette di rispondere ai comandi come "get-content" (type).

Scrivere un provider per Monad quindi significa fare in modo che i comandi che normalmente si impartiscono per navigare nel filesystem possano essere usati anche per navigare in qualsiasi altra struttura gerarchica. La stessa Shell infatti già dispone di altri provider (usare get-provider per avere l'elenco completo) che rispondono a quelli che impropriamente si potrebbero chiamare "device" o "drive". Ad esempio il drive HKLM: consente di navigare all'interno del registry; ENV: nelle variabili di ambiente. E così via.

Appena ho scoperto questa caratteristica ho subito pensato di scrivere un provider e tra tutte le possibili varianti a scopo di esercizio ho deciso di realizzare un provider che risponda al drive "sql:". Come ben potete immaginare questo device consente di navigare all'interno dello schema di un database sql nel quale si abbia accesso con la windows authentication, sfruttando i comuni "cd" e "dir".

Ora è tardi è non mi sembra il caso di continuare, però prometto che a breve tornerò su questo appetitoso argomento presentandovi il codice funzionante che ho realizzato, e magari proverò anche a migliorarlo.

powered by IMHO 1.3


per leggere il post originale o inviare un commento visita il seguente indirizzo: Scrivere un provider per Monad (MSH) #1

MSDN Universal è arrivata!

Che gioia, dopo 6 giorni che il corriere della UPS se la scarrozza in giro per Treviso e dintorni senza riuscire mai a venire ad un'orario tale da riuscire a trovarmi, ieri è finalmente arrivato il Welcome Kit accompagnato dai primi 2,5 KG di DVD della MSDN  Universal compresa nella Visual Studio Team Suite che Davide mi ha regalato. baciamo le mani vossignoria...

Stasera perciò mi sono inventato un gioco con mia figlia. Ho aperto tutti i pacchetti, sparpagliato i CD sul tavolo ed ho esclamato: Adesso li mettiamo tutti al loro posto... i verdi con i verdi, i rossi con i rossi e così via. E' passata un'ora ma alla fine ci siamo riusciti ed ora ogni CD è al suo posto in bell'ordine nel faldone in vero policlorurodivinile.

In bella mostra il cd compreso nella subscription che riporta stampigliato: Visual Studio Team Suite... maggico!

powered by IMHO 1.3


per leggere il post originale o inviare un commento visita il seguente indirizzo: MSDN Universal è arrivata!

Ciao Luca

Apprendo ora che stamattina alle 11:30 è morto Luca Coscioni, il presidente dei Radicali Italiani e dell'omonima associazione "Luca Coscioni" per la Ricerca Scientifica.

Lo voglio ricordare con le parole che aveva dedicato a lui José Saramago, premio nobel per la letteratura:

Forse il sostegno di un semplice scrittore come me stonerà un poco, o anche troppo, nella lista delle personalità scientifiche che, con i loro nomi e il loro prestigio, suggellano le affermazioni rese da Luca Coscioni in quella sua lettera del 20 marzo, così chiara e commovente. In ogni caso, potete disporre del mio nome. Purchè la luce della ragione e del rispetto umano possa illuminare i tetri spiriti di coloro che si credono ancora, e per sempre, padroni del nostro destino. Attendevamo da molto tempo che si facesse giorno, eravamo sfiancati dall’attesa, ma ad un tratto il coraggio di un uomo reso muto da una malattia terribile ci ha restituito una nuova forza. Grazie, per questo.

Cordialmente, José Saramago

Ciao Luca. Con te se ne va un grande uomo, ma resta la speranza che ci ha dato.

Grazie

 


per leggere il post originale o inviare un commento visita il seguente indirizzo: Ciao Luca

XEDOTNET: l'evento si avvicina e le iscrizioni fioccano

Il primo meeting di XEDOTNET si sta avvicinando, ciascuno affila le sue slides, io mi preparo al debutto in qualità di conduttore dell'evento e mi sto impegnando a raccogliere le iscrizioni. Sono davvero contento del riscontro che sto ottenendo. Nonostante si tratti di uno usergroup praticamente sconosciuto sono quasi arrivato a riempire la sala che ho a disposizione e la speranza è quella di riuscirci entro breve. Invito chiunque ancora non si sia registrato a farlo al più presto perchè le adesioni stanno superando le aspettative e quindi sarò costretto a lavorare di "machete" su chi non ha provveduto all'iscrizione.

Un ringraziamento a tutti quelli che mi stanno aiutando a spargere la voce e a raccogliere le adesioni. E anche all'ugidotnet che molto sportivamente sopporta questi post forse un po' ingombranti ma che di certo non minacciano la sua importanza.

L'agenda dell'incontro è disponibile al seguente indirizzo: http://www.xedotnet.org/subscriptions.aspx

Gli oratori saranno Lorenzo Barbieri e Davide Vernole. Vi aspettano i fuochi d'artificio... venghino siori, venghino!

powered by IMHO 1.3


per leggere il post originale o inviare un commento visita il seguente indirizzo: XEDOTNET: l'evento si avvicina e le iscrizioni fioccano

ASP.NET 2.0: Create un parameter personalizzato per i DataSourceControl

Il nuovo modello di accesso ai dati basato sui DataSourceControl consente con facilità di fare il binding di controlli complessi come al GridView, la DetailView e la FormView con una facilità impensabile. I controlli DataSourceControl hanno un design fortemente configurabile per adattarsi alle varie esigenze. Ad esempio è possibile con facilità parametrizzare il risultato della DataSource per mezzo di Parametri che possono essere passati come argomenti ai metodi Select, Insert, Update e Delete. I parametri vengono poi tradotti in modo conforme al tipo di DataSourceControl. Ad esempio nel caso della ObjectDataSource essi divengono parametri del metodo richiamato durante una operazione di accesso ai dati.

Esistono un buon numero di questi parametri, ad esempio Parameter, QueryStringParameter, SessionParameter, che hanno il compito di prelevare l'informazione da qualunque supporto sia necessario interfacciare. La struttura di questi parametri è molto semplice tanto che è possibile con semplicità crearne di personalizzati. Ecco ad esempio un tipo di parametro che legge il contenuto di Context.Items e lo passa alla DataSource:

public class ContextItemParameter : Parameter
{
    
private string itemName;

    
protected override object Evaluate(
        System.Web.HttpContext context, 
        System.Web.UI.Control control)
    {
        
if ((context != null) && (context.Items != null))
            
return context.Items[this.itemName];

        
return null;
    }

    
public string ItemName
    {
        
get return itemName; }
        
set { itemName = value; }
    }
}

Il nocciolo del lavoro si trova nel metodo Evaluate() che si occupa di trasformare il contenuto dell'item in un dato digeribile dai DataSourceControl

powered by IMHO 1.3

 


per leggere il post originale o inviare un commento visita il seguente indirizzo: ASP.NET 2.0: Create un parameter personalizzato per i DataSourceControl

ASP.NET 2.0: Advanced Wev User Controls

I Web User Controls, più spesso conosciuti con il diminutivo di "ascx" per l'estensione che contraddistingue il loro template, sono sovente sottovalutati per la loro intrinseca facilità di uso. Questo è un grave errore in cui si incorre nell'errata supposizione che la loro semplicità sia ottenuta sacrificando la l'estensibilità tipica dei Custom Web Controls. COn questo breve esempio vorrei dimostrarvi quanto sto dicendo; Poniamo di creare un semplice UserControl come segue:

<%@ Control 
    
Language="C#" 
    
CodeFile="TemplatedUserControl.ascx.cs" 
    
Inherits="TemplatedUserControl" %>
<asp:Table 
    
runat="server" 
    
ID="tblTris" 
    
CellPadding="5" 
    
CellSpacing="0" 
    
BorderStyle="None">
    <asp:TableRow>
        <asp:TableCell 
/>
        <asp:TableCell 
/>
        <asp:TableCell 
/>
    <
/asp:TableRow>
    <asp:TableRow>
        <asp:TableCell 
/>
        <asp:TableCell 
/>
        <asp:TableCell 
/>
    <
/asp:TableRow>
    <asp:TableRow>
        <asp:TableCell 
/>
        <asp:TableCell 
/>
        <asp:TableCell 
/>
    <
/asp:TableRow>
<
/asp:Table>

Come evidente si tratta di uno UserControl che contiene una semplice tabella con nove celle, distribuite su tre colonne per tre righe. Ora andiamo a modificare la classe che implementa la logica dello UserControl:

using System;
using System.Data;
using System.Configuration;
using System.Collections;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
using System.ComponentModel;

public partial class TemplatedUserControl : System.Web.UI.UserControl
{
    
private ITemplate buttonTemplate;

    
protected override void OnInit(EventArgs e)
    {
        
int i = 0;
        
foreach (TableRow row in tblTris.Rows)
        {
            
foreach (TableCell cell in row.Cells)
            {
                ButtonTemplateContainer container = 
new ButtonTemplateContainer();

                ButtonTemplate.InstantiateIn(container);
                WebControl textControl = container.FindControl("TitleText") 
as WebControl;
                cell.Controls.Add(container);

                
if (textControl != null)
                {
                    textControl.Width = textControl.Height = Unit.Pixel(50);

                    
if (textControl is ITextControl)
                        ((ITextControl)textControl).Text = i.ToString();
                    
else if (textControl is IButtonControl)
                        ((IButtonControl)textControl).Text = i.ToString();
                }

                i++;
            }
        }

        
base.OnInit(e);
    }

    [PersistenceMode(PersistenceMode.InnerProperty)]
    [Browsable(
false)]
    [TemplateContainer(
typeof(ButtonTemplateContainer))]
    
public ITemplate ButtonTemplate
    {
        
get return buttonTemplate;  }
        
set { buttonTemplate = value; }
    }
}

public class ButtonTemplateContainer : 
    Control, 
    INamingContainer
{
}

Questo codice, trasforma lo UserControl appena creato in un semplice ed efficace TemplateControl. In pratica nelle nove celle viene iniettato il template generato sulla base di quanto richiesto nel markup. Ecco come è possibile usare lo UserControl:

<Elite:TemplatedUserControl runat="server" ID="ucTest">
    <ButtonTemplate>
        <asp:Button 
runat="server" ID="TitleText" />
    <
/ButtonTemplate>
<
/Elite:TemplatedUserControl>

In breve sarà possibile configurare un template in ogni istanza configurata dello UserControl allo stesso modo di quello che si farebbe con una GridView. Come evidente le potenzialità degli UserControls vanno ben aldilà di quallo che si può di primo acchito pensare.

powered by IMHO 1.3

 


per leggere il post originale o inviare un commento visita il seguente indirizzo: ASP.NET 2.0: Advanced Wev User Controls

Di censura, quella moderna...

Vi segnalo un post del sempre eccellente Matteo G.P. Flora. Si parla di moderne forme di censura, dello stampo di quelle che si pensava fossero ormai riportate solo nei libri di storia. Capiamoci, la libertà fa paura, e Internet è libertà applicata. Quindi...

Link: http://www.lastknight.com/2006/02/12/censura-quanti-ip-stanno-filtrando/

powered by IMHO 1.3


per leggere il post originale o inviare un commento visita il seguente indirizzo: Di censura, quella moderna...

Windows Vista: sono beta tester!

Sono lieto di comunicarvi che stamattina mi è arrivato l'invito a partecipare BETA tester per Windows Vista. Inutile dire che ho immediatamente accettato. Non vedo l'ora di iniziare a "smanettare" un poco, anche se ancora non so da che parte inizierò. Intanto attendiamo che arrivi il materiale e poi vedremo.

powered by IMHO 1.3


per leggere il post originale o inviare un commento visita il seguente indirizzo: Windows Vista: sono beta tester!

XEDOTNET: Convocato il primo meeting

Da lunedì sono aperte le iscrizioni al primo meeting di XEDOTNET, lo user group che stiamo creando nel triveneto. L'agenda vede la partecipazione di nomi importanti. Lorenzo Barbieri ci intratterrà parlando di Visual Studio Team System e Team Foundation Server, mentre Davide Vernole presenterà in anteprima il Microsoft Expression Designer aka "sparkle".

Al seguente indirizzo è possibile vedere l'agenda completa ed eventualmente dare la propria adesione all'evento: http://www.xedotnet.org/subscriptions.aspx

Nel frattempo sono aperte le votazioni per il logo della community, cui chiunque può partecipare semplicemente postando un messaggio nell'apposito forum che potete trovare qui: http://www.xedotnet.org/forums/thread/24.aspx

powered by IMHO 1.3


per leggere il post originale o inviare un commento visita il seguente indirizzo: XEDOTNET: Convocato il primo meeting

ASP.NET 2.0: MaintainScrollPositionOnPostback

MaintainScrollPositionOnPostback è un nuovo attributo della direttiva @Page che definirei senza ombra di dubbio impagabile. Per comprenderne il significato basta pensare a cosa succede alla pagina quando invochiamo un postback. Se ad esempio la pagina è molto lunga e scrolliamo verso il basso nel momento in cui interviene il postback normalmente il browser torna a posizionare la pagina all'inizio costringendoci ad un "lavoro di rotella" un po' scomodo. Impostando a true questa proprietà questo comportamento verrà modificato riportando sempre la pagina nella posizione in cui si trovava al momento del postback.

Un grazie a Davide Vernole che stamane mi ha segnalato questa novità...

powered by IMHO 1.3


per leggere il post originale o inviare un commento visita il seguente indirizzo: ASP.NET 2.0: MaintainScrollPositionOnPostback

ASP.NET 2.0: Un generic per la ViewState

L'accesso alla ViewState nell pagine ASP.NET, ma anche a Session, Cache ed Application tipicamente soffre della mancanza di type-safety che costringe a scrivere dei cast ripetuti. Con il breve e semplice metodo generico qui riportato è possibile semplificare la gestione di questi utili strumenti

public string MyValue
{
    
get return GetViewState<string>("MyValue", string.Empty); }
    
set { SetViewState<string>("MyValue", value); }
}

private T GetViewState<T>(string name, T defaultValue)
{
    
if (ViewState[name] == null)
        SetViewState<T>(name, defaultValue);

    
return (T)ViewState[name];
}

private void SetViewState<T>(string name, T value)
{
    ViewState[name] = 
value;
}

Il metodo descritto ha il vantaggio di consentire anche la lazy initialization del valore, così da evitare di avere dei fastidiosi null di ritorno.

powered by IMHO 1.3


per leggere il post originale o inviare un commento visita il seguente indirizzo: ASP.NET 2.0: Un generic per la ViewState

Anonimato in rete

Leggo con piacere un eccellente articolo di Matteo G.P. Flora che spiega le problematiche relative l'anonimato in rete e soprattutto come proteggere le proprie comunicazioni. Da liberale, trovo che l'anonimato non sia una soluzione auspicabile, perchè tende a proteggere anche chi ne approfitta. Tuttavia è vero che in un periodo in cui la repressione della libertà di espressione si fa sentire, il bisogno di anonimato esiste per tutelare prima di tutto la propria privacy piuttosto che i propri interessi. Ricordo infatti che è abitudine comune quella di tracciare le comunicazioni per scopi che vanno dalla semplice opportunità commerciale (ad esempio i log file dei web server servono a questo), fino alla repressione vera e propria della libertà dell'individuo.

Ecco quindi che l'articolo di Matteo, che parla di Tor, un interessante strumento gratuito per la propria privacy è di notevole interesse. Chissa che Matteo prossimamente non trovi anche l'occasione per parlare di Cypherpunk, Mixmaster e Mixminion e di tutti i software correlati a questi remailer anonimi che consentono di proteggere le proprie comunicazione via e-mail.

Link: http://www.lastknight.com/tor/

powered by IMHO 1.3


per leggere il post originale o inviare un commento visita il seguente indirizzo: Anonimato in rete

ASP.NET 2.0: Anche la documentazione può avere bugs...

Nel Framework 2.0 sono presenti una serie di controlli che sono in gradi di sfruttare un nuovo tipo di binding ai dati. Mi riferisco ai controlli gerarchici, come ad esempio il TreeView, il quale ricevendo una datasouce che implementi una determinata interfaccia è in grado di visualizzare dati che non siano delle semplici tabelle. L'implementazione della datasource gerarchica, richiede la realizzazione di una serie di classi a supporto che a loro volta si basano su interfacce e classi astratte.

Quest'oggi, nel districarmi in mezzo ad esse ho scoperto mio malgrado che quello che si trova in MSDN non è tutto oro colato. Per farla breve, dopo aver replicato esattamente un esempio della documentazione ed aver cercato per ore di capire dove stavo sbagliando mi sono deciso a compilare il codice dell'esempio per poi rendermi conto che esso sofriva dello stesso problema che stavo riscontrando nel mio. Niente meno che una StackOverflowException causata da una ricorsione infinita.

Mi chiedo quanti altri di questi esempi non testati esistano su MSDN.

powered by IMHO 1.3


per leggere il post originale o inviare un commento visita il seguente indirizzo: ASP.NET 2.0: Anche la documentazione può avere bugs...