I took the opportunity to upgrade the ember-mqttjs support to Ember v4 for refactoring the addons tests. During last EmberFest (which happened in Rome on Sept. 30 and Oct. 1, 2021) I listened to a lot of brilliant talks. One of them caught my attention because it dealt with the testing topic and in particular of mocks and stubs.

Gonçalo Morais dove into this argument with some stunning hints during his talk “Mock & Roll” that opened my minds and let me wondering on how to improve my mqtt ember addon tests.

After some experiments with the mock-socket library I realized that this tool was not anymore mantained and combining some searchs into the Sinon.JS documentation I found a way to stub the MQTT.js dependency faking the connect method.

This method returns a client and triggers some events that are useful to understand the mqtt connection status. Joining the replace and fake methods from Sinon.JS I found a way to simulate the MQTT.js connect method behavior returning a client with the necessary methods and triggering the needed events.

As you can see next on the code sample attached to this post I need to add some tricks to the joke, because for example the connect event needs to be trigger after a delay while the fake client declares an event handler that must to be there when the event is fired. Or for example the subscribe and publish methods need to call a callback with the correct parameters.

Once I discovered this tricks the tests runs correctly and I can assume that my code is working fine relying on the MQTT.js client to be properly tested.

Code sample

This is the example for the connect test but you can find the whole code into the addon repository:

import { module, test } from 'qunit';
import { setupTest } from 'ember-qunit';
import sinon from 'sinon';
import mqttjs from 'mqtt/dist/mqtt';
import Service from '@ember/service';
import Evented from '@ember/object/evented';
import { later } from '@ember/runloop';

class MqttServiceStub extends Service.extend(Evented) {}

