dotNet Umbria

Segnalazione libro su Asp.Net MVC

Andrea Cruciani — Thu, 04 Sep 2008 10:22:00 GMT

L'amico Simone Chiaretta, che speriamo di ospitare al più presto ad un nostro evento di DotNetUmbria, sta pubblicando un libro per chi si vuole approcciare ad Asp.Net MVC.

Vai Simone, in bocca al lupo!

Link al libro su Amazon

Un bell'evento su Asp.Net Ajax in Umbria

Andrea Cruciani — Wed, 03 Sep 2008 16:27:00 GMT

Ricevo e con piacere vi giro l'invito da parte di PcsNet Umbria per partecipare ad un evento gratuito.

L'evento vedrà come speaker Dino Esposito, famoso autore Ms Press, e Maurizio Mammuccini ( il "prof" di molte generazioni di programmatori umbri).

A questo link trovate il programma.

Book Review: Beginning Web Development, Silverlight, and ASP.NET Ajax

Paolo Possanzini — Fri, 22 Aug 2008 09:57:00 GMT

Il libro “Beginning Web Development, Silverlight, and ASP.NET Ajax”, scritto da Laurance Moroney, è una introduzione alla programmazione Web, adatto in modo particolare per chi inizia ad affacciarsi a questo mondo. E’ diviso in 3 parti principali di cui la prima, dopo un capitolo di storia sul mondo web, introduce ai principi dello sviluppo ASP.Net 2.0. Guida passo-passo il principiante a creare la prima applicazione Web, spiegando anche il funzionamento di base di Visual Studio e affrontando progressivamente gli argomenti fondamentali come WebForms, DataBing, WebServices.

Nella seconda parte viene fatta una carrellata delle nuove tecnologie introdotte con la versione 3.0 di Microsoft .Net Framework: Windows Communication Foundation, Windows Presentation Foundation, Windows Workflow Foundation.
Nell’ultima parte viene ripreso l’argomento Web, dove viene illustrata l’evoluzione che ha portato ad Ajax per affrontare infine Silverlight.

Il libro è decisamente introduttivo e getta le basi per ulteriori approfondimenti. Di facile lettura è pienamente comprensibile anche da un programmatore inesperto. Non approfondisce troppo nessun argomento lasciando al lettore la giusta dose di curiosità per ulteriori letture. Una cosa molto importante da sottolineare è la visione di insieme che si ottiene dalla lettura di questo libro dove tutte le tecnologie affrontate trovano il loro giusto posto.

Book review: Head First Javascript

Andrea Cruciani — Mon, 18 Aug 2008 17:19:00 GMT

Tempo di ferie e anche tempo di letture "rilassanti": Ho scelto un libro della collana Head First della O'Really. Avevo già avuto un buonissimo impatto un paio di anni fa con il libro Head first Design Patterns.

Per chi non conoscesse la collana si tratta di libri "strani", votati a facilitare l'apprendimento tramite diversi espedienti (grafica, linguaggio, evidenziazione di informazioni). Tutto questo partendo dal concetto che il nostro cervello apprende di più se l'informazione viene ritenuta vitale, ovvero se veniamo coinvolti anche emotivamente nel ciclo di apprendimento.

Il libro, scritto da Michael Morrison, parte da problemi molto semplici, se non banali, probabilmente le parti più interessanti sono a partire dal sesto capitolo in poi: riuso degli script, validazione lato client, navigazione del DOM fino a parlare un po' di Ajax nell'ultimo capitolo. Molto interessante, e spesso sottovalutato come argomento, è quello del debugging degli scripts (con vari tips & tricks). A dire i lvero con le nuove funzionalità di VS 2008 siamo molto avvantaggiati in questo, e forse tra un po' ci scorderemo le "7 camicie" passare a cercare gli errori negli script.. Ho preso il libro con l'intenzione di proporlo ai ragazzi in ufficio che freschi di laurea si approcciano al web e mi convinco sempre più che un approccio come quello proposto da questa collana sarebbe prezioso se utilizzato nei corsi universitari (e anche delle superiori), chissà che qualche professore temerario non decida di provarli!

Un programmatore già abituato ad utilizzare Js può tranquillamente leggere solo i capitoli che più gli interessano, questo tuttavia non è un libro da "consultazione" è più un percorso che andrebbe fatto dall'inizio alla fine (esercizi compresi).

Localizzazione lato client con ASP.NET Ajax

Fabrizio Bernabei — Wed, 06 Aug 2008 15:30:00 GMT

Il framework ASP.NET Ajax implementa un sistema per la localizzazione delle applicazioni "lato client". Se abbiamo uno ScriptManager in una pagina, impostando l'attributo EnableScriptLocalization a "true" abilitiamo questa funzionalità che in sostanza "serve" dei file javascript in base alla cultura corrente. Prendiamo ad esempio il codice seguente e supponiamo che venga eseguita su un PC con impostata la localizzazione in lingua inglese (en-US ad esempio):

   1: <asp:ScriptManager runat="server" ID="TheScriptManager" 
                         EnableScriptLocalization="true">

   2:     <Scripts>

   3:         <asp:ScriptReference Path="~/js/Risorse.js" />

   4:     </Scripts>

   5: </asp:ScriptManager>

