Recensioni

JQuery In action

Alkampfer — Wed, 27 Aug 2008 04:38:34 GMT

Ho appena terminato il libro JQuery in action e debbo dire che è veramente un libro interessante. Prima di tutto è molto piccolo, per cui si legge velocemente e la parte più importante, ovvero la prima, può essere racchiusa in 150 pagine.

Non sono uno sviluppatore di interfacce web, sebbene negli ultimi due anni ho lavorato a progetti web, nei quali però l'interazione javascript è stata limitata all'uso della microsoft ajax library. La difficoltà maggiore che ho incontrato è stata quella di non conoscere bene il DOM e soprattutto del dover testare gli script per lo meno in FireFox ed IE.

Il risultato è stato quello di perdere letteralmente tempo a capire come individuare gli oggetti nelle pagine, come poterli modificare in reazione alla risposta di una chiamata ajax etc etc. Leggendo JQuery in Action ho compreso come in realtà non si può pensare di scrivere codice javascript da zero, ma sia necessario comunque affidarsi ad una libreria testata e crossbrowser. JQuery è la prima libreria seria javascript che ho imparato, e già leggendo il libro ho subito compreso come molte delle cose che ho fatto in javascript sarebbero state fatte in meno della metà del tempo, se avessi conosciuto prima JQuery.

Consiglio quindi la lettura a chiunque sviluppi interfacce web, sia che si lavori in ASP.NET oppure che si usi qualsivoglia altra tecnologia lato server.

Alk.

Steve McConnell - Rapid Developement

Alkampfer — Tue, 24 Oct 2006 00:16:00 GMT

Dedicato in particolar modo ai project manager, questo libro è una preziosa collezione di best practices per lo sviluppo software, scritto naturalmente con la solita maestria di McConnell che rende la lettura piacevole e divertente.

Autore:Steve McConnell (Construx)
Editore: Microsoft Press
ISBN: 1-55615-900-5
Pagine: 680
Lingua: Inglese
Anno: 1996
Categoria: Best Practices, progettazione software
Online: Amazon

Steve McConnell è autore di libri di grande successo ed ha scritto negli anni opere che sono ora considerate dei classici imperdibili del genere, trattando in particolare gli aspetti della progettazione e della gestione del ciclo di vita del software.

Rapid Developement è nelle intenzioni dell’autore un insieme di validi consigli per riuscire a sviluppare in modo efficace, impiegando il tempo a disposizione nella maniera più produttiva possibile. L’unica pecca è che il testo, essendo pubblicato nel 1996, non tratta nessuno dei moderni cicli di vita agili di sviluppo, come l’extreme programming o lo scrum, ma molti dei consigli che vengono dati possono comunque essere applicati anche negli ambienti agili senza problemi. Questo libro non include al suo interno pratiche rivoluzionarie o tecniche sofisticate e soprattutto non promette miracoli, ma vuole solamente racchiudere una serie di concetti basilari che ogni progettista software dovrebbe possedere. Il risultato è che secondo McConnell lo sviluppo rapido si ottiene solamente quando si è in grado di monitorare il ciclo di vita di un progetto, dalla gestione dei requisiti alle fasi di test, seguendo contemporaneamente alcune pratiche regole fondamentali che permettono di mantenere il ciclo di vita sotto controllo.

Il libro è suddiviso in tre parti principali, nella prima si esaminano i fondamenti della progettazione e della realizzazione di un software. Particolarmente interessante è la sezione dei Classic Mistakes, che mostra i più comuni errori che portano a ritardi nei tempi di consegna, e la sezione Risk Management in cui si fa una breve panoramica sulla gestione dei rischi, pratica indispensabile per evitare che problemi imprevisti facciano slittare i tempi di sviluppo e mancare le date di consegna.

La seconda parte è dedicata ad una trattazione dettagliata degli aspetti più importanti dello sviluppo software, in questa parte riveste una particolare importanza il capitolo sette, in cui l’autore da una panoramica sui principali cicli di vita di un progetto, spiegando in maniera coincisa ma chiara i vari waterfall, spiral, Evolutionary prototyping, etc. Al termine del capitolo è anche riportata una tabella riassuntiva dei punti di forza e debolezza di ogni ciclo di vita, questi dati sono particolarmente utili ai Project Manager che potranno così valutare in base al proprio ambiente il ciclo di vita più adatto. Si ricordi che come detto precedentemente il libro non tratta metodologie agili e la loro applicablità deve essere quindi considerata separatamente. Un altro capitolo di grande importanza è quello destinato alla stima del progetto, in cui viene spiegato come effettuare considerazioni efficaci per determinare stime realistiche che possono quindi essere mantenute senza troppe difficoltà. Il concetto chiave che l’autore da in questo capitolo è che un errore di stima provoca danni ingenti ai propri progetti. Se ad esempio un progetto richiede dieci mesi per essere completato, effettuare una stima di sei è disastroso e porta spesso a consegnare il prodotto in un tempo anche superiore ai dieci mesi che sarebbero stati necessari con una stima corretta. Per chi fosse interessato ad approfondimenti su questo argomento è disponibile un ulteriore testo di McConnel dedicato interamente alle pratiche di stima dei progetti.

