Alberto Mucignat

Segnalo un paio di raduni di sviluppatori che mi paiono interessanti.

Il GrUSP (Gruppo Utenti e Sviluppatori PHP italiani) organizza a Verona, il 18 Maggio 2007, la quarta edizione del PHPDay, articolata in due percorsi: Enterprise (PHP per le aziende) e Developer (di taglio tecnico). Ulteriori info, call for papers e possibilità di sponsorizzazione su www.phpday.it

PyCon Uno è la prima conferenza italiana dedicata al linguaggio Python che si terrà a Firenze il 9 e il 10 Giugno 2007. La conferenza si prefigge la divulgazione di Python e di dare visibilità agli sviluppatori professionisti, studenti, aziende e semplici interessati al linguaggio.

Purtroppo Pycon è a pagamento. Secondo me una scelta sbagliata perchè è la prima conferenza su Python in Italia e se si vuole diffondere l'adozione di un linguaggio magari all'inizio è meglio dare un'incentivo. Capisco l'esigenza di avere un budget, ma è così difficile trovare sponsor? Dico, al limite basta chiedere ad Andrea Beggi, no?

Invece, il PHP day è gratuito e ha anche un canale enterprise. Marchette a parte, è importante che la tecnologia non sia spiegata solo all'interno di gruppi ristretti di geek, ma che diventi un punto di discussione anche assieme alle aziende.

Con colpevole ritardo, segnalo queste slide di Ilia Alshanetsky:

- PHP and Performance (pdf)
- PHP Security (pdf)

Consiglio a sviluppatori php e sistemisti di leggersele molto attentamente.

Ilia sarà a Skien per l'eZ conference 2006, dove terrà un talk su php e alte prestazioni.

Quest'anno oltre a lui ci sarà uno dei padri di PHP, Rasmus Lerdorf, che ora lavora a Yahoo.

Stamattina mi sono svegliato con un pensiero fisso: la scalabilità delle applicazioni web non esiste. O meglio: la scalabilità non è quello che pensiamo comunemente. Cerco di argomentare.

Anzitutto, prendiamo le distanze e diamo le definizioni:

