Mytop: permette di vedere i processi MySQL attualmente in esecuzione, ed eventualmente abbattere quelli pendenti o che stanno occupando troppe risorse di sistema. Esiste anche un package per Ubuntu.

log_slow_query: permette di tener traccia in un file di tutte le query che impiegano più di n secondi <nsec> ad eseguirsi. Per abilitarlo, oltre al metodo descritto nel link, possiamo modificare il nostro file my.cnf ed aggiungere, nella sezione [mysqld]:

long_query_time = <nsec>

log-slow-queries = /path/to/mysql_slow_query.log

Bisogna poi creare il file /path/to/mysql_slow_query.log e rendere l’utente mysql proprietario con un chown (questo su Linux, naturalmente)

Altro?

Nella notte dei tempi usavo Homesite di Adobe, buono per creare pagine HTML tempestate di codice PHP (e viceversa) ma davvero poco per lo sviluppo serio (infatti l’hanno dismesso). Poi c’è stato Eclipse PDT, completo ma davvero troppo pesante e dal crash facile su Ubuntu. Mi sono quindi buttato su cose più leggere: Kate e GEdit (con le modifiche trendy & cool per farlo assomigliare a TextMate).

Infine, eccoci qua: Netbeans. Non l’avevo mai considerato perché non pensavo avesse un’estensione per PHP, e invece non solo ce l’ha ma, con sorpresa, gestisce tutto quello che mi può servire: debugging, unit testing (con PHPUnit), integrazione con Symfony. E quelle funzionalità base, come l’auto completamento del codice e la navigazione dei sorgenti, sviluppate in maniera intuitiva e che non richiedono troppi smanettamenti nella configurazione.

Esistono diversi software per wireframing, nell’ambito del web design. Parlando con Alberto, mi ha detto che nella loro società usano produttivamente Omnigraffle per Mac. Per Windows c’è Microsoft Visio. Andando più sul professionale c’è Axure, mentre una soluzione multipiattaforma è InDesign di Adobe.

Per le mie esigenze però alla fine ho trovato Mockups di Balsamiq: sketchy, simpatico e semplice da usare. Il software è a pagamento, ma c’è una bella demo web e una  installabile, per Adobe Air, perfettamente funzionante anche su Linux.

Per Alessia: dai che non è difficile questo!

Come risaputo, a fronte di un costo davvero concorrenziale, Aruba non è certo la soluzione ideale per chi sviluppa, con i suoi pochi margini di configurazione (devo dire comunque molto ampliati, rispetto a qualche anno fa).

Installare un progetto Symfony su Aruba non è semplice, ma comunque possibile. Ecco quindi come feci l’impresa. Molti spunti sono presi dalla guida per installare Symfony su OVH, un hosting provider francese.

Test della configurazione

Scaricate lo script per testare la configurazione del server, uploadatelo su Aruba e puntatelo con browser

Nel mio caso, ritorna

********************************
*                              *
*  symfony requirements check  *
*                              *
********************************

php.ini used by PHP: /etc/apache/phpini/php5/php.ini

** Mandatory requirements **

OK        PHP version is at least 5.2.4
OK        php.ini has zend.ze1_compatibility_mode set to off

** Optional checks **

OK        PDO is installed
OK        PDO has some drivers installed: sqlite2, sqlite, mysql
OK        PHP-XML module is installed
OK        XSL module is installed
OK        The token_get_all() function is available
OK        The mb_strlen() function is available
OK        The iconv() function is available
OK        The utf8_decode() is available
[[WARNING]] A PHP accelerator is installed: FAILED
*** Install a PHP accelerator like APC (highly recommended) ***
[[WARNING]] php.ini has short_open_tag set to off: FAILED
*** Set it to off in php.ini ***
[[WARNING]] php.ini has magic_quotes_gpc set to off: FAILED
*** Set it to off in php.ini ***
[[WARNING]] php.ini has register_globals set to off: FAILED
*** Set it to off in php.ini ***
OK        php.ini has session.auto_start set to off

Tutto più o meno OK, ma dobbiamo gestire i magic_quotes e register_global (vanno settati ad off)

Potete entrare nel pannello di configurazione di Aruba e selezionare un php.ini adeguato, oppure più semplicemente aggiungere un file project/config/php.yml per fixare il problema, scrivendo

check:
  magic_quotes_gpc:            on 
  register_globals:            on

Struttura delle directory

L’aspetto sicuramente più noioso è quello che la struttura delle directory di Symfony non è adatta a quella della document root di Aruba.

Se in Symfony abbiamo, ad esempio

mySite
  /project
  /web
    /css
    /index.php

su Aruba dobbiamo avere

www.mysite.it
  /project
  /css
  index.php

Quindi: spostiamo la directory project in web.

Modificate poi il file index.php in modo che punti correttamente a web/project/config

Modificate config/ProjectConfiguration, aggiungendo

$this->setWebDir($this->getRootDir().'/..');

Congeliamo il progetto

Adesso è necessario incorporare le librerie di Symfony all’interno del nostro progetto.

Rimuovere quindi la directory web/sf e lanciate

symfony freeze <data_dir>

