mercoledì 20 febbraio 2008

A programming joy, a deployment nightmare

È la sensazione che sto provando nel passaggio da PHP a Python: il linguaggio di per sé è bellissimo, lo sappiamo tutti. Certo, ci sono più web framework in giro che partiti nel nostro Parlamento, ma evitando quelli troppo grossi che-fanno-tutto-loro (i framework, dico) e ravanando un po’ in giro si trovano soluzioni flessibili, potenti, snelle, solide. SQLAlchemy è meraviglioso, la sensazione è che puoi scendere low-level quanto ti pare, oppure usare le astrazioni più elevate anche se hai un database già strutturato e per giunta in maniera sofisticata. Mako per i template è non di meno una gioia, chi viene da PHP non fa fatica. Li ho conosciuti entrambi grazie a Pylons, che poi ho mollato in favore di CherryPy.

Finché usi il server HTTP incorporato tutto fila liscio, l’incubo comincia quando vuoi mettere la tua applicazione dietro Apache o Lighttpd. Dicono che di Apache non hai bisogno se prevedi meno di 50 hits al secondo. Sarà, ma è brutto chiedere ai proprî clients/clienti di andare su http://www.example.com:8087 (o quello che è). Si può mettere CherryPy in ascolto sulla porta 80, ma ci vogliono i permessi di root, mentre un vero server web dopo aver aperto la porta TCP quei privilegi li perde: come si fa fare una cosa del genere a CherryPy? Soprattutto, di un server web regolare hai sempre bisogno perché potrebbero girare altri siti sullo stessa macchina, tutti ovviamente sulla porta 80 e con tecnologie diverse (PHP, Perl, Ruby, CGI varî, file statici etc.).

Le ho provate tutte: FastCGI, WSGI, mod_python... Un bagno di sangue. Ho seguito scrupolosamente la documentazione ma continuo a ottenere strani «Unrecoverable error in the server» e non trovo nei log niente che mi aiuti a capire. Saranno tre o quattro giorni che bestemmio.

Alla fine, l’unica cosa che funziona è il succitato server interno su localhost:8087 (o quello che è) e l’unica soluzione è continuare a usare quello. Vale a dire che l’unica configurazione funzionante è questa [reverse proxy]: e quanto ci ho messo? due minuti! ma non si può certo parlare di integrazione in Apache (quella che ci sarebbe stata se fossi riuscito a far funzionare, per esempio, mod_python).

Ora, se la comunità Python si chiede perché il suo linguaggio preferito non sfonda nel web (e per sfondare intendo sia adozione massiccia da parte di aziende e hoster che possibilità di attrarre sviluppatori da altri linguaggi) la risposta non ha a che fare col linguaggio - che, ripeto, è meraviglioso - e nemmeno coi framework: non è il rapid development che manca, semmai il rapid deployment (se il termine significa qualcosa). È come se la filosofia There is more than one way to do it per cui Perl è stato tanto criticato si fosse spostata dalla programmazione alla sistemistica.

sabato 16 febbraio 2008

RESTful PHP and SQL

Con un titolo del genere potrei essere accusato di keyword spamming, ma gli è che, ogni tanto, un piccolo contributo bisogna darlo.

Ho un debole per i progetti di nicchia, fra gli altri ricordo Avelsieve e HR-XSL.

giovedì 14 febbraio 2008

(and very fast typing) -- Guido got it

Some frameworks emphasize that the effort of getting started is low. But this is really only so to the extent that you’re trying to do something very similar to something that’s been done a 1000 times before, so that all the defaults in the framework and the setup utilities are all doing exactly what’s needed. This (and very fast typing) is what makes the first Rails movie possible.

But what if you need to into an existing authentication framework? What if you need to hook into an existing database schema that maps to in-memory objects in a different way than the framework’s ORM tool?

Guido van Rossum, due anni fa.

Cfr. 1, 2.

venerdì 8 febbraio 2008

A POST-to-anything gateway for portable ReSTful services?