module('Unit | Service | mqtt', function (hooks) {
  let mqttHost = 'ws://localhost:8883';
  let mqttTopic = 'presence';
  let mqttMessage = 'Hello';

  let mqttServiceStub;

  setupTest(hooks);

  hooks.afterEach(() => {
    sinon.restore();
  });

  // ...

  //Testing mqtt connect
  test('mqtt connect success', async function (assert) {
    let service = this.owner.lookup('service:mqtt');
    let done = assert.async();
    assert.expect(3);
    mqttServiceStub = new MqttServiceStub();
    sinon.replace(
      mqttjs,
      'connect',
      sinon.fake(() => {
        later(() => {
          mqttServiceStub.trigger('connect');
        }, 100);
        return {
          on: (sEvent) => {
            mqttServiceStub.on(sEvent, () => {
              if (sEvent === 'connect') {
                return service.onConnect();
              }
            });
          },
        };
      })
    );
    try {
      service.on('mqtt-connected', () => {
        assert.ok(true);
      });
      await service.connect(mqttHost);
      assert.ok(service);
      assert.ok(service.isConnected);
    } catch {
      assert.ok(false);
      assert.ok(false);
      assert.ok(false);
    } finally {
      done();
    }
  });

If you notice some errors or you need more informations about the code I’m happy to hear from you. Reach me through my contact page.

The post Stubbing MQTT.js library in Ember.js tests with Sinon.JS first appeared on Davide Ferrero.

Less than 2 years ago I started a new project with the company I work for that requires to an Ember Octane app to control several connected IoT devices around the world. We choosed the MQTT publish/subscribe network protocol to interact with our on-field devices for its lightweight message structure and its limited network bandwith requirements.

After googling for a javascript MQTT library I’ve found the MQTT.js client. At the moment of my search the asynchronous version was not yet released, so I had to wrap the event based client into an Ember service and transform it into a Promise based client.

This is a mandatory requirement because I need broker connection before subscribing to a topic or I need topic subscription before publishing on it. Sometimes you had retain messages on a topic for receiving last published value after the subscription. Other times you need publishing an empty value on a topic to request the status of a given device. So you need working subscribtion on a topic before sending a message. That said javascript Promises are the only way to accomplish this tasks.

When I wrote this service I didn’t find an Ember addon ready to do this things. Therefore I decided to dive into the docs and learn how to build an addon. The ember-mqttjs addon is my first Ember addon!

The code

This service extends the Evented Ember object for raising events on new messages as well as connect, disconnect events and many others you can find on its readme. In addition of raising this events it returns a Promise for connect, subscribe, unsubscribe and publish methods.

This is an example of another service that uses the ember-mqttjs service:

import Service, { inject as service } from '@ember/service';
import { bind } from '@ember/runloop';

export default class YourService extends Service {
  @service mqtt;
  constructor() {
    super(...arguments);
    //...
    let _fOnMessage = bind(this, this._onMessage);
    this.mqtt.on('mqtt-message', _fOnMessage); 
  }

  _onMessage(sTopic, sMessage) {
    //code to manage messages received on a certain topic
  }

  async subscribeAndPublish(sTopic, sMessage) {
    try {
      await this.mqtt.connect(HOST, USERNAME, PASSWORD)
    } catch (oError) {
      //code on connection error
    }
    try {
      await this.mqtt.subscribe(sTopic);
    } catch (oError) {
      //code for subscription error
    }
    try {
      await this.mqtt.publish(sTopic, sMessage);
    } catch (oError) {
      //code for message publish error
    }
    return Promise.resolve();
  }
//...
}

I’ve just refactored the addon code to use async/await features and I moved the CI from travis to github action (thanks to this Jeldrik Haschke’s repo).
Many improvements can be done in the future starting from writing more tests to cover other cases.
If you have any suggestions or proposal to improve the code as well as the tests you are welcome!

Contact me or start contributing on GitHub project repo!

The post MQTT in Ember.js first appeared on Davide Ferrero.

Today I welcome a new template for my blog by returning to write a post after a very long time!

This WordPress theme is built on top of the latest Bootstrap release, Bootstrap 5 and with this post I would like to explain you how to use this hugely popular front-end framework in an Ember app.

With this major new release the developers have focused most of their efforts towards removing jQuery as a dependency of the framework to make it lighter and usable by a wider audience now interested in saving as much kb as possible.

For those who knows and uses the previous Bootstrap version (v4) I suggest to dive into the migration guide, to understand what breaking changes were made in this new update.

As an experiment (I will tell you later about what I am working on in my spare time) I’ve tried to use Bootstrap 5 in a new Ember Octane app and thank to the release of the bootstrap npm package this turned out to be tremendously simple.

Let’s see the steps:

First you have to install the bootstrap npm package:

npm install --save-dev bootstrap

Then you have to modify your ember-cli-build.js file:

'use strict';

const EmberApp = require('ember-cli/lib/broccoli/ember-app');

module.exports = function (defaults) {
  let app = new EmberApp(defaults, {
    // Add options here
    sassOptions: {
      includePaths: ['node_modules/bootstrap/scss'],
    },
  });
  app.import('node_modules/bootstrap/dist/js/bootstrap.bundle.min.js');
  return app.toTree();
};

The last few steps are required to be able to import bootstrap SCSS files.
First you have to install ember-cli-sass addon:

ember install ember-cli-sass

Then you have to rename your app style app.css to app.scss and insert the line to import the bootstrap files:

@import 'bootstrap';

You are now ready to use Bootstrap 5 in your Ember app!

The post Ember + Boostrap 5 first appeared on Davide Ferrero.

Gulp js è una libreria javascript che permette di automatizzare svariate tipologie di noiose procedure che gli sviluppatori normalmente fanno “a mano”.

Proprio in questa direzione ho deciso di scrivere un breve script gulp che consente di automatizzare la ricompilazione dei fogli di stile SASS (scss), per evitarmi di lanciare, ad ogni modifica dei files, il comando sass sorgente.scss destinazione.css.

L’unico prerequisito per utilizzare gulp è di aver installato Nodejs ed il suo package manager npm (che viene installato di default insieme a node). Una volta installato node e scaricati i sorgenti del mio script basterà lanciare:

sudo npm install

…ed npm installerà per voi tutte le dipendenze necessarie!

Lo script prevede due modalità di esecuzione tramite i seguenti comandi:

• gulp: compila i vostri scss presenti nella sottocartella src in un unico css nella root directory minifizzato (sass –style compressed)
• gulp dev: compila gli scss in modalità espansa (sass –style expanded)

Questi due comandi avviano un task che rimane “in ascolto” e ad ogni modifica di un file scss rilancia il comando evitando il noioso compito di lanciare ogni volta la compilazione dei files per vedere le modifiche allo stile delle vostre web app/siti. In questo modo potrete scrivere le direttive di stile come si faceva prima dell’avvento di SASS/LESS e vedere immediatamente le nuove modifiche “live”.

Ho previsto un repository github “gulp-for-sass” con questo mini-progetto, scaricabile e modificabile liberamente!

The post Uno script Gulp per automatizzare la compilazione dei files Sass (scss) first appeared on Davide Ferrero.

Continuando ad interessarmi al mondo Django sono venuto a conoscenza di un interessante sistema da utilizzare nello stack per il deploy di un’app sviluppata con questo framework.

Sto parlando di Supervisor, un sistema client/server per il controllo di processi Unix. Inizialmente nel mio stack avevo utilizzato Upstart, il controllore di processi presente di default su Ubuntu, ma utilizzando la funzione respawn, ossia per ogni processo terminato ne viene lanciato un altro, il sistema si perde il riferimento con il processo lanciato e i comandi di stop non hanno più effetto. Sentendo parlare bene di Supervisor mi sono deciso a provarlo ed effettivamente funziona alla grande!!! E’ possibile conoscere lo stato di tutti i processi registrati in Supervisor oltre ai classici comandi di start, stop e restart dei vari processi attivi.

Supervisor è presente all’interno del repository dei pacchetti Ubuntu, quindi per installarlo è sufficiente il comando:

sudo apt-get install supervisor

Per il primo avvio è necessario digitare:

service supervisor restart

A questo punto possiamo aggiure un nuovo programma, che nel caso di applicazioni Django sarà lo script python per l’avvio di Gunicorn (il server wsgi per Django di cui ho già ampiamente parlato qui), vediamo un esempio:

command = '/opt/APP_VIRTUAL_ENV/bin/gunicorn'
pythonpath = '/SRC/APP/PATH/'
bind = '127.0.0.1:8000'
workers = 3
user = 'CUSTOM_USER'
pid = '/var/run/APP_NAME.pid'
accesslog = '/var/log/gunicorn/APP_NAME/access.log'
errorlog = '/var/log/gunicorn/APP_NAME/error.log'

Ovviamente questo è un mio esempio di script per il lancio di gunicorn relativo ad una app django, ma questo tipo di configurazione è valido per qualsiasi processo che si vuole controllare, basta specificare all’interno di “command” il comando che supervisor deve lanciare e controllare. Io sono solito mettere questo script in una cartella chiamata appunto “script” allo stesso livello dei sorgenti dell’app, ma può essere posizionato in qualunque punto del sistema. Sarà poi il file di configurazione del programma in supervisor a dover sapere dove recuperare lo script appena preparato.

Come dicevo, supervisor viene informato di un comando da lanciare mediante un file (un file per ogni comando) all’interno della cartella /etc/supervisor/conf.d/APP.conf contenente le seguenti linee:

[program:APP_NAME]
command=/opt/APP_VIRTUAL_ENV/bin/gunicorn APP_NAME.wsgi:application -c/SRC/APP/SCRIPT/PATH/gunicorn_config.py
autostart=true
autorestart=true
stderr_logfile=/var/log/gunicorn/APP_NAME/supervisor_stderr.log
stdout_logfile=/var/log/gunicorn/APP_NAME/supervisor_stdout.log

Non sto a spiegare nel dettaglio il significato della prima linea, che è il comando per avviare Gunicorn con la nostra app django tramite lo script precedentemente scritto, mentre la seconda e la terza linea dicono a Supervisor rispettivamente di avviare il comando all’avvio del sistema e di riavviare i processi che vengono terminati in modo non naturale. Le ultime due linee specificano i percorsi dei files di log di Supervisor.

A questo punto dobbiamo dire a Supervisor di leggere la nuova configurazione:

supervisorctl reread

Seguito dal comando per abilitare il nuovo programma:

supervisorctl update

Adesso la nostra app dovrebbe essere avviata!

Potete controllare lo stato di Supervisor con il semplice comando:

supervisorctl status

Per avviare, stoppare o riavviare i processi sono presenti i comandi:

supervisorctl start

supervisorctl stop

supervisorctl restart

Mentre per avviare la console interattiva di Supervisor è sufficiente digitare:

supervisorctl

Non vi resta che scrivere app (Django, Node, ROR o ciò che più preferite) e farne controllare i loro processi da Supervisor!

The post Django + Supervisor su Ubuntu server first appeared on Davide Ferrero.

Facendo dei test di scrittura/lettura di informazioni all’interno dei cookies sembrava che non fosse consentito utilizzarli da localhost, ossia in locale. Più precisamente il cookie settato in una pagina, spariva letteralmente passando in un’altra pagina (cambiando url).

Dopo aver perso tutte le speranze e mentre vagavo senza meta all’interno delle issues del repository Github di AngularJs mi si è aperto un modo: un utente che si era interessato al problema dei cookies diceva che dopo averne discusso con il team di sviluppo aveva scoperto che per far funzionare a dovere questa funzionalità era necessario impostare il tag html base.

Facciamo un esempio: se il vostro progetto risponde all’url http://localhost/tests/angularjs/cookies sarà necessario impostare il base tag nel seguente modo:

 <base href="http://localhost/tests/angularjs/cookies/"> 

In questo modo i cookies verranno salvati per tutte le url che inizieranno per l’indirizzo specificato nel tag.

Il particolare importante da notare è lo slash finale. Senza quello nulla funzionerà.

The post Ng-Cookies e cookies su localhost con AngularJs first appeared on Davide Ferrero.

Oggi torno sul blog per scrivere un breve tutorial riguardante il “mondo” Django.

Da buon appassionato di questo framework continuo nei miei esperimenti e in questo articolo spiegherò come modificare le chiavi primarie delle tabelle django da numero intero a stringa alfanumeriche sulla falsa riga degli uuid di PostgreSQL.

Il framework usa come default chiavi primarie di tipo integer che per ovvi limiti di architettura del tipo int possono essere grandi al massimo 32 bit. Con poche righe di codice vedremo come sostituire la chiave primaria con un valore generato tramite il modulo python uuid.

Per prima cosa in genere mi creo un file utils.py nell’app principale, un modulo in cui inserire tutte le funzioni di utilità per l’app. All’interno di questo file andremo a creare la nostra funzione che genererà gli uuid in questo modo:

import uuid

def make_uuid():
   return str(uuid.uuid1())

In questo modo genereremo un id alfanumerico basato sul mac address dell’host da cui viene generato, un numero di sequenza (in questo caso random) e il timestamp corrente. In questo modo non solo avremo id univoci all’interno della tabella, ma addirittura all’interno dell’intero database azzerando di fatto la possibilità di collisioni (l’unica possibilità sarebbe se venissero generati nello stesso istante due id con lo stesso numero di sequenza, non impossibile ma altamente improbabile).

Una volta scritta questa funzione non ci resta che usarla per generare gli id all’interno dei nostri model come nell’esempio sottostante:

from APP_NAME.utils import make_uuid
from django.db import models

class MyModel(models.Model):
   id = models.CharField(max_length = 36, primary_key = True, default = make_uuid, editable = False)
   ... altri campi ...

Come potete vedere si dovrà importare la funzione appena scritta all’interno del file models.py e utilizzarla per specificare il valore di default del campo id (omesso di default in caso di id standard).

Se si volesse evitare di usare il mac address della macchina per generare l’uuid si potrebbe utilizzare una funzione differente. Ad esempio la uuid.uuid4() genera uuid random, ovviamente a discapito di una, seppure remota, possibilità di collisioni.

The post Id alfanumerici per le chiavi primarie in django first appeared on Davide Ferrero.

Come avrete potuto sicuramente notare in questi ultimi giorni, ho finalmente pubblicato la nuova versione del template per il mio blog personale! Siamo arrivati alla versione 4!

Ho deciso di sviluppare un tema WordPress totalmente nuovo, partendo da un foglio bianco ed ispirandomi a “cose” viste qua e là.

La mia esigenza era quella di ottenere, con il minimo sforzo, un template ottimizzato per tutti i dispositivi, da quelli con schermi ad alta risoluzione fino ai “mobile”, sempre più in voga negli ultimi tempi. Ho perciò utilizzato lo standard de facto dei framework CSS: Bootstrap 3! Ed ecco il risultato, un template adatto a desktop, tablet e smartphone!

Mi sono servito di una classe walker scritta ad hoc per utilizzare i menu WordPress con Boostrap, in modo da poter sfruttare la navbar fissata in alto. Per il resto la giusta miscela di codice php e html, qualche file css/js ed ecco qua, il nuovo template!

Il font che ho scelto è l’Open Sans, uno dei più utilizzati ultimamente sul web, e mi viene servito direttamente da Google Fonts.

Spero di essere riuscito nell’intento di fornire una navigazione più piacevole e al tempo stesso più completa. Presto cercherò di rendere disponibile gratuitamente e sotto licenza open source questo tema nel repository di WordPress. Nel frattempo se avete domande/curiosità non esitate a commentare l’articolo o a scrivermi tramite la solita pagina dei contatti.

Invece il prossimo passo che ho in mente per il blog sarà qualche cambiamento “sotto il cofano”, ma non voglio svelarvi niente e mi tengo un po’ di tempo per fare ancora qualche test!

A presto!

The post Template WordPress responsive per il mio blog! first appeared on Davide Ferrero.

In questo brevissimo articolo vi dimostrerò come evitare che il browser degli utenti usi una versione non aggiornata del vostro css di WordPress.

Con questa breve funzione andremo ad inserire un parametro in fondo al richiamo del foglio di stile che inserisca il timestamp dell’ultima modifica del file, in modo che la cache continui a funzionare fino a quando non sarete voi a modificare il file.

<link href="<?php echo get_bloginfo('template_url'); ?>/style.css?v=<?php echo filemtime(get_stylesheet_directory().'/style.css'); ?>" rel="stylesheet" media="screen">

Come potete vedere abbiamo applicato il concetto al css principale di wordpress ma si può applicare a qualsiasi file css, js o di immagini. La funzione di php utilizzata è la filemtime.

The post Evitare il caching del css di WordPress first appeared on Davide Ferrero.

Torno a scrivere sul mio blog per trattare un argomento a mio giudizio interessante, anche se un po’ specifico.
Per conto di un cliente mi sto occupando delle API di Google Maps, in particolare l’ultima versione, ossia la V3.
Premetto, per chi non conoscesse l’argomento, che dalla versione 2 c’è stato un grande passo avanti, con ottime nuove funzionalità e tanti metodi che fanno risparmiare un sacco di tempo… D’altronde stiamo parlando di Big G!

Lo script che pubblico in questa pagina serve per rimediare al problema delle limitazioni poste da Google su ogni singola richiesta di calcolo di un percorso. Il cliente in questione deve visualizzare sulla mappa il tragitto tra due punti, passando però per un numero indefinito di punti intermedi.

Per fare questo Google rende disponibili le directions API impostando però il limite di 2500 richieste giornaliere e 8 punti intermedi per richiesta. L’idea è semplice, ottimizzare le richieste includendo al massimo 8 punti intermedi, settando però, dalla seconda richiesta in avanti, il punto di partenza uguale al punto finale della richiesta precedente.

Vediamo il codice javascript:

    var map = null;
    var markers = new Array();
    var coordinates = new Array();
    var directionsDisplay = new Array();
    var directionsService = new google.maps.DirectionsService();
    function placeMarker(lat, lng){
        var markerPos = new google.maps.LatLng(lat, lng);
        var marker = new google.maps.Marker({
            position: markerPos,
            map: map,
            draggable: true,
            animation: google.maps.Animation.DROP
        });
        markers.push(marker);
    }

    function removeRoutes(){
        for(var i = 0; i < directionsDisplay.length; i++){
            directionsDisplay[i].setMap(null);
        }
        directionsDisplay = new Array();
    }

    function drawRoute(begin, end, waypts){
        var request = {
            origin: begin,
            destination: end,
            waypoints: waypts,
            optimizeWaypoints: true,
            travelMode: google.maps.TravelMode.DRIVING
        };
        directionsService.route(request, function(response, status) {
            if (status === google.maps.DirectionsStatus.OK) {
                var dirDisp = new google.maps.DirectionsRenderer({suppressMarkers: true});
                dirDisp.setMap(map);
                dirDisp.setDirections(response);
                directionsDisplay.push(dirDisp);
            }
        });
    }

    function calculateRoutes(){
        removeRoutes();
        var begin = new google.maps.LatLng(coordinates[0][0], coordinates[0][1]);
        var end = null;
        var waypts = new Array();
        var wCount = 0;
        var REQUEST_WAYPOINTS_LIMIT = 8;
        var i;
        for(i = 1; i < (coordinates.length-1); i++){
            if(wCount === REQUEST_WAYPOINTS_LIMIT){
                i++;
                end = new google.maps.LatLng(coordinates[i][0], coordinates[i][1]);
                drawRoute(begin, end, waypts);
                begin = end;
                wCount = 0;
                waypts = new Array();
            }
            waypts.push({
                location: new google.maps.LatLng(coordinates[i][0], coordinates[i][1]),
                stopover: true
            });
            wCount++;
        }
        if(waypts.length > 0){
            end = new google.maps.LatLng(coordinates[coordinates.length-1][0], coordinates[coordinates.length-1][1]);
            drawRoute(begin, end, waypts);
        }
        for(var i = 0; i < coordinates.length; i++){
            placeMarker(coordinates[i][0], coordinates[i][1]);
        }
    }

Nel codice qui sopra come potete vedere ho un array di coordinate che contiene i vari punti da rappresentare sulla mappa, e il percorso deve essere calcolato partendo dalla prima coordinata presente in array per arrivare all’ultima cella dell’array, passando per tutte le altre.

Ho dato per scontato che la mappa sia già stata inizializzata e che la variabile map contenga l’oggetto google.maps.Map.

Un’ulteriore miglioria già fatta (che tratterò in un futuro articolo) sarà quella di colorare e numerare i marker dinamicamente e di adattare automaticamente lo zoom della mappa ai markers attivi sulla mappa visualizzata.

The post Aggirare le limitazioni delle API di Google Maps per il calcolo dei percorsi first appeared on Davide Ferrero.

Con l’avvento di InnoDB su MySQLci si trova sempre più spesso a dover trattare tabelle con chiavi esterne. A volte per modificare una tabella si rende indispensabile eliminare le chiavi prima di eseguire la modifica, chiavi che però non sono elencate insieme alla struttura della tabella. Per estrarre quindi la lista delle chiavi di una tabella la query da eseguire è quindi la seguente:

select * from KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = '<em>database_name</em>' AND TABLE_NAME = '<em>table_name</em>'

Come si può intuire, al posto di database_name si dovrà inserire il nome del database in cui risiede la tabella, e al posto di table_namesi dovrà scrivere il nome della tabella dalla quale estrarre le chiavi.
Una volta ottenuta la lista di foreign key, per elimare una chiave il codice sql da eseguire è:

ALTER TABLE <em>table_name</em> DROP FOREIGN KEY <em>foreign_key_name</em>

Table_name è come sopra il nome della tabella in cui risiedono le chiavi esterne, mentre foreign_key_name è il nome della chiave ottenuto dalla lista estratta con la query precedente.

The post Visualizzare ed eliminare foreign keys in MySQL first appeared on Davide Ferrero.

Succede sempre più di frequente di dover effettuare delle chiamate ajax in WordPress. In questo articolo vedremo come effettuare delle chiamate asincrone senza dover creare nuove pagine WordPress ma sfruttando lo script utilizzato dall’interfaccia del wp-admin.
Nell’esempio in questione, la chiamata AJAX restituirà un file JSON formato davvero utile per rappresentare i dati restituiti da una query. Lato javascript useremo la funzione $.getJSON(…) di jQuery mentre lato server scriveremo il nostro script all’interno del file functions.php presente in qualsiasi tema WordPress.

Per prima cosa dobbiamo creare la corrispondenza tra una nuova action e la nostra funzione php:

add_action('wp_ajax_myaction', 'my_function');

Fatto ciò possiamo scrivere la nostra funzione my_function la quale corrisponderà all’azione myaction (il nome è puramente indicativo, potete chiamare l’azione e la funzione come preferite):

function my_function() {
  global $wpdb;
  $id = $_GET['id'];
  $rows = array();
  $q = "SELECT * FROM my_table WHERE id = ".$id;
  $rows['results'] = $wpdb->get_results($q, ARRAY_A);
  if(count($rows) <= 0){
    return false;
  }
  echo json_encode($rows);
  exit();
}

In questo script trovate tutto l’indispensabile per completare la parte lato server. Come si può intuire la query dovrà utilizzare un parametro passato in GET, poi utilizzando la variabile globale wpdb effettueremo la query sul database. La json_encode trasformerà l’array associativo con i record letti tramite la SELECT in una stringa JSON e la stamperemo a video tramite l’echo. Non dimenticate la exit() finale perchè altrimenti verrà stampato uno “0” che vi metterà in difficoltà nel parsificare il JSON.

Un ultimo particolare di cui tenere conto è che la add_action crea un’azione per l’admin-ajax.php che è un file accessibile solo da utenti loggati, quindi per consentire l’esecuzione dell’azione sia da utenti registrati sia da ospiti sarà necessario aggiungere un’ulteriore linea di codice come questa:

add_action('wp_ajax_nopriv_myaction', 'my_function');

Dopo aver completato lo script PHP possiamo passare al lato client, con il codice javascript per la chiamata della funzione:

$jQ.getJSON('<?php echo get_bloginfo('url'); ?>/wp-admin/admin-ajax.php',{action: 'myaction',id: 'tuo_id'}, function(json){...Codice javascript per parsificare il json...}

Ho omesso l’inclusione di jquery in WordPress, ma potete trovare come fare in un mio precedente articolo che trattava l’argomento nello specifico.

A questo punto non vi resta che sbizzarrirvi con le chiamate ajax nel vostro template oppure dai vostri plugin (in quest’ultimo caso basta spostare il codice PHP in un file del vostro plugin).

The post Eseguire chiamate AJAX con jQuery e JSON in WordPress first appeared on Davide Ferrero.

Cari lettori del blog, oggi ho raggiunto un piccolo ma importante traguardo… I dati di google analytics parlano chiaro, sono state sorpassate le 2000 visite mensili e per questo voglio condividere con voi alcune statistiche di cui vado fiero.

Dal 27 agosto al 26 settembre questo blog ha ricevuto 2004 visite, con 1672 visitatori unici e 2369 visualizzazioni di pagina di cui 2175 uniche. L’80,84% delle visite sono nuove e ovviamente il paese predominante è l’italia con 1910 visite  delle quali 1853 in lingua italiana.

I tre articoli più popolari per il momento sono nell’ordine “Creare un web service con soap e php” con 401 visualizzazioni, “Sincronizzare Google Calendar con iCal su Mac e iPhone” con 395 visualizzazioni e “Calibrare la batteria di un Macbook Pro e non solo…” con 323 visualizzazioni.

Grazie a tutti voi che mi leggete, continuate a farlo! Mi auguro di poter continuare a scrivere articoli (spero) interessanti per accrescere questi numeri!

A presto, Davide.

The post Piccoli traguardi… piccole soddisfazioni, 2000 visite mensili! first appeared on Davide Ferrero.

Oggi torno a scrivere sul blog per raccontare come eseguire il deploy di un’applicazione Django su ubuntu server con Nginx come web server, Gunicorn come application server WSGI e MySQL come DBMS.

Inizialmente per ospitare un’applicazione scritta con il framework Django utilizzavo un classico stack in stile LAMPP (Linux + Apache + mod_wsgi). Successivamente per cercare di limitare l’utilizzo di ram ho scoperto (grazie al blog degli ingegneri di instagram) lo stack DUNG che rappresenta la configurazione con nginx + gunicorn + ubuntu.

Non appena si iniziano le configurazioni si comprendono la semplicità e la velocità di messa a punto del nuovo stack. Nginx usa file di configurazione scritti con una sintassi simile ad un linguaggio di programmazione, molto più semplici da comprendere e da scrivere per chi ha poca dimestichezza con queste cose.

Per prima cosa installiamo nell’ordine mysql e nginx, successivamente installiamo django.

Fatto ciò, tramite easy_install possiamo installare Gunicorn:

sudo easy_install gunicorn

A questo punto dobbiamo configurare nginx come proxy server per le richieste: tutto ciò che riguarda i file statici (immagini, css, js, ecc…) verrà servito direttamente da nginx mentre le richieste inerenti il codice python dovranno essere girate al server WSGI (gunicorn nel nostro caso) che le eseguirà e restituirà la pagina risultante.

Come per apache i file di configurazione dei vari siti sono in /etc/nginx/sites-available (invece di /etc/apache/sites-available), per cui creiamo il file di configurazione per la nostra applicazione django in questo modo:

upstream project {
        server 127.0.0.1:8200 fail_timeout=0;
        server 127.0.0.1:8201 fail_timeout=0;
}

server {
        listen 80;
        server_name mydomain.com www.mydomain.com;
        access_log /var/log/nginx/mydomain_access.log;
        error_log /var/log/nginx/mydomain_error.log;

        root /srv/django_srv/mydomain/app;

        location / {
                proxy_set_header Host $host;
                if (!-f $request_filename){
                        proxy_pass http://project;
                        break;
                }

        }
        location /upload  {
                alias /srv/django_srv/mydomain/uploads;
                }
        location /static  {
                alias /srv/django_srv/mydomain/app/_statics;
        }
        location /admin/media {
                alias /opt/Django-1.3.1/django/contrib/admin/media;
        }
}

Come potete vedere nel blocco di configurazione upstream project a questo punto dobbiamo configurare gunicorn in modo da farlo rispondere sulla porta 8200 e 8201. In questo modo quando caricheremo aggiornamenti del nostro progetto e dovremmo riavviare gunicorn, il sito non sarà mai irraggiungibile, inoltre se il processo gunicorn dovesse crollare per qualche motivo ce ne sarà sempre un altro disponibile. Gli alias che vedete sono per i file uploadati dagli utenti tramite l’applicazione, i file statici del sito e i file statici per il backend amministrativo (per questi ultimi dovete dare il path alla cartella di installazione di Django). Dopo aver salvato questo file create un link simbolico nella cartella effettiva dei siti di nginx:

ln -s /etc/nginx/sites-available/mydomain.com /etc/nginx/sites-enabled/mydomain.com

Per avviare gunicorn, essendo su ubuntu, utilizziamo upstart il nuovo sistema per avviare tasks e servizi all’avvio del sistema. Creiamo il file /etc/init/gunicorn_8200.conf e copiamo le seguenti istruzioni:

description "Gunicorn Django on 127.0.0.1:8200"
start on runlevel [2345]
stop on runlevel [06]
respawn
respawn limit 10 5
exec /usr/local/bin/gunicorn_django --bind=127.0.0.1:8200 --workers=2 --access-logfile=/var/log/gunicorn/8200_access.log --error-logfile=/var/log/gunicorn/8200_error.log --daemon /srv/django_srv/mydomain/app/settings.py

Con queste istruzioni diciamo al processo gunicorn di ripartire in caso di crash (respawn) di rispondere all’indirizzo 127.0.0.1 sulla porta 8200 (–bind) di partire come demone (–daemon) e gli diamo i percorsi dei file di log e del file di settings della nostra applicazione.

A questo punto riavviamo il server per verificare che anche upstart funzioni:

shutdown -r now

Il gioco è fatto e la nostra applicazione è pronta per essere utilizzata. I file del progetto django (in base a questa configurazione) devono risiedere in /srv/django_srv/mydomain/app, mentre i file di upload sono in /srv/django_srv/mydomain/uploads per fare in modo che non siano all’interno dell’applicazione e che siano facilmente backuppabili ;)

Spero di essere stato esaustivo, di sicuro con questa configurazione vi potrete accorgere del notevole risparmio di ram rispetto ad un classico stack che utilizza apache come webserver.

The post Eseguire un’applicazione Django su ubuntu server con nginx, gunicorn, upstart e mysql (DUNG stack) first appeared on Davide Ferrero.

Oggi inauguro la nuova grafica del blog con un articolo molto interessante. Questo tutorial vi aiuterà a virtualizzare dei server con VirtualBox da linea di comando.
Ho installato virtualbox 4.0 su una macchina ubuntu server 10.04, ma repository a parte penso che vada bene su qualsiasi versione di ubuntu e più in generale su qualsiasi debian.

Per chi lavora come me su ubuntu server 10.04 per prima cosa bisogna aggiungere il repository di virtualbox nei sorgenti apt. Aprite il file source.list:

sudo vim /etc/apt/sources.list

E aggiungete in fondo la linea:

deb http://download.virtualbox.org/virtualbox/debian lucid contrib

Salvate e chiudete e scaricate la chiave pubblica:

wget -q http://download.virtualbox.org/virtualbox/debian/oracle_vbox.asc -O- | sudo apt-key add -

A questo punto aggiornate:

sudo apt-get update

..e installate il software necessario:

sudo apt-get install linux-headers-$(uname -r) build-essential virtualbox-4.0 dkms

Il pacchetto dkms serve per far sì che ogni volta che il kernel verrà aggiornato verrà aggiornato automaticamente anche virtualbox.

A questo punto scaricate l’extension pack di virtualbox

cd /tmp
wget http://download.virtualbox.org/virtualbox/4.0.16/Oracle_VM_VirtualBox_Extension_Pack-4.0.16-75491.vbox-extpack
sudo VBoxManage extpack install Oracle_VM_VirtualBox_Extension_Pack-4.0.16-75491.vbox-extpack

Ora dovrete aggiungere il vostro utente al gruppo utenti di virtualbox:

sudo adduser your_user vboxusers

Ora la configurazione di virtualbox è terminata, possiamo procedere con la creazione di una nuova virtual machine.

VBoxManage createvm --name "ubu_srv_1" --register
VBoxManage modifyvm "ubu_srv_1" --memory 512 --acpi on --boot1 dvd --nic1 bridged --bridgeadapter1 eth0
VBoxManage createhd --filename /home/your_user/vbox/ubu_srv_1/ubu_srv_1.vdi --size 10000
VBoxManage storagectl "ubu_srv_1" --name "IDE Controller" --add ide
VBoxManage storageattach "ubu_srv_1" --storagectl "IDE Controller" --port 0 --device 0 --type hdd --medium /home/your_user/vbox/ubu_srv_1/ubu_srv_1.vdi
VBoxManage storageattach "ubu_srv_1" --storagectl "IDE Controller" --port 1 --device 0 --type dvddrive --medium /home/your_user/downloads/ubuntu-10.04.4-server-amd64.iso

Con queste istruzioni la nuova macchina virtuale è pronta.

Ora per il primo lancio vi consiglio di usare VBoxHeadless che oltre a lanciare la vm appena creata metterà in piedi un server VRDP, in modo che possiate accedere alla macchina con un client di desktop remoto. Per cui, settiamo la porta del vrdp:

VBoxManage modifyvm "ubu_srv_1" --vrde-port 9800

..e lanciamo la macchina virtuale (abbiate cura di mettere la “&” al fondo del comando in modo da poter continuare sulla stessa shell senza chiudere bruscamente il processo della virtual machine):

VBoxHeadless --startvm "ubu_srv_1" &

Quindi aprite il vostro client di desktop remoto preferito e collegatevi all’ip della vostra macchina su cui avete installato virtualbox aggiungendo “:9800”. Il mio indirizzo a cui rispondeva il server rdp era ad esempio 192.168.0.200:9800.
Potete quindi installare normalmente ubuntu server come se foste su una macchina fisica. Finita l’installazione riavviando la macchina partirà il sistema in automatico. Collegatevi e come prima cosa controllate l’ip (meglio assegnarne uno fisso). Prima di poter dire di avere la vm pronta dobbiamo fare in modo che al prossimo lancio non parta più l’immagine di installazione, per cui spegnete la macchina e ritornate sulla shell del server virtualbox:

VBoxManage modifyvm "ubu_srv_1" --boot1 disk

Adesso siete davvero pronti per lanciare la vostra nuova virtual machine. I passi successivi servono per ottimizzare l’utilizzo di ram del vostro server.

Riavviate la macchina fisica che ospita la/le macchina/e virtuale/i e ricollegatevi. Da shell modificate ancora la vm con il seguente comando per non lanciare il server vrdp quando avviate la vm, così da occupare la sola ram indicata per la vostra vm:

VBoxManage modifyvm "ubu_srv_1" --vrde off

Ora potete nuovamente lanciare la vostra macchina virtuale con il comando:

VBoxManage startvm "ubu_srv_1" --type headless &

Per tutti i comandi di VBoxManage fate riferimento all’help:

VBoxManage --help

Per spegnere o mettere in pausa la macchina i comandi sono:

VBoxManage controlvm "ubu_srv_1" poweroff
VBoxManage controlvm "ubu_srv_1" pause

Buon divertimento!

The post Server virtualizzato con VirtualBox 4.0 su Ubuntu Server 10.04 LTS first appeared on Davide Ferrero.

Le indiscrezioni riguardano:

• Retina display: stessa dimensione dello schermo ma doppia densità di pixel così da permettere una risoluzione dello schermo raddoppiata rispetto alle vecchie versioni.
• Batteria con autonomia maggiore: probabilmente questo porterà un leggero incremento di spessore
• Processore quad core: anche per questo serve una batteria più performante, ma sicuramente incrementerà le prestazioni
• Assenza del pulsante home: un recente brevetto Apple parla di una nuova tecnologia per utilizzare nuove gestures che sarebbero in grado di sostituire le funzioni dell’ormai immancabile pulsante rotondo presente su tutti i device mobili di Apple
• Fotocamera migliorata: l’attuale fotocamera non consente di scattare foto di buona qualità, probabilmente verrà inserita una fotocamera molto simile a quella di iPhone 4S

Per sapere quali di questi punti sono azzeccati, bisognerà aspettare le 19 di domani, quando Tim Cook salirà sul palco dello Yerba Buena Center di San Francisco.

Ci sarà anche il One More Thing?

Voi cosa ne pensate?

Se domani sera volete seguire tutte le novità in diretta, potrete farlo a questo indirizzo sul blog del mio amico Matteo Bovetti!

The post iPad 3 o iPad HD ? first appeared on Davide Ferrero.

The post Siri incontra Siri first appeared on Davide Ferrero.

Oltre a segnalarvi un fantastico restyle grafico del tema di backend per l’amministrazione del blog che potete trovare aggiornando wordpress alla versione 3 oggi voglio parlarvi di come modificare il tema dei commenti.

Questa piccola modifica servirà per visualizzare i commenti annidati, ossia far comparire le risposte ad un commento all’interno del commento stesso, per migliorare la discussione e permettere a chi legge per la prima volta tutti i commenti, chi ha risposto a chi e così via.

WordPress ammette di default una profondità di 5 commenti annidati, ma potete impostarla a piacere tramite il menu “Impostazioni”->”Discussione”.

Se utilizzate uno dei tanti temi scaricati dall’archivio di wordpress verificate solamente che il tema sia aggiornato e di norma dovrebbe già includere questa funzione.

Se invece come me sviluppate spesso temi partendo da zero e partite da un tema semplice e magari non aggiornato alle ultime versioni, dovrete compiere alcuni semplici passi:

1. Nell’header.php (il file della testata), aggiungete una riga sopra al “wp_head()” con questo codice:

   <?php if( is_singular() ) wp_enqueue_script( ‘comment-reply’ ); ?>

2. Nel file comments.php dove troverete il tag “ol” con all’interno il tag “li” che ha come classe css “comment” sostituite tutto il blocco con la semplice riga

   <ol class="commentlist">
   <?php wp_list_comments(); ?>
   </ol>

3. A questo punto non vi resta che editare il vostro css e inserire uno stile personalizzato per i vari livelli di profondità dei commenti, per selezionare il tag “li” relativo al tag “ul” dei commenti inserite in testa al selettore css la classe “.commentlist” e il gioco è fatto!

In pochi e semplici passi avrete così una più chiara visione dei commenti e soprattutto della discussione.

Da notare è che il requisito minimo per poter sfruttare questa funzionalità è quello di avere wordpress 2.7 o versione superiore.

The post Commenti annidati in wordpress first appeared on Davide Ferrero.

Se non avete ancora provveduto all’aggiornamento, ma siete in procinto di farlo, vi consiglio quest’ottima guida di macitynet (onde evitare problemi al primo avvio di Lion).

Terminato l’aggiornamento sembrava tutto apparentemente funzionante, fino a quando non ho tentato di avviare il server di sviluppo di django. Non ricordo con precisione l’errore ma il succo era che il driver per la connessione al db non era più funzionante. Ingenuamente ho disinstallato mysql-python(conosciuto anche come mysqldb) credendo fosse sufficiente una reinstallazione…. ripeto: ingenuo. ;-)

Lanciando il comando:

sudo python setup.py build

ottenevo una sbrodolata di errori relativi a librerie gcc. A fiuto ho quindi reinstallato xcode (scaricabile gratuitamente dall’app store) e rilanciato la build di mysql-python… ancora errori, ma quelli precedenti sembravano risolti. Ora le rogne venivano dal mysql_config mancante… Ho scoperto che nella cartella di installazione di mysql-python c’è un file site.cfg che contiene questa famosa variabile mysql_config, la quale deve contenere il path al file mysql_config (file di configurazione di mysql). Per me che uso XAMPP 1.7.3 su mac questo file si trova in “/Applications/XAMPP/xamppfiles/bin”.

Lanciando la build del driver ottengo errori dovuti alla mancanza degli headers di mysql, errore che avevo già riscontrato nell’installazione di Imagick su XAMPP per Mac, vado per cui diretto sul sito di XAMPP 1.7.3, scarico il development package e lo installo.

Sperando nella buona sorte rilancio per l’ennesima volta la build di mysql-python e incappo nell’ennesimo errore. Questa volta sembra che sia dovuto ad una errata versione di XCode, ma leggendo più approfonditamente noto che il problema è dovuto al mancato supporto power-pc (ppc) a partire da XCode 4. Per risolvere questo ennesimo problema si deve editare il famoso mysql_config (in “/Applications/XAMPP/xamppfiles/bin” per chi usa XAMPP) nel seguente modo.

Alla riga 97 sostituite la versione minima di mac osx, io ho modificato da 10.4 a 10.6 (vedete voi), la mia riga ora è così:

ldflags='-L/Applications/XAMPP/xamppfiles/lib -I/Applications/XAMPP/xamppfiles/include -mmacosx-version-min=10.6 '

Alla riga 122 riportate la versione di mac appena modificata e inoltre eliminate la voce -arch ppc, la mia riga ora si presenta così:

cflags="-I$pkgincludedir  -I/Applications/XAMPP/xamppfiles/include -L/Applications/XAMPP/xamppfiles/lib -mmacosx-version-min=10.6 -arch i386 -D_P1003_1B_VISIBLE -DSIGNAL_WITH_VIO_CLOSE -DSIGNALS_DONT_BREAK_READ -DIGNORE_SIGHUP_SIGQUIT  -DDONT_DECLARE_CXA_PURE_VIRTUAL " #note: end space!

A questo punto lanciate la build e per magia arriverà fino al termine senza più errori. Potete quindi installare il pacchetto lanciando il comando:

sudo python setup.py install

A questo punto django sarà tornato alla normalità (a meno che voi utilizzaste le python image library, PIL, per cui dovrete reinstallare anche quelle, ma io non ho riscontrato problemi nel farlo).

The post Installare Django 1.3 su Mac OS X 10.7 Lion e XAMPP 1.7.3 first appeared on Davide Ferrero.

Ovviamente quando parlo di server, parlo di linux e ancora più nello specifico di Ubuntu.

Ultimamente per andare sul sicuro mi sono abituato ad utilizzare solo più le versioni LTS ossia le Long Term Support, le versioni supportate per 3 anni, decisamente molto più stabili rispetto alle altre.

Quando si installa un server generalmente si ha a che fare con la necessità di mantenere il più possibile al sicuro i dati che vi verranno salvati e per fare ciò è buona norma gestire lo spazio a propria disposizione con il RAID ossiamo un sistema di replica delle informazioni in tempo reale che tenta di ridurre al minimo le possibilità di perdita di dati (ridurre, non eliminare, ne ho le prove ;-) ).

