Questa mattina ho scoperto che il codice utilizzato da anni per visualizzare in WordPress i video recuperati da un feed RSS di YouTube ha smesso di funzionare. Invece di visualizzare il video corretto, ci si trova davanti a questo avviso.

Ecco il codice aggiornato e ripulito. Il videoId è disponibile direttamente nell’XML del feed.

<?php
include_once(ABSPATH . WPINC . '/feed.php');

$get_videos = function ($feed_data) {
    $output = "<ul>\n";
    if (! $feed_data) {
        $output .= "<li>Nessun video disponibile</li>\n";
    } else {
        foreach ($feed_data as $item) {
            $youtubetitle = $item->get_title();
            $video_id = $item->get_item_tags(
                'http://www.youtube.com/xml/schemas/2015',
                'videoId'
            );
            $youtubeid = $video_id[0]['data'];

            $output .= "<li>\n";
            $output .= '<iframe width="240" height="176" src="https://www.youtube.com/embed/' .
                       $youtubeid . '?controls=0&amp;showinfo=0" frameborder="0"></iframe>';
            $output .= "<span>{$youtubetitle}</span>\n";
            $output .= "</li>\n";
        }
    }
    $output .= "</ul>\n";

    return $output;
};

?>

<h3>Video</h3>
<?php
    $url = **** URL del feed RSS****;
    $rss = fetch_feed($url);
    if (! is_wp_error($rss)) {
        // Verifica se l'oggetto è stato creato correttamente
        // Individua il numero di video presenti, al massimo leggine 3.
        $maxitems = $rss->get_item_quantity(3);
        // Crea un array di tutti gli elementi (il primo elemento ha indice 0).
        $rss_items = $rss->get_items(0, $maxitems);
    }
    echo $get_videos($rss_items)
?>

Tra i propositi per il 2015 c’era quello di correre almeno 100 km al mese. Sarà dura, visto che mi è ufficialmente tornata la scimmia per la MTB, e mi sono finalmente deciso a cambiare la vecchia (12 anni) con una 29″.

Per il momento il 2015 segna 326 km di corsa, 618 km in mtb. Per quest’ultimo dato la differenza sostanziale è il dislivello totale: 10.127 m (fatti in buona parte su sterrato), contro i 13.401 m (per 1.121 km) del 2014.

Appunti per tecnici anziani e smemorati: come configurare l’accesso via SSH utilizzando una coppia di chiavi invece di nome utente e password.

Passo 1: generare la chiave

ssh-keygen -t rsa

Personalmente assegno un nome diverso rispetto al predefinito (id_rsa) per capire al volo di che cosa si tratta.

Passo 2: copiare la chiave sul server

Copiare il file via FTP o direttamente via scp

scp /home/UTENTE/.ssh/id_rsa.pub UTENTE_REMOTO@SERVER_REMOTO:.

Effettuare l’accesso al server via SSH (con nome utente e password) e copiare il contenuto della chiave pubblica in .ssh/authorized_keys

cat /home/UTENTE/id_rsa.pub >> /home/UTENTE/.ssh/authorized_keys

Se necessario creare la cartella .ssh prima di lanciare questo comando. Dovrebbe funzionare anche con sss-copy-id, ma su Mac va installato (es. con homebrew).

ssh-copy-id -i /home/UTENTE/.ssh/id_rsa UTENTE_REMOTO@SERVER_REMOTO

Passo 3: modificare .ssh/config in locale per utilizzare la chiave

Host SERVER_REMOTO
User UTENTE_REMOTO
IdentityFile ~/.ssh/id_rsa

Nel file config è possibile utilizzare wildcard, particolarmente utile per le innumerevoli macchine virtuali 🙂

Per iniziare una rapidissima panoramica sull’attuale ciclo di sviluppo di Firefox, introdotto a partire dalla versione 5.0 e anche noto come rapid release cycle.

Il ciclo di sviluppo dura 6 settimane, con qualche eccezione causa festività o eventi particolari, ed esistono quattro canali di distribuzione.

Nightly: il più instabile, aggiornato ogni giorno. È consigliato solo a utenti più esperti che, ad esempio, sappiano come gestire più profili ed effettuare backup dei propri dati (Sync aiuta).

Developer Edition (ex Aurora): sufficientemente stabile per l’uso quotidiano, focus sugli sviluppatori web, aggiornamenti quasi quotidiani. Da quando è stata introdotta la versione Developer Edition (novembre 2014), l’opzione predefinita è quella di utilizzare un profilo specifico “dev-edition-default” per questa versione, separato dai profili esistenti.

Beta: stabile, aggiornato due volte a settimana, adatto soprattutto a chi voglia sperimentare in anteprima le novità. Nella prima metà del ciclo (indicativamente fino alla beta 4) è possibile provare caratteristiche che non verranno incluse in release.

Release: la versione consigliata per l’uso quotidiano, aggiornata ogni 6 settimane a meno che non venga distribuita una versione intermedia per problemi di stabilità o sicurezza (es. 36.0.4).

Questa è la situazione attuale (parlando di eccezioni, siamo in un ciclo di sole 5 settimane):

• Nightly: Firefox 39
• Developer Edition: Firefox 38
• Beta: Firefox 37
• Release: Firefox 36

Lunedì prossimo (30 marzo) è il merge day: Nightly diventa Firefox 40, Firefox 39 passa in Aurora, Firefox 38 in beta e viene ufficialmente distribuito Firefox 37. Il giorno di distribuzione è normalmente il martedì successivo al merge day. Da sempre, anche prima del nuovo ciclo di sviluppo, il martedì è il giorno dedicato all’uscita di nuove versioni o prodotti in Mozilla.