Viene referenziato nello script manager il file Risorse.js, questo significa che il file in questione verrà inviato (o meglio la direttiva script..ecc verrà inserita nell'html prodotto dalla pagina) al client ql momento della richiesta della pagina. La particolarità è che, avendo abilitato l'apposita opzione dello ScriptManager (che per default è impostata a false) per la localizzazione, se nella posizione dove si trova il file js ne esiste una versione con nome Risorse.en-US.js, verrà servita questa in quanto corrisponde alla cultura correntemente impostata.

In questo modo è possibile creare dei file js contenenti le risorse necessarie alla localizzazione in diverse lingue e ASP.NET Ajax provvederà in automatico ad inviarci quello corretto per la lingua in uso. Un esempio di utilizzo potrebbe essere il seguente, un file di risorse fatto in questo modo:

   1: Risorse = {

   2:     "Lingua" : "it-IT",

   3:     "testoBtnAnnulla" : "Annulla"

   4: };

oppure in questo nella sua versione per la lingua inglese (con estensione .en-US.js)

   1: Risorse = {

   2:     "Lingua" : "en-US",

   3:     "testoBtnAnnulla" : "Cancel"

   4: };

Nel codice javascript del client ci basterà scrivere qualcosa tipo:

   1: alert("La lingua corrente è: " + Risorse.Lingua);

Per ottenere un alert contenente un messaggio che cambierà in base alla lingua correntemente selezionata.

Fin qui tutto ok; qualche perplessità potrerbbe però nascere nel momento in cui la nostra applicazione debba gestire/memorizzare la cultura da utilizzare sul server. Già perche il sistema appena illustrato tiene conto in realtà della cultura corrente del client (dove gira il browser per intenderci) e non quella del server. Nella nostra applicazione invece potrebbe servire la cosa opposta perchè ad esempio la lingua impostata da utilizzare può essere impostata manualmente dall'utente attraverso l'interfaccia dell'applicazione e poi salvata nel profilo personale o in un cookie, e magari ci serve che sia lato server per localizzare altre parti/pagine dell'applicazione che "girano" soltanto sul server.

In questi casi si può comunque continuare ad utilizzare la tecnica appena descritta, con pochi accorgimenti. Prima di tutto possiamo in questo caso non abilitare la localizzazione automatica degli script, semplicemente impostando a false l'attributo EnableScriptLocalization dello ScriptManager o non impostandolo affatto in quanto come detto per default non è abilitato.
Ora possiamo sfruttare un'altra possibilità della localizzazione che consiste nel poter forzare per mezzo di un attributo la cultura con cui deve essere servito un particolare script dallo ScriptManager, semplicemente impostandola sul singolo riferimento per mezzo della proprietà ResourceUICultures come nell'esempio seguente:

   1: <asp:ScriptManager runat="server" ID="TheScriptManager">

   2:     <Scripts>

   3:         <asp:ScriptReference Path="~/js/Risorse.js" 
                                   ResourceUICultures="it-IT" />

   4:     </Scripts>

   5: </asp:ScriptManager>

In questo modo lo ScriptManager cercherà di utilizzare sempre e comunque un file scritto per la cultura italiana, indipendentemente da quella impostata sul client. Il prossimo passo per sfruttare questo meccanismo per il nostro scopo, è quello di fare in modo che il file di risorse javascript venga effettivamente inviato specificandone la cultura, ma quest'ultima sia impostata dal server prima della renderizzazione della pagina. Quello che serve quindi è semplicemente specificare il riferimento al file di risorse nello ScriptManager da codice a runtime impostandone di volta in volta la cultura da utilizzare (che ovviamente può cambiare anche da un postback all'altro.. l'importante è che per la cultura che si imposta ci sia un file js corrispondente, altrimenti le risorse non saranno inviate al client). Per farlo basta togliere dallo ScriptManager il riferimento al file Risorse.js dell'esempio ed aggiungerlo a runtime nel codice eseguito lato server, ad esempio nell'evento PageLoad della pagina in questo modo:

   1: protected void Page_Load(object sender, EventArgs e)

   2: {

   3:     // Riferimento al file di risorse da utilizzare

   4:     ScriptReference jsRisorse = new ScriptReference("~/js/Risorse.js");

5:

   6:     // la cultura viene impostata leggendola dal thread corrente,

   7:     // potrebbe essere diversa da quella del client

   8:     // e anche da quella di altri processi che girano sul server web

   9:     jsRisorse.ResourceUICultures = new string[1] 
              { System.Threading.Thread.CurrentThread.CurrentUICulture.ToString() };

10:

  11:     // il riferimento con la cultura specificata viene aggiunto allo

  12:     // ScriptManager. Se ad esempio la cultura impostata fosse en-US

  13:     // è necessario che sia presente il file ~/js/Risorse.en-US.js

  14:     // perchè questo verrà effettivamente referenziato nell'HTML

  15:     TheScriptManager.Scripts.Add(jsRisorse);

  16: }

E con questo abbiamo raggiunto il nostro scopo, cioè sul client verra servito il file js di risorse localizzato in base alle impostazioni memorizzate sul server, magari n el profilo dell'utente, e queste ultime possono essere diverse da quelle del PC client dove gira l'applicazione all'interno del browser.

Technorati tags: ASP.NET, Ajax, Localization

Prova il microframework e vinci!!!

Fabrizio Bernabei — Tue, 29 Jul 2008 07:16:00 GMT

Il titolo di questo post non è solo uno slogan da cartellone pubblicitario (anche se l'obiettivo è quello ) ma un'iniziativa "lanciata" dal team del Microsoft MF per incoraggiare gli sviluppatori a prendere parte al programma di beta della nuova versione 3.0.
In sostanza, registrandosi al programma beta e scaricando l'SDK dal sito http://connect.microsoft.com/netmf entro il 31 Agosto, si riceve un "biglietto elettronico" ed il 15 Settembre verrà "estratto" il fortunato vincitore di un RicaVision Universal Remote Control (non so quanto utile, ma sicuramente un bell'oggettino)...

Per i numerosi appassionati di Micro Framework che ci sono da queste parti, una buona scusa per studiarsi le novità della nuova versione di questo framework che, a prescindere dalle trovate marketing, promette veramente molto bene. Ecco una sintesi delle novità che saranno introdotte (tratte dal sito ufficiale):

• Interop and native code linking
• Touch screen and inking/gesturing support
• USB device
• SSL (secure sockets) for the TCP/IP stack
• Visual Studio 2008 support
• DPWS (Devices Profile for Web Services), including new codegen tools
• 4bpp font support
• Enhanced and more compatible serial/UART model
• File system*
• 802.11 Wi-Fi infrastructure*
• Support for more cores and processor architectures*
• Publicly available Porting Kit for purchase* (separate product not included with the SDK)
(Features noted with * will not be available in the first public beta)

A questo punto non resta altro che provare...

[OT] TS: MS .NET Framework 3.5, ADO .NET Application Development --> Passed

Paolo Possanzini — Wed, 23 Jul 2008 20:31:00 GMT

Anche io mi sto dilettando con gli esami in Beta. E proprio questa sera ho saputo di aver passato il 70-561 : TS: MS .NET Framework 3.5, ADO .NET Application Development

[OT] 70-562: Mcts Asp.Net 3.5 !

Andrea Cruciani — Wed, 16 Jul 2008 14:54:00 GMT

E' un periodo "prolifico" per le certificazioni, ho appena saputo di aver passato la beta dell'esame 70-562: "Microsoft .NET Framework 3.5, ASP.NET Application Development".

[update] anche il 70-561 (Ado.Net 3.5) è andato. Questo esame m'è sembrato proprio tosto, non credevo di averlo passato, ed invece ieri la sopresa.

Entro dicembre è prevista l'uscita dell'upgrade per l'MCPD, per chi fosse interessato alle certificazioni .Net e può aspettare qualche mese forse vale la pena di partire direttamente con le nuove certificazioni per Visual Studio 2008.

Di ritorno dal Workshop di DotNetMarche

Andrea Cruciani — Mon, 30 Jun 2008 07:03:00 GMT

Venerdì un piccola rappresentanza di dotnetUmbria è andata al workshop dei nostri amici delle Marche.

Si parlava di test delle applicazioni ed del prossimo framework MVC di Asp.Net, argomenti interessantissimi e molte volte indebitamente snobbati. E' stata l'occasione per fare la conoscenza di Gian maria, Simone (i due speakers dell'occasione, anche se alla fine con Simone non c'e' stata occasione di presentarci, sarà per la prossima) e Diego. E' proprio bello ritrovarsi cosi' in sintonia con persone che avevi conosciuto solo per mezzo dei loro blog, sono sicuro che d'ora in poi non mancheranno le occasioni per altri incontri (soprattutto se culinari :D)

Quindi un Bravi agli amici marchigiani, e un grazie di cuore!

Aperitivo DotNetUmbria lunedi 30 giugno ore 19:00 - Alla Posta dei Donini

Roberto Palazzetti — Thu, 26 Jun 2008 17:50:00 GMT

Posto : Posta dei Donini

Orario 19:00 alle 20:00

Aperitivo (Bevande+Stuzzichini) 9/10 euro a persona

rispondete con un commento a questo post.

Development Board per Microframework

Andrea Cruciani — Wed, 25 Jun 2008 09:52:00 GMT

Riposto una notizia letta sul blog di Lorenzo Barbieri su un nuvo kit a basso costo per fare test sul micro framework... quasi quasi gli tocca

Sembra che il prodotto sarà disponibile a 99$

Qui un link

Progetto NHooligans – Parte 2 – Finalmente un po’ di codice…

maiorfi — Sun, 15 Jun 2008 14:42:28 GMT

Resistere per ben due post all’inserimento di snippet di codice non è stato facile e proprio per questo motivo iniziamo oggi ad addentrarci in qualche esempio di utilizzo delle API del sistema che gestisce la nostra simulazione. Come giustamente mi è stato fatto notare da Paolo, l’uso del framework NSteer (oggetto dei post precedenti) potrebbe vincolare troppo la libertà in eventuali future evoluzioni del sistema di simulazione. Per questo motivo cercheremo di astrarre, laddove possibile, la concreta implementazione di NSteer degli “attori” che partecipano alla simulazione, mantenendo focalizzata la nostra attenzione soprattutto sulle interazioni tra gli oggetti descritti dalle interfacce introdotte nel post precedente. In altri termini, quando parleremo ad esempio di “Scena” faremo sì riferimento agli aspetti peculiari di un oggetto che implementa l’interfaccia IScene definita all’interno di NSteer, ma non necessariamente all’implementazione dell’unico tipo di scena definito in NSteer, ossia la GdiScene.

Già da una prima frettolosa analisi del sistema che realizzeremo appare evidente che, in un verso o nell’altro, dovremo “allestire” un’istanza di simulazione per ciascuna "sfida” giocata all’interno di NHooligans. E’ facile immaginare inoltre che il servizio (in senso generico, non in senso Windows Service o WebService) che costituirà l’host per la simulazione in questione dovrà costruire le condizioni sulle quali la simulazione costruirà il proprio contesto di esecuzione, condizioni quali la definizione dei partecipanti (ossia degli agenti), le caratteristiche fisiche e cinematiche di ciascun oggetto definito all’interno del “mondo” della simulazione (massa, accelerazione e velocità massime, ecc.) nonché ovviamente ciò che dà effettivamente un senso alla simulazione: il “programma” seguito da ciascun agente per muoversi e, soprattutto, gonfiare di botte i propri simili della squadra avversaria.

Quale che sia la conformazione del servizio “host”, la simulazione da allestire seguirà inevitabilmente i passi illustrati di seguito, che fanno riferimento ad una situazione facilmente riscontrabile anche nel demo di NSteer incluso nei sorgenti allegati nel primo post di questa sezione.

La composizione degli oggetti che partecipano alla realizzazione di una simulazione è illustrata nel diagramma che segue, in cui l’host è rappresentato da un Form Winforms denominato con grande fantasia “Form1”:

I primi servizi da inizializzare sono quelli che descrivono il “mondo” in cui la simulazione ha luogo e la “scena” che ne darà una rappresentazione (presumibilmente ma non necessariamente grafica), attraverso il retrieving di un riferimento alle interfacce IWorldService e IScene.

Qualora, come avviene tipicamente, si voglia confinare il raggio di azione degli agenti ad una regione limitata, dovremo creare un’istanza di comportamento che, applicata a ciascun agente, ne limiterà il movimento. Il tipo di comportamento in questione è già definito in NSteer e prende il nome di RectangleWorldGlobalBehavior. Per inizializzarlo è sufficiente impostare punto di partenza (di tipo PointF, ossia punto 2D con coordinate di tipo float) e dimensione (di tipo SizeF) della sua proprietà “Region”, come illustrato nel seguente snippet:

RectangleWorldGlobalBehavior region = new RectangleWorldGlobalBehavior(this.simulationComponents);

region.Region = new RectangleF(new PointF(0, 0), worldService.World.WorldSize);

Per inizializzare il servizio di gestione della “vicinanza" tra agenti, rappresentato dall’interfaccia INeighborhoodService, è necessario creare un’istanza del contenitore utilizzato dal sistema per accedere alla informazioni posizionali relative degli agenti. All’interno di NSteer sono definiti due diversi contenitori (che implementano l’interfaccia INeighborhood, di cui il più performante è il BinLatticeNeihborhood, basato su una struttura bidimensionale di “Bins”, ossia di caselle caratterizzate da una coppia di indici che ne descrive la posizione all’interno del contenitore (in termini di riga e colonna) e da una lista di agenti presenti in quella casella. Un’inizializzazione tipica del BinLatticeNeihborhood è la seguente:

INeighborhoodService neighborhood = this.simulationComponents.NeighborhoodService;

BinLatticeNeihborhood bins = new BinLatticeNeihborhood(

    this.simulationComponents,

    16, 16,

    this.sceneControl.Width,

    this.sceneControl.Height);

neighborhood.Neighborhood = bins;

Gli ostacoli presenti all’interno della simulazione possono essere facilmente creati ed inseriti nel servizio che li gestisce attraverso uno snippet di questo tipo, in cui vengono definiti due ostacoli circolari in posizioni diverse e di raggio rispettivamente 50 e 15:

IObstacleService obstacleService = this.simulationComponents.ObstacleService;

CircleObstacle obstacle = new CircleObstacle(new PointF(100, 100), 50);

obstacleService.ObstacleManager.AddObstacle(obstacle);

CircleObstacle obstacle2 = new CircleObstacle(new PointF(200, 200), 15);

obstacleService.ObstacleManager.AddObstacle(obstacle2);

Arriviamo finalmente alla creazione di un agente, caratterizzato nello snippet che segue dai seguenti aspetti salienti:

Corpo con comportamento assimilabile ad un punto dotato di massa
Area visiva “conica” (o meglio, in 2D, angolare)
Comportamento composito di tipo “prioritario”, in cui viene assunto come comportamento dell’agente il primo, all’interno dei comportamenti “componenti”, per il quale la norma dell’accelerazione sia maggiore di una certa soglia
Comportamento componente di tipo “comportamento composito pesato”, in cui i vari comportamenti componenti vengono sommati ciascuno con un proprio “peso”. In altri termini tale comportamento farà sì che vengano contemporaneamente tenuti in considerazione criteri diversi di movimento facendo sì che la “somma” di tutti i criteri propenda in favore dei criteri ritenuti più importanti
Comportamento componente (del composito pesato) di tipo ObstacleAvoidance (per evitare gli ostacoli) con peso 10
Comportamento componente (sempre del composito pesato) di tipo LocalBehavior (per rimanere nell’area di confine) con peso 5
Comportamento componente (del composito prioritario) di tipo FlockBehavior che permette all’agente di rimanere accanto ai propri “simili”. Poiché il comportamento composito prioritario prevede un ordine di priorità (decrescente) dato dall’ordine di inserimento, il FlockBehavior apporterà il proprio contributo solo se l’agente non si trova a ridosso di un ostacolo o del confine dell’area permessa
Comportamento componente (del composito prioritario) di tipo SeekBehavior che spinge l’agente verso il “target” assegnato (nel nostro esempio la posizione del cursore del mouse)
Velocità massima pari a 3 (non chiediamoci l’unità di misura)

Agent agent = new Agent(this.simulationComponents);

agent.Body = new PointMassBody();

agent.Vision = new ConeVision();

// Comportamento composito "prioritario"

PriorityBehavior behavior = new PriorityBehavior();

agent.Behavior = behavior;

// Comportamento componente del prioritario e composito "pesato"

WeightedSumBehavior wo = new WeightedSumBehavior();

behavior.Behaviors.Add(wo);

// Comportamento componente del pesato di tipo "confine"

LocalBehavior region = new LocalBehavior(this.region);

wo.AddBehavior(region,5);

// Comportamento componente del pesato di tipo "evita gli ostacoli"

ObstacleAvoidanceBehavior obstacleAvoidance = new ObstacleAvoidanceBehavior();

obstacleAvoidance.Probe = new TridentObstacleProbe();

wo.AddBehavior(obstacleAvoidance,10);

// Comportamento componente del prioritario di tipo "stormo"

FlockBehavior flock = new FlockBehavior();

behavior.Behaviors.Add(flock);

// Comportamento componente del prioritario di tipo "insegui"

MouseTargetPredictor mouse = new MouseTargetPredictor();

mouse.Style = MouseTargetPredictorStyle.Move;

mouse.OwnerControl = this.sceneControl;

SeekBehavior seek = new SeekBehavior();

seek.TargetPredictor = mouse;

seek.TargetTracker = new ArrivalTargetTracker();

behavior.Behaviors.Add(seek);

// Accelerazione, Velocità e Posizione iniziali

agent.Body.Update(new PointF(), new PointF(0, 0), new PointF(sceneControl.Width / 2, sceneControl.Height / 2));

// Velocità massima

UniformPointSaturator velsat = new UniformPointSaturator();

velsat.MaxNorm = 3f;

agent.Body.VelocitySaturator = velsat;

A questo punto uno step della simulazione può essere calcolato utilizzando il metodo SimulateTurn() dell’oggetto Simulator. Nell’esempio allegato a NSteer tale metodo viene chiamato ogni qual volta il controllo contenuto all’interno del Form che costituisce l’interfaccia utente dell’applicazione necessita di essere ridisegnato. Tale necessità viene inoltre “forzata” in corrispondenza del gestore di evento dell’evento Idle dell’oggetto Application di Winforms, come illustrato nello snippet seguente, in cui la simulazione viene rispettivamente avviata e bloccata da due pulsanti denominati (guarda caso) “startButton” e “stopButton”:

private void startButton_Click(object sender, EventArgs e)

   this.stopButton.Enabled = true;

   this.startButton.Enabled = false;

   Application.Idle+=new EventHandler(Application_Idle);

private void stopButton_Click(object sender, EventArgs e)

   Application.Idle -= new EventHandler(Application_Idle);

   this.stopButton.Enabled = false;

   this.startButton.Enabled = true;

private void Application_Idle(Object sender, EventArgs e)

   this.sceneControl.Invalidate();

Per oggi ci fermiamo qui, ma per mantenere viva l’attenzione su quanto ci aspetta propongo non uno, ma addirittura due “approfondimenti” pratici di quanto abbiamo visto.

Il primo è la realizzazione di un ostacolo di tipo rettangolare da integrare in NSteer, al quale potrebbe seguire, per i più solerti, l'implementazione di un ostacolo di tipo "polirettangolare", ossia definito da un insieme di rettangoli adiacenti.

Il secondo spunto, probabilmente più divertente, prevede la realizzazione di una semplice applicazione Winforms che, utilizzando NSteer, definisca un'area rettangolare di dimensioni 100x100 unità logiche con al centro un ostacolo circolare di raggio 30. In questo ambiente, 10 agenti con posizione iniziale (0,0), velocità e accelerazione nulla e velocità massima 3 devono arrivare nel più breve numero di step di simulazione possibili all'angolo opposto, dove per tempo più breve si intende quello dell'ultimo arrivato.

Come premio (o come penitenza?) i primi (o i soli) che posteranno del materiale interessante in merito ai due approfondimenti proposti avranno la facoltà di scegliere per primi i componenti dello sviluppo di NHoolingans da realizzare tra quelli che verranno resi a breve disponibili.

Progetto NHooligans - Parte 1 - Concetti, entità e interfacce del sistema di simulazione

maiorfi — Wed, 11 Jun 2008 05:53:00 GMT

In considerazione della straordinaria risposta al mio post nella sezione "futuri appuntamenti" (intendo straordinariamente scarsa), provo ad addentrarmi un po' più nel concreto del sistema di simulazione che costituirà l'ambiente all'interno del quale interagiranno i vari agenti (denominati "hooligan") comandati dai programmi "contendenti".

Facendo riferimento alla terminologia utilizzata nel framework NSteer, intorno al quale verrà sviluppato il sistema di simulazione, si individuano i seguenti "attori", ciascuno con le proprie peculiarità (o, in altri termini, ciascuno caratterizzato dall'implementazione di una o più delle interfacce definite dal framework:

Un oggetto di tipo "agente" (Agent, in NSteer), descrive un'entità che vive all'interno del "mondo" (World, in NSteer). Un agente ha un "corpo" (Body, in NSteer), un sistema di "visione" (Vision, in NSteer) e un "comportamento" (Behavior, in NSteer).
Il "corpo" di un agente definisce le proprietà cinematiche dell'agente (posizione, velocità e accelerazione).
Un sistema di "visione" definisce la regione in cui un agente può "vedere" gli altri agenti o gli ostacoli presenti, tipicamente, nelle sue vicinanze.
Il "comportamento" di un agente determina, ad ogni passo della simulazione, la forza (in senso vettoriale) cui sarà sottoposto il suo "corpo".
Gli agenti sono confinati all'interno del "mondo".
Il "simulatore" (Simulator, in NSteer) determina, ad ogni passo della simulazione, la situazione cinematica (posizione, velocità e accelerazione) di tutti gli agenti presenti nel sistema.
Il sistema di simulazione implementato in NSteer definisce quattro servizi per gestire gli agenti, il mondo, gli ostacoli e la "prossimità" di un agente nei confronti degli altri rispettivamente mediante i servizi AgentService, WorldService, ObstacleService e NeighborhoodService.
Per quanto concerne la visualizzazione della simulazione NSteer definisce il concetto di Sprite, un oggetto 2D caratterizzato da attributi quali colori, visibilità, forma, ecc. e il concetto di "Scena" (Scene, in NSteer), che astrae gli aspetti legati al rendering della simulazione.

Prima che vi sloghiate la mandibola per gli sbadigli, vi incollo un'immagine relativa ad uno step della simulazione realizzata all'interno del demo che accompagna il framework NSteer.

Nello screenshot è possibile individuare una decina di agenti (i punti contornati dal cerchietto rosa, che rappresenta lo spazio occupato dall'agente) ciascuno dei quali ha un proprio "orientamento" ed un proprio "cono visivo" (rappresentato dai 3 segmenti terminati da pallini che escono dal centro dell'agente). I comportamenti di ciascun agente sono descritti dall'etichetta che compare accanto a ciascun cerchietto rosa. I comportamenti definiti all'interno del framework NSteer sono già parecchi, ma è possibile definirne di nuovi o scrivendoli da zero o utilizzando uno dei comportamenti "contenitore" già definiti in NSteer. I 3 cerchi viola rappresentano degli ostacoli circolari. Nell'immagine gli agenti al centro della finestra hanno attivato il comportamento "Seek" (ossia insegui) nei confronti del pallino verde in alto (comandato dal movimento del cursore del mouse nell'applicazione di esempio). Gli altri hanno attivato invece un comportamento composito caratterizzato dalla somma del comportamento "Confine" (ossia confina, argina) e del comportamento "Avoid" (ossia evita), rispettivamente per rimanere all'interno della regione permessa (rappresentata dal riquadro interno) e per evitare l'ostacolo che hanno accanto.

Anche se nello step di simulazione immortalato da questo screenshot non è evidente (perché in questo screenshot altri comportamenti avevano priorità), gli agenti tendono a rimanere uniti ma a non sovrapporsi grazie ad un altro comportamento: il FlockBehavior (dove flock significa "stormo").Questo comportamento ha una valenza "storica" particolare perché è proprio dalla scomposizione delle regole che guidano il comportamento di uno stormo di uccelli che Reynolds ha tratto lo spunto per il proprio lavoro. Per rendervi conto meglio di quello che Reynolds ha inventato (o forse dovrei dire "scoperto") vi consiglio di dare un'occhiata ai demo allegati, ed in particolare (premento Tab si passa da un demo al successivo) al demo "Boids".

Nel prossimo post inizieremo a dare un'occhiata a qualche snippet di codice, per poi fare chiarezza sui "lotti" di progetto disponibili per l'assegnazione a chi vorrà partecipare attivamente allo sviluppo di NHooligans.

Sì, va bene, sviluppiamo un software insieme…ma quale?

maiorfi — Wed, 11 Jun 2008 05:47:54 GMT

Ciao a tutti. Riprendo il primo post in cui si è parlato di NHooligans dalla sezione Eventi del Forum per mettere subito qualcosa qui dentro prima che Paolo si arrabbi e chiuda il Blog…

Premetto di nuovo (ed è la terza volta…basta!) che lo scopo del progetto in questione non dovrebbe essere, almeno a mio avviso, quello del software da realizzare in se', quanto piuttosto un'opportunità per sperimentare metodologie, architetture e tecnologie che favoriscano lo sviluppo collaborativo anche all'interno di un gruppo di sviluppatori che non condividono un luogo di lavoro "fisico", bensì uno spazio virtuale (termine che sembra uscito dalla bocca di uno di quegli informatici degli anni 60 che stavano davanti ai calcolatori con il camice) rappresentato da un misto di sistemi informativi quali email, forum, blog, controllo sorgenti, ecc.

In breve, l'idea per il soggetto dello sviluppo è quella di un gioco on-line ispirato al celeberrimo (e antichissimo) "core wars" (la guerra dei nuclei, nella traduzione italiana di "Le Scienze"), ossia di un gioco in cui i concorrenti sono rappresentati da agenti autonomi il cui comportamento è stabilito da programmi realizzati da giocatori "umani" che (indirettamente) concorrono al raggiungimento di un obiettivo. Anche se molti sono i giochi che si sono ispirati a core wars negli anni a venire (p-robots, c-robots e ants per citarne alcuni), il capostipite resta ancora l'unico caso in cui i programmi che si sfidano sono al contempo avatar e software di controllo degli avatar stessi: un'idea a mio parere di rara genialità (anche se, a quanto dice wikipedia, pare che Dewdney, l'autore del gioco, si sia in realtà ispirato ad un altro gioco chiamato Darwin, ideato nei laboratori della Bell negli anni 60, ma a noi che ce frega?).

Ovviamente, essendo qui tutti appassionati di sviluppo .NET (qualcuno anche perché non ha una ragazza), l'idea è quella di realizzare un sistema in cui degli oggetti .NET, compilati ed ospitati in un assembly, comandino degli agenti autonomi che si sfidano in una sorta di "arena" a suon di..."mazzate". Mi spiego meglio: l'ambientazione di riferimento sarebbe quella, sicuramente italiana almeno quanto la pizza ma anche un po'inglese, di due tifoserie avversarie che si gonfiano come zampogne nel tentativo di raggiungere una meta (che nel caso reale manca, ma questo dimostra ancora una volta che l'informatica è un mondo estremamente più concreto di quello reale) rappresentata da una bandiera (della tifoseria avversaria, si intende), da conquistare e, presumibilmente, in seguito bruciare sghignazzando. Proprio per questo non mi dispiacerebbe se il progetto si chiamasse "NHooligans", anche se è un nome un po' lassativo. In alternativa potremmo usare, come fa mamma Microsoft, il nome di qualche frazione locale, tipo "Ramazzano", ma forse è meglio NHooligans...

