Zen Programming.it

Nel post di qualche settimana fa (lo potete trovare a questo link ) abbiamo fatto una rapida introduzione al tema delle misurazioni delle prestazioni di una piattaforma applicativa fortemente basata su REST. Il tema è estremamente complesso, e le quattro idee che ho "buttato giù" sono solo la superficie di un mondo vastissimo ed articolato. Al mio primo approccio con questo argomento - non lo nego - mi sono trovato parecchio spiazzato. Sono sempre stato abituato a "calcoli insindacabili" e certezze; ma tutto questo richiede una buona dose di analisi dei comportamenti e di...speranza. Dico questo per un motivo molto semplice: rispondere alla domanda "quanti utenti l'ora è in grado di supportare la mia applicazione?" , non è così banale. Vuol dire prima misurare tutto il misurabile, e poi dover fare i conti con la variabile più imprevedibile con cui un professionista dell'IT deve fare i conti: il comportamento dell

A fine 2012 ho iniziato ad avvertire una maggiore sensibilità dei clienti riguardo il tema delle prestazioni di un sistema basato sul web. Parecchi degli applicativi a cui stavo lavorando in quel periodo erano già basati su architetture con piattaforme REST e dati in formato JSON, che si adattavano molto bene al tema della "misurazione dei tempi di risposta". La separazione dei moduli applicativi e - in particolare - del "presentation layer" dallo strato di servizi, è a mio parere una caratteristica essenziale per ottenere una metrica dell'applicazione sotto carico. Faccio subito una precisazione ritengo doverosa. In ogni situazione - ed in particolar modo se si lavora con SPA (Single Page Application) - è fondamentale distinguere tra le problematiche prestazioni dovute ad un codice client "lento", magari non adeguatamente ottimizzato, da una piattaforma di servizi che fatica a fornire risposte nei tempi desiderati. In questo post mi soffermerò su qu

Lavorando con ASP.NET Web Api vi sarà sicuramente capitato di dover caricare lato server un file presente sul computer dell'utente. Se state usando un client basato su JavaScript - magari jQuery, se non volete farvi del male con XHR - è certamente una cosa piuttosto semplice: sono decide, per non dire centinaia, i controlli che si trovano in rete che già fanno quello che vi serve; basta trovare quello giusto che risponde alle vostre esigenze, aggiungere il riferimeto allo script, e....via! Se poi, come sovente accade, dovete passare anche dei dati "form" nella richiesta di upload - magari per associare il file caricato sul server ad una entità presente nella vostra base dati - l'operazione richiede qualche sforzo in più, pur rimanendo fattibile e molto documentata. Parlo sempre di JavaScript, eh... Ma se dovete fare questa cosa da .NET, magari un'applicazione WPF o una semplice console application, anche eseguire un semplice upload non è banalissimo. I post che

Secondo alcuni studi americani, già dal gennaio del 2014, l'utilizzo di Internet - intesa come volume di traffico - richiesto da dispositivi mobili (smartphones e tablet) ha superato la quantità richiesta da computer desktop e ambienti business (servers e quant'altro). Questo dato deve far pensare: si tratta di uno dei traguardi più significativi da quando la rete globale è entrata nella nostra quotidianità. Una persona media fruisce la rete in maniera del tutto nuova, con una frequenza differente, durante tutto l'arco della giornata e non soltanto nelle ore lavorative. Internet ha raggiunto persone di ogni età, cultura e ceto sociale. E' questo ha portato - e porterà sempre di più in futuro - alla necessità di realizzare strumenti più accessibili, che permettano la fruizione delle informazioni in maniera semplificata ed intuitiva. Questo, cercando di raggiungere più terminali, e quindi più persone possibili. E' così che - da oltre quattro anni (dal lontano 2010)