L’ultima parte del libro contiene infine una lista di Best Practices da seguire per raggiungere l’obiettivo del Rapid Developement. Ogni pratica inizia con una scheda in cui l’autore riporta: una breve descrizione, gli effetti sui propri progetti, i rischi e le interazioni con le altre pratiche. Ogni scheda è comunque seguita da una descrizione dettagliata che tratta in maniera più approfondita la pratica descritta.

Il libro è ben scritto e la lettura scorre velocemente, soprattutto grazie a piccole storie di esempio tratte da situazioni reali. Nel corso del libro si leggeranno le avventure di Jill, Bill ed i loro colleghi alle prese con i vari prodotti: Square Calc, Giga Quote, etc. Sicuramente molte delle letture vi faranno tornare alla mente situazioni vissute in prima persona, storie di ritardi di consegna causati dall’inserimento di features nelle fasi di test, difficoltà di integrazione dovuta alla mancanza di daily build sono problemi che sicuramente molti di noi hanno vissuto. Il ritrovare in queste storie le proprie esperienze è una dimostrazione che il testo tratta di problematiche concrete e non è sicuramente un testo accademico di pura teoria.

Come per tutti i libri di McConnel, anche in Rapid Developement la bibliografia di riferimento è vastissima, al termine di ogni capitolo l’autore inserisce infatti molti titoli di opere di approfondimento, in questo modo è possibile utilizzare il libro anche come catalogo, se ad esempio si vuole acquistare un testo di progettazione si può andare nell’apposito capitolo e leggerne semplicemente la bibliografia.

La lettura di questo testo è consigliata particolarmente a chi svolge il ruolo di Project Manager, ma anche gli sviluppatori troveranno informazioni utilissime, in particolar modo nella terza parte dedicata alle best practices.

Rapid Developement è un libro che non dovrebbe quindi mancare nella vostra libreria.

Software Estimation: Demystifying the Black Art

Stefano Ottaviani — Tue, 03 Oct 2006 15:45:08 GMT

Autore: Steve McConnell (Construx)
Editore: Microsoft Press
ISBN: 0735605351
Pagine: 308
Lingua: Inglese
Anno: 2006
Categoria: Stime Software, Best Practices
Online: Safari BOL - Gorilla – Amazon

In questo libro Steve McConnell (per chi non lo conoscesse, si tratta di uno degli scrittori più autorevoli del settore, tanto da essere stato nominato dai lettori del magazine “Software Development” nel 1998 una delle persone più influenti nell’industria del software, insieme a Bill Gates e Linus Torvalds) parla delle tecniche per migliorare l’affidabilità delle stime sui tempi di sviluppo dei software, un argomento molto delicato dato che sulla base di esse, in genere, vengono presentate le offerte ai clienti (ed è quindi collegato direttamente con i fatturati della ditta), ma che spesso viene affrontato con troppa superficialità, adottando metodi non ottimali, se non addirittura basandosi sull’intuito.

Nell’introduzione, la cui lettura è consigliata in quanto riassume molto bene gli obiettivi del libro, l’autore spiega che ci sono due approcci per poter effettuare le stime del software: quello scientifico, utilizzato dalle organizzazioni che vogliono contenere i margini di errore delle stime entro il 5-10% e/o trattano progetti di grandi dimensioni (oltre 1.000.000 di linee di codice), e che per ottenere ciò debbono ricorrere a complessi sistemi matematici, ed il metodo dell’”arte della stima”, costituito da molte regole pratiche, suggerimenti e tecniche alla portata anche di chi non ha una laurea in matematica o non esegue stime come professione principale, e che si adatta a tutte le ditte che in genere cercano di ridurre il più possibile un margine di errore che, altrimenti, potrebbe essere facilmente superiore al 50-100%.

