I just wrote a script to easily download your FULL friendfeed stream. I mean: every post with comments, likes and even images and/or files. Enough for the good news: the bad news is that this a PHP command line script and you have to know how to run it. On a recent  OSX or Linux environment you should be ready to go. For Windows-ers it could be a little more difficult. Sorry.

Anyway, here is the features list:

• can fetch a private stream, giving your remote key
• locally downloads images and files (detects already downloaded things)
• upon subsequent runs, it tries to get only the newly added posts
• the output file is JSON
• it scales well!
• it’s free software (MIT license)

Download the scripts from Github (the link points to the project page, where you can read the README too. In this case you’re interested to the ffexp.php script).

You then may run it like:

php ffexp.php somefilename.json

As you may infer from the output file extension, the output is plain good JSON. This format is very handy for whatever thing you may need to do with the export file. But this is up to you (or your programmer friend).

As an example of JSON postprocessor I also wrote a converter that given your export file will render a fully functional HTML file, looking just like a Friendfeed page. It also automatically embeds the necessary JavaScript, CSS and even icon images. Download the ffexp2html from Github, open it, read the fine documentation and run it like:

php ffexp2html.php somefilename.json > somefilename.html

Now you can open the somefile.html file with your browser (no internet connection needed). You may find a generated output here.

Limits? Yes there are:

• No download of your DMs (don’t know exactly why, maybe a limit of the API. But I don’t care)
• You can download even entire rooms (just use the room name as the username), but it seems that there is a limit of how back you can go. Very high, but it exists.

I wrote a little script in PHP that converts your bookmarks file exported from Delicious in some other formats. The script, if you’re in the mood, is even easily extensibile if you provide it another “driver” to convert in another format (you write it and then plug it into the script. Pretty straightforward).

The script is ready to be used if you need to convert the file in CSV.

Run it like this:

php deliconv.php delicious_export.html > delicious_export.csv

Another idea on how to use the script would be to check every URL for its existance. It’s a pretty easy task if you know how to use the curl extension. I’ll leave it as an exercise for the reader :)

So, if know how to run PHP from the command line, grab the script here (remove the .txt extension).

There is also a Delicious XML exporter, out there.

Update: my friend Nicola D’Agostino has collected some other useful informations and tricks on the matter.

Another login, another password checking, another… Boooring. Given the nature of the application I decided that this time I could cut the mess down and go only with the «Use your Google account» “one click” login. Why not? Lot of people have an google account already and it’s OpenID!

The usual Google documentation page is this one. The good news is that if you follow this guide you probably will not need to read that whole page :) Later on you should integrate this very document with the Google one.

The first thing to know is that you are going to write an OpenID client/consumer. OpenID 2 protocol is indeed the system behind the whole client/server scenario from your application (the client) and the Google accounting system (the server). I have to assume that you know what that means (at an high level, at least). The examples here are in PHP and below I will provide some sample code for you to play with.

OK; so here are the relevant points:

• This one is theoretical, but it’s how Google deployed the OpenID protocol on top of his already existing authentication system. Normally, in a “pure” OpenID environment, during the login process the user will give you his/her openid identifier (an URL); using that identifier your program will discover (via the Yadis protocol) which is the corresponding server party to talk to for the authentication process. In the Google scenario you don’t know which is the user’s OpenID identifier (the user, of course, is not even aware that there’s something like “openid” involved in the way s/he logs in). You have NOT to ask her for her “google account”; you have to make him press a button or follow a link to “Login with your Google account”. But you DO know who you have to ask for protocol informations and not have to infer it from the user’s OpenID (technically, a discovery process is needed anyway). Upon a succesfull login you WILL have the user’s OpenID identifier; it’s something like a generated string, not choosen by the user and crafted by Google itself.
• You need a recent OpenID library that supports OpenID 2.0 XRI and Yadis discovery. This excludes (as for now) the Zend Framework OpenID component (it does support OpenID 2.0, but not the discovery part in the version Google uses). Too bad. You then need to go straight to the JanRain library
• Don’t bother thinking about Simple Registration (SREG): Google does support the more advanced (and useful) Attribute Exchange (AX) extension only
• Speaking of profile data, there is nothing much you can get: email, name and surname. I noticed that unless you specify each one as mandatory (within the AX request), the user is not even asked – by Google – to give them to you. There’s probably somethng I misunderstood, but this is it.

