Dopo svariati mesi di assenza su questo blog ritorna la categoria de les indispensables, questa occasione però sarà particolare perché per la prima volta parlerò del mondo Mac con un’applicazione che sto trovando abbastanza comoda: AppFresh. AppFresh vi permette di tenere sotto controllo e installare comodamente e in maniera centralizzata gli update di tutte le applicazioni che avete sul vostro Mac, non solamente quelle Apple ma anche quelle di terze parti compresi tra l’altro plugin, pannelli delle preferenze e widgets. La configurabilità è buona: potete scegliere in quali path andare a cercare le applicazioni, con quali modalità effettuare le scansioni dei programmi e le installazioni degli aggiornamenti oppure marcare la versione di un’applicazione che avete installato per considerarla come se fosse l’ultima, facendo in modo da non averla in elenco nel caso non siate intenzionati ad aggiornarla. AppFresh ha anche una funzionalità di snapshot e ripristino che vi permette di tornare sui vostri passi e ripristinare un’applicazione allo stato precedente un eventuale aggiornamento fallito o molto più semplicemente di vostro non gradimento. Non l’ho ancora provata, ma potrebbe tornare utile. Tutto sommato non mi dispiace e non mi ha dato problemi nelle ultime due settimane, ho aggiornato circa una ventina di applicazioni di vario tipo senza il minimo intoppo. Stando al sito ufficiale, AppFresh per ora è compatibile solamente con OS 10.4 ed è da considerarsi ancora come un’applicazione work in progress.

Messaggio di servizio. Finalmente ho aggiornato l’installazione di WordPress per questo blog e l’update è stato abbastanza sostanzioso vedendo il passaggio diretto dalla versione 2.1.2 alla 2.3.1 (mea culpa, ma negli ultimi mesi non ho avuto tempo e voglia di stare al passo con il susseguirsi di release a raffica che c’è stato) seguito da qualche martellata a funzioni del template, la rimozione di qualche mio hack ^(*) e un po’ di pulizia dei plugin, che fortunatamente avevo già aggiornato due mesi fa risparmiandomi un po’ di lavoro. Ho simulato, sistemato e provato tutto offline su una VM per cui non dovrebbero esserci problemi in questa versione online, ma nel caso doveste incappare in qualche glitch o bug vi chiederei cortesemente di segnalarmi il problema. Grazie mille!

(*) Nel ramo 2.3 di WordPress, all’interno della classe wpdb, hanno aggiunto la query SET NAMES ‘%charset%’ per impostare il set di caratteri del client MySQL per l’interfacciamento con il database. Prima era uno degli hack che dovevo puntualmente inserire a mano a ogni aggiornamento per ottenere il supporto del testo in UTF-8 su questo blog. Quante release hanno impiegato prima di capirla? Una ventina? Senza contare le segnalazioni…

Recentemente è stata rilasciata una nuova versione di PHP, per la precisione la 5.2.5, che va a sistemare alcuni bachi di sicurezza e sistema svariati bug sparsi. Il changelog è lungo, ma mi sono accorto di un comportamento modificato rispetto alla precedente versione che però non è stato segnalato: adesso la definizione del metodo magico __call restituisce un fatal error se lo stesso metodo viene definito all’interno di una classe usando argomenti passati per riferimento. Tradotto in codice:

class Test {
    public function __call($method, &$arguments) {
        // [...]
    }
}

Da notare la & prima di $arguments. Fino alla versione 5.2.4 l’interprete PHP faceva finta di nulla, non veniva nemmeno emesso un warning, mentre dalla 5.2.5 sono passati direttamente al lancio di un fatal error in fase di compilazione dello script:

Fatal error: Method Test::__call() cannot take arguments by reference in test.php on line 5

Sono d’accordo sul fatto che non avrebbe senso chiamare __call con $arguments passato per riferimento dal momento che comunque non funzionerebbe per come è pensato il funzionamento di questo metodo, però credo che almeno nel changelog avrebbero potuto segnalare questo cambio di comportamento da parte dell’interprete visto che adesso ci si ritrova con un Fatal error. Io ci sono incappato solo per una svista (avevo &arguments in una definizione e senza motivo visto che non cercavo nemmeno di fare chissà cosa), meno male che faccio sempre dei test sul server di sviluppo e non mi fido eccessivamente del changelog.

Che Apple faccia del pensiero alternativo il suo motto è un fatto risaputo, ma che applichi la filosofia del think different alla gestione delle eccezioni negli spostamenti di file nei suoi sistemi operativi è tutto un programma. Date un’occhiata a questo articolo di un blogger che parla di perdite di dati in caso di interruzioni repentine causate da errori durante le operazioni di spostamento di file in Leopard (ma non solo). Una gestione indubbiamente innovativa. Magari per ridere un po’ leggetevi i relativi commenti su Slashdot nella stessa notizia taggata come haha, bug, lol, macosx, apple

Comunque una doverosa nota chiarificatrice: chi mi segue penso abbia capito che nella realtà le guerre di religione tra i sistemi operativi non mi interessano nemmeno di striscio (ne ho per tutti, tranquilli) però ammetto con assoluta sincerità di divertirmi a infierire sulla mole di fanboy Apple che sarebbero pure pronti a buttarsi in un fosso nel nome della mela smangiucchiata. Tra l’altro ho posseduto un Quadra 900 con Mac OS 7.5 e un Beige PowerMac G3 333MHz con Mac OS X 10.1 e attualmente sto usando seriamente Mac OS X 10.4.10 per sondare lo sviluppo in ambiente OS X, quindi cortesemente il fanboy dell’ultimo minuto che dovesse leggere queste righe è pregato di astenersi da eventuali commenti che non apportino nulla di più rispetto a il mio sistema operativo è il più avanzato dell’universo, grazie

Per riconoscere in maniera rapida e indolore se i nostri script ruby vengono eseguiti da un interprete compilato a 32 bit piuttosto che a 64 bit basta interrogare la dimensione di un Fixnum usando Fixnum#size, un metodo che ritorna il numero di byte utilizzati dal computer per rappresentare un’istanza di Fixnum:

irb(main):001:0> "#{0.size * 8} bit"
=> "32 bit"

Lo stesso script eseguito in un interprete compilato a 64 bit su una architettura a 64 bit:

irb(main):001:0> "#{0.size * 8} bit"
=> "64 bit"

La sottile differenza con l’interrogare il sistema per ottenere in qualche modo l’architettura del sistema ospitante risulta ovvia pensando al fatto che potremmo avere un interprete compilato a 32 bit che gira su un’architettura a 64 bit e un sistema operativo a 64 bit. Implicitamente questo significa anche che Fixnum non è del tutto fixed e pertanto il valore massimo che può assumere in un’architettura a 64 bit è superiore al valore massimo in un’architettura a 32 bit, tanto che nell’header ruby.h possiamo trovare la seguente riga:

#define FIXNUM_MAX (LONG_MAX>>1) 

La costante LONG_MAX è definita in limits.h e il suo valore può variare in base all’architettura target della compilazione (2147483647 a 32 bit, 9223372036854775807 a 64 bit).