maggio 2010 Blog Posts

[OT] Breve assenza…

Sono stato un pò ingrato nei confronti di questo blog, nelle ultime settimane. Molti di voi avranno notato la mia assenza, molti altri no… forse più no :) In realtà in questo caso il lavoro c’entra ma relativamente, il grande colpevole è il mio impegno in un progetto community che, teoricamente, è già partito… ma ancora in sordina, perchè da perfezionista come sono preferisco parlarne ufficialmente quando sarà pronto come si deve :) Nel frattempo ringrazio chiunque abbia già partecipato al progetto (chi lo ha fatto, lo sa :)): io sto per partire per...

posted @ mercoledì 26 maggio 2010 12:41 | Feedback (0)

[Weekly Issue] Disabilitare il debug in ASP.NET a livello di server

Qualche post fa avevo evidenziato i principali effetti deleteri dell’avere in produzione un applicativo con il debug abilitato. Ultimamente (ieri), mi è capitato ancora una volta di trovare un applicativo in produzione da parecchio tempo che, per motivi ancora da chiarire, si è ritrovato con il debug abilitato. Gli effetti sono stati che l’architettura bilanciata su due nodi continuava a cadere, provocando disservizio. Un frontend che fino al giorno prima reggeva tranquillamente un milione e mezzo di pagine viste al giorno, si è ritrovato a non sopportarne più di 400 mila, con gravi danni per l’advertising. Una volta riconfigurato il...

posted @ giovedì 13 maggio 2010 17:21 | Feedback (1)

[Umbraco] Macro o non Macro? Questo è il problema…

Chi di voi ha utilizzato almeno qualche volta Umbraco, conosce sicuramente il meccanismo potente delle macro. Come probabilmente sapete, le macro hanno la possibilità di essere “cachate” (utilizzano la cache nativa di ASP.NET) per evitare che vengano interpretate ogni volta. Questa funzionalità è, però, tanto utile quanto pericolosa. Il rischio, infatti, è di “abusare” in maniera eccessiva di questa facilitazione, soprattutto quando si parla di macro XSLT. Un esempio: chiunque lavori in XSLT da più di qualche ora sa che ci sono dei selettori che in generale è meglio evitare. Qualcosa come $currentPage/ancestor-or-self::node//node...

posted @ martedì 11 maggio 2010 12:08 | Feedback (0)