Lo schema del gioco dovrebbe essere questo: si sfidano due tifoserie, ognuna rappresentata da N agenti autonomi, detti "hooligan" (ironicamente al contempo tifosi e agenti, ah ah), ciascuno dei quali viene "pilotato" da uno di M programmi, con la possibilità di attribuire teoricamente anche un programma differente per cisacun hooligan. Ciascun hooligan è rappresentato nell'arena di gioco da un'area circolare che ne rappresenta, per così dire, l'ingombro. Gli hooligan, amici o nemici, non possono "compenetrarsi", ossia i loro "cerchi" non possono sovrapporsi. Ogni hooligan viene dotato inizialmente di una riserva di energia (ad es. 100 unità), che viene decrementata sia per effetto del muoversi (per più tempo e più forte corre, più si affatica) sia, soprattutto, per effetto delle botte che prende. Inoltre, l'energia residua di un hooligan determina la velocità massima con cui può muoversi e i danni che fa quando picchia un avversario. Ogni qualvolta due hooligan avversari si trovano a distanza minima (la somma dei due raggi, ossia quando si toccano) essi si sottraggono punti energia in ragione dei loro rispettivi stati di salute (uno sano picchia di più di uno già malconcio). Quando l'energia di un hooligan arriva a zero, questi viene ovviamente "rimosso" dall'arena. Se un hooligan si trova a contatto con più avversari, questo subirà un danno maggiore della somma dei danni dei singoli avversari, per effetto di una "sinergia" che spesso manca nei film tipo quelli con Bruce Lee in cui , anche se sono 100 contro 1, i cattivi sfidano il protagonista uno per volta, per onestà. Se un hooligan riesce a raggiungere il punto dell'arena che contiene la bandiera avversaria, la sua squadra vince e totalizza i punti corrispondenti alla somma dei punti energia degli hooligan ancora in gioco.

