Di nuovo in sessione plenaria, ci arriva la voce dell’engineering di Google con Brian Fitzpatrick, una frizzante parentesi, di sicuro il talk più pieno di verve di tutte le giornate. Fitzpatrick vuole parlarci del buon marketing, ovvero come rendere un buon prodotto attraente, senza dover mentire su di esso: un talk che è un po’ marketing, un po’ customer service, un po’ usabilità. C’è un minimo di imbarazzo, ed un leggero glissare, ad una domanda finale piuttosto scontata - perché Google non rende disponibile il codice di tutti i propri programmi? - ma sicuramente le coloratissime slide dell'ingegnere Google (in realtà un umanista convertito sulla via di Damasco) non rimarranno dimenticate.

Si ricomincia nel primo pomeriggio con Alex Martelli ed il Google App Engine (GAE), la tanto discussa offerta di hosting di applicazioni (per ora solo web app Python, ma Martelli promette novità in futuro) sulla potente infrastruttura di Google, con qualche ovvio limite sui servizi offerti. Dopo averci parlato dell'interfaccia di configurazione per il deployment, Martelli si concentra sul GAE SDK per lo sviluppo di applicazioni in locale. Questo richiede Python 2.5 ed offre un file di configurazione della web app in formato YAML; il deployment sul server locale, ovvero dev_appserver, avviene con dev_appserver.py. L’applicazione proposta è delle più complesse, ovvero Hello, world!, ma viene mostrato subito come usare il package di logging e gli handler della request, sia del GAE che dell'interfaccia WSGI.

<center></center>

Il package google.appengine.ext.webapp offre non solo un semplice supporto a WSGI, ma soprattutto la consapevolezza del main, che permette di semplificare la gestione dello stato delle richieste. Viene poi spiegato come servire file statici, usando l’URL mapping nel file di configurazione YAML, e si discute la natura di sandbox del GAE: non vi è alcun accesso al file system, né possibilità di usare i socket, piuttosto che sottoprocessi e thread. Il login degli utenti usa di default quello degli account Google, ma lo sviluppatore può utilizzare, gestendolo però a mano, qualsiasi sistema alternativo. Dopo aver discusso l’invio di e-mail ed urlfetch, le slide finali si dilungano alquanto sul Datastore del GAE, di tipo relazionale SQL, ma molto limitato.

Alle 16.00 scatta l’ora dell’inglese Menno Smits e di IronPython. Vediamo brevemente Python in azione su .NET - in mattinata Bajo, il più convincente sosia vivente di Stallman, aveva mostrato il debugging e profiling con VS - ma soprattutto si parla di una bella applicazione IronPython, il foglio di calcolo Resolver One. Ma andiamo con ordine. Smits spende due parole (per forza di cosa una panoramica non certo esaustiva) su .NET e sul progetto IronPython, sottolineando il grosso vantaggio di avere a disposizione le librerie .NET, anche di terze parti. Sorvola velocemente sul progetto IronClad, nato per usare in maniera trasparente in IronPython le librerie Cython, ovvero quelle del compilatore Python standard.

Usa poi la shell interattiva di IronPython, ovvero ipy.exe (dopo aver configurato la variabile d’ambiente IRONPYTHONPATH nella cartella, che ospita l'installazione standard di Python, almeno 2.4) per creare da linea di comando, una WinForm, con relativo gestore dell'evento clic su un Button. Egli illustra quindi un'altra applicazione, un catalogatore di file MP3, che usa la libreria ID3Sharp per estrarne gli ID3, ed un pattern già tipico di F#, e che diventerà ricorrente man mano che prende forma il Dynamic Language Runtime (DLR): usare il designer di Visual Studio per creare una form e compilarla come assembly, importare l’assembly inIronPython (o IronRuby, o tutto quello che conseguirà), ed usarlo.

Infine, vediamo in azione il già citato Resolver One, un foglio di calcolo per ambienti finanziari che usa Python come macro language, sviluppato con eXtreme Programming e che è forse oggi la più grande applicazione IronPython esistente: il fatto che sia possibile creare un foglio di calcolo con circa 35.000 linee di codice la dice lunga su quella che è la vera forza di IronPython, ovvero l'avere lo sterminato universo .NET alle spalle. La sorpresa più bella arriva però dalle domande finali: mentre tutti chiediamo a Smits se è previsto un IronPython integrato in Visual Studio, tocca ad Hettinger, presente fra il pubblico, annunciare la disponibilità di IronPython Studio, un progetto sponsorizzato da ClariuS Consulting e creato grazie alla Visual Studio 2008 Shell, del quale ci aveva parlato su P.it Paolo Raviola. Un'avvertenza: anche se di Python non ve ne importa assolutamente nulla e volete continuare a programmare in C# o VB, finché morte non vi separi, usando IronPython Studio comincerete ad imparare come funziona davvero .NET, dietro le quinte dei form designer. Da provare.

• Pubblicazioni correlate:
• 13-05-2008 PyCon Due, un resoconto in esclusiva per P.it (1/6)
• 14-05-2008 PyCon Due, un resoconto in esclusiva per P.it (2/6)
• 15-05-2008 PyCon Due, un resoconto in esclusiva per P.it (3/6)
• 16-05-2008 PyCon Due, un resoconto in esclusiva per P.it (4/6)
• 22-05-2008 PyCon Due, un resoconto in esclusiva per P.it (6/6)