Alberto Mucignat

Negli ultimi giorni ho giocato un po' con Rails e Django, giusto il setup di una piccola applicazione, tanto per vedere come funzionano.

La scelta tra i due è ardua, ma credo che per ora utilizzerò Django, lo trovo più comodo e intuitivo. Devo ancora però vedere come funzionano le interfacce AJAX nei due modelli. Ovviamente, questo è uno dei punti più interessanti e importanti.

Per ora alcune riflessioni iniziali e da profano (quindi incline alle gaffe colossali):
- ci vogliono pochi minuti per avere un prototipo
- la programmazione è intuitiva (model/view)
- si fa solo il necessario, è importante l'efficenza
- ci si concentra principalmente a strutturare i dati (contenuti) e configurare le viste (pagine web)
- il web è sottointeso, l'interfaccia web quasi nativa
- il content management è quasi una conseguenza naturale. Strutturi i contenuti e li navighi/gestisci poco dopo.

Per chiudere, magari la sparo grossa, ma ho l'impressione che i sistemi di content management siano ormai superati. Con questo livello di efficenza, questi framework sono il content management personalizzato.

È come se non servissero gli enormi baracconi di una volta, tanto le funzionalità comuni sono espresse ormai a livello di API. Il valore è nella possibilità di customizzazione.

Che dire... tutto ciò è copiaincolloso!

Da qualche tempo sto testando ActiveCollab, un software web per la gestione di progetti, scritto in PHP. Interfaccia pulita e chiara, facile da usare e abbastanza completo. Unica pecca, è comunque un software ancora troppo feature-based, piuttosto che user-based.

Ultimamente c'è stata parecchia discussione sulle future features, a cui ho partecipato entusiasta, proprio perchè ritengo che la base di partenza sia molto interessante per fare qualcosa di bello.

Forse a causa di questo palpabile interesse da parte di molti, lo sviluppatore a capo del progetto ha deciso di dare una sterzata commerciale non da poco:

activeCollab 1.0 and future core development will be developed exclusively by company that I started and community will be able to contribute by developing plugins, themes and translations

Copione già visto. È sucecsso senza problemi anche per molti altri progetti (lo stesso linguaggio PHP, ad esempio). Però qualche dubbio è lecito, specie dopo le repliche alle critiche della community. Alcune strane risposte mi hanno infatti alzato un warning istintivo.

Sicuramente questi modelli di business sono delicati da gestire, soprattutto all'inizio.

Lulu.com ti permette di pubblicare un vero libro senza dover per forza conoscere un editore (via Web at work).

Beh, se hai un libro nel cassetto -e chi non ce l'ha?- allora adesso non ci sono più scusanti.

Tempo fa avevo parlato dell'utilizzo delle breadcrumbs in un sito web.

Adesso trovo segnalato in rete un report sull'uso delle breadcrumb per la navigazione, realizzato analizzando quasi 5000 siti web e conducendo dei test con 14 partecipanti.

Leggo anche alcune annotazioni di GUUUI a proposito.

Una prima considerazione che mi conforta: le breadcrumb non sono utilizzate per sapere dove mi trovo in un sito web, anche perchè l'utente non ha chiaro il loro significato:

Participants described location breadcrumbs in the following ways:
- an indication of location
- the path they took to get here
- the keyword they wanted, when they wanted it
- an alternative to using the back button

Piuttosto le breadcrumb vengono utilizzate come i tag: costituiscono una possibilità per l'utente di avvicinarsi a quello che cerca e favoriscono la continuazione della navigazione:

The scenario where breadcrumbs were used most consistently was during the task of locating other "horror" DVDs. After finding the Pitch Black DVD page on the Walmart.com site, participants were asked to locate other available horror DVDs on the site. Nine out of 14 users (64%) noticed the breadcrumb labeled "horror" and clicked on it during this task.
When asked what they had clicked on and why, they generally responded that they were looking for the term "horror", happened to find a link to it on their way to using the back button or the search box, and clicked on it.

Ancora più importante, così come altri elementi e link delle pagine web, le breadcrumb possono evitare il comportamento click-and-back dell'utente:

Most participants made frequent use of the back button to find and refine their searches. [...] we often saw, after clicking through several pages of search results without finding the desired item, participants use breadcrumbs instead of clicking on the back button repeatedly to get back to where they wanted to be. When asked about how she arrived at the decision to use breadcrumbs instead of the back button one participant responded, "clicking 'back-back' is too much work."

Infine, la conclusione del report è liberatoria:

If a breadcrumb label happens to match what the user is looking for, and the user happens to see it, they may indeed use the links provided.

Messa così, la scelta delle breadcrumb è ancora più importante e, soprattutto, deve essere svincolata dall'idea di "luogo" o "percorso". Le breadcrumb devono darmi informazioni su come proseguire la navigazione verso quello che cerco.

Se c'è, l'errore è umano. Infatti a volte perfino gli enterprise si dimenticano di gestire gli errori. Come dire, anche JSP se non configurato bene...
ps: cliccate, così magari primaopoi se ne accorgono.

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.

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.

Scopro, con colpevole ritardo, dell'esistenza di un log analyzer chiamato AWStats. Potete confrontare le features con altri log analyzer nella pagina di comparazione.

Inoltre ho trovato anche V-webmail in quanto stavo valutando se aveva senso lasciare Imp/Horde.

Entrambe le applicazioni sono opensource e gratuite. La mia idea è che siano anche appetibili per essere proposte ai clienti.

Segnalo il rilascio di dblog 2.0, un software di blogging opensource creato da uno sviluppatore italiano. Dblog è scritto in ASP e funziona ovviamente solo su sistemi Microsoft.
Nel caso vi servisse, per qualche cliente che non vuole separarsi dalla sua costosissima infrastruttura MS (magari perchè ama buttare soldi in licenze), avete una soluzione molto completa e in costante sviluppo.
Non l'ho mai provato, ovviamente, ma la lista di features mi sembra interessante.