Anche se seguiranno altri dettagli nei prossimi post, una prima idea che vorrei proporre è quella di utilizzare nei programmi di controllo degli hooligan delle "primitive" complesse del tipo "segui quell'holigan", oppure "voi 4 rimanete vicini", oppure "evita quell'ostacolo", oppure "vigila in questa zona", oppure (e più spesso) "scappa". Per far questo potremmo utilizzare il framework NSteer, sviluppato da Jonathan de Halleux a partire dal lavoro originale di Craig W. Reynolds della Sony, che per primo ha ideato e sviluppato gli algoritmi "comportamentali" di cui sopra, senz'altro motivato dalla partecipazione a diversi progetti di sviluppo per software playstation.

Se ne avete voglia, potete intanto dare un'occhiata al progetto NSteer (dalla solution togliete il progetto di test e lanciate il demo winform per farvi un'idea) e, perché no, anche alla pubblicazione originale (del 1999) di Craig W. Reynolds e ai relativi demo animati.

Book review: Essential Silverlight 2 - UpToDate !

Andrea Cruciani — Tue, 10 Jun 2008 13:00:00 GMT

Periodo di molte letture questo :-).

In questi giorni, volendo approfondire Silverlight, ho letto il libro di Christian Wenz (da notare che nel suo bog si parla di Asp.Net e Php, nel blog spazia proprio su tutto! ) mi sono trovato alle prese con un nuovo genere di libro... un libro molto Web 2.0!

