Jso

Dopo più di un anno dall’uscita della release 1.5 di Java (Tiger) e con la versione 1.6 (Mustang) ormai alle porte, ancora ci sono grandi aziende che utilizzano le versioni più datate (1.3 o 1.4).

Soprattutto in ambito Enterprise sembra ci sia il timore di passare alle release più nuove per non stravolgere grandi impianti e proteggere così gli investimenti, senza perdere tempo in lunghi test di compatibilità.

Da un punto di vista più strettamente tecnologico ritengo invece che i tempi siano maturi per il passaggio alla 1.5 che oltre ad aggiungere nuove interessanti features al linguaggio (generics, annotation, boxing/outboxing…) magari non ancora utilizzati da tutti, introduce miglioramenti notevoli al Garbage Collector e delle performance in generale che rendono le applicazioni Java sempre più vicine a quelle scritte in linguaggio compilato.

Leggi anche l’articolo originale.

Chi ritiene la programmazione una pura fase di “manovalanza” all’interno di un progetto, è portato a ricredersi. L’utilizzo sistematico di pattern e l’evoluzione ciclica del design attraverso refactoring riportano lo sviluppatore, con la sua personalità ed esperienza al centro del progetto.

Sviluppo non significa solo scrivere codice. Sviluppo significa prendere decisioni concernenti il design. L’attività di sviluppo è qualcosa di creativo che richiede nel contempo grande disciplina. È un’attività di grande responsabilità che permette di progettare, creare, controllare e fare evolvere l’architettura e la funzionalità del progetto.

To test or not to test, this is the question… o meglio, quanto tempo e quante risorse dedicare al testing automatico del software?

E’ vero, JUnit è un ottimo strumento per il test di unità, ma predisporre gli unit test richiede tempo (anche il 50% del tempo totale di programmazione) e non si può dimenticare che il test di integrazione e funzionale è ben altra cosa… c’è ancora bisogno dei test manuali? Pare di sì…

Leggi anche l’articolo completo.

La semplicità di Ruby (e dei linguaggi di scripting in generale) o la consolidatà versatilità e robustezza di J2EE per la creazione di grosse architetture Enterprise? E un dubbio: è sempre vero che problemi complessi si possono ridurre ad una programmazione “semplice”, oppure è ancora giustificato l’elevato prezzo di una “learning curve” iniziale?
Come dire… la programmazione non è (ancora) per tutti…

Leggi anche l’articolo originale.