Riguardo alla faccenda mi preme segnalare un nuovo punto di vista per affrontare il problema della valutazione di un framework proposto da Chris Hartjes che sul suo blog parla per esperienza diretta data dall’ultimo progetto su cui sta lavorando. A poco dal rilascio (colpevolmente) si è trovato a dover scrivere dei test per verificare in modo semplice e sicuro che le varie parti funzionassero a dovere anche dopo l’inserimento di nuove funzionalità o modifiche, utilizzando Code Igniter per il progetto si è posto una semplice domanda: dove sono i test e gli strumenti per realizzarli?

Allargando anche agli altri framework sulla piazza ne esce quanto segue:

• Code Igniter: 0 test per il core, atto di fede verso gli sviluppatori
• Zend Framework: ha una grossa quantità di test che vengono richiesti per ogni contributo dalla community
• CakePHP: vedi sopra, i test coprono l’80% del codice
• symfon: ha il suo testing framework dalla nascita con oltre 8800 test per la copertura dell’80% del codice base

Chris aggiunge che vista la disponibilità di strumenti per il testing non ci possano essere scuse per la mancanza di test a supporto delle funzionalità di un’applicazione. Pagare adesso, o paga dopo, sicuramente dovrai pagare per risolvere qualche bug nella tua applicazione. Pagare ora è semplicemente più economico.

I test sono la prova che il codice si comporta come ci si aspetta, inoltre il codice testabile è molto spesso più facile da modificare man mano che il tempo passa.

E’ così che François Zaninotto introduce un suo post molto interessante su un argomento dibattuto spesso dagli sviluppatori e che forse non avrà mai una risposta precisa ma solo delle valutazioni che ci possono indirizzare verso una soluzione piuttosto che un’altra.

Gli aspetti trattati sono molteplici e la lettura completa dell’articolo aprirà sicuramente alcuni dubbi al lettore grazie ai quali potrà valutare in futuro situazioni simili con occhio diverso.

Personalmente sono dell’opinione che ogni problema vada affrontato in modo atomico rispetto ad altri affrontati precedentemente, quindi le valutazioni su un progetto devono tenere conto dei requisiti del progetto stesso e non del fatto che “se usiamo questo abbiamo poi anche questa e questa e quest’altra feature”. Provo a metterla più semplice: se ciò che ci viene commissionato deve poter fare A, B e C è molto spesso inutile proporre qualcosa che faccia anche D, E, F e G. Nel breve magari potreste non accorgervene ma nel medio/lungo periodo saranno più i costi che i benefici.

La mia l’avete sentita, ora dite la vostra. I commenti sono aperti a tutti!

Sull’AVNet Labs Blog è iniziato tutto da un interessante post di confronto tra i vari framework PHP attualmente sulla piazza tenendo in considerazione tempi di apprendimento, flessibilità oltre ad aspetti più tecnici che vanno dalla documentazione al testing e dal templating alla validazione. Dopo una scrematura inizale il confronto è continuato tra CodeIgniter e Zend Framework. Tra tutti c’è stato un confronto delle performace, empirico ma sufficiente a far capire l’ordine di grandezza su cui si trovano i vari framework.

I risultati di questi test sono stati pubblicati in un secondo post anche su richiesta di un lettore che ha commentato il primo. Vi invito alla lettura di entrambe i post che reputo interessanti.

Dal blog ufficiale vengono comunicate le principali novità e come eseguire il passaggio delle proprie applicazioni dalla versione 1.0 ad 1.1:

• La nuova architettura di symfony è più configurabile e maggiormente disaccoppiata permettendo l’uso o la sostituzione di una sua parte in modo davvero semplice
• Il nuovo object-oriented form framework rende la creazione ed il riutilizzo dei form un gioco da ragazzi
• Propel 1.2 ORM è ora un plugin, questo significa che è semplice passare a Doctrine o eventualmente a Propel 1.3 se preferite