On your side, the login process will consist of two distint phases: one that initiates the login process the and one that finalizes it.

Normally you point your “Login with Google…” link to the script that implements the initiation phase (let’s say “login.php”). The finalize script (let’s say “finalize.php”) will be called by the Google server as per protocol. There is a lot more to know about the OpenID process, of course, but the library should hide the gory details for you.

The login script will immediately and trasparently forward the user to the real Google account login page. The finalize script will have the logic that checks if the authentication has been succesfull or not and act consequently.

I’m about to show you some code, but keep in mind that this is NOT valid PHP code; I want you to understand what’s going on rather than being able to just copy/paste. To further limit clutter I did not even add basic error checking. Please check the JanRain library examples for full fledged (and working) code.

So, for the login process:

# Requires the needed JanRain scripts
require_once "Auth/OpenID/Consumer.php";
require_once "Auth/OpenID/FileStore.php";
require_once "Auth/OpenID/AX.php";

# Setup the library (leaved blank on purpose).
# Will also create the $store variable used below
...

$consumer = new Auth_OpenID_Consumer($store);

$auth_request = $consumer->begin("https://www.google.com/accounts/o8/id");

# Create attribute request object (this is where you prepare the Attribute Exchange request)
$attribute = array();
$attribute[] = Auth_OpenID_AX_AttrInfo::make('http://axschema.org/contact/email', 2, true, 'email');
$attribute[] = Auth_OpenID_AX_AttrInfo::make('http://axschema.org/namePerson/first', 1, false, 'firstname');
$attribute[] = Auth_OpenID_AX_AttrInfo::make('http://axschema.org/namePerson/last', 1, false, 'lastname');

# Create AX fetch request
$ax = new Auth_OpenID_AX_FetchRequest();

# Add attributes to AX fetch request
foreach($attribute as $attr){
  $ax->add($attr);
}

$auth_request->addExtension($ax);

$return_to = sprintf("http://%s:%s%s/finalize.php", $_SERVER['SERVER_NAME'], $_SERVER['SERVER_PORT'], dirname($_SERVER['PHP_SELF']));
$trust_root = sprintf("http://%s:%s%s/", $_SERVER['SERVER_NAME'], $_SERVER['SERVER_PORT'], dirname($_SERVER['PHP_SELF']));

$form_html = $auth_request->htmlMarkup($trust_root, $return_to, false, array('id' => 'openid_message'));

# This will actually redirect to Google
print $form_html;

This is what I have in my finalize.php script:

# Requires the needed JanRain scripts
require_once "Auth/OpenID/Consumer.php";
require_once "Auth/OpenID/FileStore.php";
require_once "Auth/OpenID/AX.php";

# Setup the library (leaved blank on purpose).
# Will also create the $store variable used below
...

$consumer = new Auth_OpenID_Consumer($store);

$return_to = sprintf("http://%s:%s%s/finalize.php", $_SERVER['SERVER_NAME'], $_SERVER['SERVER_PORT'], dirname($_SERVER['PHP_SELF']));
$response = $consumer->complete($return_to);

$msg = '';

switch($response->status) {

  case Auth_OpenID_CANCEL:
    # This means the authentication was cancelled by the user
    $msg = 'Verification cancelled.';
    break;

  case Auth_OpenID_FAILURE:
    $msg = "OpenID authentication failed: " . $response->message;
    break;

  case Auth_OpenID_SUCCESS:
    # "$openid" is the user openid given by Google
    $openid = $response->getDisplayIdentifier();
    $ax_resp = Auth_OpenID_AX_FetchResponse::fromSuccessResponse($response);
    # Here you could save the user data in session for further references...
    ...

    # Redirect the user to her dashboard
    header('Location: /account');
    exit();

}

Giusto un paio di giorni fa sono entrato in possesso di un bellissimo MacBook Pro. La mia attività principale, nell’utilizzo di un computer, è lo sviluppo di applicazioni web. Dopo aver installato tutto il necessario lato client (ah, il software libero… ma di questo parlerò più avanti) rimaneva tutta la parte “server” ovvero, nella fattispecie, PHP, MySQL e Apache.

Quando mi sono posto il problema della loro installazione, partivo da questi prerequisiti:

