Il WikiWiki è una ragnatela di pagine tra loro correlate, ecco un Walkthrough su come scrivere nelle pagine di UGIdotNETWiki: Apri la pagina di prova PaginaPerFarPratica Entra in modalità di modifica con il bottone Modifica o col doppio click Nel grande riquadro editabile indica una breve descrizione del contenuto della pagina scrivendo:Summary: Esercizio di realizzazione del Walkthrough. Vai a capo e scrivi:Questo è un esempio di scrittura nelle pagine del Wiki con gli stili più comuni come il '''grossetto''' e il ''corsivo o italico'' che dir si voglia. Mentre il +sottolineato+ non si usa spesso perché si potrebbe confondere con un link ;-) Visualizza l'anteprima della pagina...

In attesa della prossima iniziativa su UGIdotNETWiki (grazie a Riccardo e Roberto) mi sono deciso a postare un breve manuale (estremamente) pratico del Wiki. Bando alla chiacchiere, ecco le info preliminari per cominciare. Per andare in modifica di una pagina clicca sulla barra sinistra il comando Modifica: oppure fai doppio-click nel mezzo della pagina.Quando sei entrato in modifica, sulla barra destra hai a disposizione i comandi per Salvare, Annullare e per avere l'Anteprima della pagina modificata: mentre sul lato sinistro puoi editare il testo. Prova su questa pagina cavia. I comandi saranno utili nel prossimo Walkthrough.

Le ragioni per formarsi su C#2.0... in ordine sparso... (continuano da qui): semplificare l'uso contemporaneo da codice di 2 versioni dello stesso Assembly migliorare la leggibilità e comprensibilità del codice e l'organizzazione dei file sorgente ridurre la quantità di codice da scrivere aumentando le possibilità di riutilizzo degli algoritmi e delle strutture dati implementate aumentare la possibilità di definire standard / pattern da seguire nello sviluppo migliorare le prestazioni riducendo le inefficienze dovute al boxing/unboxing last but not least: attraverso il C# poter capire e comprendere la BCL, il Framework .NET e il suo funzionamento avere le basi indispensabili per il prossimo...

Secondo statistiche del 2001 indicate dal Gartner Group il 30% dei progetti di IT (uno ogni 3!!!) non giungono ad una conclusione positiva ossia vengono abortiti oppure producono un software che non soddisfa i bisogni per cui è stato commissionato. Mentre il 51% supera il budget in media del 189% relizzando solamente il 74% delle funzionalità previste. Lo scorso anno mi è capitato di vivere l'esperienza di un progetto che è stato abortito, abbastanza presto da ridurre al minimo i danni, abbastanza tardi per poter salvare tutte le teste in un periodo di recessione. L'aspetto positivo è quanto ho potuto imparare da questa situazione nel adoperarmi...

Organizzando corsi su .NET per poi erogarli mi è capitato di stendere dei piani di formazione per .NET 2.0. Ho dovuto scegliere gli argomenti giustificando il tempo da impiegare e i costi in funzione delle abilità che verranno acquisite dai partecipanti. Certo il piano deve soddisfare le aziende che vogliono corsi di aggiornamento per il proprio personale e che hanno vincoli di tempi e costi, ma alla fine il "risultato" mi è sembrato interessante anche per gli appassionati di .NET come me perché poi anche noi si deve fare una selezione sulla direzione in cui investire le energie, gli sforzi, il tempo che è sempre troppo poco (benedetta la noia che a...