Le risposte, molte volte, lasciano a bocca aperta. No, non perchè il contenuto sia di interesse sopraffino tale da cambiarvi la vita. Più che altro perchè mentre la leggi pensi “speriamo di non dover mai lavorare con sto qui”.

Non ho mai usato un framework, da quale dovrei iniziare?
Chi pone la domanda è già sicuramente confuso dopo le prime ricerche fatte in rete (perchè ha cercato in rete vero?). Per complicare ulteriormente le cose le risposte che riceve, tramite qualsiasi canale abbia utilizzato (mailing list, social network, sito dedicato), non fanno altro che ripetere quanto probabilmente aveva già ottenuto dalle ricerche effettuate precedentemente: risposte secche che spesso rappresentano l’unico framework conosciuto da chi risponde. Non il massimo della vita per chi brancola nel buio. Se uno volesse davvero rispondere dovrebbe quanto meno supportare la propria risposta con qualche informazione specifica riguardo almeno un paio di punti di forza che l’hanno spinto verso un prodotto piuttosto che verso un altro.

Conosco linguaggio X e linguaggio Y, per un progetto pensavo di utilizzare PHP, mi consigliate il miglior framework?
Qui la carne al fuoco è davvero troppa. Perchè oltre all’argomento framework, già sufficiente per far scoppiare il flame, si gioca anche il carico del linguaggio di programmazione in un ambiente in cui sicuramente sono presenti sviluppatori che utilizzano diversi linguaggi (più della religione). Scordatevi risposte costruttive perchè in pochi minuti arriverà la risposta “PHP? Ma sei matto? Usa Python! Al massimo Java.”. Ovviamente chi risponde aggiungerà di essere sviluppatore di lunga data e che quindi ha dalla sua l’esperienza per sparare a zero su tutte le altre cose che oggi non usa (e che magari ha provato solo per un Hello World anni e versioni prima).

Personalmente in situazioni del genere passo in punta di piedi, raso muro, facendo attenzione a non smerdarmi. Anche un consiglio pensato bene verrebbe sommerso dal resto. Tempo perso.

Framework? Ma fattelo da solo!
Sì, nel 2012, c’è ancora chi preferisce reinventare la ruota e perdere tempo a lavorare sullo strumento piuttosto che sul prodotto. Di situazioni del genere si sono stufati anche i Maya che ovviamente hanno deciso di darci un taglio, proprio quest’anno. Serve davvero che affronti i problemi legati a una scelta di questo tipo? Qualità del prodotto ottenuto dallo sviluppo interno contro quello portato avanti da un core team (già di per sè molto skillato) più gli occhi e le mani di centinaia se non migliaia di altri sviluppatori che partecipano alla causa nei più disparati modi. Documentazione per eventuali nuovi sviluppatori da introdurre sui progetti. Sicurezza, questa sconosciuta. Standardizzazione dei processi. Devo continuare? Magari in un altro post.

Meglio Zend Framework o meglio Symfony? Ed il migliore in assoluto?
Ma di cosa stiamo parlando? Migliore rispetto a cosa? Le componenti in gioco sono talmente tante, spesso nemmeno paragonabili, che non è possibile affermare “questo è meglio” in modo assoluto. Un prodotto potrà essere più interessante su una certa funzione e pagare dazio su altre. Molte funzioni, non essendo coincidenti, non possono essere paragonate perchè si finirebbe con il dire “però, effettivamente, questo serve anche per fare altro…”. Ovviamente tutto questo discorso si riferisce a prodotti di un certo livello, già affermati e che rispettano dei vincoli minimi per essere tenuti in considerazione per progetti in quel campo enterprise di cui ci piace tanto parlare. Quali sono questi vincoli? Alcuni secondo me sono i seguenti:

- documentazione
- community
- risorse disponibili (plugin, bundle, estensioni…comunque vengano chiamate)
- diffusione (per future collaborazioni, cercare nuovi sviluppatori…la diffusione di un framework fatto in casa è pari a zero)
- case history di rilievo (sapere che si può arrivare almeno fino a quel punto X aiuta)
- …

Quindi una volta appurato tutto questo una possibile risposta è “Io mi trovo bene con questo framework per questo, questo e quest’altro motivo. Ho invece avuto alcuni problemi per fare questa cosa e non mi piace molto la soluzione messa a disposizione…”.

Ok, ma tu cosa mi suggerisci allora?
Il mio consiglio è sempre quello di scremare il più possibile tra i papabili eliminando quelli che non rispettano i vincoli che il singolo sviluppatore ritiene essere più importanti per lui, il suo team, ed il tipo di progetti che affronta. Fatto ciò sporcarsi le mani ed investire qualche ora realizzando un’applicazione non proprio banale, e questo non implica il fatto che debba essere “grande”, per arrivare a prendere una decisione in base ai propri gusti ed alle proprie necessità. La decisione dopo tutto è piuttosto personale e nessuno dovrebbe sentirsi autorizzato a dire “noooo usa questo!” piuttosto che consigliare in altro modo. Quando si avrà la prima versione della risposta “io mi trovo bene con…” molto probabilmente si sarà individuato il framework più adatto allo sviluppatore/scenario in questione.

Via al flame.

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.