Buon upgrade!

Alla prox

Technorati Tags: wordpress, wordpress 3.0

Direi che Lifestream copre un ventaglio piuttosto ampio di servizi, e in ogni caso se il nostro stream preferito non è tra quelli previsti di default, beh, c’è il sempre valido RSS generico a venirci in aiuto.

Finalmente ho ottenuto quello che volevo, e lo trovate a questa pagina.

Alla prox

Technorati Tags: lifestream

E’ basato su Precious, tema chiaro e minimale, che supporta bene sia i widget sia il plugin BackType, a differenza della carrozzeria precedente. Il tema l’ho hackato un poco per farci funzionare il mio plugin che mostra le categorie e i bookmarks come menù dropdown a scomparsa.

Per rispetto della licenza GPL, qui c’è il diff con le modifiche che ho apportato al tema, e qui il mio plugin.

Piace?

Alla prox

Technorati Tags: precious, wordpress, theme

L’installazione è filata via liscia, ma subito dopo ha riscontrato un problema: mentre MySQL partiva tranquillamente, Apache non aveva nessuna intenzione di andare su.
Essendo un utente smaliziato (e programmatore di professione), il mio collega ha effettuato alcuni test con il Firefox e con telnet, e si è accorto che esisteva un processo in listening sulla porta 80: già, ma quale?
Era certo di non avere altri web server installati e avviati nella sua macchina, e quindi mi ha interpellato per risolvere il problema.
La caccia al processo incriminato l’abbiamo svolta usando ProcessExplorer, un task manager avanzato in grado di fornire molte informazioni utili circa i processi in esecuzione sul sistema, e tra queste informazioni ci sono anche le porte di rete utilizzate.
Un primo check sui processi in esecuzione non ha mostrato niente di significativo, e quindi abbiamo passato in rassegna un processo alla volta per trovare l’usurpatore; e alla fine, come da titolo del post, è emerso che Skype era in listening sia sulla porta 80 (http) che sulla porta 443 (https)!

Dopo uno sguardo sconsolato, e qualche maledizione verso i realizzatori del software per aver perso tutto quel tempo per una cavolata, abbiamo aperto le opzioni di Skype, e trovato la parte incriminata, parte che potete vedere quì sotto (l’immagine l’ho recuperata in rete):

E’ stato quindi sufficiente deselezionare il checkbox incriminato, e finalmente abbiamo ottenuto Apache up and running.
Quindi, caro lettore, se mai dovessi installare XAMPP, o qualsiasi altro web server, in un PC nel quale c’è Skype in esecuzione, verifica le impostazioni di cui sopra.

Alla prox

Technorati Tags: skype, php, xampp

Prerequisiti:
0) un server con il client Subversion installato ed utilizzabile dall’utente di Apache, nel mio caso www-data;
1) un repository Subversion raggiungibile dal server;
2) un linguaggio di scripting presente nel repository, utilizzabile per scrivere il post-commit hook, nel mio esempio Python;

Semplificazioni:
0) il repository risiede nel mio PC, e ci accedo tramite il protocollo file://;
1) i server remoti, nel dettaglio tre, sono rappresentati da tre diverse directory nella DocumentRoot di Apache;

Ecco una piccola descrizione di cio’ che ho realizzato e di quello che vedrete negli snippets successivi.
Io ho sviluppato una web application general purpose, molto flessibile e adattabile a molti clienti, ed essendo un bravo programmatore utilizzo gia’ subversion per mantenere i miei sorgenti. Aggiungo quindi una specie di installer per l’applicazione, in pratica una pagina PHP che invoca il checkout del progetto dal repository principale.

Ecco il codice dell’installer.

1. <?php
2. exec("svn co file:///home/massi/svn/svnwebapp");
3. ?>

Che cosa succede quando invochiamo l’esecuzione dell’installer (preventivamente copiato nel server)?
Il client svn sl server preleva il progetto dal repository e crea, con i giusti permessi (quelli del webserver), la copia locale dei files.

Cominciamo con gli snippets!

Ecco il contenuto della directory che ospita il progetto iniziale della web application

