lunedì 26 marzo 2007
Invidioso del plugin di Trix per YubNub, stavo quasi per iniziare il mio ennesimo progetto per un tool che facesse una cosa simile per ie.
Sono incappato in They're Alive! che una volta selezionata un testo in una pagina web, fornisce un menu da cui è possibile lanciare una nuova finestra del browser con un url creato in base alla selezione.
Non è proprio la stessa cosa, ma mi risparmierà qualche nottata ;-)
martedì 6 marzo 2007
Dovendo fare del performance tuning, risulta particolarmente interessante usare il process explorer (pe) per verificare lo stack trace dei processi in esecuzione.
Selezionando un processo in pe viene aperta una finestra con alcuni tab. Usando il tab Threads viene visualizzata la lista dei thread (ordinabili per nome, CPU e CSwitch).
Cliccando su un thread viene visualizzata la stack trace di quel thread in quel momento.
Per rendere più leggibile tale stack trace bisogna configurare la directory dove pe ricerca i symbol.
Installare l'ultima versione dei debugging tools.
Sotto il menu Options->Configure Symbols impostare il path delle dbghelp.dll (appena installata)
es: C:\Program Files\Debugging Tools for Windows\DbgHelp.dll
Configurare il percorso dei simboli. La prima voce è la directory dove risiedono i nostri pdb, la seconda dove ci sono i simboli di windows (che vengono scaricati con i debuggin tools e l'ultima l'url dove andare a ricercare i simboli in caso non siano ancora presenti (se notate dei blocchi del process explorer probabilmente stà scaricando i simboli necessari):
es: D:\MyPdbDir;SRV*C:\ProcessExplorerNt\Symbols\SymSrv*http://msdl.microsoft.com/download/symbols
Visualizzando lo stack trace è quindi possibile 'a campione' vedere cosa stà facendo il processo in oggetto. Solitamente si nota che una particolare stack trace ricorre più volte, andando quindi ad analizzare il caso riusciremo (si spera) ad ottimizzare quel pezzo di applicazione.
venerdì 1 dicembre 2006
Ho visto la richiesta dell'obolo a UGI. Non mi sono chiari gli scopi di tale richiesta (giuro).
C'è qualcuno che mi può illuminare?
Carlo
venerdì 21 aprile 2006
Ciao,
un paio di tips collegati al post di Luca
Visto che ci ho perso un po' di tempo ....
Per specificare il nome del tag degli elementi all'interno di "actions" nella classe in cui si implementa la collezione "MyActionCollection" bisogna specificare il nome con la proprietà ElementName.
Es. se volessimo mettere un tag "pippo" (evviva la fantasia)
Altra chicca poco documentata se vogliamo specificare la configurazione in un file separato definiamo la configSection in maniera usuale, ma al posto di inserire l'xml corrispondente direttamente nel app.config o web.config mettiamo un 'placeholder' con l'attributo configSource che ha come valore il nome del file.
es:
martedì 7 febbraio 2006
Interessante sito per sapere tutto (o quasi) su fusion e security in .Net.
Scritto per la 1.1 ha degli aggiornamenti significativi per la 2.0.
http://www.grimes.demon.co.uk/workshops/index.htm
lunedì 16 gennaio 2006
Dopo un bel po' di tempo Pablo ha pubblicato i demo del PDC (rivisti)
http://blogs.msdn.com/dataaccess/archive/2006/01/09/510083.aspx
lunedì 28 novembre 2005
Casualmente ho trovato una update (
http://sourceforge.net/project/shownotes.php?release_id=374130&group_id=96589) su source forge (purtroppo non c'è come per altri programmi la segnalazione automatica).
lunedì 7 novembre 2005
lunedì 24 ottobre 2005
Nelle scorse settimane ho discusso sull'opportunità o meno di far passare tutte le chiamate al SOS (Service Oriented Server ;-)) attraverso un unico servizio (per intenderci un asmx) che invia il messaggio al servizio corretto in base al contenuto.
Venendo da un modo di applicazioni n-tier, questo paradigma non mi è molto congeniale.
Una delle principali problematiche che vedo sono legate alla facilità con cui uno sviluppatore riesce a 'trovare' i servizi che gli servono per implementare una determinata funzionalità (tale concetto lo riassumo come discoverability, che mi sembra rendere bene l'idea, ma non è forse neanche inglese!).
Averli in un asmx raggruppati per tipologie coerenti facilita molto in contrasto con doverli andare a ricercare in una qualche sorta di metabase.
Chiaramente la strada maestra sarebbe quella di avere un coordinatore (analista?) che scriva della documentazione e degli sviluppatori che la leggano....nessuno è perfetto!
L'altra è legata agli strumenti che uno sviluppatore deve avere per creare i contratti. Creare un asmx è banale, creare un sistema per censire i 'contratti' in un metabase è già più difficile.
Ho trovato un articolo di Rocky Lhotka http://www.theserverside.net/articles/showarticle.tss?id=SOAVersioningCovenant" (Barbieri Lorenzo vedi che anch'io mi stò impegnando sulle regole dell'usabilità specialmente sulla 4 ;-) )
che parla di questi argomenti, che mi ha chiarito un po' le motivazioni di ragionare per covenant (patti) in contrapposizione ai servizi.
Riassumendo e semplificando (da un punto di vista non troppo SOA) dice che anche per i servizi dovrebbero esserci dei meccanismi simili agli overload dei metodi. Questo per semplificare l'estensibilità dei metodi.
In effetti se cerchiamo di esporre un metodo con degli overload in un asmx viene ritornato un errore quando andiamo a recuperare il wsdl del servizio.
Parlando del servizio unico, lui lo sconsiglia proprio per i discorsi di 'discoverability'.
Lhotka dice anche di aver richiesto al team di Indigo il supporto nell'IDE di tali feature....devo ancora riuscire a installare WCF per capire come si relazionano i data contract con questi discorsi.
giovedì 20 ottobre 2005
Alcuni prodotti (anche per .net 2.0) per skinning delle winform....
DotNetSkin
IrisSkin
http://www.stardock.com/