Come si evince dal titolo, l’autore utilizza l’approccio dell’”arte della stima”, creando un testo di riferimento che si adatta comunque alle esigenze della maggior parte delle organizzazioni, in cui in genere non ci si affida a persone che svolgono come professione principale quelle di stimatori, e che non di rado si ritrovano ad affrontare situazioni non piacevoli a causa di stime errate.

Grazie alla presenza di molti riferimenti ad altri testi che trattano delle tecniche in modo più approfondito, il libro rappresenta comunque un ottimo punto di partenza anche a chi poi vorrà trattare il tema seguendo metodi più scientifici.

Data inoltre la natura dell’argomento, che non riguarda solamente i tecnici (sviluppatori, ...) ma anche gli executive (commerciali, manager, capi-progetto…) ed il cliente finale, l’autore ha adottato un taglio molto pratico, in modo da dare la possibilità anche a queste categorie di poter leggere il libro; ad esempio, sono presenti molti suggerimenti e regole pratiche (ben 118), messi in evidenza e riepilogati alla fine del testo, contro solo 18 formule matematiche, concentrate in poche delle tecniche analizzate; inoltre, il testo è di breve - media lunghezza (circa 250 pag. effettive), se paragonato con la norma dei testi del settore informatico di 800-1000 pag.

L’unica pecca può essere rappresentata dalla mancanza (almeno al momento della scrittura di questa recensione) di una versione in lingua italiana, cosa che sarebbe gradita a persone non tecniche, in genere poco inclini ad affrontare una lettura in lingua inglese.

Il testo è suddiviso principalmente in tre parti; nella prima si viene introdotti nella tematica delle stime sul software, illustrando vari termini come stima, target e commitment, che spesso vengono confusi dai soggetti coinvolti, ottenendo dei conflitti che potrebbero essere risolti molto più facilmente avendo ben chiare le loro differenze (tra l’altro, l’autore dimostrerà che il significato di stima nel mondo del software è ben diverso da quello classico, da dizionario).

Sono poi indicati i motivi per cui è utile una stima corretta (nonché la differenza tra una stima precisa ed una accurata) e quali sono le conseguenze di progetti sovrastimati e sottostimati (vedi anche la Legge di Parkinson e la “Sindrome dello Studente” di Goldratt a riguardo), dimostrando che un grosso ruolo è giocato dai fattori psicologici, più che da quelli matematici.

Sono inoltre illustrati i vari fattori che influenzano le stime (tecnologia usata, impiego di processi di sviluppo sequenziali o agili, composizione del team,…) e le cause che possono portare a degli errori, indotte sia dall’ambiente circostante a chi le effettua, sia interne al soggetto stesso, come i pregiudizi o il basarsi su convinzioni errate, oppure dal non considerare nella stima attività come il deploy dei programmi, che comunque qualcuno dovrà effettuare ad un certo costo.

Per un assaggio, in questo sito è presente un “particolare” test tratto dal secondo capitolo, che dimostra l’influenza di alcuni fattori psicologici sui risultati delle stime: test e risultati.

La seconda parte del libro illustra molte tecniche per ottenere delle stime migliori, e per ognuna di esse viene indicato:

l’obiettivo della stima (si può voler stimare la grandezza del progetto, il numero di features che possono essere consegnate entro una certa data, i mesi che occorrono per lo sviluppo,…)
la categoria di grandezza del software per cui è applicabile (piccolo, medio, grande)
in quale step delle attività è applicabile la tecnica (es. all’inizio della pianificazione o in uno stato medio - avanzato dello sviluppo, in questo caso la tecnica può essere utilizzata per verificare se la stima iniziale è ancora corretta)
se utilizzabile con metodologie sequenziali o iterative (agili)
il livello di accuratezza che ci si può attendere da quella particolare tecnica.
Le tipologie di tecniche sono molto varie, alcune sono dei semplici accorgimenti che possono comunque migliorare il lavoro di chi effettua la stima (magari a livello intuitivo alcune vengono utilizzate senza sapere della loro esistenza, come la T-Shirt sizing), altre sono più complesse e possono richiedere la collaborazione di più persone all’interno della ditta (es. quelle che poi andranno effettivamente a sviluppare il software), di dati storici prelevati dai precedenti progetti o di tool appositi, come quello offerto gratuitamente dalla ditta dell’autore, Construx Estimate.

L’autore espone anche la sua opinione (molto interessante) riguardo l’utilizzo di tecniche controverse, come il conteggio delle righe di codice, oppure sulla diatriba riguardante l’impiego di più persone all’interno del team di sviluppo in modo tale da velocizzare lo sviluppo del software.