Il libro è interessante e propone gli argomenti base di Silverlight 2 in modo abbastanza conciso, forse troppo... arrivati a metà libro, sorpresa! La restante metà del libro è composta da pagine bianche, un po' troppe per essere pagine per gli appunti...

Essendo Silverlight 2 una tecnologia drasticamente in movimento Christian ha capito che non poteva scrivere subito un libro compiuto, ha così reso il libro dinamico, oltre agli esempi sul sito O'Reilly ne usciranno continui aggiornamenti mano a mano che la tecnologia si evolverà. Ciascuno potrà scegliere se scaricarsi i pdf degli aggiornamenti e stamparseli oppure se ordinare le nuove pagine già stampate (per circa 4$). E' già stato pubblicato un nuovo aggiornamento a Maggio 2008, la cosa intrigante è che gli stessi lettori possono partecipare al forum e chiedere di approfondire un argomento (per esempio è stato chiesto un approfondimento sulla Sicurezza).

E' sicuramente un format interessante, forse non sarà troppo popolare perchè in questo mondo dove si và troppo veloci pochi si prenderanno cura di aggiornare un "vecchio" libro cartaceo e si terranno i pdf in una cartella... ma, almeno per me, il fascino della carta stampata rimane sempre. Cmq compliementi a Christian ed alla O'Reilly per il coraggio!