Performance is measured by the output behavior of the application. In other words, performance is whether or not the app is fast. [...] Scalability is the ability of the application to maintain good performance under heavy load with the addition of resources. (dal già citato, Digg PHP's scalability and performances)

Queste prime definizioni sono importanti: spesso si confondono le due cose. Le performance sono qualcosa di tangibile anche con un solo utente, la scalabilità ha a che fare invece con un alto carico.

Inoltre, solitamente per scalabilità si intende la capacità di un'applicazione di gestire un maggior numero di utenti, semplicemente aggiungendo nuovo hardware. Questo è il primo falso mito, quasi mai vero: aggiungere un server richiede comunque delle configurazioni e dei tuning, specie se all'inizio si lavora con un unico server. Situazione peraltro comune a tutti i siti medio-piccoli.

Il secondo falso mito riguarda Java. Premetto che conosco poco le applicazioni Java perchè ho sempre usato sistemi opensource. Le poche volte che mi è capitato, semplicemente le applicazioni non erano predisposte per scalare. Per esempio utilizzavano i cosiddetti local persistent object o cose del genere. E infatti trovo un articolo su OnJava che spiega egregiamente come non c'è differenza sostanziale sulla scalabilità tra Java, PHP e gli altri linguaggi web:

Scalability is mainly about the architecture of the application layer, and there is no one true panacea architecture that will work for all application architectures. The key to success is not in any particular technology, but in simplifying your server model and understanding all of the components of the application layer, from the HTML and HTTP on the front end to the SQL in the back end. Both PHP and Java are flexible enough to create scalable applications for those who spend the time to optimize their application architecture.

Insomma, non è il linguaggio in sè che aumenta la scalabilità, ma la capacità di sviluppare applicazioni scalabili. In altre parole:

For any technology, the statement “X doesn’t scale” is a myth. The reality is that there are ways X can be made to scale and ways to screw up trying. Understanding the possibilities and avoiding the pitfalls requires experience that doesn’t (yet) come in a box. (da IT Myth: IT doesn't scale)

Da queste considerazioni e dalla mia esperienza personale, traggo le seguenti conclusioni:

1. La scalabilità non si ottiene aggiungendo hardware, ma lavorando sodo e professionalmente sul lato architetturale dell'applicazione. Tradotto per i manager e i non tecnici: ci vogliono tempo e bravi programmatori. Meglio: ci vuole qualcuno con i cosiddetti.

2. La scalabilità è una cosa che si mantiene lavorando continuamente sulla qualità e soprattutto sui dettagli. Come al solito, ci vogliono metodo e persone in gamba (sistemisti, sviluppatori, manager).

3. Anche se un'applicazione è venduta come scalabile, quando ci sono problemi non basta solo aggiungere hardware.

Corollario 1: la scalabilità non viene da sola e costa abbstanza. Sorry.

Corollario 2: è molto difficile, nella maggior parte dei casi, lavorare allo sviluppo considerando anche la scalabilità. A meno che nel progetto non vengano inclusi particolari task a proposito.

Spesso mi hanno chiesto: le vostre applicazioni sono scalabili? Non sono mai riuscito a rispondere per bene a questa domanda. D'ora in poi darò il link a questo post.

PHP è diventato così maturo che si guarda ormai solo ai framework. Adesso li chiamano i framework di prossima generazione (via Fullo, chettelodicoaffà).

È chiaro che se dovessi iniziare a sviluppare un nuovo progetto, il primo passo sarebbe la scelta del framework. Per ora vedo bene Symfony in testa, seguito da altri tipo Prado, il che significa un passaggio a PHP5, con tutto ciò che ne consegue.

Di riflesso, la programmazione a oggetti e PHP5 ci riportano a parlare di MVC e su questo ci sono spunti interessanti da parte di qualche santone.

Ma in definitiva, perchè tanta attenzione ai framework?

Anzitutto perchè semplificano la vita agli sviluppatori. Poi, aggiungo io, perchè impongono un metodo di sviluppo comune, per evitare di creare quei software esoterici (via Ludo), dove alla fine riesce a metterci mano solo chi ha scritto il codice originario. Questo, in passato, ha portato molte aziende a riscrivere tutto o a cambiare sistema, con un danno economico notevole.

Insomma, i framework dovrebbero portare ad un rigore nello sviluppo e ad applicazioni PHP di classe enterprise, più professionali. Questo mette daccordo sia gli sviluppatori che le esigenze delle aziende. E forse è proprio per questo che la scelta di un framework diventa strategica e non dovrebbe essere affidata solo agli sviluppatori.

A quel che vedo, al PHPDay di Bari si parlerà parecchio di framework, a conferma delle mie impressioni. Se tutto va bene passerò a seguire i lavori, see you there.

Segnalo un autorevole parere che illustra il vantaggio di utilizzare PHP, in termini di scalabilità e performance.

Digg, noto motore di social bookmarking, con PHP garantisce un flusso di 200 milioni di pagine viste al mese con 3 web server. L'unica cosa che mi lascia interdetto è il fatto che vengono usati 8 db server (però piccolini), a causa di un non meglio specificato problema di scalabilità di MySQL: le applicazioni dinamiche che ho sviluppato negli anni avevano un rapporto medio di 3:1 tra i server PHP e MySQL.

Sulla scalabilità di PHP avevo già parlato a proposito del case study di Yahoo e del fatto che a Studenti.it abbiamo gestito picchi di traffico con un'infrastruttura abbastanza semplice, ma ben configurata.

(Via Fullo l'instancabile)

La pasqua ha risvegliato i miei buoni propositi.

Mi ero ripromesso di testare PIM e di parlarne sul mio blog, ma ultimamente non ho avuto molto tempo. Quindi mi scuso per il ritardo della segnalazione e procedo.

PIM è un sistema di gestione fatture e clienti, adatto ai professionisti, sviluppato con PHP/Symfony e un pizzico di web 2.0, disponibile in licenza Nuova BSD.

L'autore è Francesco Trucchia, altresì noto agli avventori di questo blog con lo pseudonimo Ciccio.

Esiste anche una demo online, che consiglio di visitare.

PHPit.net ha fatto una comparazione dei 10 principali framework php, che mi porta a fare alcune considerazioni:

- la maggior parte dei framework è ormai focalizzata su php5, ovvero conviene iniziare a migrare ragazzi
- quasi tutti i framework prevedono la possibilità di cambiare motore db facendo solo delle piccole configurazioni e quasi tutti hanno una mappatura ad oggetti: l'interoperabilità dei db è essenziale.
- tutti hanno un sistema di filtering dell'input utente, segno che attacchi tipo XSS e SQL injection sono considerati uno dei maggiori problemi del web, da risolvere alla radice

Ultima osservazione: solo metà hanno il supporto per AJAX, che secondo me è una delle tecnologie emergenti che non può mancare in un framework.

Da un paio di giorni è stata aperta le repository dello Zend Framework:

http://framework.zend.com/svn/framework

Intanto, già qualcuno dice che si tratta di un PEAR incompleto, ma fatto meglio.

Per le ultime notizie e informazioni: http://framework.zend.com/.

Ludo ci segnala una serie di articoli molto interessante, che racconta come è stata aumentata la scalabilità di un'applicazione web, grazie al refactoring di un'applicazione PHP di 50k righe con un'applicazione ROR da 5k righe. Ok, questa era per attirare l'attenzione.

In attesa del quarto articolo, vi segnalo quelli attualmente online:
- The adventures of scaling (stage 1)
- The adventures of scaling (stage 2)
- The adventures of scaling (stage 3)
- Question and answers

Sul numero di righe del codice dico subito che è una mera speculazione. ROR è un linguaggio a oggetti e quindi molto più "compatto" di un procedurale. Soprattutto, è normale che quando un'applicazione diventa vecchia, si porti dietro molte righe di codice inutili, di cui magari non è mai stato fatto il refactoring.

Comunque dice bene Ludo. E pare anche a me che ROR comporti una complessità notevole a livello architetturale.

In anni di lavoro a Studenti.it ho progettato diversi cluster, che servono in media 1 milione di pagine viste al giorno, con picchi di 2-3 milioni (oltre 200k utenti), durante i giorni degli esami di maturità. E l'architettura è abbastanza semplice, considerato quella messa in piedi per eins.de.

Per dire che PHP è molto più semplice da scalare, a mio avviso. O forse siamo stati bravi noi.

Rigirando la frittata, mi chiedo cosa significhi gestire la scalabilità in ROR, perchè quel che vedo è principalmente un lavoro su architettura e base dati, ottimizzando i vari passaggi che possono diventare bottlenecks.

Esperienza da leggere, comunque. Come quando si parla del cluster MySQL 5, della ricerca FULLTEXT e dell'ottimizzazione delle slow query. Negli ultimi giorni ho risolto così alcuni bottlenecks di eZ publish, a proposito di JOINs e INDEXes...

Gli sviluppatori di Gallery, noto software opensource per le gallerie di immagini, hanno rilasciato un paper (pdf) che identifica i key points per integrare diverse applicazioni scritte in PHP.

Come giustamento osserva Harry Fuecks, questo documento costituisce una base di partenza che potrebbe essere facilmente generalizzata.

Ho notato infatti che molte delle cose descritte le abbiamo adottate per lo sviluppo di IoScelgo, nell'integrazione tra parte editoriale e community.