Infine, nella terza parte, ed in particolar modo negli ultimi due capitoli, il discorso si concentra sul rapporto tra i vari soggetti, in particolar modo tra chi ha effettuato le stime, gli executive ed il cliente finale: ad esempio, vengono illustrate varie tecniche per presentare i risultati delle stime in modo comprensivo anche per chi non è un tecnico, e sono discussi i punti di vista delle varie parti in causa, in modo tale da farle dialogare al meglio tra loro. In particolare, a riguardo, l’autore indica di vedere questa fase non come una negoziazione in cui un soggetto vince e l’altro perde (non c’è nessuna torta da spartirsi), bensì come un dialogo in cui le parti stanno tutte nello stesso tavolo, e vincono o perdono insieme (ed in questo, McConnell indica esplicitamente di aver cambiato opinione rispetto a quanto affermò in un suo precedente libro, “Rapid Development”).

In conclusione, si tratta sicuramente di un libro molto interessante da leggere, in particolare per chi non ha mai letto testi dello stesso genere, ed in questo caso aiuta a mettere in chiaro anche certi concetti di cui magari si intuiva la natura, ma che non sono stati mai approfonditi.

Oltre ai soggetti che si occupano della parte tecnica, la lettura di un testo su questo argomento dovrebbe essere “obbligatoria” anche per gli executive, ai quali spettano molte responsabilità e possono essere causa di errori molto gravi dovuti anche a comportamenti superficiali e facilmente evitabili.

Anche se, molto probabilmente, a causa della particolare natura dell’argomento delle stime software, nessuna delle tecniche sarà illuminante e definitiva (anzi, l’autore consiglia in genere di adottarne più di una nello stesso progetto, in modo tale da vedere se i risultati convergono o meno), in generale il testo saprà dare una maggiore sicurezza su questi temi e consapevolezza su ciò che può portare a commettere errori che saranno poi pagati a caro prezzo.

Joshua Kerievsky - Refactoring To Patterns

Diego Guidi — Wed, 06 Sep 2006 14:28:00 GMT

L'autore in questo libro offre un punto d'unione tra due dei testi fondamentali nello sviluppo di software object oriented, vale a dire Design Patterns della Gof e Refactoring di Martin Fowler (che non per niente firma la prefazione di RtP). Quello che offre questo testo è infatti una serie di percorsi guidati alla implementazione dei più importanti Design Patterns a partire da codice esistente, funzionante ma dal design errato oppure limitato.

In particolare, tutta la parte iniziale del libro offre una discreta introduzione sui patterns e soprattutto su quando seguirne i dettami: divertente e formativo è l'esempio di codice dell'onnipresente Hello World (riportato in appendice alla recensione), implementato però in questo caso attraverso lo Strategy Pattern, a cui seguono le conclusioni dell'autore circa l'inutilità di un approccio in casi così semplici... oppure ancora l'accenno alla Singletonite, la malattia comune a tutti gli sviluppatori che tendono ad abusare del Singleton Pattern ...

Un capitolo è inoltre dedicato ai Code Smells , vale a dire gli elementi presenti in una determinata porzione di codice, di per sè perfettamente funzionante, che indicano errate scelte di design e/o di implementazione, e che rendono il codice stesso difficilmente comprensibile, manutenibile ed espandibile.

Alla risoluzione di questi "difetti" è dedicata la restante, e corposa, parte del libro, organizzata in sezioni principali:

Creation: miglioramento del design nella fase di costruzione degli oggetti, ad esempio sostituendo un elevato numero di costruttori (che si differenziano tra loro solo per il numero e tipo di parametri) con dei metodi di creazione maggiormente esplicativi.
Simplification: semplificazione di codice attraverso la modifica, eliminazione, sostituzione o isolamento di ben definite porzioni di codice, ad esempio creando metodi brevi e il cui nome comunichi immediatamente la loro funzione e il loro contesto di utilizzo.
Generalization: trasformazione di un codice altamente specifico in un codice più generico e quindi maggiormante riutilizzabile, ad esempio attraverso l'uso dei Composites in luogo delle relazioni uno-a-molti.
Protection: miglioramento della protezione del proprio codice, ad esempio per evitare InvalidCastExceptions o le NullReferenceExceptions.
Accumulation: linee guida di design per migliorare il modo di recuperare informazioni da una gerarchia omogenea od eterogenea di oggetti, ad esempio usanto il Visitor pattern.
Utilities: refactorings di utilità generale, ad esempio l'unificazione di interfacce o l'estrazione di parametri.

Il catalogo completo dei refactorings presenti è visualizzabile sul sito web, insieme ad ulteriori refactorings proposti dall'autore e dai suoi collaboratori.

