Qualche giorno fa UgiDotNet ha pubblicato un mio semplice intervento dal titolo “Isolare la dipendenza da DateTime.Now”.

L’articolo  vuole  essere  un  semplice  esempio  per  porre  l’attenzione  sull’importanza  di  creare,  ove necessario, un codice che sia  facilmente  testabile. Questa semplice necessità conduce all’adozione di una serie  di  provvedimenti  che  rendono  il  codice  più  flessibile,  modulare  e  aderente  a  principi  utili indipendentemente dalla tipologia di sviluppo adottata, quali SRP, KISS o SoC.

Nello specifico,  la creazione di una semplice astrazione, come in questo esempio porta numerosi vantaggi, tra i quali il disaccoppiamento del modulo dal tempo di sistema,  la semplicità richiesta per scrivere test ed eseguirli  in un ambiente congelato e  la possibilità di creare situazioni di anomalia (facendo restituire date fuori range, o in ordine inaspettato, simulando eventuali errori non facilmente riproducibili).

L’astrazione,  più  in  generale,  permette  di  isolare  facilmente  le  responsabilità  di  ciascun  componente, inducendo a pensare alle funzionalità offerte piuttosto che all’implementazione, e permette sia una facile estensione  in  uno  scenario  futuro  che,  soprattutto,  rende  possibile  creare  implementazioni  ad  hoc (solitamente via mocking framework) da utilizzare per  isolare completamente  il componente sotto test da dipendenze  incontrollabili  (DateTime.Now),  lente  (HugeDBDataAccess),    remote  (GoogleResponse)  o indisponibili (WonderfulServiceIWillWriteTomorrow).

Markino dice:

L’articolo propone alcuni scenari di testing in merito ad una possibile dipendenza da DateTime.Now. Sebbene la cosa potrebbe sembrare banale, in realtà con un esempio molto semplice l’articolo mostra chiaramente il problema della dipedenza dei test dall’ambiente in cui lo stesso è eseguito; dipendenze che inficiano i test e che ne fanno gridare l’inutilità...

L’articolo è dal mio punto di vista un’ottima presentazione per capire la filosofia con cui occorre approciare al testing e alle metodologie di testing. L’articolo mostra l’importanza di isolare le dipendenza saprattutto per rende il codice quanto più testabile.

Creare batterie di test richiede tempo, e anche il mantenimento degli stessi pensa molto sul bilancio di un progetto... quindi sebbene il testing dovrebbe essere un must, posso capire – in alcuni contesti - la scelta di non operare batteria di test approfondite, tuttavia è importante - ed è una cosa che cerco di non trascurare mai - la testabilità del  codice! Scrivere codice in primis testabile non è costoso ed è investimento per quando sceglieremo di creare test più approfonditi su tutta la linea di progetto o su un subset dello stesso.

Ringrazio sia Markino per la recensione che UgiDotNet per l’opportunità offertami.

Un’interessante guida in pdf riguardo l’Agile Software Development:

Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated.

Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. [Wikipedia]

Colgo l’occasione del post di ieri, The void is invariant, del fantastico Eric Lippert per segnalare l’ottima serie di articoli riguardanti i concetti covariance and contravariance in un determinato type system, in questo caso C#:

• Covariance and Contravariance in C#, Part One
• Covariance and Contravariance in C#, Part Two: Array Covariance
• Covariance and Contravariance in C#, Part Three: Method Group Conversion Variance
• Covariance and Contravariance in C#, Part Four: Real Delegate Variance
• Covariance and Contravariance In C#, Part Five: Higher Order Functions Hurt My Brain
• Covariance and Contravariance in C#, Part Six: Interface Variance
• Covariance and Contravariance in C#, Part Seven: Why Do We Need A Syntax At All?
• Covariance and Contravariance in C#, Part Eight: Syntax Options
• Covariance and Contravariance in C#, Part Nine: Breaking Changes
• Covariance and Contravariance in C#, Part Ten: Dealing With Ambiguity
• Covariance and Contravariance in C#, Part Eleven: To infinity, but not beyond

John had just started out in the hat-making business and wanted a sign for his shop. He composed his sign like so:

Before using the new sign, John decided to show it to some friends to seek their feedback. The first friend thought that the word "hatter" was repetitive and unnecessary because it was followed by the words "makes . . . hats," which showed that John was a hatter. The word "hatter" was struck out. The next friend observed that the word "makes" could be removed because his customers would not care who made the hats. So "makes" was struck out. A third friend said he thought the words "for ready money" were useless, as it was not the custom to sell hats on credit. People were expected to purchase hats with money. So those words were omitted.

The sign now read, "John Thompson sells hats."

"Sells hats!" said his next friend. "Why, nobody will expect you to give them away. What then is the use of that word?" "Sells" was stricken. At this point there was no use for the word "hats" since a picture of one was painted on the sign. So the sign was ultimately reduced to:

