giovedì 22 novembre 2012
IBM AIX: Java process size monitoring
http://javaeesupportpatterns.blogspot.ie/2012/11/ibm-aix-java-process-size-monitoring.html
venerdì 16 novembre 2012
Loggare Request e Response nei WebServices WCF
Avete mai avuto la necessità di loggare la Request e la Response del vostro WebServiceClient fatto con WCF?
Io purtroppo, si, ed ho scoperto con mio sommo disappunto che non esiste una maniera semplice, tipo un evento a cui potersi agganciare.
Ad un certo punto ho anche perso la speranza che si potesse fare, e che si dovesse capire cosa passa solo frapponendo un proxy nel mezzo.
Voi mi direte, ma non hai il wsdl da cui creare il proxy, perché devi capire cosa passa? Lavorate per mezza giornata con le pubbliche amministrazioni e vi accorgerete che i wsdl sono una cosa abbastanza aleatoria...
Comunque, pensando solo agli aspetti meramente tecnici della questione, vediamo come si può fare a sniffare Request e Response HTML
Il trucco sta tutto nella classe IEndpointBehavior. In pratica esiste un meccanismo (molto sofisticato, devo dire) per cui ad un WebServiceClient si possono agganciare dei comportamenti custom a runtime.
Nel nostro caso ci interessa gestire i comportamenti lato client, quindi andremo ad implementare il metodo ApplyClientBehavior
Devo dire che il meccanismo, se pur complesso, è molto ben fatto, permettendo di customizzare il WebService fino a stravolgerlo totalmente.
Credits: Per risolvere il problema sono partito da questo articolo.
Io purtroppo, si, ed ho scoperto con mio sommo disappunto che non esiste una maniera semplice, tipo un evento a cui potersi agganciare.
Ad un certo punto ho anche perso la speranza che si potesse fare, e che si dovesse capire cosa passa solo frapponendo un proxy nel mezzo.
Voi mi direte, ma non hai il wsdl da cui creare il proxy, perché devi capire cosa passa? Lavorate per mezza giornata con le pubbliche amministrazioni e vi accorgerete che i wsdl sono una cosa abbastanza aleatoria...
Comunque, pensando solo agli aspetti meramente tecnici della questione, vediamo come si può fare a sniffare Request e Response HTML
Il trucco sta tutto nella classe IEndpointBehavior. In pratica esiste un meccanismo (molto sofisticato, devo dire) per cui ad un WebServiceClient si possono agganciare dei comportamenti custom a runtime.
Nel nostro caso ci interessa gestire i comportamenti lato client, quindi andremo ad implementare il metodo ApplyClientBehavior
namespace Utility.Behavior
{
public class ClientTraceBehavior : IEndpointBehavior
{
public void AddBindingParameters(ServiceEndpoint endpoint, System.ServiceModel.Channels.BindingParameterCollection bindingParameters)
{
//nop
}
public void ApplyClientBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.ClientRuntime clientRuntime)
{
clientRuntime.MessageInspectors.Add(new ClientTraceExtension());
}
public void ApplyDispatchBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.EndpointDispatcher endpointDispatcher)
{
//nop
}
public void Validate(ServiceEndpoint endpoint)
{
//nop
}
}
}
Come si vede nell'esempio abbiamo aggiunto ai MessageInspectors del client un oggetto ClientTraceExtension, che implementa l'interfaccia IClientMessageInspector
Questo oggetto contiene gli eventi BeforeSendRequest e AfterReceiveReply che, come dicono i nomi, vengono chiamati prima di inviare la Request e dopo aver ricevuto la Response.
namespace Utility.Behavior
{
///
/// SOAP Extension that traces the SOAP request and SOAP response
///
///
public class ClientTraceExtension : IClientMessageInspector
{
private static string xmlRequest;
private static string xmlResponse;
public static string XmlRequest {
get { return xmlRequest; }
}
public static string XmlResponse
{
get { return xmlResponse; }
}
public void AfterReceiveReply(ref System.ServiceModel.Channels.Message reply, object correlationState)
{
xmlResponse = reply.ToString();
}
public object BeforeSendRequest(ref System.ServiceModel.Channels.Message request, System.ServiceModel.IClientChannel channel)
{
xmlRequest = request.ToString();
return null;
}
}
}
Manca solo un passo perché tutto funzioni: far scattare il meccanismo. Basta aggiungere il behaviour all'instanza del nostro client.ClientWs client = new ClientWs(); client.Endpoint.Behaviors.Add(new ClientTraceBehavior());//adds the behaviorQuindi, se vorremo loggare , ci basterà farlo subito dopo aver chiamato il motodo del client, visto che ClientTraceExtension.XmlRequest e ClientTraceExtension.XmlResponse sono statici.
client.callWebMethod();
System.Console.WriteLn("Request: " + ClientTraceExtension.XmlRequest);
System.Console.WriteLn("Response: " + ClientTraceExtension.XmlResponse);
Et Voilà!Devo dire che il meccanismo, se pur complesso, è molto ben fatto, permettendo di customizzare il WebService fino a stravolgerlo totalmente.
Credits: Per risolvere il problema sono partito da questo articolo.
lunedì 22 ottobre 2012
Mono 3 is out
Programmer World (@ProgrammerWorld) ha twittato alle 8:00 p. on lun, ott 22, 2012: Mono 3.0 is out http://t.co/lpWQX0nS (https://twitter.com/ProgrammerWorld/status/260440498102218752) Scarica l'app ufficiale di Twitter su https://twitter.com/download
venerdì 5 ottobre 2012
lunedì 3 settembre 2012
Cosa ha ucciso il desktop Linux
Miguel de Icaza, uno dei padri del progetto GNOME, sotiene in questo articolo che il Desktop Linux sia morto.
Secondo lui le ragioni sono 2:
"First dimension: things change too quickly, breaking both open source and proprietary software alike; (b) incompatibility across Linux distributions."
In una nota, fatta qualche giorno dopo l'articolo, Miguel precisa che, fondamentalmente, quello che voleva dire era che Linux ha perso l'occasione di diventare un sistema consumer, perché le sue specifiche non sono abbastanza durevoli nel tempo da permettere alle aziende di creare prodotti che durino nel tempo
("[...] we lost the chance of becoming a mainstream consumer OS."), cosa che invece ha fatto Apple con OSX
Devo dire che capisco le sue motivazioni, anche se una gran parte della colpa non può fare altro che imputarla a se stesso (GNOME e le GTK+ sono figli suoi), ma d'altronde in un sistema libero ognuno fa quel che gli pare, e non quello che lo fa guadagnare.
Le società che cercano di trarre profitto dai sistemi Linux Desktop, Canonical prima di tutte, non hanno cattive rendite (circa 30 milioni di $ nel 2009), ma ovviamente sviluppano quelle parti di prodotto che servono a loro (Unity nel caso di Canonical)
Miguel ha fatto una scelta diversa, ha continuato a portare avanti lo sviluppo di Mono in Xamarin. Se veramente pensa che la strategia Apple sia vincente (partire da una base open e creare un prodotto custom), perché non si è fatto assumere da Canonical o RedHat per sviluppare il miglior sistema Desktop Unix-based? Anche perché, e qui sto esprimendo un'opinione del tutto personale, non mi sembra che Mono si sia radicato in maniera così massiccia da essere uno standard de-facto.
Secondo lui le ragioni sono 2:
"First dimension: things change too quickly, breaking both open source and proprietary software alike; (b) incompatibility across Linux distributions."
In una nota, fatta qualche giorno dopo l'articolo, Miguel precisa che, fondamentalmente, quello che voleva dire era che Linux ha perso l'occasione di diventare un sistema consumer, perché le sue specifiche non sono abbastanza durevoli nel tempo da permettere alle aziende di creare prodotti che durino nel tempo
("[...] we lost the chance of becoming a mainstream consumer OS."), cosa che invece ha fatto Apple con OSX
Devo dire che capisco le sue motivazioni, anche se una gran parte della colpa non può fare altro che imputarla a se stesso (GNOME e le GTK+ sono figli suoi), ma d'altronde in un sistema libero ognuno fa quel che gli pare, e non quello che lo fa guadagnare.
Le società che cercano di trarre profitto dai sistemi Linux Desktop, Canonical prima di tutte, non hanno cattive rendite (circa 30 milioni di $ nel 2009), ma ovviamente sviluppano quelle parti di prodotto che servono a loro (Unity nel caso di Canonical)
Miguel ha fatto una scelta diversa, ha continuato a portare avanti lo sviluppo di Mono in Xamarin. Se veramente pensa che la strategia Apple sia vincente (partire da una base open e creare un prodotto custom), perché non si è fatto assumere da Canonical o RedHat per sviluppare il miglior sistema Desktop Unix-based? Anche perché, e qui sto esprimendo un'opinione del tutto personale, non mi sembra che Mono si sia radicato in maniera così massiccia da essere uno standard de-facto.
lunedì 16 luglio 2012
lunedì 9 luglio 2012
MongoDb, ovvero che bello loggare
Sono mesi che rigiro un'idea in testa, che cerco di capire che funzione possano avere i NoSQL database.
Mi dico che, più o meno, un dato che viene salvato sia sempre strutturato, tutt'al più si può ovviare con un bel campo text o blob se si vogliono inserire informazioni non strutturate.
Poi un giorno arriva una necessità: monitorare gli accessi ad un particolare servizio, sapere chi ti sta chiamando, con quale frequenza. Poter insomma fare un po' di statistiche.
Facile, dico io, basta loggare. Eh si, e dove, su files di testo? E poi come aggregare i dati disaggregati?
Allora in una tabella: nooo, troppo rigida la struttura, in questo caso ci vuol roba duttile, si devono poter mescolare le pere con le mele.
E la scelta finisce sui NoSQL Database, dopo aver scoperto che anche Amazon li usa per il logging.
In particolare io ho usato MongoDb, per il fatto che mi sembra abbastanza maturo come prodotto, semplice da installare e gestire e con un livello accettabile di documentazione.
Devo dire che ha reso veramente semplice avere statistiche, anche perché c'è la possibilità di aggregare dati in tempo reale (funzioni di map/reduce), in modo sia full che incrementale.
Mi dico che, più o meno, un dato che viene salvato sia sempre strutturato, tutt'al più si può ovviare con un bel campo text o blob se si vogliono inserire informazioni non strutturate.
Poi un giorno arriva una necessità: monitorare gli accessi ad un particolare servizio, sapere chi ti sta chiamando, con quale frequenza. Poter insomma fare un po' di statistiche.
Facile, dico io, basta loggare. Eh si, e dove, su files di testo? E poi come aggregare i dati disaggregati?
Allora in una tabella: nooo, troppo rigida la struttura, in questo caso ci vuol roba duttile, si devono poter mescolare le pere con le mele.
E la scelta finisce sui NoSQL Database, dopo aver scoperto che anche Amazon li usa per il logging.
In particolare io ho usato MongoDb, per il fatto che mi sembra abbastanza maturo come prodotto, semplice da installare e gestire e con un livello accettabile di documentazione.
Devo dire che ha reso veramente semplice avere statistiche, anche perché c'è la possibilità di aggregare dati in tempo reale (funzioni di map/reduce), in modo sia full che incrementale.
giovedì 14 giugno 2012
Things are moving (faster than I can follow)
Bene bene, mi distraggo un attimo e tu vedi cosa succede?
E' un po' che non seguo lo sviluppo delle interfacce Web, e all'improvviso i ragazzi di google hanno deciso che a loro l'Html sta stetto.
Con un piccolo post, niente di che, hanno annunciato che AngluarJs è uscito. Ora, a una prima occhiata sembra una bella semplificazione delle GWT, spostando davvero tutta la logica sulla pagina e permettendo una semplicità di creazione delle pagina mai vista (pensate ad un creatore di GUI). Devo ancora ben capire quali sono i meccanismi che permettono lo scambio verso i contenitori di dati, siano essi SQL, immagini, video, documenti.
Quando avrò tempo mi ripropongo di fare un esempio e saggiare un po' più a fondo la tecnologia.
Nel frattempo i commenti sono i benvenuti!
E' un po' che non seguo lo sviluppo delle interfacce Web, e all'improvviso i ragazzi di google hanno deciso che a loro l'Html sta stetto.
Con un piccolo post, niente di che, hanno annunciato che AngluarJs è uscito. Ora, a una prima occhiata sembra una bella semplificazione delle GWT, spostando davvero tutta la logica sulla pagina e permettendo una semplicità di creazione delle pagina mai vista (pensate ad un creatore di GUI). Devo ancora ben capire quali sono i meccanismi che permettono lo scambio verso i contenitori di dati, siano essi SQL, immagini, video, documenti.
Quando avrò tempo mi ripropongo di fare un esempio e saggiare un po' più a fondo la tecnologia.
Nel frattempo i commenti sono i benvenuti!
sabato 26 maggio 2012
mercoledì 23 maggio 2012
Tieni alla tua carriera nel software? Licenziati
Mi sono per caso imbattuto in questo articolo, che purtroppo devo condividere al 100%, visti i miei trascorsi e le prospettive future. Se si vuol essere "vivi" nell'ambiente del software, l'unica possibilità è cambiare continuamente, per vedere nuovi ambienti, nuove idee e nuovi modi di fare.
giovedì 17 maggio 2012
Node.js is cancer
Non conosco bene node.js, ma mi sembra che le argomentazioni portate a sostegno della tesi siano valide.
http://teddziuba.com/2011/10/node-js-is-cancer.html
Comments are welcome
http://teddziuba.com/2011/10/node-js-is-cancer.html
Comments are welcome
mercoledì 16 maggio 2012
NAnt, o "del compilare a mano"
Creare una libreria ad uso interno può sembrare un'operazione banale: scrivi il codice, lo testi, se gira nel tuo ambiente è tutto ok. Poi un bel giorno ti dicono: dai la libreria anche ad altri gruppi di lavoro, serve per fare la stessa cosa, mettiamo a comune il know how. E tu pensi "ok, tanto lavoriamo tutti nello stesso modo, se funziona a me funzionerà anche a loro". Ecco, non c'è pensiero più sbagliato di questo.
Recentemente mi sono trovato proprio in questa situazione: avevo una libreria sviluppata in .Net 4.0 che faceva comodo ad altri colleghi, che però lavoravano in .Net 3.5
A questo punto ti chiedi: e ora come faccio a compilare per più piattaforme? Io voglio essere il padrone del codice sorgente, ma non voglio cambiare impostazioni al progetto per compilarlo su 2 framework di riferimento.
E qui ci viene incontro NAnt, un build tool molto simile (anche nel nome) ad Ant. La cosa che più ho apprezzato di questo tool è proprio il suo gran supporto ai diversi framework, sia Microsoft che Mono (é ancora un'alternativa valida a .Net?). Per le mie esigenze ho fatto tutto a mano, verificando che i build andassero a buon fine.
Non so però dire se ci siano AddIn di VisualStudio che permettano una buona integrazione, e qualora ci fossero gradirei suggerimenti.
Recentemente mi sono trovato proprio in questa situazione: avevo una libreria sviluppata in .Net 4.0 che faceva comodo ad altri colleghi, che però lavoravano in .Net 3.5
A questo punto ti chiedi: e ora come faccio a compilare per più piattaforme? Io voglio essere il padrone del codice sorgente, ma non voglio cambiare impostazioni al progetto per compilarlo su 2 framework di riferimento.
E qui ci viene incontro NAnt, un build tool molto simile (anche nel nome) ad Ant. La cosa che più ho apprezzato di questo tool è proprio il suo gran supporto ai diversi framework, sia Microsoft che Mono (é ancora un'alternativa valida a .Net?). Per le mie esigenze ho fatto tutto a mano, verificando che i build andassero a buon fine.
Non so però dire se ci siano AddIn di VisualStudio che permettano una buona integrazione, e qualora ci fossero gradirei suggerimenti.
giovedì 10 maggio 2012
martedì 27 marzo 2012
.Net e la gestione delle dipendenze
Ultimamente sto lavorando ad un progetto molto frammentato, costituito da un motore a cui si possono agganciare tanti plugin. Per tenere insieme questa massa di progetti (siamo ormai a 30), visto che ancora le interfacce sono in movimento, la soluzione più veloce ed immediata è stata quella di mettere tutto in un solo calderone, cioè una sola solution.
Questa gestione non risulta affatto pratica, anche perché il "compila soluzione" cambia la data (e quindi l'hash md5) anche alle librerie che non si sono toccate.
Come fare quindi a gestire in maniera semplice un repository in .Net?
La prima idea è stata quella di mettere le dipendenze in una directory condivisa a tutti gli sviluppatori dell'azienda. E' però necessario gestire l'albero delle versioni e creare per ogni versione di libreria rilasciata una directory, in modo da preservare tutte le versioni. Idea quindi buona ma un po' macchinosa.
Visto che in Java usiamo Archiva, ci siamo messi alla ricerca di un equivalente in .Net, che magari si fosse integrato in Visual Studio. Il tool che abbiamo trovato è stato NuGet.
"Nuget è un'estensione di VisualStudio 2010 che semplifica l'aggiunta, la modifica e l'eliminazione di librerie e tools nei progetti VisualStudio che usano il Framework .Net"
In pratica permette di accedere ad una repository centralizzata da cui attingere le dipendenze ai vari tool, lo stesso concetto di repository manager che troviamo in Maven.
Guardando la documentazione ho anche scoperto che NuGet permette di creare il proprio server, da pubblicare nella propria Intranet per ostare i pacchetti privati.
Questo è esattamente ciò di cui avevo bisogno! Certo, se potessi usare Maven anche con .Net sarei più felice, ma purtroppo il progetto NPanday è ancora nell'incubatore Apache...
Questa gestione non risulta affatto pratica, anche perché il "compila soluzione" cambia la data (e quindi l'hash md5) anche alle librerie che non si sono toccate.
Come fare quindi a gestire in maniera semplice un repository in .Net?
La prima idea è stata quella di mettere le dipendenze in una directory condivisa a tutti gli sviluppatori dell'azienda. E' però necessario gestire l'albero delle versioni e creare per ogni versione di libreria rilasciata una directory, in modo da preservare tutte le versioni. Idea quindi buona ma un po' macchinosa.
Visto che in Java usiamo Archiva, ci siamo messi alla ricerca di un equivalente in .Net, che magari si fosse integrato in Visual Studio. Il tool che abbiamo trovato è stato NuGet.
"Nuget è un'estensione di VisualStudio 2010 che semplifica l'aggiunta, la modifica e l'eliminazione di librerie e tools nei progetti VisualStudio che usano il Framework .Net"
In pratica permette di accedere ad una repository centralizzata da cui attingere le dipendenze ai vari tool, lo stesso concetto di repository manager che troviamo in Maven.
Guardando la documentazione ho anche scoperto che NuGet permette di creare il proprio server, da pubblicare nella propria Intranet per ostare i pacchetti privati.
Questo è esattamente ciò di cui avevo bisogno! Certo, se potessi usare Maven anche con .Net sarei più felice, ma purtroppo il progetto NPanday è ancora nell'incubatore Apache...
mercoledì 29 febbraio 2012
mercoledì 25 gennaio 2012
Iscriviti a:
Post (Atom)