Rilasciato Silverlight 2 beta 2

Andrea Cruciani — Tue, 10 Jun 2008 07:11:00 GMT

E' notizia "vecchia" di qualche giorno ma non posso evitare di riproporla: è stata rilasciata la versione beta 2 di Silverlight 2.

Tra le novità una di quelle più interessanti per capire la direzione che sta prendendo Silverlight 2 è che lo Xaml sta diventanto sempre più conforme a quello utilizzato in Wpf, per chi avesse seguito la mia sessione all'ultimo evento capisce quale possa essere l'importanza strategica di questa notizia.

In attesa del rilascio dell'SDK altre novità potete trovarle riassunte in questo post di Pietro Brambati, che rimanda anche ad alcune breaking changes con la beta 1.

Immancabile il "solito" post di Scott Guthrie sull'argomento

Una nota sulla licenza di rilascio. SL 2 beta 2 è rilasciato in Go-Live che permette l'utilizzo a fini commerciali del prodotti.

Happy SL !

Book review: Expert .Net Micro Framework

Andrea Cruciani — Sat, 31 May 2008 15:31:00 GMT

Era da un po' che volevo dedicare del tempo a capire meglio il MicroFramework e il libro di Jens Kühner è stata la scusa per iniziare a dargli uno sguardo. Il MicroFramework mi permette di unire i miei vecchi (ed impolverati) studi di elettronica al mio "pane quotidiano", la programmazione con .Net. Leggendo il libro (adatto anche a chi conosce il .Net framework "standard" non approfonditamente) si scopre un mondo di microcontrollori già predisposti per l'utilizo del Microframework, uno tra tutti un dispositivo costituito da una porta di rete "intelligente" che trovate qui.