Nightly in italiano?

Sempre più spesso vedo utenti esperti utilizzare Nightly in inglese: mentre le versioni Developer Edition/Beta/Release localizzate in italiano sono facili da scaricare, questo non è purtroppo vero per Nightly.

È possibile scaricare Nightly in italiano direttamente dal server FTP Mozilla utilizzando questo link. Cercate ‘.it’ nell’elenco e selezionate la versione adatta al vostro sistema operativo. La versione localizzata è aggiornata ogni giorno, esattamente come quella inglese. Eventuali nuove stringhe vengono generalmente tradotte nel giro di 1/2 giorni, e potete utilizzare il forum di supporto per segnalare eventuali errori. Un modo semplice per dare il vostro contributo 😉

Il mio profilo Eolo ha un limite di traffico di 40 GB mensili al massimo della velocità (20/2 Mbit/s). Superato questo limite la velocità viene ridotta a 5/0,5 Mbit.

Eolo fornisce un’applicazione per visualizzare il traffico rimanente, ma la trovo piuttosto scarsa di informazioni. Siccome il codice è su Github, pur non conoscendo nulla di Adobe Flex ho cercato di capire come funziona e scoperto che i dati vengono recuperati in formato JSON.

Questo è lo script che attualmente utilizzo per tenere d’occhio il traffico con GeekTool (i programmatori Python sono pregati di ignorare la bruttezza del codice, disponibile anche su GitHub).

#! /usr/bin/env python

import json
import urllib2
from datetime import datetime

eolo_url = "https://care.ngi.it/ws/ws.asp?a=get.quota"
try:
    response = urllib2.urlopen(eolo_url)
    json_data = json.load(response)
    if json_data['response']['status'] == 200:
        data = json_data['data']
        # Days before reset
        cycle_length = 30
        end_date = datetime.strptime(data['nextReset'], "%Y-%m-%d %H:%M:%S")
        remaining_days = abs((end_date - datetime.today()).days);
        if cycle_length - remaining_days > 0:
            used_days = cycle_length - remaining_days
        else:
            used_days = 1
        # Data quota/usage
        quota_mb = data['quota'] / 1024
        used_mb = data['used'] / 1024
        remaining_mb = quota_mb - used_mb
        # Print values
        print "Rimamenti:        %5.0f MB" % remaining_mb
        print "Quota:            %5.0f MB" % quota_mb
        print "Giorni:              %2.0f g" % remaining_days
        # Avoid division by 0
        if remaining_days == 0:
            remaining_days = 1;
        print "Media consumo:    %5.0f MB/g" % \
              (used_mb / used_days)
        print "Media dispon.:    %5.0f MB/g" % \
              (remaining_mb / remaining_days)
except urllib2.HTTPError, err:
    if err.code == 403:
        print "Errore 403 - Connessione non Eolo"
    else:
        raise
except Exception as e:
    print "Errore lettura JSON da %s:\n %s" % (eolo_url, e)

Un altro script mi permette di verificare il gateway in uso (per scaricare file di grandi dimensioni e non urgenti posso usare l’ADSL standard).

#! /usr/bin/env bash

printf "IP Address: `ifconfig en0 | grep inet | grep -v inet6 | awk '{print $2}'`\n"
printf "Gateway:    `route -n get default | grep gateway | awk '{print $2}'`\n"

Il secondo script è stato aggiunto dopo essermi accorto di aver scaricato 5 GB di XCode e aggiornamenti pensando di essere collegato all’ADSL. Su Windows mi serve solo visualizzare il gateway, e Rainmaker fa il suo lavoro piuttosto bene.

Ho una connessione ADSL Telecom da una vita, partita come Tin.it 512k non appena la mia zona è stata raggiunta dal segnale (a memoria oltre dieci anni fa).

Conoscendo le esperienze di amici e colleghi, sono consapevole di non potermi lamentare: credo di aver avuto 4 o 5 black-out seri in tutti questi anni, la connessione è stabile e decentemente veloce.

Nota: per avere queste velocità pago l’opzione Superinternet Plus (10,08 €/bimestre da aggiungere ai 43,80 € di Alice 7 Mega).

Considerato che lavoro da casa, e Internet è assolutamente fondamentale, da un po’ di tempo stavo pensando di mettere una connessione di backup (la ricezione dei cellulari è pessima nella zona in cui vivo). Per darmi la spinta finale Telecom ha deciso di lasciarmi a piedi per 48 ore, in cui ho dovuto arrangiarmi utilizzando un Flame con Firefox OS come hotspot, e rinviare almeno 2 o 3 riunioni (banda disponibile su cellulare e connessione video non vanno d’accordo).

La scelta è caduta su Eolo. Ho bisogno di utilizzare la connessione per un po’ di giorni prima del verdetto finale, ma per ora l’unico problema è quello di definire questa connessione il “backup”.

Il profilo è 20/2 Mbit, con limite mensile di 40GB. Se le prestazioni rimangono queste, Eolo è destinato a diventare la connessione primaria e Telecom il backup.

Per i curiosi: per l’ADSL Telecom utilizzo un Fritz!box 3390, mentre per Eolo ho preso un Asus RT-N56U. Sono rimasto piacevolmente sorpreso dall’Asus, peccato solo per la malsana idea di dover ripristinare la configurazione quando aggiorni il firmware.