• su quei servizi ho bisogno di avere la massima flessibilità. Devo poter decidere la loro versione, le eventuali estensioni, dove mettere i dati, i permessi, i virtual host, eccetera eccetera
• il deploy delle nostre applicazioni avviene sempre su server linux, per cui mi piaceva continuare ad usare una Ubuntu come macchina di sviluppo per non avere sorpresine in fase di deploy
• questo OSX è puro e vergine e non ho nessuna voglia di incasinarlo con installazioni non… “standard”
• i vari MAMP, distribuzioni buffe di PHP e MySQL, sono roba per ragazzi (per non parlare di quello che arriva direttamente con OSX) :)

Detto questo rimaneva da scegliere il sistema di virtualizzazione ma ovviamente (costo, libertà, solite cose) la scelta è caduta su VirtualBox.

Installarci Ubuntu è stata una passeggiata di salute: avevo l’immagine ISO di una 9.10 su una pennetta USB e dopo aver creato una macchina virtuale ho montato la ISO all’interno del suo CD (senza neanche toglierla dalla chiavetta USB) e l’installazione è partita.

Anche la rete è stata vista subito e da Ubuntu ho installato tutto il necessario. Anche qui tutto allegro e banale.

A questo punto dovevo condividere una directory tra OSX e Ubuntu. L’idea appunto è quella di usare OSX per programmare, fare debug con i browser, magari un po’ di grafica e usare la macchina virtuale Ubuntu per servire l’applicazione via Apache. Avrei dunque condiviso la directory Sites di OSX con Ubuntu (che sarebbe poi diventata la base di tutti i miei virtual host di sviluppo).

Lato OSX è stato facile: si dichiara direttamente da VirtualBox che esiste uno “shared folder”, dandogli il path locale e un nome (questa configurazione è per singola macchina virtuale). Nel mio caso il nome è stato proprio “Sites”.

In Ubuntu occorre montare da qualche parte questa directory “esportata”. Non esistono però sistemi automagici per farlo, afaik. L’operazione è fattibile direttamente tramite mount, configurando /etc/fstab. Nel mio caso ho aggiunto la seguente riga al file (dopo aver creato la directory Sites nella mia home):

Sites /home/claudioc/Sites vboxsf uid=1000,gid=1000,exec 0 0

A questo punto un bel sudo mount Sites e siete a posto (successivi riavvii della macchina virtuale useranno l’fstab e non ci sarà bisogno di intervenire manualmente). Credo si possa fare anche in modo di che il mount sia permesso ad un utente qualsiasi usando il parametro “user” della riga di mount, ma non ho indagato oltre.

A questo punto si è presentato il primo problema: non è possibile creare link simbolici dalla macchina guest. In pratica, da Ubuntu, non si possono creare link simbolici su un file system montato con vboxsf. Non si può: è proprio un limite riconosciuto. È tuttavia possibile fare il contrario: ovvero creare un link simbolico in quella directory dal sistema ospite (nel mio caso OSX). In tal caso il link simbolico sarà visto, da Ubuntu, come un normale file (non so se questo fatto possa avere o meno conseguenze strane…). Per certe configurazioni questo rimane comunque uno show stopper. Speriamo che nelle versioni successive di vbox il limite sia superato.

Passo successivo era quello di testare il funzionamento di apache di Ubuntu da OSX, accedendo da un browser di OSX all’indirizzo IP del server embedded. Il funzionamento (me illuso) sembrava scontato… e invece niente da fare. Eccoci al secondo problema.

Non appena viene installata una macchina virtuale con supporto di rete, questa viene configurata per uscire in modalità NAT. Questo vuol dire che da vbox viene assegnato un IP privato all’interfaccia di rete della macchina virtuale la quale poi userà la macchina ospite come gateway. Il tutto viene configurato automaticamente e trasparentemente.

Un ifconfig di Ubuntu mi aveva rilevato l’IP del serverino Ubuntu (10.0.2.15). Da OSX riuscivo a fare ping a quell’indirizzo, ma qualsiasi altro servizio sembrava stranamente non attivo. Questo dettaglio (il ping…) è quello che mi ha fatto sprecare più tempo in assoluto. Si dà il caso, ho realizzato più tardi, che non era assolutamente possibile che io potessi fare ping al 10.0.2.15! Eppure succedeva. La cosa buffa infatti è che quell’indirizzo esisteva, sì, ma… nella rete di Fastweb. Non apparteneva dunque al mio server embedded, ma a chissà chi :)