massi@aspire:~$ cd Projects/svnwebapp/
massi@aspire:~/Projects/svnwebapp$ ls -l
totale 8
-rw-r--r-- 1 massi massi 104 2007-11-11 22:35 index.php
-rw-r--r-- 1 massi massi  30 2007-11-02 06:48 updater.php
massi@aspire:~/Projects/svnwebapp$

Creiamo ora il repository svn

massi@aspire:~$ svnadmin create /home/massi/svn/svnwebapp
massi@aspire:~$

Effettuiamo ora l’import della web application nel repository appena creato

massi@aspire:~$ cd Projects/
massi@aspire:~/Projects$ svn import -m "Import iniziale" svnwebapp file:///home/massi/svn/svnwebapp
Aggiungo       svnwebapp/updater.php
Aggiungo       svnwebapp/index.php

Commit della Revisione 1 eseguito.
massi@aspire:~/Projects$

Ora ci spostiamo nella root del nostro webserver locale, ed eseguiamo il checkout del progetto per continuare a svilupparlo, sotto svn.

massi@aspire:~$ cd /var/www/
massi@aspire:/var/www$ sudo svn co file:///home/massi/svn/svnwebapp
A    svnwebapp/updater.php
A    svnwebapp/index.php
Estratta revisione 1.
massi@aspire:/var/www$

Guardiamo cosa e’ successo in /var/www

massi@aspire:~$ ls /var/www/svnwebapp/
index.php  updater.php
massi@aspire:~$

Bene, la directory e’ stata creata, cosi’ come i files della web application.
Ora eseguiamola!

massi@aspire:~$ lynx --source http://localhost/svnwebapp
<html>
<head>
</head>
<body>
Versione PHP installata: 5.2.3-1ubuntu6
</body>
</html>
massi@aspire:~$

Per curiosita’ diamo una occhiata a questo complicatissimo script (index.php).

1. <html>
2. <head>
3. </head>
4. <body>
5. <?php
6. echo 'Versione PHP : ' . phpversion() . '<br>';
7. ?>
8. </body>
9. </html>

Ora che abbiamo testato le funzionalita’ di svn per la gestione “locale” della web application, creiamo i nostri tre server simulati (con gli opportuni permessi), copiamo in ognuno di essi l’installer e lanciamo quest’ultimo per creare le applicazioni.

massi@aspire:~$ cd /var/www
massi@aspire:/var/www$ sudo mkdir fakesrv{1,2,3}
massi@aspire:/var/www$ sudo chown www-data:www-data fakesrv{1,2,3}
massi@aspire:/var/www$ ls
fakesrv1  fakesrv2  fakesrv3  index.html  svnwebapp
massi@aspire:/var/www$ cd
massi@aspire:~$ sudo cp svnwebapp_installer.php /var/www/fakesrv1/
massi@aspire:~$ sudo cp svnwebapp_installer.php /var/www/fakesrv2/
massi@aspire:~$ sudo cp svnwebapp_installer.php /var/www/fakesrv3/
massi@aspire:~$ lynx --source http://localhost/fakesrv1/svnwebapp_installer.php
massi@aspire:~$ lynx --source http://localhost/fakesrv2/svnwebapp_installer.php
massi@aspire:~$ lynx --source http://localhost/fakesrv3/svnwebapp_installer.php

Giusto per scrupolo vediamo cosa e’ successo dentro a fakesrv1.

massi@aspire:/var/www$ ls -lR fakesrv1
fakesrv1:
totale 4
drwxr-xr-x 3 www-data www-data 136 2007-11-26 13:34 svnwebapp
-rw-r--r-- 1 root     root      59 2007-11-26 13:34 svnwebapp_installer.php

fakesrv1/svnwebapp:
totale 8
-rw-r--r-- 1 www-data www-data 169 2007-11-26 13:34 index.php
-rw-r--r-- 1 www-data www-data  30 2007-11-26 13:34 updater.php
massi@aspire:/var/www$

Tramite lynx verifichiamo che tutto funzioni.

massi@aspire:~$ lynx --source http://localhost/fakesrv1/svnwebapp
<html>
<head>
</head>
<body>
Versione PHP installata: 5.2.3-1ubuntu6
</body>
</html>
massi@aspire:~$