Refactoring To Patterns è semplicemente una lettura indispensabile per qualsiasi sviluppatore interessato a migliorare il design e la qualità del proprio codice. Innanzitutto è un libro molto pratico: tutti i refactorings proposti per "abbracciare" un determinato pattern sono versioni semplificate di refactoring effettivamente sperimentati dall'autore su progetti reali, quindi niente esempi fini a se stessi.

Inoltre, la chiarezza espositiva è esemplare, in pieno stile GoF. Per ogni refactoring trattato viene infatti presentato nell'ordine:

Schema UML del codice pre-refactoring e del codice a refactoring completato
Spiegazione sintetica del refactoring.
Introduzione "storica", ovvero la descrizione del progetto reale da cui proviene e le motivazioni che hanno portato alla necessità di effettuare le modifiche.
Tabella riassuntiva sui benefici e sugli eventuali problemi derivati dall'adozione del refactoring.
Dettaglio delle meccaniche di trasformazione, vale a dire tutti i refactoring steps necessari per modificare il codice al fine di migliorarne il design.
Uno o più esempi completi, con spiegazione dettagliata di tutti i passaggi necessari.

Il testo è inoltre molto interessante per vedere "in campo" alcune tecniche di sviluppo di cui magari si sente spesso parlare ma che per limiti teorico-pratici o di tempo non è mai stato possibile applicare ai propri progetti software: innumerevoli sono infatti i riferimenti ad alcune pratiche di Agile Development (ad esempio il DRY - Don't Repete Yourself - ovvero l'evitare in ogni modo le duplicazioni di codice), e di Extreme Programming (spesso l'autore cita il contributo del suo "compagno di tastiera" nell'elaborazione dei corretti refactorings); in aggiunta, praticamente ogni esempio del libro è realizzato in base al Test-Driven Development, giudicato dall'autore l'unico metodo realmente efficace per affrontare in tutta sicurezza i refactorings più spinti.

Consiglio quindi senza riserve a tutti questo testo, sia per la chiarezza espositiva (il libro è perfettamente fruibile anche da parte di sviluppatori non particolarmente a proprio agio con i Design Patterns o con le pratiche di refactoring, anzi può essere considerato un valido stimolo per l'approfondimento) che per gli innumerevoli suggerimenti di sviluppo che contiene: non sarà raro, leggendo gli esempi riportati, pensare ai propri progetti e a come migliorarli in base ai dettami del libro.

L'unica nota "negativa" del testo: il codice riportato negli esempi è codice Java! Ciò non pregiudica in alcun modo la leggibilità o la comprensibilità degli esempi, soprattutto per sviluppatori C++ o C#, ma ferisce un pò l'orgoglio degli sviluppatori .NET...

P.S: inevitabilmente, una volta letto il libro vi verrà voglia di comprare pure ReSharper...

Appendice: HelloWorld from a patterns-happy developer ...

Fonte: SlashDot - Conceptual models of a program?

public interface MessageStrategy 
{
   public void sendMessage();
}
public abstract class AbstractStrategyFactory 
{
   public abstract MessageStrategy createStrategy(MessageBody mb);
}
public class MessageBody
{
   Object payload;
   public Object getPayload()
   {
      return payload;
   }
   public void configure(Object obj) 
   {
      payload = obj; 
   }
  
   public void send(MessageStrategy ms) 
   {
      ms.sendMessage();
   }
}
public class DefaultFactory extends AbstractStrategyFactory 
{
   private DefaultFactory() { }
   static DefaultFactory instance;
   public static AbstractStrategyFactory getInstance()
   {
      if (instance==null) 
         instance = new DefaultFactory();
      return instance;
   }
   public MessageStrategy createStrategy(final MessageBody mb) 
   {
      return new MessageStrategy() 
      {
         MessageBody body = mb;
         public void sendMessage() 
         {
            Object obj = body.getPayload();
            System.out.println((String)obj);
         }
      };
   }
}
public class HelloWorld 
{
   public static void main(String[] args) 
   {
      MessageBody mb = new MessageBody();
      mb.configure("Hello World!");
      AbstractStrategyFactory asf = DefaultFactory.getInstance();
      MessageStrategy strategy = asf.createStrategy(mb);
      mb.send(strategy);
   }
}

Data di pubblicazione: 30/ 8/ 2006

Biografia: Appassionato di informatica e di programmazione sin dai tempi del basic su Commodore 64, attualmente si occupa di sviluppo applicazioni e servizi GIS su piattaforma .NET e Java.