Se il guest è in modalità NAT, l’host non può vedere i suoi servizi di rete. Period.

Un’altra possibilità sarebbe stata quella di configurare il sottosistema di rete di Ubuntu a lavorare in modalità “bridge”, ovvero fare in modo che usando OSX come ponte (appunto…) questa entrasse direttamente nella rete di OSX ricevendo dunque un IP dal dhcp server usato dallo stesso OSX. Per fare questo avrei dovuto associare l’interfaccia di rete di Ubuntu ad un’interfaccia di rete fisica di OSX (per esempio Airport). Ma così non andava bene: io volevo che le due macchine, quella fisica e quella virtuale, potessero colloquiare anche quando nessuna connessione esterna fosse attiva.

In pratica quello che mi serviva era la possibilità di poter uscire su internet con Ubuntu, quando una connessione fosse presente, ma comunque poter SEMPRE parlare con l’host OSX usando una sottorete privata.

Questa configurazione è possibile avendo a disposizione DUE schede di rete sulla Ubuntu (operazione da eseguire nei Settings della macchina virtuale, aggiungendo una scheda). La prima scheda è quella che farà parte della sottorete “privata” tra Ubuntu e OSX e va configurata in modalità Host-only. La seconda è quella che ci farà uscire su internet e possiamo configurarla a piacere su NAT o Bridge (Bridge, per me).

La cosa bella, una volta capito il funzionamento, è che il resto è tutto automatico. Fatta ripartire la macchina virtuale Ubuntu, avremo a disposizione due interfacce, una delle quali si troverà nella stessa sottorete di una nuova interfaccia di rete virtuale creata sul sistema host (OSX). Nel mio caso, su OSX, l’interfaccia si chiama vboxnet0.

Maggiori informazioni nel manuale di VirtualBox (pdf).

With the recent release of the 1.10 version of the  Zend Framework, they made a subtle change on how Zend_Tool searches its providers. Before 1.10 the loader (aka the provider discover) was set to be the IncludePathLoader class; what that meens is that if you wrote a new provider, all that you needed to do to have Zend_Tool automatically find it was to edit your PHP’s include_path or add your provider’s directory to the ZEND_TOOL_INCLUDE_PATH_PREPEND environment variable.

Now that is history, because (source):

There were many issues for people when Zend_Tool used a scanning approach to finding providers. This caused many issues on all different platforms. Now we’ve opted to go the specify your providers approach.

(beware: the suggested solution in that post is wrong)

So if you ever write a new tool provider remember that there’s no more “auto discovery” by scanning the path. The loader now is the BasicLoader and you have to explicitely tell Zend_Tool where your providers are and how their classes are named. For this to happen, you can use the zf enable config.provider command or use the zf.ini file.

My solution is:

• create a zf.ini file for your project. This is slighlty different from what the documentation implies; it considers zf.ini to be an hidden file in your $HOME. But this is only a default you can change via the  ZF_CONFIG_FILE env variable
• put something like basicloader.classes.0 = “Migrations_MigrationProvider” as the first line (that example is the actual class name of my migration tool provider)
• assure that your class can be loaded, setting ZEND_TOOL_INCLUDE_PATH_PREPEND accordingly

On the same topic you can also read this issue.

As a bonus track, below is a little bash script I use to run my migration tool.

#!/bin/bash

APPPATH=$(readlink -f ..)/app

export ZF_CONFIG_FILE=${APPPATH}/../zf.ini

if [ ! -f ${ZF_CONFIG_FILE} ]; then
  echo "Non trovo zf.ini"
  echo "Forse non stai eseguendo questo programma dalla directory DB?"
  exit -1
fi

if [[ "${ZF_BIN_DIR}" == "" ]]; then
  ZF_BIN_DIR=$(readlink -f ../vendor/Zend)/../../bin
  ZF_BIN_DIR=$(readlink -f ${ZF_BIN_DIR})
fi

if [ ! -f ${ZF_BIN_DIR}/zf.sh ]; then
  echo "Non trovo zf.sh in " ${ZF_BIN_DIR}
  echo "Forse non stai eseguendo questo programma dalla directory DB?"
  exit -1
fi

MIGCLASSDIR=$(readlink -f ../vendor/Renomo/library)

