Tech blog, roba varia & me stesso
Giovedì ho avuto il piacere di raccontare a Radio24 le mia esperienze riguardo al coworking, ed in particolare al periodo passato nel Cowo.
Potete ascoltare qui la registrazione dell’intervista, in cui parlo nei 30 secondi finali 
Nessun compendio, solo un paio di appunti a riguardo:
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?
http://jeremy.zawodny.com/mysql/mytop/
Si dice che l’IDE sia estensione stessa dello sviluppatore: se ne trova uno che abbia le funzionalità che ci servono e si impara ad usarlo in maniera veloce e produttiva.
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.
Non sono un designer, ma lavorando per il web e avendo interesse per la User Experience capita di dover disegnare grafi, layout e interfacce. La soluzione matita + carta è sempre la più pratica, ma quando è necessario condividere i propri schizzi – e renderli modificabili – è più funzionale utilizzare un software ad hoc.
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!
Ultimamente mi e’ capitato di sviluppare un paio di siti utilizzando Symfony come framework di sviluppo e Aruba come hosting provider.
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.
Vi ricordate il post in cui affermavo di andare al Wordcamp? Beh – scordatelo, non ci andrò più, visto che sarò in Sardegna per una sessione di lavoro! (e no, non è un villaggio turistico)
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:
Salta niente all’occhio? A me sì: nessuna di queste keyword è strettamente legata a PHP
In questi giorni mi e’ capitato di dover applicare delle modifiche e debuggare un sito Wordpress installato su un server remoto. Naturalmente la cosa piu’ semplice da fare e’ lavorare su una copia del sito stesso installato in locale; l’operazione pero’ non si limita a un dump dei file del db, ma ci sono anche alcuni passi da compiere che possono far perdere tempo.
Ecco i passi che ho seguito io:
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)
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.
A Milano, il 22 e 23 maggio, si svolgerà il WordCamp 2009, un barcamp incentrato su Wordpress e quello che gli gira intorno: blog, tecnologie, metodi, usabilità e quant’altro.
Io ci sarò, in qualità di curioso. Se qualcuno ha intenzione di andarci, come sempre, mi faccia un fischio!
Fino ad oggi in PHP era possibile creare funzioni anonime (lambda) utilizzando la funzione create_function, ma il suo utilizzo non mi ha mai convinto, sapeva troppo di eval. Essendo abituato a Javascript, e a jQuery, trovo questa sintassi molto più funzionale:
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
In passato avevo già parlato di coworking e lavoro da casa, questa volta invece voglio condividere alcune considerazioni sui metodi di lavoro. E non intendo metodologie di sviluppo agili o simili, ma semplicemente modi per affrontare le proprie giornate lavorative.
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 