Oltre al controllo delle porte hardware (GPIO: Genera Purpose Input/Output), al threading, alla crittografia (!!) è possibile pilotare diplay lcd per visualizzare dettagli (anche grazie ad un SDK aggiuntivo SideShow, creato ad hoc per il Micro Framework) nonchè gestire le comunicazioni via socket TCP ed UDP. Proprio nel capitolo del networking ho scopeto l'esistenza delle specifiche DPWS (Device Profile for Web Service) un subset delle specifiche dei Web Services che permettono di offrire le capacità del dispositivo tramite un web service hostato dal device stesso!! Ovviamente tale funionalità e' rivolta ai dispositivi che possiedono un'interfaccia di rete. Immaginate una serie di dispositivi che fanno monitoraggio ambientale e la possibilità di visualizzare lo stato di un ambiente (temperatura, umidità, ...) in un mesh up che riassume tutti i dati dai vari dispositivi, il tutto utilizzando le normali tecniche di interrogazione dei web services... Sinceramente questo framework mi ha intrigato tantissimo. Spero di poter iniziare presto a fare qualche esperimento, poi vi dirò come procede. Per chi fosse interessato all'argomento credo che il libro aiuti, in modo veloce e puntuale, a capire quale sia la situazione attuale del prodotto e la panoramica delle funzionalità che offre.