if [ ! -d ${MIGCLASSDIR} ]; then
  echo "Impossibile trovare la directory della classe Migration"
  exit -1
fi

MIGDIR=$(readlink -f migrations)

if [ ! -d ${MIGDIR} ]; then
  echo "Impossibile trovare la directory delle migration"
  exit -1
fi

export ZEND_TOOL_INCLUDE_PATH_PREPEND=${MIGCLASSDIR}

${ZF_BIN_DIR}/zf.sh run migration ${1}

Ecco cosa devi fare:

• devi usare solo la strftime() e non la date(), visto che quest’ultima non è sensibile al locale del sistema
• devi verificare che il tuo sistema abbia il supporto per il locale italiano (altrimenti il nome dei mesi da dove se lo prende? Il PHP non ha mica tutti i mesi in tutte le lingue “dentro sé stesso”). Verificalo con il comando locale -a. Ti verrà visualizzata la lista di tutti i locali supportati sul tuo sistema
• se il locale che ti serve non è presente nella lista, lo devi installare. Il comando è locale-gen e il parametro è il locale che ti interessa (es: locale-gen it, installerà tutti i locale italiani conosciuti, compreso quello standard e quello svizzero)
• prendi la stringa ESATTA che identifica il locale che ti interessa e la usi come argomento della funzione PHP setlocale() prima di usare la strftime. Esempio: setlocale(LC_TIME, “it_IT.utf8″)

That is all what I needed, from Facebook: I do not need any fancy “get your friends here” or “post in your wall” rubbish. Simple and plain “single sign on”, among Facebook and my application.

After a quick search, the tutorials I found here and there were very disappointing (just a point of view, no offense), with a lot of useless PHP code. So I give you just one more tutorial that focuses more on the process than in the copy & paste kind of help.

I will use PHP for some examples, and FB for “Facebook” so bear with me and give it a spin.

What you need:

• a FB account, if you don’t own one already. Unlikely; I’ll skip this step :)
• a new FB application need to be created
• the FB PHP library, to easily talk to their RESTful API
• Some code refactoring of your own

Creating a new FB application.

Two paths, here:

• the long and detailed multistep form
• the super easy wizard

Note that, whichever way you’ll choose, you will end up creating the exact same thing: an FB application (all your applications are stored here).

We’ll use the wizard:

• the website name is just the name of the application (the handle by which you’ll refer to it in the application list).
• the website url is self explanatory. Note that you could use ANY kind of URL, even something like “http://myapplication.localdomain”. In fact, FB will not need to contact the site, so you can use an development URL as well. For the test purposes I created two applications: one for the “real thing” and one for the mydomain.local devel environment.

The next step will ask you to download a file. You can put the file WHEREVER you want. The root directory of your site is the first choice, and it’s where the wizard will try to find it. There’s no need for the wizard to find the file, though: it’s only a test. You can download the file and skip the test pressing “Upload later“. Two words about that particular file: the file is part of the system that permits our application to be proxied to FB (and vice-versa). I will not enter in details here, but think about this file as your “gateway” to and from the FB requests (more info). The other thing is: there is NOTHING in that file that identifies you application. Every FB application of the world could use the same xd_receiver.htm file. The file name itself is not important… it’s just the default. More on this later.

The third step is the landing page for your newly created FB application. Just a comfy place to pick things up. You need to write down the API KEY and the SECRET strings. You’ll use them from within your application.

What you also need to take from this page is the JavaScript snippet at point 1) and the FBML markup for the “Connect with Facebook” button at point 2).

Enough for the FB setup.

The FB PHP Library and the FB API

This is a set of helper PHP classes that will give you a simple PHP API interface to the RESTful FB API. You could even NOT use the library, and talk directly to the REST endpoints with some code of your own. Your choice.
The FB API are documented here, while you can download the latest version of the PHP 5 Library via SVN

svn co http://svn.facebook.com/svnroot/platform/clients/php/trunk/ fb

(more info on FB Client libraries)

We are finally ready to get our hands dirty.

Hands on the code

