Jso

Le Metodologie Agili stanno facendo molto parlare di sè. Recenti sondaggi dimostrano come la popolarita di queste metodologie (XP, Scrum, TDD) dal 2005 ad oggi sia costantemente in ascesa. Ma in quali contesti reali queste metodologie sono applicate con successo? Ovvero.. in quali contesti rappresentano un reale vantaggio (anche economico!) nello sviluppo? Secondo alcuni se il beneficio derivante dall’adozione di queste metodologie era decisamente “sottostimato” fino a qualche anno fa, ora probabilmente è addirittura “sovrasimato”.

E’ sicuramente vero che non si può certo pretendere di ridurre il tutto ad una semplice metodologia, impacchettarla, infiocchetterla ed inserirla in azienda sperando che tutto magicamente funzioni… la vera potenza di tutta la metodologia è il team, ovvero le persone che lo compongono. Ad oggi ci sono aziende che pretendono di essere agili, senza implementare l’essenza dell’approccio. Il consiglio è quello di essere “pratici” e di non accettare la metodologia come un credo religioso ma di utilizzarla sempre con spirito critico. Un esempio:

• Status Meeting – un incontro mattutino ed una mail serale di riscontro
• Short Iterations – mantenere i cicli di sviluppo semplici e brevi ed espandere secondo necessità
• Continuous Integration – test JUnit automatici e altamente parallelizzati
• Minimal Documentation – può bastare Javadoc…
• Team Collaboration Tools – wiki e Jira tickets…
• Strict Coding Guidelines – uniformità nello stile, naming, spacing…
• Constant Code Reviews – controllare ogni riga di codice che va in produzione!
• Pair Programming – scegliere oculatamente l’accostamento tra i 2 developers (rotazioni)
• TDD – nella forma “pura” rischia di essere troppo oneroso, si può valutare un compromesso…

Leggi anche gli articoli originali: 1 e 2

Ancora a proposito di web framework… discorso inflazionato è vero ma a quanto pare tutt’altro che concluso! Il topic in questo caso è se in una web application sia meglio codificare tutto in una action oppure separare nettamente la web logic dalla business logic. La risposta parrebbe ovvia, ma non tutti sono dello stesso avviso.
Si possono catalogare fondamentalmente 4 approcci:

1. Due classi: 1 action basata (*) sul framework e 1 business logic non basata sul framework
2. Due classi: 1 action non basata sul framework e 1 business logic non basata sul framework
3. Una classe: action e business logic nella stessa classe basata sul framework
4. Una classe: action e business logic nella stessa classe non basata sul framework
   (*) si legga “che estende classi del framework”

Tra tutte l’approccio preferito è sicuramente il numero 1, la 2 rappresenta il totale disaccoppiamento (ad esempio in Struts 2 / Webwork le azioni possono essere POJO e quindi totalmente disaccoppiate dal framework), mentre 3 e 4 sono generalmente considerate bad practise. Esistono sicuramente buone ragioni per disaccoppiare la business logic dalla action:

• Testability: se disaccopiata la business logic può essere testata in maniera indipendente (es. JUnit)
• Web services: la business logic può essere utilizzata in un web-service o in servizi remoti
• Caching: riferito alle business facades

Mentawai (un framework ad approccio programmatico con supporto per l’injection di cui esiste anche una versione Ruby) sembra offrire la libertà sufficiente per implementare tutti gli approcci (1,2,3,4). A voi la scelta…

Leggi anche l’articolo originale.

Una lunga discussione sull’ennessimo web framework, Apache Wicket che viene qui paragonato al “fratello” Apache Tapestry, con divagazioni su JSF, GWT e sull’onnipresente Struts ovviamente. Tra i suoi punti di forza e innovazioni rispetto agli altri web framework vi sono:

• Un eccellente supporto built-in ad AJAX;
• La capacità di modificare la struttura delle pagine programmaticamente;
• Perfetta separazione tra codice e templates (i templates non possono contenere codice);
• Un approccio object-oriented
• Facile apprendimento (per developers Java-oriented)

Naturalmente ci sono pro e contro, come in ogni cosa. Ma la principale ragione dell’esistenza di Wicket è che non esistono altri web framework programmabili in puro codice Java (quasi tutti seguono piuttosto il classico modello dichiarativo, con file di configurazione XML ad esempio). Naturalmente poi è anche questione di gusti, ma gli impatti più evidenti si hanno nell’ottimizzazione e nella versatilità del codice. In ogni caso anche Wicket, come pure Tapestry, Freemarker, JSF (con Facelets) e gli altri framework component-oriented rappresenta una valida alternativa ai precedenti framework Model 2 tipo Struts, tanto per citarne uno famoso 🙂

Leggi anche gli articoli originali: 1, 2 e 3

Alcune interessanti riflessioni sulla tematica dell’open-source: quando un progetto realizzato nel tempo libero può diventare un progetto open-source da proporre alla comunità degli sviluppatori?

Geertjan Wielenga, sviluppatore del NetBeans Team, racconta la sua esperienza spiegando i passi che hanno portato il suo JFugue Music NotePad (un editor musicale scritto utilizzando la NetBeans Platform e JFugue API, una potente API per la gestione dei file midi) a diventare un progetto open-source.

In sintesi, secondo la sua opinione occorre:

• disporre di un progetto che abbia raggiungo almeno un certo livello di coerenza (ovvero che possa attrarre l’interesse di altri sviluppatori)
• rilasciare un prototipo, anche non completo, alla comunità
• attendere che qualcuno si interessi al progetto (nel frattempo lo sviluppo da parte dell’autore non si arresta)
• se qualcuno si interessa al progetto ed ha una conoscenza specifica del dominio maggiore di quella dell’autore diviene “contributor”
• altri utenti sono semplici utilizzatori, “observers”
• negli anni il progetto può evolvere raggiungendo buoni livelli, addirittura oltre le aspettative dell’autore stesso!

Leggi anche l’articolo originale.

Java è nato come linguaggio general-pourpose, ma al giorno d’oggi il campo di utilizzo più vasto è sicuramente il Web/Enterprise. Che dire dei sistemi safety critical o cosiddetti real-time? Questo è storicamente il mondo delle applicazioni C++, ma qualcosa sta cambiando e anche Java sta per dire la sua. Un esempio? Le specifiche Real-Time per Java RTSJ e la loro relativa implementazione Java SE Real-Time Edition, o le implementazioni alternative (ed ottimizzate) delle classi Sun di base come Javolution o Joda rendono davvero realistica l’applicazione di Java nei contesti cosiddetti real-time.
L’articolo mette a confronto alcuni aspetti della programmazione C++ vs Java come:

• Segmentation Fault vs Runtime Exception
• Deallocazione della memoria vs Garbage Collection
• Stabilità della piattaforma (open bugs)
• Testabilità e scalabilità delle applicazioni (JVM multiple)

Leggi anche l’articolo originale.

Alcuni accorgimenti che possono rendere un programmatore più efficiente nello scrivere un codice di migliore qualità. Poche regole semplici, ma a mio parere azzeccate:

1. Eliminare il codice non utilizzato
2. Non documentare codice complesso, piuttosto scrivere codice semplice
3. Non scrivere tanti commenti, ma migliorare il log
4. Applicare la legge di Demeter per mantere il codice semplice
5. Non ripetersi (non duplicare codice)
6. Marcare volutamente le porzioni di codice incomplete
7. Controllare le assunzioni nel codice (rilevare subito il fallimento)

Leggi anche l’articolo originale.