Se volete iniziare a guardare l'argomento vi segnalo alcuni links:

MicroFramework SDK 2.5
Windows SideShow Device SDK for .NET Micro Framework

.Net Microframework

Uno snippet per le DependencyProperty su WPF

Paolo Possanzini — Tue, 27 May 2008 07:59:00 GMT

Mi capita molto spesso di creare DependencyProperty per i miei oggetti da utilizzare con WPF.
Nello snippet base devo sostituire continuamente UIPropertyMetadata con FrameworkElementMetadata, quindi ho deciso di farmi uno snippet gia modificato.

Ve lo allego.
Potete richiamarlo con propdpf

Per installarlo è sufficiente copiare il file nella cartella
C:\Program Files\Microsoft Visual Studio 9.0\VC#\Snippets\1033\NetFX30\

Applicazione Silverlight 2 - VS 2008 {Community} Launch

Andrea Cruciani — Fri, 16 May 2008 17:07:00 GMT

Un mese di attesa per pubblicare la demo fa sicuramente molto poco "web 2.0" ma spero che mi perdonerete.

Trovate in allegato due demo:

Silverlight 2
Conversione "brutale" in WPF

Mentre la parte WPF non ha requisiti particolari per SL è necessario installare un ambiente che abbia i seguenti requisiti:

Per l'editor consiglio di installare Expression Blend:

Microsoft Expression Blend 2.5 March 2008 Preview

La parte SL funziona nell'inserimento dei dati e nella consultazione. La conversione in Wpf è solo parziale (non e' stato sviluppata la parte di persistenza), l'obiettivo era quello di verificare come fosse possibile utilizzare uno Xaml pressocchè uguale in entrambe le situazioni.

Nei prossimi post vorrei analizzare alcune parti di questa demo in profondità e magari sfruttarla per introdurre qualche concetto architetturale.

Demo SL: Demo SL.rar

Demo Wpf: Wpf Version.rar

WPF - VS 2008 {Community} Launch - Il Codice della demo

Paolo Possanzini — Mon, 12 May 2008 00:24:00 GMT

In allegato a questo Post trovate il codice della demo della sessione su WPF utilizzata durante l'evento dell'8 Aprile.