We first need to focus on how things works, at an higher level. What will happen when a not logged-in user will click the “Connect with Facebook” button? Using some sort of magic Facebook will test if the user is currently logged in Facebook. If it’s not, it will spawn a popup window asking two things: the user has to agree to give your application access to her data, and after that Facebook will ask her for credential (username/password, as usual). Upon a succesful login, FB will redirect the user to your application toward an url of your choice (let’s call it the “FB Connect endpoint“).
If the user is already logged in Facebook and has already given permission to our application to read some of her data, the login process will be completely transparent. The user clicks on our FB blue-ish button, and he will be instantly logged in our application too. Oh, joy.

As for the HTML part, you will place the FBML markup for the login button you got beforehand wherever you want. The FBML have to be programmatically converted in HTML by JavaScript, and for that to work you need to include the JavaScript snippet you already have. Put it at the end of your <body>, for example, and then run the FB.init() function. This function will be passed two parameters: the API KEY and the name and location of the “gateway” file. As said before, if the second parameter is not passed, the default is “xd_receiver.htm” on the document root.

  <!-- The login button, somewhere in your page -->
  <fb:login-button onlogin="window.location='/fbconnect.php';" v="2" size="medium">Login with Facebook</fb:login-button>
  ...
  <!-- At the page end of the page, presumibly -->
  <script src="http://static.ak.connect.facebook.com/js/api_lib/v0.4/FeatureLoader.js.php/en_US"></script>
  <script>
    FB.init("b4bbr43b4bb3b3b3");
  </script>
</body>
</html>

The interesting part, here, is in the highlighted row. The onlogin attribute contains what we pretentiously called the “FB Connect endpoint”. The onlogin attribute value is a JavaScript snippet that will be automatically run after a succesfull FB login. What we say here is: after a login, please redirect the user to our “fbconnect.php” page.
The fbconnect.php page is where OUR magic will happen. There, we will use the FB Client API to ask FB some questions: “Is this guy a Facebook, logged in user?”, “Can you please give me the picture of him?”… and so on.
The code, here, is given only as an example; think about it more as a pseudocode, really. The actual code I use is somewhat more complex, and I needed to dumb it down a little for clarity.

require("fb/facebook.php");
$fb = new Facebook("b4bbr43b4bb3b3b3", "supersecret1234");
/* If it's present, ask FB for the ID of the current user */
$fbId = $fb->get_loggedin_user();
if (empty($fbId)) {
  /* No FB user, redirect to home page */
  header("Location: /");
}
/* Now we know the FB user id.
   It's our responsability to ask our Database if we already know him */

You need to have a way to find one user of yours given its FB user id. For instance I used a “fb_id” column in my Users table.

What happens now is up to you. There will presumably be two major cases:

1. the user already exists: I programmatically login him into my application, and redirect to the home page as a logged in user.
2. the user does not exist: I give her the choice to merge her old account or to create a new one

For the merge part, I need him to login with his credentials and then update the Users table with his FB id.

For the registration part, I luckily do not need anything else that FB can’t give me; so it’s a matter of pushing a button. The code is something like that:

$fbInfo = $fb->api_client->users_getInfo($fbId, array('name', 'pic_square', 'proxied_email'));
$model = new User();
$name = $fbInfo['name'];
$tries=1;
# find a unique username
do {
  $user = $model->fetchRow($model->select()->where('username=?', $name));
  if (!$user)
    break;
  else
    $name = $name . ($tries++);
} while(TRUE);
$user = $model->createRow();
$user->username = $name;
$user->avatar = $fbInfo['pic_square'];
$user->name = $fbInfo['name'];
$user->fb_proxy_email = $fbInfo['proxied_email'];
$user->fb_id = $fbId;
...
$user->save();
...

Finally, let me complain a bit: I find writing code that interacts with Facebook a very frustrating experience. The information you need is scattered all over the web (and the Facebook site itself, even), and examples quality is very poor. The technology behing FB is very sophisticated, though, and no matter what they try to do, you need to grasp some concepts that are sometimes quite difficult to master or a nightmare to debug.

Good luck.

Further readings

• The official Facebook Connect page (and the developers Wiki one)
• How Connect Authentication Works
• 10 Great Implementations of Facebook Connect
• What is behind Cross Domain Communication and even more
• Facebook API documentation

Ecco come ho fatto (nota per gli amici Debianisti: ho più pratica nella compilazione del php/apache che nei vari giochini a colpi di dpkg; abbiate pazienza):