L’installazione di Ubuntu consente di creare un RAID software nel caso in cui il server che stiamo preparando non abbia un sistema di RAID hardware.

Tralasciamo la discussione sulla scelta del RAID, per quello che ho potuto provare sulla mia pelle in genere è sempre meglio un RAID 0 o un RAID 1 o meglio ancora un RAID 1+0 detto anche RAID 10 perchè a differenza dell’alternativo RAID 5 lascia i dati in chiaro e quindi leggibili in qualsiasi momento, anche collegandolo su un’altra macchina (in caso di problemi). Detto ciò, veniamo a come preparare le partizioni per costruire il RAID.

Prendendo l’esempio di 2 dischi da 500 Gb vi conviene creare due partizioni primarie per ciascun disco (scegliete la voce “partizionamento manuale”): una dimensionata il doppio della ram presente sul server, e una con lo spazio rimanente. Ripetete la stessa cosa con le altre due partizioni dell’altro disco. Per ogni partizione alla voce “usare come” dobbiamo ricordarci di impostare “volume per il raid”. Fatto ciò possiamo terminare il partizionamento e configurare gli array raid tramite l’apposito menu, scegliendo il raid desiderato e settando quanti dischi usare per il raid (2) e quanti dischi di spare(0).

Come detto dobbiamo configurare due array, uno per la swap e uno per il sistema vero e proprio. Per il primo array scegliamo i due volumi a cui abbiamo assegnato il doppio della dimensione della ram, confermiamo e passiamo alla configurazione del secondo array con i restanti due volumi.

