gennaio 2006 - Posts
Forse sarebbe meglio dire "perché non è ancora GoLive". In questo post, di qualche giorno fa, la risposta. Francamente non trovo che sia una motivazione molto "solida". Chi utilizza un prodotto beta, sia client che server, deve essere consapevole del rischio che corre ... comunque non spetta a me la decisione.
Nel frattempo ho notato con piacere che la CTP di gennaio di WCF mi ha compilato al primo colpo il progetto WCF sul quale sto lavorando.... credetemi non è cosa da poco, visto che con le precedenti CTP ho sempre dovuto dedicare diverse ore al "recupero" del codice e delle feature già implementate con le build precedenti.
Pare proprio che sia possibile: http://msmobiles.com/news.php/4853.html .
Mi sa che provare ... sarà una delle prime cose che farò questa settimana!
Sito da tenere assolutamente sotto controllo:
http://windowscommunication.net/
Come indicato in questo link, Windows Workflow Foundation e Windows Communication Foundation entrano nella fase di Beta 2 e sono utilizzabili con GoLive License.
Si tratta di un segnale davvero molto importante, perché significa che il livello di stabilità dei due framework inizia ad essere elevato. Inoltre è probabile che d'ora in poi non ci saranno più notevoli stravolgimenti dell'architettura.
Per chi non sapesse cosa vuole dire GoLive License: ecco una FAQ.
Molto bene!
Come annunciato da Christian Weyer nel suo blog WSCF 0.6 è feature complete e entro pochi giorni dovrebbe uscire la versione finale. Ho avuto modo di provarlo in versione beta e devo dire che è davvero un ottimo prodotto oltre che molto completo. Tra l'altro le funzionalità e potenzialità sono state notevolmente ampliate rispetto alla release precedente (0.51). Tra l'altro la versione 0.6 sarà la prima per Visual Studio 2005 e .NET 2.0, beneficiando di tutte le novità e caratteristiche del nuovo framework, come i generics, le entità utilizzabili in data binding, l'implementazione dei servizi interface-based anziché class based e molte altre.
Tenete d'occhio la pagina ufficiale del prodotto.
Durante il security roadshow che abbiamo fatto io e Marco lo scorso anno, ho consigliato a diversi partecipanti la lettura del libro "Practical Cryptography" di Niels Ferguson and Bruce Schneier. Si tratta di un libro secondo me molto ben fatto, chiaro, che tratta al giusto livello di approfondimento le tematiche relative alla crittografia passata e moderna.
Oggi andando a scaldarmi :-) in una libreria mentre passeggiavo al freddo per i portici del centro di Brescia ho scoperto che Apogeo ha tradotto e commercializzato la versione italiana del libro (in realtà già dal 2005, ma me ne sono accorto per caso soltanto oggi). Non ho potuto valutare la qualità della traduzione, ma la versione inglese è un libro "da leggere". Non l'ho comprato perché ho già il fratellino in lingua originale, però per chi non ha voglia o tempo di leggerlo in inglese consiglio almeno di leggere la versione in lingua italiana.
Dalla versione 2.0 di .NET è stato introdotto un Namespace dedicato all'invio delle email, migliorato ed ampliato rispetto a System.Web.Mail (che ora è deprecated). Sino ad oggi l'avevo guardato solo rapidamente, ma oggi ho avuto l'esigenza di usarlo sul serio, quindi per prima cosa l'ho aperto con Reflector per vedere come era implementato. Ad una prima verifica, sembra ben fatto. Segnalo le caratteristiche nuove e maggiormente interessanti (secondo me):
- Non siamo più costretti ad utilizzare CDO
- Possiamo intercettare i destinatari inesistenti delle email (molto comodo per chi scrive dei motori di mailing e vuole rimuovere la rumenta :-) ...) intercettando l'eccezione SmtpFailedRecipientException o SmtpFailedRecipientsException
- L'invio dei messaggi può essere asincrono (uno alla volta però) ed è possibile annullare invii già accodati, se non sono già partiti ovviamente :-)
- Il protocollo SMTP funziona anche in modalità sicura su SSL e possiamo utilizzare dei certificati X.509 nei messaggi
- Gli allegati sono meglio gestiti che non in System.Web.Mail.MailMessage
- Possiamo attivare del logging per capire il perché di eventuali errori di delivery
- Sul fronte della sicurezza è stata aggiunta la classe SmtpPermission per poter limitare l'uso di System.Net.Mail solo a particolari utenti/principal/applicazioni/ecc.
Vi consiglio di dargli uno sguardo, all'occorrenza.
Vi segnalo anche questa utile FAQ: http://www.systemnetmail.com/default.aspx
Ebbene sì! Da questo anno la novità è che farò il sistemista!!!
Mica ci avrete creduto, vero? :-)
Però nell'ultimo periodo ho utilizzato abbastanza pesantemente DFS e FRS per realizzare sistemi di replica dati e disaster recovery, utilizzando la replica dati su siti remoti. La soluzione di per sé è semplice: prendi un file server "critico" e lo replichi presso un sito remoto, sfruttando il servizio FRS che Windows Server utilizza per replicare tra i Domain Controller i file relativi al dominio. Nulla vieta di farlo per file server "importanti" di diverse decine di Gigabyte di dati. Ormai l'ho già fatto per alcuni clienti della mia società e il "gioco" funziona. L'importante è avere una buona banda dati per collegare i site, ma soprattutto conviene avere una linea con banda flat :-) !
Avendoci lavorato un po', riporto alcuni riferimenti, limiti dimensionali, e tips che ho raccolto durante queste esperienze.
Limiti dimensionali:
- Dimensione massima del singolo file replicato: 20Gb
- Numero massimo di files e cartelle replicabili: 500 mila per ogni replica root
- Numero massimo di replica set per ogni server: 150
- Dimensione massima dei dati replicabili: 64Gb per ogni server
- Dimensione massima dello staging folder: 2TByte
Consigli:
- In generale, se possibile, è meglio partire da zero, con i folder da replicare vuoti, per poi riempirli.
- Il servizio FRS allo startup deve eseguire una scansione completa dei file da replicare per sincronizzare i server, questo significa che si deve allocare un tempo ragionevole per la fase di messa a regime. Ad esempio su un cliente che ha 45Gbyte da replicare, siamo in ballo da 10gg e mancano ancora 15Gb. Per la cronaca la banda teoricamente a disposizione è di 2Mbit/s. Dico "teoricamente" perché poi il servizio di replica non la usa mai tutta e non la usa sempre (questo è l'andamento nell'ultima settimana).
- Non sottovalutate la fase di startup e tenetela molto controllata, con strumenti come Ultrasound (che potete trovare su TechNet, vedi link in fondo)
- FRS utilizza delle cartelle di staging nelle quali appoggia i file da replicare. La dimensione predefinita di queste cartelle è di 660Mbyte (spesso decisamente troppo pochi). Conviene alzare questo limite (vedi qui). Il valore massimo è come indicato in precedenza di 2TByte. Se c'è spazio può essere furbo stare alti su questo valore (qui si spiega come calcolarlo), per evitare che, in situazioni di carico elevato e/o linea sovraccarica, dei file non vengano aggiornati. FRS se raggiunge il 90% del limite dimensionale della cartella di staging, inizia a cancellare i file più vecchi, finchè non libera il 40% del folder, senza quindi sincronizzarli! Se lavorate con il default di 660Mbyte e per qualsiasi ragione avete un file di dimensione maggiore (ad es. un'immagine ISO di un CD o di un DVD da replicare o un MPEG con l'ultima prestazione di qualche signorina poco vestita :-) ma molto disinvolta, perché presente nella cartella My Documents di un utente ....) il servizio FRS si fermerà non essendo in grado di allocare spazio a sufficienza.
- Se possibile utilizzare un disco diverso per i file di staging.
- Fate attenzione a situazioni di recovery da nastro o in generale da unità di backup perché per le ragioni descritte nel punto precedente, potreste avere problemi legati alla dimensione massima dello staging folder. In teoria la cosa migliore sarebbe avere un folder di staging di dimensione almeno pari ai dati da replicare.
- Attenzione che in caso di guasto, se i Domain Controller non si vedono per più di N giorni (21 se non erro) perdono "fiducia" reciproca e occorre prevedere dei meccanismi di recovery abbastanza drastici e in extremis manuali (chiavi del registry da cambiare a mano) per far sì che ricomincino la replica, altrimenti bisogna sacrificare il DC meno aggiornato, rimuoverlo e reinstallarlo.
Per maggiori dettagli leggete:
Se vi venisse voglia di replicare anche i vostri dati ... spero che queste informazioni vi agevolino. Se c'è qualche collega sistemista che vuole dire la sua completando e/o correggendo queste informazioni, ovviamente i commenti sono attivi e i contributi saranno ben accetti.
Stimolato dal post di Marco sono andato a rivedere i miei buoni proposito per il 2005, per verificare che anche io non sono stato molto bravo nel 2005.
In sostanza:
- DevCon OneDay coi fiocchi: forse questo sì, almeno a giudicare dai feedback avuti a gennaio dello scorso anno ... pare di sì. Purtroppo non sono riuscito a fare il bis per gennaio 2006. Al prossimo punto capirete anche il perché.
- Riposarmi un po' nei primi mesi dell'anno: proposito fallito. Nel 2005 mi sono massacrato :-) di lavoro .... tanto che a fine anno, verso la metà di dicembre ho avuto un crollo fisico che mi ha costretto al riposo forzato (con un bello spavento!), annullando alcuni appuntamenti con clienti e rinviando le date di consegna di alcune attività conclusive per il 2005 (sorry). Sicuramente nel 2006 dovrò darmi una regolata.
- Basta lavorare fino alle 3 o alle 4 di notte
- Devo iniziare a frequentare una palestra (stavolta sul serio!!!)
- Devo tornare a casa dall'ufficio verso le 18.30/19.00
- Non organizzerò più una DevCon 2005 svolgendo in parallelo altre N attività, ma sicuramente muoio dalla voglia di vedere la DevCon 2006, alla quale stiamo già lavorando dalla sera in cui è finita DevCon 2005 (e non è una battuta!)
- Scrivere un nuovo libro: il progetto è in corso, ma per varie ragioni i tempi si stanno allungando, ma ci credo ancora molto!
- Spingere al massimo su SOA e Smart Client: beh sì, questo l'ho fatto anche troppo :-) ...
- Approfondire SQL 2005: sì e no, dipende, avrei voluto vedere di più, ma per ora mi ritengo soddisfatto
- Andare in ferie: ops ... mi sono dimenticato! Però il punto 8 mi consentirà di fare una bella vacanza :-) ...
- Andare in piscina o in palestra: vedi il punto 2 ... ho fallito ma da domani sarò iscritto e ci andrò!
- C'era un ulteriore punto relativo ad un cambiamento drastico nella mia vita .... beh grazie agli impegni per organizzare DevCon ;-) ... sono riuscito a rinviare di qualche mese l'inizio della fine :-D, però la casa c'è già, i mobili li ho ordinati in questi giorni .... ormai non manca molto ...
Per dare un senso a questo inutile post mi preme però segnalare che sono conscio di essere stato negli ultimi mesi molto (troppo!) impegnato su progetti sia software che di altro tipo (i.e. DevCon 2005). Da domani per me ricomincia l'anno lavorativo vero, con alle spalle 15 giorni di riposo sano e legittimo. Ho intenzione di tornare ad occuparmi per bene del mio blog, degli articoli per VBJ (dove negli ultimi 2 mesi ho dovuto alzare bandiera bianca) e anche un po' della mia vita privata ...
Il 2006 per me sarà l'anno di WCF, WinFX, Sharepoint 3.0, C# 3.0, Linq e DevCon 2006. Sono contento che il 2005 sia finito perché seppure pesante è stato un anno ricco di soddisfazioni e risultati.
Bridge The Gap!