Tralascio gli snipper delle verifiche per gli altri due “server”, tutto funziona ovviamente allo stesso modo.
Riassumiamo quello che e’ successo finora: tramite l’installer ho potuto replicare la mia web application nei server dei miei ipotetici tre clienti, attingendo il codice direttamente dal repository SVN, che contiene l’ultima release del progetto.
Ora pero’ mi sono accorto che la mia web application manca di un requisito fondamentale, e cioe’ una stringa di testo con il mio indirizzo email, percio’ sono costretto ad aggiornare le varie installazioni!
Vediamo quindi in che modo il mio sistema di installer diventa comodissimo in caso di aggiornamenti: aggiungiamo un post-commit hook al repository.
Ecco il contenuto della directory del repository.

massi@aspire:~$ ls -l svn/svnwebapp
totale 8
drwxr-xr-x 2 massi massi 128 2007-11-11 23:20 conf
drwxr-xr-x 2 massi massi  48 2007-11-11 23:20 dav
drwxr-sr-x 5 massi massi 256 2007-11-12 00:12 db
-r--r--r-- 1 massi massi   2 2007-11-11 23:20 format
drwxr-xr-x 2 massi massi 392 2007-11-11 23:58 hooks
drwxr-xr-x 2 massi massi 104 2007-11-11 23:20 locks
-rw-r--r-- 1 massi massi 229 2007-11-11 23:20 README.txt

La directory che ci interessa e’, ovviamente, hooks.

massi@aspire:~$ ls -l svn/svnwebapp/hooks/
totale 40
-rwxr-xr-x 1 massi massi  290 2007-11-11 23:58 post-commit
-rw-r--r-- 1 massi massi 1996 2007-11-11 23:20 post-commit.tmpl
-rw-r--r-- 1 massi massi 1673 2007-11-11 23:20 post-lock.tmpl
-rw-r--r-- 1 massi massi 2290 2007-11-11 23:20 post-revprop-change.tmpl
-rw-r--r-- 1 massi massi 1602 2007-11-11 23:20 post-unlock.tmpl
-rw-r--r-- 1 massi massi 2969 2007-11-11 23:20 pre-commit.tmpl
-rw-r--r-- 1 massi massi 2038 2007-11-11 23:20 pre-lock.tmpl
-rw-r--r-- 1 massi massi 2764 2007-11-11 23:20 pre-revprop-change.tmpl
-rw-r--r-- 1 massi massi 1979 2007-11-11 23:20 pre-unlock.tmpl
-rw-r--r-- 1 massi massi 2137 2007-11-11 23:20 start-commit.tmpl
massi@aspire:~$

Come si vede, e’ presente il mio file post-commit , al quale ho dato di permessi di esecuzione.
Vediamone il contenuto.

1. #!/usr/bin/python
2.  
3. import sys
4. import urllib2
5.  
6. urls = ["http://localhost/fakesrv1/svnwebapp/updater.php",
7. "http://localhost/fakesrv2/svnwebapp/updater.php",
8. "http://localhost/fakesrv3/svnwebapp/updater.php"]
9.  
10. repos = sys.argv[1]
11. rev = sys.argv[2]
12.  
13. for url in urls:
14. urllib2.urlopen(url)
15.  

Come si puo’ vedere, e’ un semplicissimo script Python che viene eseguito ad ogni commit (da qui’ il nome post-commit): il codice mi sembra piuttosto chiaro, data una lista di URL, quelli relativi alle varie installazioni della web application, un ciclo sulla lista effettua il collegamento alla pagina updater.php di ogni installazione.
Il codice dell’updater e’ molto simile a quello dell’installer, addirittura piu’ semplice.

1. <?php
2. exec("svn update");
3. ?>

Ok, direi che siamo pronti a testare il tutto. Apriamo il file index.php con il nostro editor preferito, apportiamo la modifica di cui sopra e effettuiamo il commit.

massi@aspire:/var/www/svnwebapp$ sudo vi index.php
massi@aspire:/var/www/svnwebapp$ sudo svn commit -m 'Aggiunto autore'
Trasmetto      index.php
Trasmissione dati .
Commit della Revisione 2 eseguito.
massi@aspire:/var/www/svnwebapp$