Thompson's sign was gradually revised by his friends, who helped him remove duplicate words, simplify his language, and clarify his intent.

Chi ha sempre considerato Mac OS X come un sistema operativo più sicuro di Microsoft Windows, dovrà assolutamente ricredersi, o quantomeno rivalutare in modo approfondito le proprie posizioni.

Il contest sulla sicurezza dei sistemi operativi recentemente svoltosi, non solo fornisce ampia dimostrazione che il comune concetto di sicurezza che accompagna OS X, sia totalmente infondato, ma anzi, a sentirla tutta, illustra come problematiche ampiamente risolte su Windows Vista e successore, siano tuttora profondamente radicate nel kernel XNU.

Charlie Miller, autore dell’exploit che ha messo in ginocchio un MacBook in pochi secondi, parla chiaro e nella sua intervista a ZDNet spiega che su un sistema OS X, privo della randomizzazione del codice, è possibile inserire codice malevolo e fare qualsiasi cosa.

Miller parla anche di altri browser, nello specifico la versione di Firefox per Windows e spiega come questo browser e il sistema operativo di casa Microsoft sono molto difficili da scardinare. Anche se iniettassimo del codice in memoria, infatti, non sapremo dove ritrovarlo e, ammesso che per puro caso ci riuscissimo, il codice ritrovato non sarebbe eseguibile.

L’exploit, anche se non ufficialmente dichiarato, è stato sicuramente preparato tenendo in considerazione il lavoro svolto dal giovane ricercatore italiano Vincenzo Iozzo, già noto per aver parlato del problema di sicurezza di OS X qualche mese fa.

Il bug, difficilmente risolvibile in Leopard, verrà molto probabilmente eliminato nella successiva versione di OS X: Snow Leopard.

Questa volta Apple deve seguire l’esempio e l’esperienza di Microsoft, che negli anni ha implementato delle policy di sicurezza più efficaci di quanto si pensi.

Gli utenti, momentaneamente, possono solamente prendere alcune precauzioni per minimizzare il rischio di poter essere attaccati: effettuare l’accesso al sistema operativo con i minimi privilegi, firewall attivo e molta prudenza nell’aprire link su siti poco conosciuti.
( http://www.oneapple.it/27/03/2009/os-x-leopard-meno-sicuro-di-windows/ )

Ho citato questo articolo giusto per mettere in evidenza che, poichè OS X sta diventando sempre più popolare, rispetto agli anni passati, è normale che le vulnerabilità vengano allo scpoerto.

In generale comunque, confrontare la sicurezza di diversi sistemi operativi non ha molto senso su un piano assoluto per diversi motivi, spiegati molto bene qui:

Lo scenario di rischio che vivono i diversi sistemi operativi concorrenti è profondamente diverso in virtù della diversa quota di mercato e della diversa appetibilità dei dati da carpire. Si può confrontare un sistema operativo client adottato da milioni di utenti con altri diffusi molto molto meno? Non credo proprio. L'interesse da parte di chi intende attaccare è per forza orientato verso le piattaforme più diffuse e che possono far ottenere maggior guadagno con minor investimento possibile in termini di ricerca. L'attenzione e la ricerca di vulnerabilità è per forza sbilanciato verso la piattaforma Microsoft che ha un mercato molto molto più appetibile.

[...]

Le dinamiche di produzione dei sistemi operativi e delle funzionalità informatiche al contorno (hardware e software) sono diverse. Microsoft fa solo software e abilita l'ecosistema di partner nel realizzare hardware (e quindi driver: è di Microsoft la responsabilità dei driver???) e software. Apple fa il software ma controlla parte dell'hardware su cui fa eseguire il suo OS. Linux ha un modello di sviluppo del software totalmente diverso e per certi versi destrutturato (con il rischio di sfuggire al governo dei tipici processi di revisione di codice sicuro)

[...]

Il punto è, semmai, quali dei modelli di sviluppo e dei processi reali di produzione del software di questi diversi sistemi operativi è quello che offre maggiori garanzie di riduzione del livello di rischio in termini di riduzione vulnerabilità, miglioramento delle funzionalità protettive, maggiore supporto agli utenti nelle situazioni decisionali che sono legate ad aspetti di sicurezza, e capacità di reazione alle emergenze di sicurezza dal punto di vista gestionale?
(http://blogs.technet.com/feliciano_intini/archive/2008/04/01/quale-tra-windows-mac-os-e-linux-il-sistema-pi-sicuro.aspx)

L'articolo dice "Apple deve seguire l’esempio e l’esperienza di Microsoft, che negli anni ha implementato delle policy di sicurezza più efficaci di quanto si pensi": tutto parte da  The Microsoft Security Development Lifecycle (SDL): Process Guidance, a cui dare almeno un occhio...