Le idee alla base di ReST sono affascinanti, ma non tutte le configurazioni possibili di client e server consentono l’uso indiscriminato di PUT o DELETE. Il colmo è raggiunto dalla libreria cURL, il cui binding per PHP rende disponibile GET, POST e PUT ma non DELETE!

ReSTful a 3/4?

Riscriversi a manina il metodo DELETE a colpi di fsockopen()?

Il problema può presentarsi in ogni linguaggio. ReST ci ha fatto riesumare il Vero HTTP; insieme ad un paio di metodi che la maggior parte degli sviluppatori di software client ha ragionevolmente ritenuto in disuso. Come stupirsene? Il primo e ultimo ricordo che ho di HTTP PUT risale ai tempi di Netscape Composer; ed è inutile dire che allora come oggi nessun hosting provider lo accetta. Anziché farti “piazzare risorse” preferiscono farti “caricare file” via FTP o al massimo tramite un’interfaccia web e il solito metodo POST.

E allora? Allora l’idea è questa: configurare un servizio web ReSTful che più ReSTful non si può, ed ai client che non sanno inviare la richiesta:

DELETE /user/john
offrire la possibilità di inviare
POST /delete/user/john
ottenendo gli stessi effetti. Sembra un buon compromesso, no?

Addendum: non avevo notato questo.

venerdì 1 febbraio 2008

Alternativa a chroot e nspluginwrapper: Firefox a 32 bit in un sistema Debian a 64, con tutti i plugin funzionanti

Questa mini-guida è in un certo senso un backport da Ubuntu a Debian ed è fortemente basata su questo post.

I primi pacchetti che dovete installare sono naturalmente ia32-libs e ia32-libs-gtk.

La differenza principale rispetto a Ubuntu è che vi servirà un pacchetto aggiuntivo: lib32nss-mdns. Ho dovuto smadonnare non poco per capire che era questo il motivo per cui Firefox non risolveva i nomi.

Se avete etch, non troverete questo pacchetto ma avrete due possibilità: la prima è tirar su un sistema misto (ma non garantisco nulla), la seconda è l’accrocchio suggerito in /usr/share/doc/ia32-libs/README.Debian, cioè qualcosa come:

dpkg -X libnss-mdns_0.9-0.2_i386.deb /emul/ia32-linux
ldconfig

Ora non vi resta che scaricare Firefox x86 da mozilla.com e scompattare l’archivio. L’ultima modifica che dovete fare è aggiungere, all’inizio dello script firefox:

export GTK_PATH=/usr/lib32/gtk-2.0

e a questo punto potete installare i plugin a 32 bit nella sottocartella plugins come se foste in un normale sistema x86.

Vi conviene rinominare la cartella firefox in firefox32 e metterla magari in /opt (è il percorso a cui faremo riferimento negli esempî seguenti).

Flash e Java sono fra gli esempî più comuni di plugin disponibili solo a 32 bit. Per quanto riguarda i contenuti QuickTime, MPEG etc., Mplayerplug-in è open source ed è disponibile a 64 bit, ma a questo punto vorremmo installare tutto nel browser a 32 senza essere costretti a cambiare il browser a seconda delle pagine che visitiamo. Ecco come fare: installate comunque il pacchetto a 64 bit:

aptitude install mozilla-mplayer

non tanto per il plugin in sé ma perché vi installerà il pacchetto MPlayer come dipendenza, e i file independenti dall’architettura in /etc e in /usr/share. Dopodiché scaricate manualmente il plugin a 32 bit (stable|testing|unstable), scompattatelo in una directory provvisoria, e copiate manualmente i file *.so e *.xpt nella directory dei plugin.

dpkg -X mozilla-mplayer_*_i386.deb directory/
cd directory/usr/lib/mozilla/plugins
cp -v *.so /opt/firefox32/plugins/
cp -v *.xpt /opt/firefox32/plugins/


In pratica, un plugin a 32 bit lancia Mplayer a 64 bit, cosa perfettamente possibile, non trattandosi del linking di una libreria ma del lancio di un’applicazione esterna.