Ora la prova del 9, verifichiamo i tre server.

massi@aspire:~$ lynx --source http://localhost/fakesrv1/svnwebapp
<html>
<head>
</head>
<body>
Versione PHP installata: 5.2.3-1ubuntu6<br>
---<br>
Autore: Massimiliano Calamelli<br>
Email: mcalamelli@gmail.com</body>
</html>
massi@aspire:~$ lynx --source http://localhost/fakesrv2/svnwebapp
<html>
<head>
</head>
<body>
Versione PHP installata: 5.2.3-1ubuntu6<br>
---<br>
Autore: Massimiliano Calamelli<br>
Email: mcalamelli@gmail.com</body>
</html>
massi@aspire:~$ lynx --source http://localhost/fakesrv3/svnwebapp
<html>
<head>
</head>
<body>
Versione PHP installata: 5.2.3-1ubuntu6<br>
---<br>
Autore: Massimiliano Calamelli<br>
Email: mcalamelli@gmail.com</body>
</html>

Perfetto, tutto mi sembra ok, direi che il sistema ha funzionato!
Ovviamente sono conscio del fatto che il tutto e’ realizzato in un ambiente molto differente dalla realta’, ma mi sento di poter affermare che con poche modifiche il tutto possa funzionare anche nel mondo reale; alcuni perfezionamenti che mi vengono in mente sono questi:

post-commit hook : l’elenco degli host da aggiornare potrebbe essere letto da un file, e non hard-coded all’interno dello script, in modo da poter escludere piu’ facilmente host che per svariati motivi non devono essere aggiornati. Inoltre un controllo sul risultato della connessione tramite urllib2 sarebbe auspicabile, magari con una notifica via mail dell’insuccesso dell’operazione per il/i determinati hosts;

updater.php : la pagina in questione andrebbe in qualche modo protetta, cosi’ da impedire eventuali chiamate non autorizzate.

Che dire, e’ stato veramente interessante realizzare un sistema del genere, anche se molto semplificato rispetto ad un uso reale, un motivo in piu’ per studiarsi i sistemi di controllo versione: io ho usato SVN come RCS e Python per il post-commit hook, ma nulla vieta di realizzare un sistema simile con CVS e un qualsiasi altro file eseguiibile che si chiami post-commit.
Ogni bravo programmatore dovrebbe SEMPRE usare un sistema di controllo versione.

Grazie a Fullo e Jaures per le preziose verifiche.

Alla prox

Technorati Tags: subversion, php, python, post-commit hooks, web development

Alla prox

Title: <lang_it> Vino </lang_it><lang_en> Wine </lang_en>
Body: <ang_it> Vino rosso</lang_it><lang_en> Red wine </lang_en>

now it’s enough to bring some modification is to the template ones of the sidebar that to the template ones of the single one post so that in before the languages available appear (than, if selected will apply the language to the blog), and in the second appears the small flag of the languages available for the single post.

Here’s my settings

sidebar.php

single.php

The last thing that I have made is to modify the file polyglot.php in order to personalize the plugin; here one snippet of mine:

polyglot.php

And this is all, simple and clear.

Alla prox

1. <?php
2. define("LOCALDIR",getcwd());
3. $files = array();
4.  
5. if ($dir = opendir(LOCALDIR)) {
6. while (($file = readdir($dir)) !== false) {
7. $fileinfo = pathinfo(LOCALDIR."\\".$file);
8. if ($file != "." && $file != ".." && $fileinfo["extension"] == "swf") {
9. $finfo = stat(LOCALDIR."\\".$file);
10. $files[] = $file;
11. }
12. }
13. closedir($dir);
14. }
15.  
16. shuffle($files);
17.  
18. $swf = $files[0];
19.  
20. header("Pragma: public");
21. header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
22. header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
23. header("Cache-Control: must-revalidate");
24. header("Content-type: application/x-shockwave-flash");
25. header("Content-Length: ".filesize($swf));
26. header("Content-disposition: inline; filename=$swf");
27. header("Accept-Ranges: ".filesize($swf));
28. readfile($swf);
29. exit();
30. ?>
31. Download this code: swfproducer.txt