• Primo problema: trovare i sorgenti di PHP4. Questa è facile: si prendono direttamente dal sito ufficiale.
• PHP andrà compilato solo come CGI (l’idea è quella di usare lighttpd + fastcgi). Scompatta i sorgenti e poi dai un bel ./configure –with-mysql=/usr  –enable-fastcgi. Attenzione che non è sufficiente il solo –with-mysql, perché altrimenti verrà compilato il supporto mysql “vecchio”, che non funzionerebbe con i server 5.x. Probabilmente il configure si lamenterà della mancanza di qualcosa, la qual cosa provvederete ad installare (es: libmysqlclient-dev).
• Apt-get install lighttpd (probabilmente non partirà se avrai attivo Apache, ma non ti preoccupare) e poi:
  • Modifica /etc/lighttpd/lighttpd.conf per farlo andare su un’altra porta che non sia l’80 (dove potresti avere Apache). Io ho usato l’81.
  • Esegui lighttpd-enable-mod fastcgi
  • Modifica /etc/lighttpd/conf-enabled/10-fastcgi.conf e cambia il “bin-path” del php, per farlo puntare a <dirSorgentiPhp4>/sapi/cgi/php
  • fai (ri)partire lighttpd /etc/init.d/lighttpd start

A questo punto i file php letti da localhost:81 verranno interpretati dal php4 fastcgi, via lighttpd mentre tutto il resto continuerà a funzionare come prima via Apache e php5 DSO :)

Se vuoi usare un sistema del tipo VirtualHost di Apache con lighttpd, ti copio la mia configurazione da mettere nel tuo /etc/lighttpd/lighttpd.conf

$HTTP["host"] =~ "miodominio\.local(\:[0-9]*)?$" {
server.document-root = "/home/claudioc/Sites/miodominio"
}

La cosa a cui fare attenzione è che anche se la chiave si chiama “host”, in realtà nella regexp occorre fornire il match anche per una eventuale porta (come nel caso di esempio).

In questo articolo, suddiviso per motivi di lunghezza in più parti, cercherò di  spiegare il sistema tramite il quale sia possibile monitorare l’upload di un file in modo da visualizzare all’utente lo stato di avanzamento dell’operazione.

Questi articoli non sono vogliono essere un semplice how to, quando invece una dettagliata analisi delle problematiche inerenti a questo sistema diventato ormai di sempre più comune utilizzo sui siti web.

La complessità di tutto questo “giochino” è da imputare principalmente al linguaggio  server side che utilizzerò in questi articoli: il PHP.

Vediamo subito il perché.

A grandi linee, l’upload di un file dal browser al server funziona semplicemente così: l’utente seleziona il file dal proprio computer e poi invia la form. In quel momento il browser inizia una trasmissione dati con lo script che riceve i dati della form, inviandogli senza soluzione di continuità i byte che compongono il file in fase di trasmissione.

Lato server il PHP dal momento che inizia la ricezione del file, “appoggia” su un file temporaneo i dati che stanno arrivando finché la trasmissione non sarà terminata o cancellata. Nel secondo caso il PHP provvederà a cancellare il file temporaneo e tutto finisce lì. Nel caso di ricezione avvenuta, lo script riprenderà il controllo e sarà in grado di copiare il file temporaneo dove meglio crede (move_uploaded_file(), non dico certo niente di nuovo.)

Non esistono sistema “nativi” da parte del browser per capire quanti byte ha al momento trasmesso. È possibile utilizzare dei trucchetti lato client che prevedono l’utilizzo di un piccolo Flash movie che fa da “gateway” usando Flash stesso per aprire il socket di trasmissione dati verso il server. In tal caso sarà lo stesso Flash a fornire le indicazioni che ci interessano e la gestione è assai più semplice. Tuttavia l’approccio (usato in tantissime soluzioni di alto livello) non è scevro da problemi e in questa sede non ci interessa.

Senza usare Flash, dunque, quello che occorre fare è chiedere al server continuamente a che punto è arrivato leggendo il file temporaneo che sta crescendo man mano che la trasmissione procede.

Questa richiesta verrà fatta dunque via Ajax, chiedendo ad un altro script PHP lo stato di avanzamento del file xxxyyyzzz…

Sembra facile, ma non è.