(nel mio caso, <data_dir> è /usr/share/php/symfony, su Linux)

Lanciate

symfony cc

per eliminare la cache, e uploadate il progetto sul server.

Ultimi accorgimenti

Per ultimo, date i permessi 777 alle directory project/cache, project/log e upload su Aruba. E ricordate che ogni volta che copiate nuovi file sul server, bisogna cancellare il contenuto della directory project/cache.

In caso riceviate Internal Server Error 500, provate a rimuovere option follow symlink da .htaccess.

E attenzione ad utilizzare la protezione password da admin: cancella il file .htaccess.

In compenso, durante il weekend appena trascorso, ho avuto il piacere di partecipare al phpDay 2009, evento organizzato dal GrUSP, la community italiana su PHP appunto.

I talk, tranne qualche – soporifero – caso, sono stati interessanti; evito di tediarvi con i verbali, ecco comunque le keyword che maggiormente mi sono rimaste impresse, o perchè ho avuto il riscontro della loro validità, o perchè sicuramente avrò voglia di approfondire:

• Cloud computing
• REST
• Test Driven Development
• Design Patterns

Salta niente all’occhio? A me sì: nessuna di queste keyword è strettamente legata a PHP

Ecco i passi che ho seguito io:

1. copiare via ftp i file da remoto a locale (in una locazione che chiameremo “wpDir”)
2. copiare/linkare wpDir all’interno della document root del web server (in modo che il sito sia accessibile via “http://localhost/wpSite”
3. esportare il database ed importarlo in locale (“wpDatabase”)
4. creare nel database locale lo stesso utente del database remoto, dandogli i permessi di accesso a wpDatabase
   
   CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'wp_password';
   GRANT ALL PRIVILEGES ON wpDatabase.* TO 'wp_user'@'localhost';

   (controllare le costanti DB_USER e DB_PASSWORD nel file wp-config.php, in caso di dubbi)

5. modificare i riferimenti all’indirizzo del sito, tra le opzioni di Wordpress salvate sul database
   
USE wpDatabase;
UPDATE wp_options SET option_value = "http://localhost/wpSite" WHERE option_name = "siteurl";
UPDATE wp_options SET option_value = "http://localhost/wpSite" WHERE option_name = "home";

A questo punto, puntando il browser su http://localhost/wpSite, dovreste avere una copia funzionante del vostro sito Wordpress! (sempre che fosse vostro, si intende)

Se, come nel mio caso, avete modificato il file wp-config.php, ricordate di salvarne prima una copia di backup, e di evitare si sovrascriverne la versione sul server remoto.

Io ci sarò, in qualità di curioso. Se qualcuno ha intenzione di andarci, come sempre, mi faccia un fischio!

var a = 5;
var myFunc = function (b) {
  return a + b;
};
a = 10;
alert( myFunc(2) ); //print 7

L’utilizzo di a all’interno di myFunc è chiamata closure: il valore di a viene bindato (legato) nello scope di myFunc, e rimarrà invariato nel tempo.

Dalla prossima versione di PHP, la 5.3, sarà possibile fare qualcosa del tutto simile. Ecco come:

$a = 5;
$myFunc = function ( $b ) use ( $a ) {
  return $a + $b;
};
$a = 10;
echo $myFunc( 2 ); // print 7

Notare che in PHP le closures vanno dichiarate esplicitamente con l’utilizzo del comando use.

Per quanto sia contento di questa nuova feature, rimango perplesso sulla linea con cui viene sviluppato ed aggiornato PHP: si prosegue con la mancanza di convenzioni, e a volte, come in questo caso, funzionalità nuove sanno più di patch che di improvement.

Sul sito di PHP trovate maggiori info, mentre in questo PDF sono elencate tutte le nuove features di PHP 5.3

Via: Zaemis

Il primo spunto viene da questo post intitolato Killing Distractions. Per quanto la mole di distrazioni che mi assalgono sia molto inferiore a quella di chi ha svariati clienti con i quali trattare durante la giornata, anche io sento che parte della mia produttività si disperde tra una lettura dei feed, risposte agli instant messages e mantenimento della mia presenza sul web perennemente “live”. E per fortuna sto evitando Twitter!

Lavorando nel web, sento la pressione di dovermi tenere costantemente aggiornato riguardo a nuove tecnologie, pratiche, linguaggi. Ma è necessario trovare un equilibro, limitando le distrazioni in finestre di tempo ben definite. Un metodo per riuscirci è pensare a tutte le persone che, non lavorando di fronte ad un computer, durante il giorno non possono nemmeno controllare la posta!

Sempre sul tema, recentemente parlavo con i colleghi di un metodo di lavoro per aumentare la produttività (e vivere felici): lavorare un giorno in meno! Guarda caso, l’autore dell’articolo è il buon Ryan Carson, l’organizzatore di FOWD, FOWA ed altri eventi simili.
Quella del non lavorare il venerdì è sicuramente una sfida interessante, ma, paradossalmente, praticabile soltanto quando si ha una grossa mole di lavoro (e quindi, di richiesta); di certo in periodi di crisi non dispiacerebbe a nessuno lavorare anche durante il weekend