*scritto a 4 mani con Cesare di Mauro*
Dopo aver cercato di riassumere, speriamo al meglio, i (complessi) keynote della giornata d’apertura, passiamo a vedere quel che è successo nel weekend.
Come ormai consuetudine, nella 3 giorni PyCon, il “vero” inizio della conferenza è in realtà proprio il sabato, quando cioè si delineano i percorsi e si addensa il grosso dei talk proposti.
Lo schema delle tre track parallele è stato riutilizzato anche quest’anno.
Divise in “Scoprire Python”, “Diffondere Python” ed “Imparare Python” si rivolgono ad un pubblico differente in termini di esperienza per quanto riguarda il linguaggio.
Non essendo ancora in possesso del dono dell’ubiquità, abbiamo cercato di privilegiare i talk che potessero risultare più interessanti da esporre.
Alle 9 abbiamo scelto di privilegiare l’intervento “Controllare il cloud con Python“.
Il cloud computing è di questi tempi, al pari della virtualizzazione, una delle buzz word più in voga.
La medaglia ha chiaramente sempre due facce. Il lato positivo è che se molte persone ne parlano è perché sono interessate all’argomento e vogliono capire se l’adozione in un ambiente reale possa giovare alla produttività.
Allo stesso tempo, quando molti affrontano lo stesso tema è normale trovare interventi che fraintendano la tecnologia o siano privi di un impianto di analisi critica davvero efficace.
A posteriori, almeno dal nostro punto di vista, devo dire che siamo rimasti un po’ a metà strada tra un sentimento di delusione e soddisfazione.
Nonostante l’abstract menzionasse chiaramente che il talk avrebbe parlato di Amazon Web Services, ci saremmo aspettati forse una trattazione più ad ampio raggio.
O almeno questo ci suggeriva il titolo stesso.
Poco male, il secondo intervento della fascia mattutina che abbiamo deciso di seguire è stato Erlang + Python, l’unione di due mondi.
Lawrence Oluyede pur mostrando un’evidente giovane età è un Pythonista di vecchia data e garanzia come speaker. Quel che interessava particolarmente era capire l’interazione tra il linguaggio protagonista della conferenza ed Erlang, che sta avendo molta attenzione in questo ultimo periodo anche da grossi calibri come IBM.
Il tempo tiranno a disposizione non ha consentito di mettere in mostra un esempio di architettura particolarmente sofisticata ma sufficiente per far capire quali siano i vantaggi nell’utilizzare un approccio di tipo “misto”.
In generale, l’aumento della complessità delle applicazioni di questi ultimi anni ha di fatto reso molto difficile la realizzazione di progetti monolitici in cui tutte le fasi di sviluppo e le funzionalità dell’applicazione stessa sono coperte da una sola tecnologia.
Anche nel talk finale su XNA ed IronPython, di cui parleremo domani, si è fatto riferimento a questa necessità.
L’imperativo dev’essere sempre The right tool for the right job.
Ed Erlang, linguaggio funzionale non tipizzato reso Open Source nel ’98, brilla particolarmente in situazioni di concorrenza spinta.
La gestione dei thread a dire il vero è già buona con Python, ma è chiaro che sfruttare una tecnologia sviluppata ad hoc e che garantisca prestazioni ottimale quando sia previsto un certo livello di parallellismo possa essere un plus da sfruttare.
D’altra parte non è un caso che ad esempio il mondo Java abbia mostrato un qual certo interesse.
Subito dopo il coffee-break è stata la volta dell’intervento di Cesare Di Mauro: Beyond bytecode: a wordcode-based Python.
Non mi soffermerò molto sui dettagli tecnici perché lui stesso ha preparato un post nella rubrica Pensieri da Coder.
Come anticipato nei giorni scorsi, c’è stata un’impennata di interesse ed una ricerca verso il miglioramento delle prestazioni dell’intera infrastruttura Python, vero punto debole e che ormai sente il peso di un’implementazione non più al passo con i tempi, come sottolineato anche nel keynote d’apertura dallo stesso Van Rossum.
Cesare, con una tempistica davvero ragguardevole (anche considerando che lui solo ha lavorato a questo progetto), ha cercato di ottimizzare praticamente tutti gli stadi della pipeline d’esecuzione di Python: cinque su sei a voler essere precisi.
Un lavoro enorme che ha lasciato abbastanza di stucco i numerosi addetti ai lavori presenti al talk e che, mi piace sottolineare, ha suscitato l’interesse di Fredrik Lundh, sviluppatore presso la sede di Google Zurigo il quale ha lavorato anch’egli nella medesima direzione seppur perseguendo un progetto differente (l’Unleaded Swallow accennato nel resoconto del day one).
Ricevuti i meritati onori e risposto alla trafila di domande tecniche, ci siamo divisi per poter seguire due diversi talk.
Considerato l’ambito privilegiato dello sviluppo su web ho optato per il percorso Imparare Python, dedicato in questo caso a Turbogears 2.
Avendo esperienza del solo Django, ero curioso di capire se questo ennesimo prodotto fosse in grado di soddisfare le mie (e non solo mie) esigenze di sviluppatore.
Uno dei “problemi” del linguaggio creato da Guido Van Rossum è il dilagare di framework, un problema comune ad altre tecnologie come Java stesso.
A volte si sovrappongono oppure cambiano radicalmente da una versione all’altra provocando così la rottura delle dipendenze che manda potenzialmente in fumo il lavoro di chi ha progettato l’architettura di un intero sistema o applicazione.
E soprattutto mancano spesso di quel quid che possa davvero far pendere l’ago della bilancia verso un prodotto specifico.
Detto in parole povere manca(va) un equivalente a Ruby On Rails, vero asso nella manica degli sviluppatori che adottano l’altro linguaggio dinamico in ascesa nella scala di gradimento. L’altra metà del cielo vista la non particolare convergenza delle due comunità (non voglio usare la parola odio ma per parafrasare la canzone dell’Olmo di Mai Dire Gol “Non c’è simpatia fra di noi”).
Mancava perché la seconda release di Turbogears è stata sviluppata proprio nell’ottica dei concetti fondanti RoR.
In primis offre un framework full-stack, ovvero la possibilità di confezionare un’applicazione web sviluppata in toto con quella determinata tecnologia.
Non ci si concentra più su un solo aspetto ma sull’intero stack appunto dell’applicazione stessa.
I vantaggi diventano evidenti quando si pongono davanti al team di sviluppo problemi di scalabilità anche in previsione che l’utilizzo cresca nel tempo con ordini di grandezza.
Dal punto di vista tecnico, si basa fortemente su Pylons ed implementa meccanismi di prototipizzazione del progetto che evolve seguendo un approccio dettato da metodologie agili ed il cambiamento dei requisiti funzionali.
Oltre allo unit testing va segnalato il supporto a molteplici formati di dati (come JSON e RSS) che rendono lo sviluppo più semplice ed immediato, dove per immediato, come fatto notare dallo stesso relatore, si intende la scrittura di meno righe di codice da dover debuggare recuperando tempo da dedicare piuttosto alla logica dell’applicazione.
Una bella presentazione seppur conclusa con il classico malfunzionamento che però ha potuto mostrare la rinnovata gestione degli errori, molto utile in fase di sviluppo.
Cesare ha invece seguito il talk Distribuire programmi Python con PyInstaller e riporto quindi direttamente il suo report.
PyInstaller è maturato molto e sembra la soluzione migliore per quanto riguarda la distribuzione di pacchetti che trasformano in “applicazioni standalone” quelle scritte con Python.
I vantaggi rispetto a progetti più blasonati come Py2EXE risultano nella possibilità di distribuire applicazioni multipiattaforma, risolvendo inoltre brillantemente anche il problema delle dipendenze, che spesso affligge gli altri prodotti.
Questo grazie all’uso di una cartella temporanea in cui vengono decompressi i file in modo da riprodurre un ambiente del tutto simile a quello che si avrebbe lanciando l’applicazione dalla cartella in cui risiederebbe se fosse installata.
In questo modo si è riusciti ad aumentare enormemente la compatibilità.
Altra caratteristica interessante è che, almeno per Windows, i file eseguibili e le DLL utilizzate vengono compressi con UPX, per cui si ottiene un ottimo risparmio di spazio sia per il pacchetto creato sia nel momento in cui questi file vengono decompressi nella cartella temporanea.
Purtroppo esistono dei casi in cui non riesce a riconoscere tutte le dipendenze, oppure inserisce nel pacchetto più file del previsto, ma è possibile porre rimedio specificando in un apposito file i path di esclusione e di inclusione, per cui alla fine è sempre possibile ottenere un’applicazione funzionante.
Terminato il lauto pranzo, è stata la volta di PyPy 1.1: presente e prospettive future.
Antonio Cuni, dottorando presso l’Università di Genova, aveva presentato il progetto PyPy nell’edizione passata.
Quest’anno quindi si è sorvolato sull’impianto tecnico della promettente soluzione, cercando di mettere in luce i progressi raggiunti dalla versione 1.1 rilasciata pochi giorni fa.
Ci sono voluti circa due anni per questa nuova release ma i risultati lasciano ben sperare soprattutto sul fronte compatibilità.
Qui di seguito la summa delle caratteristiche più rilevanti:
- Compatibilità piena con Cpython 2.5 (alcuni test condizionali sono stati logicamente modificati ad hoc)
- Miglioramenti di prestazioni
- Introduzione di CTypes che permette di scrivere estensioni compatibili sia con CPython che PyPy stesso
- Funzionalità di sandboxing
- Tentativo di portare PyPy su sistemi embedded con il supporto a Nokia PyMaemo
Il talk scelto per la fascia antecedente all’ultimo coffee-break è stato invece PyHP – The Python Hypertext Preprocessor.
Pur non apprezzandolo per tutta una serie di motivi, bisogna dare atto che il web, quando non parla Java e .NET, parla essenzialmente PHP.
Lo stesso WordPress dal quale scriviamo quotidianamente è realizzato con questo linguaggio, come buona parte delle piattaforme “2.0” siano essi CMS, forum board o blog appunto.
La vera forza, oltre al dilagare di script e porzioni di codice già pronte, è anche la velocità di sviluppo di soluzioni medio-piccole.
PyHP cerca di sposare alcuni dei concetti su cui si basa PHP ma con il vantaggio, indubbio, di utilizzare un linguaggio più elegante e più ricco dal punto di vista semantico come Python.
I ragazzi di OS3 hanno dunque sviluppato un nuovo modulo per Apache che si pone ad un livello di astrazione più alto rispetto all’attuale ed a volte macchinoso modpython.
La gestione delle sessioni risulta molto più semplice e tutti i dati impostati, per ovvie ragioni di sicurezza restano sul server.
Il linguaggio di embedding nelle pagine è naturalmente Python, con un supporto nativo alla compressione gzip.
Si sta lavorando nella direzione dell’utilizzo di un sistema di caching ed al momento ci si può appoggiare al solo MySQL, che comunque in ambito web resta la soluzione Open Source largamente più diffusa.
Un altro progetto presentato nello stesso talk e davvero interessante è LiWe.
Si tratta sostanzialmente di un altro framework, ma con qualche caratteristica che vale la pena di citare.
Mentre gli altri prodotti, come i già citati Turbogears e Django, solitamente utilizzano una filosofia del “prendere o lasciare” (cioè difficilmente consentono uno sviluppo che si discosti dall’approccio previsto dal team che ha rilasciato quel dato framework), LiWe si basa su una struttura a moduli, di cui i due principali sono detti macro e si identificano fondamentalmente con il client side ed il server side.
Non disponendo di una grossa mole di interdipendenze è possibile prendere solo i “pezzi” dell’infrastruttura che fa al caso nostro.
In un contesto AJAX risulta molto importante la possibilità offerta di ricaricare solo i moduli inclusi nella richiesta al server, il quale utilizza inoltre un meccanismo load on demand, in modo da non appesantire il carico delle normali transazioni effettuate con il dispositivo client.
Le LiWe sono facilmente estendibili e cosa molto importante, funzionano anche con JavaScript disabilitato, in modo da non inficiare il livello di accessibilità di un’applicazione web; caratteristica molto importante se si ha a che fare con un’utenza che affetta da disabilità di varia natura e costretta ad usare per esempio lettori di schermo.
[Guido Van Rossum illustra l’architettura di Google App Engine]
Il talk di chiusura della giornata ha visto nuovamente la presenza sul palco di Guido Van Rossum con la presentazione di Google App Engine.
E’ un progetto nel quale la grande G crede fermamente e visti i risultati non si può darle torto.
Si tratta sostanzialmente di una piattaforma di hosting la quale si appoggia completamente all’infrastruttura offerta da Google e che gestisce richieste http(s).
Offrendo pieno sviluppo “out-of-the-box” (cioè che funziona senza dover essere modificata ad hoc), presenta il vantaggio di scalare davvero molto bene, a partire dalle applicazioni molto piccole, il cui utilizzo rimarrà gratis, fino a poter servire realtà enterprise.
Attualmente ci lavorano circa 150 mila sviluppatori con un bacino d’utenza stimato in circa 50 milioni di utenti.
Tra i punti più importanti occorre segnalare che prevede:
- SDK più la documentazione allegata
- meccanismo di sandbox che previene in particolar modo gli errori accidentali (come la cancellazione)
- database scalabile ma non basato su SQL
- meccanismo di memcache
E’ stato inoltre aggiunto il supporto a Java anche se il core resta focalizzato comunque in ottica Python il cui client dialoga direttamente con il datastore offerto da Google tramite le Remote API.
Si sta lavorando inoltre al supporto del protocollo XMPP (largamente utilizzato in sistemi di comunicazioni di tipo sincrono ed in contesti aziendali) ed al background workflow.
Ovviamente è un sistema sviluppato non per la gloria ma per generare revenue: i costi a carico dell’utente (qualora la soglia prevista sia superata) vengono conteggiati in base al traffico in entrata, uscita, ore CPU, dati salvati ed email inviate (per proteggersi dal pericolo spamming) ed è possibile inoltre appoggiarsi al sistema Google Checkout.
Data però la facilità di utilizzo ed il panorama free piuttosto scarso di soluzioni adeguate vale però la pena dare un’occhiata al progetto AppEngine, se non altro perché solitamente i ragazzi di Google raramente sbagliano e quindi potrebbe rivelarsi un prodotto interessante sia per un uso amatoriale che aziendale.
Questo è tutto per la seconda giornata della PyCon Italia 2009.
Prima di concludere ribadiamo il suggerimento della puntata precedente: tenete sempre d’occhio le pagine dei singoli talk ospitati nel programma, perché verranno linkate le slide e successivamente i webcast dell’evento.
A domani dunque per l’ultimo resoconto.