Il problema nasce dal fatto, come dicevo poco fa, che stiamo usando PHP. Soltanto dalla versione 5.2 in poi è possibile infatti usare un sistema per chiedere al PHP a che punto è con l’upload. Prima, non esisteva modo… impossibile sapere il nome del file temporaneo da un altro processo, né tantomeno dal processo PHP che lo sta generando.

Dalla versione 5.2 è stato introdotto un “hook” che permette alle estensioni PECL del php di intercettare le fasi di upload di un file (no, non si può fare direttamente da PHP). Ovviamente non è che adesso ci mettiamo lì, con il nostro compilatore C a scrivere la nostra fantastica estensione che usa quell’hook. Questo lavoro, fortunatamente, è già stato fatto da qualcuno.

Credo che la maggior parte degli sviluppatori in PHP siano a conoscenza di APC. Il suo mestiere è duplice. In primis è un cosidetto sistema di “opcache”, ovvero permette al PHP di salvarsi i nostri script “precompilati” (passatemi il termine), in modo da velocizzarne le esecuzioni successive (stessa cosa di eAccelerator o xcache, se conoscete già queste alternative). In secundis, mette a disposizione agli script PHP un buffer di memoria ad accesso rapido, per salvare al suo interno delle informazioni magari lette da un sottostitema più lento (dbms, per esempio). È più o meno quello che fa memcache, solo che in questo caso non c’è bisogno di un servizio esterno che giri. APC infatti è un’estensione del PHP e come tale, una volta che questa sia stata compilata e caricata dal PHP, è disponibile da subito.

Fin qui – credo – nessuna grossa novità.

La cosa interessante è che, dalla versione PHP 5.2, APC implementa appunto la gestione di quel famoso “hook” per il monitoraggio dell’upload, offrendo un sistema ai normali script PHP per interrogare l’andamento della creazione del nostro file. Non solo: tramite il servizio di APC sarà così possibile controllare se il nostro file ha terminato il caricamento, se il caricamento è stato annullato dall’utente o da un problema di rete e fare dei semplici calcoli per sapere anche il “rate” di trasmissione in kbyte.

Nella seconda parte dell’articolo vedremo come fare ad implementare un sistema del genere, usando “solo” HTML, PHP e un po’ di sano JavaScript.

Nel frattempo, assicuratevi di avere a disposizione APC (perlomeno) sulla vostra macchina di sviluppo. In Ubuntu è questione di “sudo apt-get install php-apc” e far ripartire Apache. La configurazione, eventualmente, la troverete in
/etc/php5/apache2/conf.d/apc.ini

Cosa potevo fare per provarlo? Ovviamente cercare di capire da dove provengono le visite delle persone (o altro) che usano Internet Explorer 6. Il test è stato utile solo per provare che non è vero, purtroppo, che la maggior parte degli IE6 sono dei bot travestiti.

Gli impazienti possono vedere i risultati aggregati su questo documento gdocs.

Per i curiosi, ecco come ho proceduto. I dati sono quelli di un mio sito, frequentato per la maggior parte da utenti italiani, raccolti in un periodo di tre mesi.

Ho scaricato il database (è un dump MySQL di circa 68MB) e me lo sono importato in locale.

Con queste due righe di bash (spezzate per motivi di questo spazio) mi sono procurato tutti gli IP degli utilizzatori di IE6 (circa 6500, al momento).

grep "MSIE 6.0" access.log > ie6
awk '{print $1'} ie6 | sort | uniq > ip_ie6

Infine qualche riga di PHP:

$ips = file('ip_ie6');
$countries=$cities=array();
foreach($ips as $ip) {
  list($a,$b,$c,$d) = split('\.',$ip);
  $val = ($a*256+$b)*256+$c;
  $sql = "SELECT * FROM `ip_group_city` where `ip_start` <= {$val} order by ip_start desc limit 1";
  $row = mysql_fetch_object(mysql_query($sql));
  $countries[$row->country_code]++;
  if (!empty($row->city))
    $cities[$row->city . ", " . $row->country_code]++;
}

asort($countries);
foreach(array_reverse($countries) as $country => $count) {
  print "$country\t$count\n";
}

asort($cities);
foreach(array_reverse($cities) as $city => $count) {
  print "$city\t$count\n";
}

Nota che usando un tab (\t) e un ritorno a capo (\n) si può fare copia & incolla direttamente dentro uno spreadsheet di di GDocs e lui “sentirà” la suddivisione in colonne.