Finita la configurazione dei due array del raid possiamo terminare l’operazione e scrivere le modifiche.

Quando apparirà nuovamente la schermata con le tabelle delle partizioni potremo notare che sono state aggiunte due voci all’elenco, ossia quelle corrispondenti ai due arrays. A questo punto possiamo creare due partizioni (una per array) e impostare la voce “usare come” su “volume per LVM”.

L’LVM è un gestore dei volumi logici, ossia consente di creare dei volumi “estendibili” in qualsiasi momento. Infatti smontando i volumi si possono aumentare le loro dimensioni senza dover formattare e senza subire perdite di dati, e addiritture si possono raggruppare in un unico volume più dischi (anche aggiunti in un secondo momento). Un po’ quello che si può fare tramite l’ormai conosciutissimo GParted in Ubuntu desktop.

Tornando all’installazione del nostro ubuntu server, una volta impostate le nostre partizioni come volumi per LVM possiamo procedere alla creazione dei due volumi logici, come già detto uno per lo swap e uno per il sistema. Una volta confermata la creazione dei due volumi logici (dovrete assegnare un nome ai volumi da creare, ad esempio “swap” e “srv”) nella tabelle delle partizioni troveremo altre due voci, rappresentati i due nuovi volumi appena creati.

A questo punto possiamo procedere alla creazione delle partizioni da far usare all’installazione di Ubuntu: una da impostare come “volume swap” e l’altra da impostare con ext4 (o ext3 per i più tradizionalisti :-P ). Ovviamente la partizione formattata con ext4 dovrà avere come punto di mount “/” (root). Confermate queste modifiche l’installazione procederà a gonfie vele, e in pochi minuti il vostro server sarà pronto per l’uso! :-)

The post Installare Ubuntu Server 10.04 LTS con RAID 10 e LVM first appeared on Davide Ferrero.