...I'm simply feeling fine, so fine that I can't stand waiting, just can't stand...
.m
The journey is the most important thing, not the destination. Find your next destination and start travelling again.
Thursday, November 23, 2006
Friday, November 17, 2006
[OT] Pelle d'oca
Probabilmente non interessa a nessuno... o meglio a qualcuno mi sa che interessa :-D
Mi sono appena arrivati i biglietti, si "i" perchè ne ho comperati 2 anche se non so ancora con chi andare, per il concerto di Roger Waters a Milano il prossimo mese di Aprile... non vedo l'ora, il solo pensiero di acoltare Comfortably Numb, o altre perle che hanno fatto la storia della musica, dal vivo mi fa venire i brividi!
Naturalmente siccome non ho più l'età posti seduti numerati :-D, poca voglia di sbattimento in mezzo alla bolgia :-D, poi non sono mica i Metallica o i Dream Theater dove stare in mezzo alla bolgia paga, qui bisogna gustarselo religiosamente...
.m
Mi sono appena arrivati i biglietti, si "i" perchè ne ho comperati 2 anche se non so ancora con chi andare, per il concerto di Roger Waters a Milano il prossimo mese di Aprile... non vedo l'ora, il solo pensiero di acoltare Comfortably Numb, o altre perle che hanno fatto la storia della musica, dal vivo mi fa venire i brividi!
Naturalmente siccome non ho più l'età posti seduti numerati :-D, poca voglia di sbattimento in mezzo alla bolgia :-D, poi non sono mica i Metallica o i Dream Theater dove stare in mezzo alla bolgia paga, qui bisogna gustarselo religiosamente...
.m
Labels:
Why not...
Tuesday, November 14, 2006
Migrazione completata, addio VS2003 e fx1.1
Oggi, complice un pomeriggio un po' fiacco, ne ho approfittato per completare l'opera, ho definitivamente migrato tutte le applicazione che ho in sviluppo verso il fx 2.0 e VS2005, finalmente non ce la facevo più :-D
Fondamentalmente tutto e filato abbastanza liscio a parte qualche magagna con P/Invoke e naturalmente con il mio "amico" Crystal Report (maledetto lui...).
Per chiunque si trovasse di fronte alla stessa sistuazione e avesse un semplice metodo che imposta le fatidiche "ConnectionInfo" e "TableLogonInfo" al fine di poter switchare da un db ad un altro senza piangere in cinese... cominci a piangere perchè smette clamorosamente di funzionare... maledizione!
Quello che facevo fino ad oggi era "semplicemente" questo:
protected string ParseDBObjectName( string name )
{
if( name.IndexOf( " " ) != - 1 || name.IndexOf( "." ) != - 1 )
{
if( !name.StartsWith( "[" ) )
{
name = "[" + name;
} if( !name.EndsWith( "[" ) )
{
name = name + "]"
}
} return name;
} protected void ApplyLogOnInfo( ReportDocument rpt, ConnectionInfo ci )
{
foreach(Table tb in rpt.Database.Tables)
{
TableLogOnInfo loi = tb.LogOnInfo;
loi.ConnectionInfo = ci;
tb.ApplyLogOnInfo( loi ); if( tb.TestConnectivity() )
{
if( tb.Location.IndexOf(".") > 0 )
{
tb.Location = this.ParseDBObjectName(
tb.Location.Substring(tb.Location.LastIndexOf( "." ) + 1 )
);
}
else
{
tb.Location = this.ParseDBObjectName( tb.Location );
}
}
}
}
public void ApplyLogOnInfo()
{
ConnectionInfo ci = new ConnectionInfo(); ci.ServerName = this.ServerName;
ci.DatabaseName = this.DatabaseName;
this.ApplyLogOnInfo( this.Report, ci );
foreach( ReportObject obj in this.Report.ReportDefinition.ReportObjects )
{
if( obj.Kind == ReportObjectKind.SubreportObject )
{
SubreportObject subObj = ( SubreportObject )obj;
ReportDocument subRpt = this.Report.OpenSubreport(
subObj.SubreportName );
this.ApplyLogOnInfo( subRpt, ci );
}
}
} tutto ciò non fa altro che applicare in maniera ricorsiva su tutti gli oggetti (report e subreport) presenti nel report le stesse ConnectionInfo e TableLogonInfo, bene tutto ciò non funziona più, o meglio non produce il risultato atteso... all'inizio semplicemente panico... :-D Poi studiando un po' il problema e i soliti comprensibilissimi errori di CR, ma questi alla versione 11 o quel che è non hanno ancora capito nulla..., sono giunto alla soluzione decisamente banale :-S public void ApplyLogOnInfo()
{
ConnectionInfo ci = new ConnectionInfo(); ci.ServerName = this.ServerName;
ci.DatabaseName = this.DatabaseName;
ci.IntegratedSecurity = true;
è comparsa una nuova proprietà che non esisteva nella versione per il fx 1.1, naturalmente il suo valore di default, come mi sembra ovvio, è "false"...
Tutto è bene quel che finisce bene :-D
.m
Fondamentalmente tutto e filato abbastanza liscio a parte qualche magagna con P/Invoke e naturalmente con il mio "amico" Crystal Report (maledetto lui...).
Per chiunque si trovasse di fronte alla stessa sistuazione e avesse un semplice metodo che imposta le fatidiche "ConnectionInfo" e "TableLogonInfo" al fine di poter switchare da un db ad un altro senza piangere in cinese... cominci a piangere perchè smette clamorosamente di funzionare... maledizione!
Quello che facevo fino ad oggi era "semplicemente" questo:
protected string ParseDBObjectName( string name )
{
if( name.IndexOf( " " ) != - 1 || name.IndexOf( "." ) != - 1 )
{
if( !name.StartsWith( "[" ) )
{
name = "[" + name;
} if( !name.EndsWith( "[" ) )
{
name = name + "]"
}
} return name;
} protected void ApplyLogOnInfo( ReportDocument rpt, ConnectionInfo ci )
{
foreach(Table tb in rpt.Database.Tables)
{
TableLogOnInfo loi = tb.LogOnInfo;
loi.ConnectionInfo = ci;
tb.ApplyLogOnInfo( loi ); if( tb.TestConnectivity() )
{
if( tb.Location.IndexOf(".") > 0 )
{
tb.Location = this.ParseDBObjectName(
tb.Location.Substring(tb.Location.LastIndexOf( "." ) + 1 )
);
}
else
{
tb.Location = this.ParseDBObjectName( tb.Location );
}
}
}
}
public void ApplyLogOnInfo()
{
ConnectionInfo ci = new ConnectionInfo(); ci.ServerName = this.ServerName;
ci.DatabaseName = this.DatabaseName;
this.ApplyLogOnInfo( this.Report, ci );
foreach( ReportObject obj in this.Report.ReportDefinition.ReportObjects )
{
if( obj.Kind == ReportObjectKind.SubreportObject )
{
SubreportObject subObj = ( SubreportObject )obj;
ReportDocument subRpt = this.Report.OpenSubreport(
subObj.SubreportName );
this.ApplyLogOnInfo( subRpt, ci );
}
}
} tutto ciò non fa altro che applicare in maniera ricorsiva su tutti gli oggetti (report e subreport) presenti nel report le stesse ConnectionInfo e TableLogonInfo, bene tutto ciò non funziona più, o meglio non produce il risultato atteso... all'inizio semplicemente panico... :-D Poi studiando un po' il problema e i soliti comprensibilissimi errori di CR, ma questi alla versione 11 o quel che è non hanno ancora capito nulla..., sono giunto alla soluzione decisamente banale :-S public void ApplyLogOnInfo()
{
ConnectionInfo ci = new ConnectionInfo(); ci.ServerName = this.ServerName;
ci.DatabaseName = this.DatabaseName;
ci.IntegratedSecurity = true;
è comparsa una nuova proprietà che non esisteva nella versione per il fx 1.1, naturalmente il suo valore di default, come mi sembra ovvio, è "false"...
Tutto è bene quel che finisce bene :-D
.m
Labels:
Why not...
Sunday, November 12, 2006
MSDN Flash - Che storia! Ci sono anche io :-D
...sono belle soddisfazioni, grazie di nuovo!
http://www.microsoft.com/italy/msdn/risorsemsdn/community/tips/1110.mspx#EKB
.m
http://www.microsoft.com/italy/msdn/risorsemsdn/community/tips/1110.mspx#EKB
.m
Labels:
Why not...
Saturday, November 11, 2006
TechEd Developer - Perchè non usare le Stored Procedure
Facciamo un po' di chiarezza sugli ultimi commenti che sia io che Raff abbiamo postato riguardo all'uso di stored procedure...
Contesto
Sessione di Ingo Rammer sul tuning e l'analisi delle performance in applicazioni distribuite.
Rammer ha analizzato tutte le possibili cause che portano a problemi di performance in applicazioni distribuite e alla fine parlando dell'accesso ai dati ha detto che le stored procedure non devono essere usate perchè generano un sacco di traffico di rete inutile.
Considerazioni
Lo scenario di Rammer si inserisce in un contesto in cui ad esempio carico la mai entity "Customer" eseguo la modifica di un solo valore e aggiorno il db usando una sola sp mi ritrovo a passare tutti i dati presenti nella mia entity alla stored procedure generando quindi del traffico di rete inutile, l'uso di uno statement sql creato ad hoc, come del resto fanno i principali ORM, permette di gestire in maniera molto più granulare la situazione.
L'uso di uno statement specifico che si preocupa di aggiornare i soli dati realmente modificati permette inoltre di gestire meglio la concorrenza ottimistica nel caso in cui, ad esempio, il client X modifichi la Ragione Sociale mentre il client Y modifichi l'indirizzo della ns entity, in un caso come questo potrebbe non avere senso gestire la concorrenza ma basterebbe semplicemente accettare le 2 modifiche che non sono "concorrenziali".
In quest'ottica l'uso di sp porta ad un calo di performance dovuto proprio al traffico di rete inutile, l'unica soluzione sarebbe quella di avere tante sp quante sono le combinazioni possibili di parametri in ingresso, impensabile.
Per tutto le altre operazioni su db le sp vanno più che bene e lo stesso Rammer non ha fatto commenti di sorta, resta però doveroso leggersi questo:
http://msdn.microsoft.com/msdnmag/issues/06/11/SQLSecurity/default.aspx
.m
Contesto
Sessione di Ingo Rammer sul tuning e l'analisi delle performance in applicazioni distribuite.
Rammer ha analizzato tutte le possibili cause che portano a problemi di performance in applicazioni distribuite e alla fine parlando dell'accesso ai dati ha detto che le stored procedure non devono essere usate perchè generano un sacco di traffico di rete inutile.
Considerazioni
Lo scenario di Rammer si inserisce in un contesto in cui ad esempio carico la mai entity "Customer" eseguo la modifica di un solo valore e aggiorno il db usando una sola sp mi ritrovo a passare tutti i dati presenti nella mia entity alla stored procedure generando quindi del traffico di rete inutile, l'uso di uno statement sql creato ad hoc, come del resto fanno i principali ORM, permette di gestire in maniera molto più granulare la situazione.
L'uso di uno statement specifico che si preocupa di aggiornare i soli dati realmente modificati permette inoltre di gestire meglio la concorrenza ottimistica nel caso in cui, ad esempio, il client X modifichi la Ragione Sociale mentre il client Y modifichi l'indirizzo della ns entity, in un caso come questo potrebbe non avere senso gestire la concorrenza ma basterebbe semplicemente accettare le 2 modifiche che non sono "concorrenziali".
In quest'ottica l'uso di sp porta ad un calo di performance dovuto proprio al traffico di rete inutile, l'unica soluzione sarebbe quella di avere tante sp quante sono le combinazioni possibili di parametri in ingresso, impensabile.
Per tutto le altre operazioni su db le sp vanno più che bene e lo stesso Rammer non ha fatto commenti di sorta, resta però doveroso leggersi questo:
http://msdn.microsoft.com/msdnmag/issues/06/11/SQLSecurity/default.aspx
.m
Friday, November 10, 2006
TechEd Developer - Non siamo gli unici... :-D
Non usate le stored procedure :-D
.m
.m
Labels:
Why not...
TechEd Developer - Optimizing Performance and Scalability of Distribuited .NET Applications
Ingo Rammer
Iniziamo con un commento goliardico sul ns stato di salute dopo aver dormito qualcosa come 2 ore...
Orario noto, condizione accettabile, tasso alcolico nella norma: sono fedele, mi sentirei una m***a se lo facessi...
orario indefinito... viaggio dal porto olimpico verso il nulla... OutOfAlcoholicTaxException... stesso personaggio: be insomma il tradimento.. che vuoi che sia... no ma se la baci e basta non è mica tradire... va bene così l'ho fatto un sacco di volte...
ROT[C*]L / *C: "Cab"
Torniamo alle cose serie se no mi gambizzano :-D
Brev e in ntroduzione sulle best practice da aplicare alle metodoligie di testine e stressing di un'applicazione per essere sicuri che quello che stiamo testando dia dei risultati che siano utili all'analisi di un eventuale problema e/o collo di bottiglia.
Rammer suggerisce un approccio basato su setp per arrivare ad identificare il collo di bottiglia:
- network tracing / sniffing: bell'esempio di uso di Etheral per analizzare i pacchetti scambiati tra server e client alla ricerca di eventuali problemi, il primo test viene fatto su un'applicazione remoting il secondo su una WCF;
- Tracciare l'accesso al db: fondamentale è capire cosa succede dietro le quinte, ci sono situazioni in cui lasciare nelle mani di un tool (leggi DataSet e/o ORM) la generazione del codice SQL è un suicidcio, la seconda cosa fondamentale è ridurre all'osso il locking sulle tabelle;
- il terzo step rigurda la profilazione della memoria, un tool free a CLR Profiler, una nota fondamentale è che non traccia i memory leaks ma semplicemente l'uso della memoria;
Va tutto benissimo, abbiamo seguito tutte le best practice ma la ns applicazione continua ad avere problemi... l'indagine deve spostarsi verso i componenti di terzi parti, Ingo ci fa vedere una demo profilando dei componenti di terze parti con risultati a dir poco allarmanti... quindi okkio ;-)
.m
Iniziamo con un commento goliardico sul ns stato di salute dopo aver dormito qualcosa come 2 ore...
Orario noto, condizione accettabile, tasso alcolico nella norma: sono fedele, mi sentirei una m***a se lo facessi...
orario indefinito... viaggio dal porto olimpico verso il nulla... OutOfAlcoholicTaxException... stesso personaggio: be insomma il tradimento.. che vuoi che sia... no ma se la baci e basta non è mica tradire... va bene così l'ho fatto un sacco di volte...
ROT[C*]L / *C: "Cab"
Torniamo alle cose serie se no mi gambizzano :-D
Brev e in ntroduzione sulle best practice da aplicare alle metodoligie di testine e stressing di un'applicazione per essere sicuri che quello che stiamo testando dia dei risultati che siano utili all'analisi di un eventuale problema e/o collo di bottiglia.
Rammer suggerisce un approccio basato su setp per arrivare ad identificare il collo di bottiglia:
- network tracing / sniffing: bell'esempio di uso di Etheral per analizzare i pacchetti scambiati tra server e client alla ricerca di eventuali problemi, il primo test viene fatto su un'applicazione remoting il secondo su una WCF;
- Tracciare l'accesso al db: fondamentale è capire cosa succede dietro le quinte, ci sono situazioni in cui lasciare nelle mani di un tool (leggi DataSet e/o ORM) la generazione del codice SQL è un suicidcio, la seconda cosa fondamentale è ridurre all'osso il locking sulle tabelle;
- il terzo step rigurda la profilazione della memoria, un tool free a CLR Profiler, una nota fondamentale è che non traccia i memory leaks ma semplicemente l'uso della memoria;
Va tutto benissimo, abbiamo seguito tutte le best practice ma la ns applicazione continua ad avere problemi... l'indagine deve spostarsi verso i componenti di terzi parti, Ingo ci fa vedere una demo profilando dei componenti di terze parti con risultati a dir poco allarmanti... quindi okkio ;-)
.m
Labels:
Why not...
TechEd Developer - OT :-D
Keith Brown
Keith chi...???
Keith Richards...?
Charlie Brown...?
Carlie Marrone...?
LOL
.m
Keith chi...???
Keith Richards...?
Charlie Brown...?
Carlie Marrone...?
LOL
.m
Labels:
Why not...
Thursday, November 9, 2006
TechEd Developer - .NET Apps Boosting :-D
Claudio Caldato - Perfromance & Garbage Collector PM
Seconda sessione Whiteboard, stimolante :-D, queste sono le domande poste dal pubblico:
Intrusiviness of the GC
Ho già parlato delle novità, che lo stesso Claudio ci ha introdotto, nella gestione del GC che Orcas porterà, adesso ci sta facendo vedere l'API:
GCSetting.LatencyMode = GCLatencyMode.Batch | Interactive | LowLatency;
Batch: StopEE --> Collection --> RestartEE uguale a quello che oggi è "GCConcurrency Off";
Interactive: molti StotEE --> Collection --> RestartEE ma di brevissima durata al fine di massimizzare l'interattività uguale a quello che oggi è "GCConcurrency On";
LowLatency: Chiede al GC di intervenire molto più spesso ma cercando di impattare il meno possibile sulle performance dell'intera applicazione, questo porterà il GC probabilmente a non fare tutto il lavoro che si era prefissato ma ci restituisce il controllo nel più breve tempo possibile;
GC.Collect( generation, [Default | Force | Optimized] );
la novità è Opmized che lascia decidere al GC se sia effettivamente il caso di fare una Collection o meno.
Generics Performance
Non ci sono note particolare sulle performance legate ai Generics, i Generics potrebbero impattare su NGen e venir comunque jittati nel caso in cui il tipo non sia noto.
Reflection
Non è una "bad pratice" ma è una "expensive pratice", quindi è da dosare e usare con le pinze. Un ottimo trucco per velocizzare le operazioni nel caso di chiamate multiple (in un ciclo ad esempio) ad un metodo sullo stesso tipo è quello di ricavare il MethodRuntimeHandle dalla classe (MethodBase.MethodHandle) e quindi recuperare un riferimento al metodo all'interno del ciclo tramite il metodo MethodBase.GetMethodFromHandle(), questa caching dell'handle ci permette di evitare che reflection faccia tutte le volte tutta l'analisi del grafo alla ricerca di quello che ci serve compreso l'eventuale overhead della CAS.
Finalization
Il Dispose pattern, non aggiungo altro ci sono montagne di articoli al riguardo...
Multi Threading
Anche qui le solite cose che tutti dovremmo sapere a menadito: non suare Thread.Abort(), usare il ThreadPool, non usare Thread.Suspend() ma sistemi più sofisticati tipo locking, mutex, semafori etc..
NGen
Fondamentale che NGen venga eseguito sulla macchina di destinazione.
benefits:
- non c'è jitting durante lo startup;
- sharing: il codcie NGened è condivisibile attraverso più processi, ad esempio un assembly viene condiviso su più processi, uno scenario particolarmente adatto è l'uso di un applicazione via RDC;
Interessante è la possibilità di usare un sevizio per "NGennare" in background l'applicazione
Marshaling Performances, P/Invoke
La prima cosa da controllare è che ci siano il minor numero di roundtrip tra codice managed e codice unmanaged, è inoltre fondamentale usare un profiler per tracciare l'uso della memoria... è appena intervenuto Raff con una soluzione ad un problema... giustamente non ho capito... Raff troppo avanti! :-D
nel fx 2.0 è stato fatto un lavoro notevole per ottimizzare il marshaling dei dati e Claudio ci conferma che per i tipi di dati semplici le performance sono molto buone, quello a cui dobbiamo porre molta attenzione è il passaggio di strutture molto complesse.
Rebasing
L'uso di NGen fa si che l'assembly venga convertito in codice nativo e gli viene assegnato un base address, se durante il loading dell'assembly in quell'indirizzo in memoria c'è già qualcosa l'assembly deve essere rebased e si perdono tutti i benefici di NGen, un workaround è quello di impostare il base address direttamente in fase di compilazione, ma resta comunque un terno al lotto ;-)
.m
Seconda sessione Whiteboard, stimolante :-D, queste sono le domande poste dal pubblico:
Intrusiviness of the GC
Ho già parlato delle novità, che lo stesso Claudio ci ha introdotto, nella gestione del GC che Orcas porterà, adesso ci sta facendo vedere l'API:
GCSetting.LatencyMode = GCLatencyMode.Batch | Interactive | LowLatency;
Batch: StopEE --> Collection --> RestartEE uguale a quello che oggi è "GCConcurrency Off";
Interactive: molti StotEE --> Collection --> RestartEE ma di brevissima durata al fine di massimizzare l'interattività uguale a quello che oggi è "GCConcurrency On";
LowLatency: Chiede al GC di intervenire molto più spesso ma cercando di impattare il meno possibile sulle performance dell'intera applicazione, questo porterà il GC probabilmente a non fare tutto il lavoro che si era prefissato ma ci restituisce il controllo nel più breve tempo possibile;
GC.Collect( generation, [Default | Force | Optimized] );
la novità è Opmized che lascia decidere al GC se sia effettivamente il caso di fare una Collection o meno.
Generics Performance
Non ci sono note particolare sulle performance legate ai Generics, i Generics potrebbero impattare su NGen e venir comunque jittati nel caso in cui il tipo non sia noto.
Reflection
Non è una "bad pratice" ma è una "expensive pratice", quindi è da dosare e usare con le pinze. Un ottimo trucco per velocizzare le operazioni nel caso di chiamate multiple (in un ciclo ad esempio) ad un metodo sullo stesso tipo è quello di ricavare il MethodRuntimeHandle dalla classe (MethodBase.MethodHandle) e quindi recuperare un riferimento al metodo all'interno del ciclo tramite il metodo MethodBase.GetMethodFromHandle(), questa caching dell'handle ci permette di evitare che reflection faccia tutte le volte tutta l'analisi del grafo alla ricerca di quello che ci serve compreso l'eventuale overhead della CAS.
Finalization
Il Dispose pattern, non aggiungo altro ci sono montagne di articoli al riguardo...
Multi Threading
Anche qui le solite cose che tutti dovremmo sapere a menadito: non suare Thread.Abort(), usare il ThreadPool, non usare Thread.Suspend() ma sistemi più sofisticati tipo locking, mutex, semafori etc..
NGen
Fondamentale che NGen venga eseguito sulla macchina di destinazione.
benefits:
- non c'è jitting durante lo startup;
- sharing: il codcie NGened è condivisibile attraverso più processi, ad esempio un assembly viene condiviso su più processi, uno scenario particolarmente adatto è l'uso di un applicazione via RDC;
Interessante è la possibilità di usare un sevizio per "NGennare" in background l'applicazione
Marshaling Performances, P/Invoke
La prima cosa da controllare è che ci siano il minor numero di roundtrip tra codice managed e codice unmanaged, è inoltre fondamentale usare un profiler per tracciare l'uso della memoria... è appena intervenuto Raff con una soluzione ad un problema... giustamente non ho capito... Raff troppo avanti! :-D
nel fx 2.0 è stato fatto un lavoro notevole per ottimizzare il marshaling dei dati e Claudio ci conferma che per i tipi di dati semplici le performance sono molto buone, quello a cui dobbiamo porre molta attenzione è il passaggio di strutture molto complesse.
Rebasing
L'uso di NGen fa si che l'assembly venga convertito in codice nativo e gli viene assegnato un base address, se durante il loading dell'assembly in quell'indirizzo in memoria c'è già qualcosa l'assembly deve essere rebased e si perdono tutti i benefici di NGen, un workaround è quello di impostare il base address direttamente in fase di compilazione, ma resta comunque un terno al lotto ;-)
.m
Labels:
Why not...
TechEd Developer - Robotics Studio
Sono tornato un po' prima dal mio bel giro per Barcellona e mi sono fiondato in una sessione che in realtà non mi interessa ma semplicemente mi incuriosisce... Microsoft Robotics Studio vediamo se capisco qualcosa :-D
Per ora mi sto annoiando... sta facendo un sacco di teoria di cui non ho le basi... poi il mio vicino di sedia si sta bellamente facendo gli affari mie spulciano il contenuto del mio desktop, della posta etc.. adesso gli tiro un destro se non la pianta :-D, mi sa che ha subodorato il rischio perchè se ne è andato... LOL
Ci rinuncio non so proprio nulla di automazione industriale e di tutte le problematiche ad essa connesse... peccato speravo in qualche demo fantasmagorica... ma nulla.
Aspettiamo Claudio Caldato che ci porterà nei meandri del CLR per ottimizzare le performance delle ns applicazioni.
.m
Per ora mi sto annoiando... sta facendo un sacco di teoria di cui non ho le basi... poi il mio vicino di sedia si sta bellamente facendo gli affari mie spulciano il contenuto del mio desktop, della posta etc.. adesso gli tiro un destro se non la pianta :-D, mi sa che ha subodorato il rischio perchè se ne è andato... LOL
Ci rinuncio non so proprio nulla di automazione industriale e di tutte le problematiche ad essa connesse... peccato speravo in qualche demo fantasmagorica... ma nulla.
Aspettiamo Claudio Caldato che ci porterà nei meandri del CLR per ottimizzare le performance delle ns applicazioni.
.m
Labels:
Why not...
TechEd Developer - WF Drop in clinic WD
Paul Andrew e Matt Winkler - Q&A Session
Ho fatto anche io la mia domanda :-D
- best practice to impletment "go-to", mutuata da un po' di elucubrazioni con Raffaele
Sulla lavagna per ora ci sono un sacco di domande la cosa si fa interessante...
Hosting designers vs building your own designer
Suggeriscono di costruire il ptoptio deisgner piuttosto che ostare quello fornito perchè è dev oriented e non end user oriented
XAML vs Code Behind
Se l'uso del solo XAML permette di persistere lo schema del workflow pressochè ovunque e di conseguenza di modificarlo molto facilmente non ci permette facilmente di benificiare di tutti i vantaggi del code behind uno su tutti le CodeActivity o le Custome Properties all'interno del Workflow
Migrating from exixting formats
Nulla di più semplice, si fa per dire. C'è la possibiolità di pluggare un proprio Loader per eseguire il parsing del proprio formato e costruire l'albero delle Activity
Dynamic updating existing and running Workflows
Sembra la cosa più facile di questa terra... ma non è proprio così comunque l'unico requisito è che il Workflow sia un "suspend state", c'è anche la possibilità di modificare via CodeDom del codice all'interno ad esempio di una CodeActivity... una nota importante è che le performance NON ci sono proprio, ma del resto stiamo facendo qualcosa di decisamente "tosto" ;-)
Custom Persistance Provider Service
Semplicemente suggeriscono di guardare gli esempi presenti nel Windows SDK
Scalbility with 100k instances running
Non è un problema perchè ci basta implementare una buona politica di persistenza quando il WF è on "idle state", il problema si pone se fossero tutti running ma comunque ci penserebbe il ThreadPool ad acccodarli in modo da non satuirare le risorse.
Se parliamo invece di scalabilità la cosa si fa un po' più tosta ma il problema si sposta sulla gestione dei messaggi in ingresso, è quindi possibile ad esempio avere un Front-End che fa poi dispatch dei messaggi in ingresso verso una batteria di server in load balancing che accedono tutti ad un Cluster di Sql Server per lostaorage implementando un proprio meccanismo di locking per controllare la concorrenza sugli eventualei WF running...
Compensation
Bell'esempio su come implementare ICompasatableActivity in una proprio Custom Activity per gestire il roolback in uno scerario si transazionale ma non basato su locking come invece è una transazione tradizionale
Go-To
Ritengono che la soluzione migliore sia quella di implemenatere un proprio tipo di WorkFlow, anche se una soluzione c'è usando uno "State Machine Workflow" che comunque non è la soluzione definitiva, all'interno del proprio tipo implementare delle Custom Activity che consentano di "saltare indietro" verso uno step precedente, certo che non è proprio una cosa banale ;-)
Molto ma molto interessante, bella questa sessione, è proprio un bel format.
.m
Ho fatto anche io la mia domanda :-D
- best practice to impletment "go-to", mutuata da un po' di elucubrazioni con Raffaele
Sulla lavagna per ora ci sono un sacco di domande la cosa si fa interessante...
Hosting designers vs building your own designer
Suggeriscono di costruire il ptoptio deisgner piuttosto che ostare quello fornito perchè è dev oriented e non end user oriented
XAML vs Code Behind
Se l'uso del solo XAML permette di persistere lo schema del workflow pressochè ovunque e di conseguenza di modificarlo molto facilmente non ci permette facilmente di benificiare di tutti i vantaggi del code behind uno su tutti le CodeActivity o le Custome Properties all'interno del Workflow
Migrating from exixting formats
Nulla di più semplice, si fa per dire. C'è la possibiolità di pluggare un proprio Loader per eseguire il parsing del proprio formato e costruire l'albero delle Activity
Dynamic updating existing and running Workflows
Sembra la cosa più facile di questa terra... ma non è proprio così comunque l'unico requisito è che il Workflow sia un "suspend state", c'è anche la possibilità di modificare via CodeDom del codice all'interno ad esempio di una CodeActivity... una nota importante è che le performance NON ci sono proprio, ma del resto stiamo facendo qualcosa di decisamente "tosto" ;-)
Custom Persistance Provider Service
Semplicemente suggeriscono di guardare gli esempi presenti nel Windows SDK
Scalbility with 100k instances running
Non è un problema perchè ci basta implementare una buona politica di persistenza quando il WF è on "idle state", il problema si pone se fossero tutti running ma comunque ci penserebbe il ThreadPool ad acccodarli in modo da non satuirare le risorse.
Se parliamo invece di scalabilità la cosa si fa un po' più tosta ma il problema si sposta sulla gestione dei messaggi in ingresso, è quindi possibile ad esempio avere un Front-End che fa poi dispatch dei messaggi in ingresso verso una batteria di server in load balancing che accedono tutti ad un Cluster di Sql Server per lostaorage implementando un proprio meccanismo di locking per controllare la concorrenza sugli eventualei WF running...
Compensation
Bell'esempio su come implementare ICompasatableActivity in una proprio Custom Activity per gestire il roolback in uno scerario si transazionale ma non basato su locking come invece è una transazione tradizionale
Go-To
Ritengono che la soluzione migliore sia quella di implemenatere un proprio tipo di WorkFlow, anche se una soluzione c'è usando uno "State Machine Workflow" che comunque non è la soluzione definitiva, all'interno del proprio tipo implementare delle Custom Activity che consentano di "saltare indietro" verso uno step precedente, certo che non è proprio una cosa banale ;-)
Molto ma molto interessante, bella questa sessione, è proprio un bel format.
.m
Labels:
Why not...
TechEd Developer - WF Rules Engine
Paul Andrew - WF PM
Inizia con una rapida introduzione sui concetti base legati a Rules, RuleSet e Policy per passare subito ad un Demo e poi introdurre e spiegare abbastanza nel dettaglio la possibilità di modificare il Workflow a runtime, Dynamic Update.
CAG - Condirtions Activity Group
Viene presentato come uno dei concetti più complessi di WF, la CAG è una sorta di contenitore di altre Activity controllato, nella sua esecuzione e nel suo ciclo di vita, da una serie di Rules. In effetti è tutto tranne che semplice... le Activity in essa contenute vengono eseguite, in maniera sequenziale, tutte e ognuna viene ripetuta fintanto che il suo stato non sia "true" (when), quindi non si esce dal ciclo (until) della CAG fintanto che tutte le Activity incluse non hanno dato esito positivo. Nella demo che ci propone viene usato come un potente sistema di validazione e gestione dell'input dell'utente.
Breve pausa commerciale presentando BizTalk server e vantandosi che il "Rules Engine" è totalmente basato su WF.... markettaro :-D
Demo sulle Policy: Le policy non sono altro che un contenitore di Rule che possono essere legate tra loro in svariati e potenti modi, producendo nell'insieme un risultato. Nella demo viene usato questo sistema per filtrare secondo un set di criteri (RuleSet) una base dati. E' molto interessante nello specifico viene usato per filtrare i voli aerei disponibili in un ipotetico sistema di prenotazione online, la policy viene valutata e alla fine ogni volo presente (che non è sgtato scartato dalla policy) ha uno score che determina quanto sia attinente con i criteri di ricerca. Non male.
Una considerazione su quello che ho appena visto: nulla ci vieta di fare tutto alla "vecchia" maniera, scrivendo cioè il ns bel codice, magari in un Assembly separato e caricandolo a runtime in modo da poter pluggare a caldo le modifiche, ma... WF diventa veramente tosto se pensiamo che possiamo dare il Designer all'utente finale e permettergli di gestire da solo tutta la logica. Potente! molto potente, si aprono scenari veramente interessanti. Certo gli scogli sono tanti soprattutto perchè WF è ancora molto acerbo, è "solo" un engine e gli strumenti che mette a disposizione oggi sono tutto tranne che end user friendly quindi il lavoro da fare per arrivare all'utente finale è tanto ma IMHO ci sono scenari in cui ne vale veramente la pena.
Dopo la "mazzata" (perchè stamattina sono veramente cotto) passiamo a qualcosa di più tosto... :-D esternalizzazione delle policy, cioè la possibilità di utilizzare il Rules Engine a prescindere da WF. Nella demo che stiamo vedendo c'è un'applicazione Windows Forms che edita un set di rules e le salva in un db e un WF che gira in un Servizio che legge le rules e le esegue e si aggiorna dinemanicamente secondo le modifiche apportate al RuleSet...
Molto ma molto bella la possibilità di persistere le "rules" ad esempio in un db...
.m
Inizia con una rapida introduzione sui concetti base legati a Rules, RuleSet e Policy per passare subito ad un Demo e poi introdurre e spiegare abbastanza nel dettaglio la possibilità di modificare il Workflow a runtime, Dynamic Update.
CAG - Condirtions Activity Group
Viene presentato come uno dei concetti più complessi di WF, la CAG è una sorta di contenitore di altre Activity controllato, nella sua esecuzione e nel suo ciclo di vita, da una serie di Rules. In effetti è tutto tranne che semplice... le Activity in essa contenute vengono eseguite, in maniera sequenziale, tutte e ognuna viene ripetuta fintanto che il suo stato non sia "true" (when), quindi non si esce dal ciclo (until) della CAG fintanto che tutte le Activity incluse non hanno dato esito positivo. Nella demo che ci propone viene usato come un potente sistema di validazione e gestione dell'input dell'utente.
Breve pausa commerciale presentando BizTalk server e vantandosi che il "Rules Engine" è totalmente basato su WF.... markettaro :-D
Demo sulle Policy: Le policy non sono altro che un contenitore di Rule che possono essere legate tra loro in svariati e potenti modi, producendo nell'insieme un risultato. Nella demo viene usato questo sistema per filtrare secondo un set di criteri (RuleSet) una base dati. E' molto interessante nello specifico viene usato per filtrare i voli aerei disponibili in un ipotetico sistema di prenotazione online, la policy viene valutata e alla fine ogni volo presente (che non è sgtato scartato dalla policy) ha uno score che determina quanto sia attinente con i criteri di ricerca. Non male.
Una considerazione su quello che ho appena visto: nulla ci vieta di fare tutto alla "vecchia" maniera, scrivendo cioè il ns bel codice, magari in un Assembly separato e caricandolo a runtime in modo da poter pluggare a caldo le modifiche, ma... WF diventa veramente tosto se pensiamo che possiamo dare il Designer all'utente finale e permettergli di gestire da solo tutta la logica. Potente! molto potente, si aprono scenari veramente interessanti. Certo gli scogli sono tanti soprattutto perchè WF è ancora molto acerbo, è "solo" un engine e gli strumenti che mette a disposizione oggi sono tutto tranne che end user friendly quindi il lavoro da fare per arrivare all'utente finale è tanto ma IMHO ci sono scenari in cui ne vale veramente la pena.
Dopo la "mazzata" (perchè stamattina sono veramente cotto) passiamo a qualcosa di più tosto... :-D esternalizzazione delle policy, cioè la possibilità di utilizzare il Rules Engine a prescindere da WF. Nella demo che stiamo vedendo c'è un'applicazione Windows Forms che edita un set di rules e le salva in un db e un WF che gira in un Servizio che legge le rules e le esegue e si aggiorna dinemanicamente secondo le modifiche apportate al RuleSet...
Molto ma molto bella la possibilità di persistere le "rules" ad esempio in un db...
.m
Labels:
Why not...
TechEd Developer - Workflow Foundation
Paul Andrew - WF Program Manager All'ultimo abbiamo, su consiglio di Raffaele, Stefano ed io, deciso di switchare verso WF al posto della sessione white board su WCF perchè l'argomento e lo speaker promettono molto bene!
L'agenda sembra confermare la nostra scelta ;-)
La sessione si è poi svolta seguendo un profilo abbastanza basso mentre ci aspettavamo qualcosa di meno entry level, è comunque stata utile e istruttiva visto che di WF so comunque poco!
.m
L'agenda sembra confermare la nostra scelta ;-)
La sessione si è poi svolta seguendo un profilo abbastanza basso mentre ci aspettavamo qualcosa di meno entry level, è comunque stata utile e istruttiva visto che di WF so comunque poco!
.m
Wednesday, November 8, 2006
TechEd Developer - Managing WCF Services
Shy Choen Shall we start? ;-) una breve, proprio breve!, introduzione a cosa è WCF e alla sua architettura A.B.C.... per poi passare al sodo partendo dagli strumenti di configurazione che ci vengono messi a disposizione.
Siamo appena partiti con la demo e l'applicazione che ci sta facendo vedere sembra decisamente complessa per una demo quindi posso immaginare che non deluderà le mie aspettative ;-)
Sta sfruttando la demo per mostrare tutte le possibilità di monitoring che WCF ci offre, siano esse via WMI, via Performance Counters o via il più classico Tracing & Logging, in relazione proprioa quest'ulrima ci sta mostrando le potenzialità che WCF offre builtin per tracciare tutto lo scambio di messaggi tra server e client(s) senza dover mettere in piedi nessun arzigogolato sistema di sniffing che comunque altera l'ambiente e rischia di falsare l'analisi.
La sessione si conclude con una panoramica approfondita su quelle che sono le best pratcice per realizzare un'infrastruttura WCF manutenibile.
Sessione molto interessante, anche se mi sarei aspettato più codice, ma io sono un code addicted ;-), quindi va bene così!
Adesso passiamo ad una Jam Session (whiteboard) sempre su WCF con lo stesso speaker ;-)
ma prima il feedback perchè un iPod mica mi schifo :-D
.m
Siamo appena partiti con la demo e l'applicazione che ci sta facendo vedere sembra decisamente complessa per una demo quindi posso immaginare che non deluderà le mie aspettative ;-)
Sta sfruttando la demo per mostrare tutte le possibilità di monitoring che WCF ci offre, siano esse via WMI, via Performance Counters o via il più classico Tracing & Logging, in relazione proprioa quest'ulrima ci sta mostrando le potenzialità che WCF offre builtin per tracciare tutto lo scambio di messaggi tra server e client(s) senza dover mettere in piedi nessun arzigogolato sistema di sniffing che comunque altera l'ambiente e rischia di falsare l'analisi.
La sessione si conclude con una panoramica approfondita su quelle che sono le best pratcice per realizzare un'infrastruttura WCF manutenibile.
Sessione molto interessante, anche se mi sarei aspettato più codice, ma io sono un code addicted ;-), quindi va bene così!
Adesso passiamo ad una Jam Session (whiteboard) sempre su WCF con lo stesso speaker ;-)
ma prima il feedback perchè un iPod mica mi schifo :-D
.m
TechEd Developer - Garbage Collection
Claudio Caldato - CLR Program Manager Introduzione sui performance counters, sul loro uso e su alcune delle loro peculiarità, siamo poi passati alle principali cause che portano ad una OutOfMemoryException, le cause per ora sono le cause interne, sempre per colpa del ns codice, ma ci sta spiegando cosa succede internamente al fx.
Siamo poi passati agli strumenti necessari per affrontare questi problemi e siamo inevitabilmewnte ricaduti su WinDbg e in generale sui Debugging Tools per Windows, stiamo quindi rivedendo per la 3 volta le stesse cose ma la cosa più interessante è che per la 3 volta le stiamo affrontando da un punto di vista diverso, in questo caso ci stiamo focalizzando sulla memoria e su tutti gli "iusses" ad essa legati sempre nell'ottica di capire come ottimizzare e assecondare al meglio la Garbage Collection...
Molto interessante la possibilità di impostare dei break point in WinDbg. La cosa può essere fatta con il comando "bp" passandogli una serie di parametri (tutt'altro che semplice) che permettono di specificare dove e in che condizioni fermarsi.
Passiamo poi alla casistica in cui i problemi siano legati ad una elevata frammentazione della memoria o al consumo di cicli CPU dovuto ad un'eccessivo lavoro che il GC deve fare, generalmente questo secondo scenario è dovuto ad un elevato numero di Collections in Generation 2 o ad un ciclo di Colletion della Generation 2 troppo costoso.
Ci ha poi mostrato un interessante uso dei Pperformance Counter per cercare di capire quanto tempo spende la ns applicazione per eseguire le collection delle generazioni, questo è estremamente utile in tutti quie casi in cui si ha bisogno di tenere strettamente sotto controllo l'applicazione in quegli scenari simil "real time" o "soft real time" come li ha definiti Claudio.
Durante la Q&A ha poi buttato li una delle novità di Orcas che permetteranno di controllare la modalità con cui il GC interviene, ad esempio chiedendo al GC di non intervenire per un certo "time frame" o chiedendo al GC di intervenire (similmente a GC.Collect()) ma lasciando al GC l'onere di decidere se sia effettivamente necessario intervenire, cosa che non avviene adesso perchè una chiamata a GC.Collect() porta ad una Collection immediata cosa che non è detto sia sempre necessaria.
Che dire... giornatona oggi, sono veramente soddisfatto, adesso ci (stavolta con Stefano Mostarda) aspettano altre 2 "deep sessions" su WCF che spero non tradiscano le aspettative, ma lo speaker che è lo stesso di ieri e quindi promette bene!
Stay tuned ;-)
.m
Siamo poi passati agli strumenti necessari per affrontare questi problemi e siamo inevitabilmewnte ricaduti su WinDbg e in generale sui Debugging Tools per Windows, stiamo quindi rivedendo per la 3 volta le stesse cose ma la cosa più interessante è che per la 3 volta le stiamo affrontando da un punto di vista diverso, in questo caso ci stiamo focalizzando sulla memoria e su tutti gli "iusses" ad essa legati sempre nell'ottica di capire come ottimizzare e assecondare al meglio la Garbage Collection...
Molto interessante la possibilità di impostare dei break point in WinDbg. La cosa può essere fatta con il comando "bp" passandogli una serie di parametri (tutt'altro che semplice) che permettono di specificare dove e in che condizioni fermarsi.
Passiamo poi alla casistica in cui i problemi siano legati ad una elevata frammentazione della memoria o al consumo di cicli CPU dovuto ad un'eccessivo lavoro che il GC deve fare, generalmente questo secondo scenario è dovuto ad un elevato numero di Collections in Generation 2 o ad un ciclo di Colletion della Generation 2 troppo costoso.
Ci ha poi mostrato un interessante uso dei Pperformance Counter per cercare di capire quanto tempo spende la ns applicazione per eseguire le collection delle generazioni, questo è estremamente utile in tutti quie casi in cui si ha bisogno di tenere strettamente sotto controllo l'applicazione in quegli scenari simil "real time" o "soft real time" come li ha definiti Claudio.
Durante la Q&A ha poi buttato li una delle novità di Orcas che permetteranno di controllare la modalità con cui il GC interviene, ad esempio chiedendo al GC di non intervenire per un certo "time frame" o chiedendo al GC di intervenire (similmente a GC.Collect()) ma lasciando al GC l'onere di decidere se sia effettivamente necessario intervenire, cosa che non avviene adesso perchè una chiamata a GC.Collect() porta ad una Collection immediata cosa che non è detto sia sempre necessaria.
Che dire... giornatona oggi, sono veramente soddisfatto, adesso ci (stavolta con Stefano Mostarda) aspettano altre 2 "deep sessions" su WCF che spero non tradiscano le aspettative, ma lo speaker che è lo stesso di ieri e quindi promette bene!
Stay tuned ;-)
.m
TechEd Developers - .NET Debugging Facilities
Un'altra sessione sul debug, lo speaker iniza dicendo che se si è seguita la sessione di Ingo questa è più o meno una replica... ma dopo circa mezz'ora direi che non è per nulla così.
E' stata fatta una panoramica più introduttiva rispetto a quella che ha fatto Ingo Rammer, quindi per ora un po' più entry level, ma staimo sempre parlando di production/post mortem debug quindi definirla entry level è comunque un po' limitante.
L'unica critica che mi sento di fare, organizzativa, è che sarebbe stato meglio scambiare temporalmente le 2 sessioni, perchè questa è la base per quella di Ingo Rammer che ha dato per scontate tutta una serie di cose che invece qui stiamo affrontando... come ad esempio la configurazione degli strumenti, i concetti base legati ai debug symbols e via dicendo...
Una nota curisoa, lo speaker è troppo inglese... vi lascio immaginare quindi la parlata che è troppo da Sherlock Holmes... e le battute che sono troppo inglesi :-D
.m
we love barzaus
E' stata fatta una panoramica più introduttiva rispetto a quella che ha fatto Ingo Rammer, quindi per ora un po' più entry level, ma staimo sempre parlando di production/post mortem debug quindi definirla entry level è comunque un po' limitante.
L'unica critica che mi sento di fare, organizzativa, è che sarebbe stato meglio scambiare temporalmente le 2 sessioni, perchè questa è la base per quella di Ingo Rammer che ha dato per scontate tutta una serie di cose che invece qui stiamo affrontando... come ad esempio la configurazione degli strumenti, i concetti base legati ai debug symbols e via dicendo...
Una nota curisoa, lo speaker è troppo inglese... vi lascio immaginare quindi la parlata che è troppo da Sherlock Holmes... e le battute che sono troppo inglesi :-D
.m
we love barzaus
Labels:
Why not...
TechEd Developers - folclore
Mi ricollego a questo post di Lorenzo solo per dire che con Raff le cose si fanno toste sin dalla mattina presto quindi ci saimo buttati alla grande :-D
Advenced .NET Debugging alla mattina presto, un risveglio come si deve! :-D
.m
we love barzaus
Advenced .NET Debugging alla mattina presto, un risveglio come si deve! :-D
.m
we love barzaus
TechEd Developer - Advanced .NET Debugging
Ore 8.50 un po' cotti ma ci siamo... siamo in prima fila davanti a Ingo Rammer (non che ci sia da vantarsi ;-) ) in attesa dell'inizio della sesssione...
Il titolo, il livello e la location (una saletta minore) secondo me promettono bene! stiamo a vedere... e a sentire :-D
Iniziato, per ora non c'è che dire promette un gran bene! Siamo partiti con WinDbg... e la strada è tutta in salita :-D
Ok, abbiamo aggiunto a WinDbg le estensioni di SOS (son of strike) veramente togo ;-)
Bene sta introducendo MDbg che è un debugger da command line totalmente managed, fatta una rapida ma esaustiva carrellata su Mdbg Ingo è passato a Global Flags uno strumento che permette di "infilare" un debugger prima dell'avvio di un eseguibilee quindi ad esempio debuggare l'avvio di un Servizio per windows, molto bella la possibilità di avviare WinDbg come server tcp e quindi attacchare un'altra istanza di WinDbg... in questo modo è possibile debuggare anche servizi che non girano come LocalSystem o nel caso in cui non si voglia/possa permettere al servizio di interagire con il desktop (cosa comunque deprecata).
Siamo appena entrati in un campo veramente interessante l'analisi dei Memory Leak tramite WinDbg, non è certo un'operazione User Friendly ma è sicuramente potentissima, mi riprometto di stressare all'infinito Raffaele, che è qui di fianco a me, perchè faccia una sessione sul debug ad un workshop UGI è un'argomento veramente di importanza vitale per un dev.
Ok, l'argomento si fa tosto! Siamo alla creazione di un memory dump... per poter fare post mortem debug, lasciatemelo dire una vera figata!
Ingo ha anche introdotto un nuovo strumento (prodotto da loro) che si chiama SOS Assist che altro non è che un front-end a WinDbg che rende un po' meno painfull l'uso proprio di WinDbg.
Sessioni come questa valgono un TechEd! veramente spettacolare!
.m
Il titolo, il livello e la location (una saletta minore) secondo me promettono bene! stiamo a vedere... e a sentire :-D
Iniziato, per ora non c'è che dire promette un gran bene! Siamo partiti con WinDbg... e la strada è tutta in salita :-D
Ok, abbiamo aggiunto a WinDbg le estensioni di SOS (son of strike) veramente togo ;-)
Bene sta introducendo MDbg che è un debugger da command line totalmente managed, fatta una rapida ma esaustiva carrellata su Mdbg Ingo è passato a Global Flags uno strumento che permette di "infilare" un debugger prima dell'avvio di un eseguibilee quindi ad esempio debuggare l'avvio di un Servizio per windows, molto bella la possibilità di avviare WinDbg come server tcp e quindi attacchare un'altra istanza di WinDbg... in questo modo è possibile debuggare anche servizi che non girano come LocalSystem o nel caso in cui non si voglia/possa permettere al servizio di interagire con il desktop (cosa comunque deprecata).
Siamo appena entrati in un campo veramente interessante l'analisi dei Memory Leak tramite WinDbg, non è certo un'operazione User Friendly ma è sicuramente potentissima, mi riprometto di stressare all'infinito Raffaele, che è qui di fianco a me, perchè faccia una sessione sul debug ad un workshop UGI è un'argomento veramente di importanza vitale per un dev.
Ok, l'argomento si fa tosto! Siamo alla creazione di un memory dump... per poter fare post mortem debug, lasciatemelo dire una vera figata!
Ingo ha anche introdotto un nuovo strumento (prodotto da loro) che si chiama SOS Assist che altro non è che un front-end a WinDbg che rende un po' meno painfull l'uso proprio di WinDbg.
Sessioni come questa valgono un TechEd! veramente spettacolare!
.m
Labels:
Why not...
Tuesday, November 7, 2006
TechEd Developer - ADFS...
Sessione notevole, Keith Brown (Pluralsight.com) che introduce, e approfondisce, A.ctive D.irectory F.ederation S.ervices che è una novità introdotta con Windows Server 2003 R2.
In soldoni è un eccezzionale sistema per "trustare" (permettetemi il termine) sistemi di autenticazione diversi e geograficamente dislocati, permette l'interoperabilità tra sistemi eterogenei perchè si basa sugli standard WS-*
.m
In soldoni è un eccezzionale sistema per "trustare" (permettetemi il termine) sistemi di autenticazione diversi e geograficamente dislocati, permette l'interoperabilità tra sistemi eterogenei perchè si basa sugli standard WS-*
.m
TechEd Developer - Intro to WCF
ok, nuova sessione: Introduzione a Windows Comunication Foundation, siamo partiti bene, lo speacker ha detto che non saprebbe come fare una sessione di livello 200 su WCF quindi si lancerà in esempi fornendo tanto codice, vediamo come va!
Per ora sta facedno la classica intro: ABC: Address, Binding, Contract, ma questa parte comunque mi interessa perchè so veramente poco di WCF.
Abbiamo iniziato con le demo, sta costruendo il classico "Hello World" ma lo sta facendo sviscerando bene tutti i punti cruciali...
.m
Per ora sta facedno la classica intro: ABC: Address, Binding, Contract, ma questa parte comunque mi interessa perchè so veramente poco di WCF.
Abbiamo iniziato con le demo, sta costruendo il classico "Hello World" ma lo sta facendo sviscerando bene tutti i punti cruciali...
.m
TechEd Developer - VSIP Partnership Program
Giornata un po' sottotono e per ora anche un po' sotto le aspettative, io e Raff stiamo seguendo una sessione sull'estensibilità di Visual Studio 2005 ma per ora a parte un paio di demo carine, abbiamo visto ben poco di interessante, almeno per me, speravo in molto più codice! invece per ora slide e slide e ancora slide... anche un po' troppo commerciali... anche se è doveroso sottolineare che la sessione è di livello 200.
Provvederò a dare il mio feedback ;-)
.m
Provvederò a dare il mio feedback ;-)
.m
Labels:
Why not...
TechEd Developers - Key Note (aka "chinotto")
Non c'è molto da dire, molto scenografica me anche altrettanto commerciale ed istituzionale... quindi direi che per un Dev definirla interessante è difficile, un po' di demo queste più simpatiche ma comunque sempre "end user oriented". Adesso inizia il vero TechEd, Lorenzo e Raff sono già pronti per la loro prima sessione all'ATE, io me la godo fino all'ora di pranzo gironzolando per gli stand e poi mi butto nelle prime sessioni, ho già pianificato quasi tutta la settimana... vediamo che succede! :-D
.m
.m
Monday, November 6, 2006
TechEd Developers - Pre Conference
Finalmente ci siamo, abbiamo appena finito di seguire, io e Raff, la pre conference.
Stamattina abbiamo scelto di la track relativa a Windows Workflow Foundation tenuta da Ingo Rammer e Christian Weyer, direi molto interessante. All'inizio avevo paura potesse trattarsi di una cosa un po' istituzionale orientata al commerciale invece Chirstian è partito dicendo che avevano solo 7 slide in 2 per ben 4 sessioni da un'ora e mezza... :-D niente male.
Alla fine abbiamo visto un sacco di codice, molto entry level, ma comunque un sacco di codice... che male non fa mai!
E' la seconda volta che ascolto delle sessioni tenute da Rammer e stavolta il mio cervello si è fasato decisamente più velocemente sul suo inglese che ha un pesantissimo accento tedesco... se poi ci mettiamo che ha il brutto vizio di parlare velocemente e mangiarsi le parole... :-D, Christian invece è decisamente semplice da seguire.
Entrambi si sono dimostrati decisamente disponibili e preparati, questo lo davo per scontato, e hanno saputo tener alta l'attenzione della platea.
Bene, direi un ottimo inizio, adesso "los tres caballeros" si preparano per la MVP Dinner :-D
.m
Stamattina abbiamo scelto di la track relativa a Windows Workflow Foundation tenuta da Ingo Rammer e Christian Weyer, direi molto interessante. All'inizio avevo paura potesse trattarsi di una cosa un po' istituzionale orientata al commerciale invece Chirstian è partito dicendo che avevano solo 7 slide in 2 per ben 4 sessioni da un'ora e mezza... :-D niente male.
Alla fine abbiamo visto un sacco di codice, molto entry level, ma comunque un sacco di codice... che male non fa mai!
E' la seconda volta che ascolto delle sessioni tenute da Rammer e stavolta il mio cervello si è fasato decisamente più velocemente sul suo inglese che ha un pesantissimo accento tedesco... se poi ci mettiamo che ha il brutto vizio di parlare velocemente e mangiarsi le parole... :-D, Christian invece è decisamente semplice da seguire.
Entrambi si sono dimostrati decisamente disponibili e preparati, questo lo davo per scontato, e hanno saputo tener alta l'attenzione della platea.
Bene, direi un ottimo inizio, adesso "los tres caballeros" si preparano per la MVP Dinner :-D
.m
Subscribe to:
Posts (Atom)