Tuttavia chi non sentisse la reale necessità di passare alla versione 1.1, che verrà mantenuta per un anno da oggi, può dormire sonni tranquilli continuando ad usare la 1.0 che verrà supportata fino al 2010 (anticipazione fatta già da Fabien Potencier in occasione del PHPDay 2008 a Rimini).

Per le ulteriori novità e le raccomandazioni vi consiglio la lettura del comunicato originale.

Partiamo da un presupposto: questi strumenti sono nelle intenzioni di chi li ha creati dei script che dovrebbero aiutare il programmatore e semplificargli la vita.

Il punto è però questo: quanto abbiamo davvero il controllo su queste cose? Utilizzando symfony sinceramente non ho mai avuto il dubbio che non fosse uno strumento valido, sicuro o di cui non mi potessi fidare. Ma d’altronde, questo è uno dei rischi dell’open source: la provenienza non è sempre davvero sicura.

Secondo voi vale la pena di fidarsi? Avete mai avuto brutte esperienze con l’open source?

Eclipse è immenso come quasi tutti i prodotti Ibm. Le estensioni possibili sembrano infinite. Per questo motivo è un ide che richiede un approccio professionale. Ritengo sia uno strumento valido per lo sviluppo di un progetto a medio-lungo termine, non per scrivere 2 pagine di PHP una tantum. Eclipse puo essere accessoriato con una infinita di accessori (plugin) che lo trasformano in editor PHP, Java, Python…ma non solo: può addirittura essere un document manager e chissà quante altre possibilita non ho ancora scoperto.

Ho utilizzato il libro PHPEclipse: A User Guide (Paperback) per trasformare Eclipse in un ambiente di sviluppo per PHP. Il libro è ben fatto, purtroppo manifesta un po’ di vecchiaia (edito 2006) specialmente nella parte relativa al debugger. Inoltre la guida fa riferimento al plugin per eclipse PHPeclipse che non ha nulla a che vedere con PDT. PHPeclipse e PDT sono due plugin “concorrenti” ma il primo, un tempo piu avanzato, soffre di scarsi aggiornamenti ed ha tutta l’impressione di essere su un binario morto. Di fatto però il contenuto del libro rimane valido e mi è stato di aiuto nella configurazione dell’ambiente e ne consiglio caldamente la lettura.

I presupposti

• piattaforma Linux, più precisamente Ubuntu Gutsy Gibbon 7.10
• web server è Apache2
• database di rifermento è MySQL 5
• punto di partenza installazione base di Eclipse

Come andrà a finire? Basta continuare a leggere la guida sul blog di Damiano Venturin. Se anche voi vi siete costruiti un ambiente di sviluppo ad hoc raccontatecelo usando i commenti, potrebbe uscirne qualcosa di interessante.

E’ notizia recente che symfony nelle prossime major release non si avvarrà più del supporto di uno dei più popolari framework javascript: l’accoppiata prototype/script.aculo.us (presente anche in molti altri framework, come ad esempio ruby on rails).

Questa decisione ha però portato con se discrete polemiche, in quanto symfony forniva ottimi strumenti e rapide funzioni server side per facilitare la stesura di codice javascript, come la creazione di interfacce ajax e la realizzazione di semplici ed immediati drag and drop. Nei template del framework infatti, tramite semplici funzioni veniva inserito il codice js necessario, cosi lo sviluppatore non doveva più penare per scrivere il codice per realizzare quella noiosa chiamata asincrona o quant’altro. Ma allora perché levare questo prezioso supporto?

Innanzitutto bisogna dire che script.aculo.us, insieme a molti altri framework javascript (come jquery, ext, yui, e dojo) sarà supportato ed installabile a parte come plugin. Ma la decisione degli sviluppatori è quella di lasciare scrivere il codice javascript ai coder javascript, ed il codice php ai coder php.

E’ giusto secondo voi questo? Oppure nell’era del Web 2.0 la professione di web developer deve essere “tuttofare“, dato che per offrire un intensa esperienza all’utente uno sviluppatore deve saper sia scrivere codice server-side, che conoscere un minimo di codice client-side, e perché no, anche qualcosa di CSS?

Aspettiamo le vostre numerose risposte qui sotto nei commenti.