"Già, dove trovarli? I miei colleghi sono veramente fantastici?

Ma, soprattutto, ho mai parlato con tutti i miei colleghi?"

, forse è già chiaro che la risposta sia no.

Si provi a pensare alla vita d'ufficio classica, a quante volte ci si trova a fare due chiacchiere alla macchinetta del caffè, in pausa pranzo o anche alla scrivania.<br>
In quei momenti 

, facendosi un'idea delle persone che si siedono accanto a noi tutti i giorni e con cui collaboriamo: 

condividiamo gli stessi valori? Abbiamo delle passioni in comune? Abbiamo degli argomenti di cui parlare anche extra lavoro?

Da remoto, tutto questo è molto ovattato.

 con tutti i colleghi sono pochi e soprattutto ben mirati, quindi non c'è tanto spazio per conoscersi.<br>
Se si lavora in 

 si ha l'occasione di conoscere meglio le persone del proprio gruppo, ma spesso le chiacchiere sono relative ad un 

, un'attività, insomma, inerenti al progetto su cui si sta lavorando.

"How to build a great culture in a distributed team"

.<br>
Questo argomento, molto sentito a livello aziendale, è stato poi ampiamente discusso su Basecamp e un punto sul quale eravamo tutti d'accordo era 

l'esigenza di trovare un modo per conoscersi meglio

, per parlare anche con i colleghi con cui non si lavora sullo stesso progetto.<br>
Questo ha fatto sì che nascessero idee e proposte per migliorare proprio l'aspetto delle relazioni interpersonali.<br>
Tra i vari suggerimenti ne sono emersi due particolarmente interessanti e realizzabili nel breve periodo: creare un 

, per facilitare e accompagnare l'ingresso dei nuovi colleghi, e organizzare delle 

pause caffè con un numero di persone ridotto

 per cercare di conoscersi.<br>
Del primo punto ve ne parleremo più avanti - 

 -, mentre delle pause caffè ne parliamo proprio ora!

Dopo aver deciso che prendere un caffè in compagnia è meglio che prenderlo da soli, il conseguente interrogativo è stato: 

 dell'azienda e avvisarle che per quella settimana avrebbero potuto organizzare una pausa caffè e fare quattro chiacchiere, ancora meglio se non lavorative.<br>
E, ovviamente, questo sistema doveva essere 

Ci sono sul mercato strumenti che già fanno la selezione casuale tra gli elementi di un elenco, ma noi avevamo bisogno di qualcosa di nostro, da gestire e personalizzare completamente. Anche perché, diciamocelo, a noi sviluppatori stimola fare un po' di ricerca e sviluppo e lavorare su qualcosa di diverso da quello che facciamo tutti i giorni!

Abbiamo lavorato in due sul progetto, aiutati dalla 

 e i consigli del nostro COO, e dopo un po' di 

, quindi un linguaggio che conosciamo bene e che sappiamo essere ben adattabile alle varie esigenze.

Siamo partiti dal fare l'elenco dei dati utili al nostro scopo di tutte le persone di Bitbull, quindi nome, email e Slack ID, perché nella nostra idea c'era quella di utilizzare Slack come principale sistema di notifica.<br>
Siccome il sistema è casuale e automatico, c'era bisogno di tenere traccia delle persone già selezionate e quelle ancora da selezionare in modo da cercare di far pescare sempre tutti. Abbiamo aggiunto due 

, uno che viene popolato direttamente dallo 

 di saltare alcune persone, magari assenti temporaneamente, la cui selezione "sprecherebbe" uno 

 per la chat di gruppo di quella settimana.<br>
Inoltre, abbiamo aggiunto un contatore, non solo per avere un dato statistico, ma soprattutto per cercare di livellare quante volte ogni persona fosse stata sorteggiata e dare priorità a quelle selezionate meno volte. In questo modo cerchiamo di garantire che ogni persona venga estratta con cadenza più o meno regolare.<br>
Questo è tutto ciò che serviva lato Spreadsheet per partire!

Lato codice, invece, la prima cosa da fare era prendere delle decisioni, quali:<br>

In realtà le domande erano molte di più, ma queste sono quelle a cui abbiamo dato una facile risposta.<br>
Si è deciso di far partecipare ad ogni Chatbull 

Quindi, dopo questa prime righe di configurazioni, entriamo nel vivo della faccenda.

, i contatti realmente disponibili, controllando i 

, che ne mescola gli elementi, da cui vengono poi estratti i sei partecipanti della settimana.<br>
Le persone selezionate vengono, quindi, divise in due gruppi da tre.<br>
Questa selezione è tanto banale quanto complessa, perché deve tenere conto delle selezioni del giro di Chatbull precedente e, soprattutto, in azienda, non siamo un numero divisibile per sei, quindi ci rimane sempre il resto.<br>
Questo fa sì che lo 

 debba girare più volte per poter raggiungere il numero desiderato di elementi dell'

 e, nel caso in cui il primo giro ci siano disponibili meno persone di quelle realmente necessarie, prevediamo che il sistema, dopo aver selezionato i partecipanti "obbligatori", svuoti i restanti 

 di disponibilità, cosicché tutte le altre persone possano essere nuovamente selezionate in modo da completare l'

(PS: se vuoi aiutarci a risolvere questo problema e renderci divisibili per sei, puoi 

Come dicevamo precedentemente, il sistema di notifica principale è Slack. Sì è vero, abbiamo settato anche l'invio di un'e-mail tramite il metodo 

 messa a disposizione da App Scripts nella classe 

, ma il vero protagonista delle notifiche rimane Slack, grazie alla sua usabilità e immediatezza nel mettere in contatto le persone tra loro.

 a parte per gestire la comunicazione con il nostro Slack aziendale, al quale ci interfacciamo tramite 

 formate dalle tre persone selezionate per ogni gruppo e il nostro Chatbull Bot, che dà il benvenuto agli invitati e comunica loro che sono stati scelti per farsi una pausa caffè insieme durante la settimana corrente.<br>
Una delle cose belle di App Scripts è proprio il poter 

 che abbiamo inserito nello Spreadsheet, quindi, riusciamo a 

 le persone interessate e a metterle già in comunicazione tra loro così da agevolare il primo contatto, poi da lì ovviamente è tutto in mano alla volontà e disponibilità delle persone per organizzare la pausa caffè, ma noi siamo colleghi fantastici, quindi ci piace prendere i caffè insieme!

Infine, per non farci mancare nulla, abbiamo utilizzato Google Moduli per raccogliere un po' di feedback.

L'obiettivo era soprattutto capire se davvero questo sistema ci stesse aiutando a raggiungere il nostro scopo, ossia far sì che le persone che non lavorano insieme sullo stesso progetto riescano comunque a trovare l'occasione di parlarsi e fare una pausa caffè insieme, e guardando le statistiche sembra proprio che funzioni!

<br>
Concludendo, questa è la versione 1.0 del Chatbull, ma è solo un primissimo passo, perché abbiamo già vari 

 per venire incontro alle nostre esigenze come azienda 

migliorare la comunicazione tra le persone dell'azienda

 non tanto da un punto di vista lavorativo, quanto 

, perché lavorare da remoto ha veramente tantissimi pro, ma ha il contro di non facilitare le relazioni umane, a meno che non lo si voglia e noi, in Bitbull, lo vogliamo eccome.

"Già, dove trovarli? I miei colleghi sono veramente fantastici? Ma, soprattutto, ho mai parlato con tutti i miei colleghi?" Se si lavora in un'azienda full-remote, forse è già chiaro che la risposta sia no.

Chatbull: Colleghi Fantastici e Dove Trovarli

A lot of people are talking about the next big e-commerce thing - PWA. If you are not familiar with that term - check 

It will be a refresh of existing e-commerce storefront. Every part of front-end will be new, because PWA implementation will not rely on existing one.

PWA will be implemented like a new application and the only way to communicate with e-commerce platform will be using API - make sure your modules expose all the business logic needed by the front end thru the API.

,
but no one knows how they will last and survive updates.

The biggest problem with it is that you can’t just apply it to a specific part of the app - you need to go big or go home.
So for projects that are already in production or under development it might be tricky - nothing is backward compatible because front end will be fully in JavaScript, CSS, and HTML - split into components.

But there is a solution for those of you that like me are a bit scared to accept one solution and want to start in small increments.

So to make migration to PWA incremental and start it today we can bridge both worlds.

 module loader and a lot of other JavaScript goodies - Knockout, Prototype, jQuery that are used to develop cool user interfaces.

If you are following JavaScript world then you might know that those are legacy tools but Magento will keep them in their package with ability to chose for separate PWA application with React and Webpack or default front end with Knockout and RequireJS.

{{< figure src="/blog/prepare-for-magento-future/middleware.png#center"  width="333">}}

Let's do this! You can start to create next code in any front-end library you prefer + do it in ES6.

 because I like its community, good documentation and easy set up. Also, it is easy to plug it into those blocks where you want it without applying it to the whole application.
If you are comfortable with React, Angular or other MVVM framework - just go with it.

    "devDependencies": {
      "@babel/core": "^7.0.0-beta.44",
      "@babel/preset-env": "^7.0.0-beta.44",
      "babel-loader": "^7.1.4",
      "vue-template-compiler": "^2.5.16",
      "webpack": "^3.11.0"
    },
    "dependencies": {
      "babel-core": "^7.0.0-beta.32",
      "babel-register": "^6.26.0",
      "vue": "^2.5.16",
      "vue-loader": "^13.7.1",
      "vue-resource": "^1.5.0"
    }

We need to create a new module. In our example 

Next up is Webpack. Those who don’t know what’s Webpack, just check the 

.
The main thing is to set up libraryTarget to AMD, so our ES6 modules will be exported as AMD and we can use them in RequireJS like every normal JavaScript module. So make sure that on your Webpack configuration 

    output: {
        libraryTarget: 'amd'
    }

Then we need to adapt the template. Here we set the output for Vue.js component and pass needed parameters to make it work.

    <div id="app">
        <newsletter
                ref="newsletter"
                action-url="<?php echo $block->escapeUrl($block->getFormActionUrl()) ?>"
        ></newsletter>
    </div>
    
    <script type="text/x-magento-init">
        {
            "#app": {
                "BitbullNewsletter": {}
            }
        }
    </script>

This will be the main entry point for all ES6 files. As you can see the vue object will be be exported and compiled to AMD thanks to Webpack. So then we can import vue object in our native Magento JavaScript implementation using RequireJS.


import Vue from 'vue';
import Newsletter from './components/Newsletter.vue';
import VueResource from 'vue-resource';
Vue.use(VueResource);

export var vue  = new Vue({
    el: '#app',
    components: {
        'newsletter': Newsletter
    },
    data: {
        translate
    }
});

Now to the Vue.js component side!
The first part that we cover will be the template part.
Pretty much simple newsletter subscribe template prepared for Vue.js
By using translate method the built-in Magento translate AMD module will be used, so no need to do anything additional.

<div class="block newsletter">
    <div class="title"><strong>{{ translate("Newsletter") }}</strong></div>
    <div class="content">
        <div class="form subscribe" id="newsletter-validate-detail">
            <div class="field newsletter">
                <label class="label" for="newsletter"><span>{{ translate("Sign Up for Our Newsletter:") }}</span></label>
                <div class="control">
                    <input v-model="email"
                           name="email" type="email" id="newsletter"
                           v-bind:placeholder="translate('Enter your email address')"
                    />
                </div>
            </div>
            <div class="actions">
                <button v-if="isValidEmail" @click="send" class="action subscribe primary" title="Subscribe"  >
                    <span>{{ translate("Subscribe") }}</span>
                </button>
            </div>
        </div>
    </div>
</div>

This one is ViewModel part that will communicate with the template. Just send, translate method, isValidEmail computed property that shows/hide email field.


export default {
        data: function () {
            return {response: null, email: ''}
        },
        props: ['actionUrl'],
        computed: {
            isValidEmail: function(){..............}
        },
        methods: {
            send: function () {
                if (this.email) {
                    var formData = new FormData();
                    formData.append('email', this.email);
                    this.$http.post(this.actionUrl, formData).then(response => {
                        this.response = response;
                        this.email = '';
                    }, response => {
                        this.response = response;
                    });
                }
            },
            translate: function (value) {
                if (!value) return '';
                return this.$parent.$data.translate(value);
            }
        }
    }

The part that should be familiar for those that already did something with Magento 2 front-end. Here we will connect Webpack exported AMD module in our newsletter AMD module.
Basically, two things are going on here. We pass Magento translate the object to Vue.js component. Then we use Vue.js watch method to check for response data property change. This is for loading customer notification fo customer,because there is a need to show website customer a notification on successful or failed subscription action. For that we will use customer-data model that already has a functionality to deal with it.

define([
    './dist/index',
    'Magento_Customer/js/customer-data',
    'mage/translate'
], function (script, customerData,tr) {
    "use strict";
    return function (config) {
        script.vue.$data.translate = tr;
        script.vue.$refs.newsletter.$watch('response', function (newVal, oldVal) {
            customerData.reload('messages');
        });
    }
});

So after this you created one part that will be easier to migrate once you decide migrate to PWA. In conclusion - nothing is changing in PHP side and everything is achievable in incremental steps

Prepare for Magento Future

Oggi vengo a raccontare la mia esperienza riguardo alla configurazione di una pipeline con Bitbucket per poter compilare asset statici e DI (Dependency injection) per poi eseguire il deploy sui webserver.

Di cosa stiamo parlando? Pipeline, Continuous Integration (CI), Continuous Delivery (CD) sono termini che avrete già sentito nominare nel mondo DevOps, ma anche da sviluppatori prima o poi ne avrete a che fare.

 si intende il sistema dove il codice sorgente di un’applicazione viene scaricato dal repository dove risiede e viene eseguita una serie di step o task. Questo viene fatto in un ambiente isolato (di solito utilizzando un container Docker) il più simile possibile a quello che ospiterà l’applicazione vera e propria.

 è il procedimento automatico che porta le modifiche da un repository (server di controllo versione) verso un ambiente comune, di solito l’ambiente di staging. Questa operazione viene eseguita anche più volte al giorno e spesso vi sono collegati dei test di funzionalità per validare il lavoro. Questo per prevenire un disallineamento e incompatibilità delle versioni su vari rami di sviluppo e delle eventuali librerie esterne.

 invece è un procedura che compila il codice proveniente da un repository e attraverso vari step si occupa di distribuire l’applicazione fino all’utente finale o server web di produzione.

Utilizzando la versione di Magento 1.x sicuramente molti di voi avranno configurato una pipeline, con qualsiasi servizio di CI/CD come Bitbucket, Gitlab, Jenkins, Trevis o qualsiasi altro servizio senza grossi problemi. La parte fondamentale che agevola questo lavoro è l’utilizzo di composer per l’installazione dei moduli utilizzando 

magento-hackathon/magento-composer-installer

Con la versione 2.x di Magento avrete sicuramente avuto a che a fare con il deploy di asset statici, compilazione delle DI e le tante ottimizzazioni che si porta dietro la versione 2.x.

Questo richiede uno step successivo all’installazione dei moduli, ovviamente cerchiamo di eseguire questa procedura nella pipeline per non appesantire il server durante il deploy. Alla versione attuale (2.1.7) per eseguire i comandi necessari alla compilazione è necessaria la connessione al database, questo aggiunge una complicazione: essendo il container della pipeline isolato non è possibile connettersi al database dell’ambiente di destinazione e, anche potendo, non sarebbe una buona pratica.

Il primo requisito necessario è un repository su Bitbucket, nel caso usiate un altro servizio come GitLab potete usare il suo sistema di pipeline, molto ben fatto, oppure con GitHub un servizio esterno.

Aggiungete il file di configurazione della pipeline di Bitbucket, chiamato “bitbucket-pipelines.yml”.

La struttura del file è molto semplice, come prima riga indichiamo quale immagine Docker utilizzare per creare il container della pipeline, nel nostro caso abbiamo cucinato un’immagine molto simile al sistema usato sui server e in locale 

Aggiungiamo ora la dichiarazione della pipeline, qui ci sono due possibilità: usarla in modo automatico, ovvero ad ogni commit viene eseguita (filtrabile in base a tag o branch) oppure lasciare a noi il compito, con un semplice click. Nella maggior parte dei casi si utilizza un solo server di staging e per non sovrascrivere accidentalmente le modifiche di qualcun altro del team, che al momento sta testando una feature, è bene seguire la seconda strada.

Dichiariamo dunque che vogliamo una pipeline eseguita in modo manuale

custom:
    01_staging:

    02_production:

Abbiamo ora dichiarato due pipeline, una per ogni ambiente. Un consiglio utile è quello di anteporre al nome un numero incrementale, questo perchè Bitbucket le mostrerà in ordine alfabetico e non vogliamo che la prima selezionata sia “Production” invece di “Staging”.

Aggiungiamo ora i comandi che devono essere eseguiti, all’interno di “step” (al momento solo uno step per pipeline è supportato in futuro sarà possibile eseguirne più di uno in parallelo) e utilizziamo delle variabili d’ambiente per rendere tutto più configurabile. Un consiglio è quello di utilizzare lo stesso nome all’interno degli script e valorizzarle in base alla pipeline che vogliamo usare.

01_staging:
      - step:
          script:
            - export LOCALES="en_US it_IT"
            - chmod +x deploy-scripts/Build.sh && ./deploy-scripts/Build.sh

Notiamo che tutti i comandi verranno eseguiti da un file contenuto nel repository, questo per rendere tutto più leggibile.

È possibile configurare le variabili d’ambiente dal pannello di impostazioni e offuscare quelle più a rischio come le credenziali dell’utente AWS.

Andiamo ora a scrivere i comandi bash necessari per la compilazione creando il file 

#!/usr/bin/env bash

set -e # interrompe l’esecuzione in caso di errore

TAG=$BITBUCKET_COMMIT

#Configurazione di composer

COMPOSER_AUTH=$(cat &lt;&lt;EOF { "github-oauth": { "github.com": "$COMPOSER_AUTH_GITHUB_TOKEN" }, "http-basic": { "repo.magento.com": { "username": "$COMPOSER_AUTH_MAGENTO_REPO_USERNAME", "password": "$COMPOSER_AUTH_MAGENTO_REPO_PASSWORD" } } } EOF ) mkdir -p /root/.composer && echo "$COMPOSER_AUTH" &gt; /root/.composer/auth.json

composer install --no-dev

Con questi comandi ora verranno installati i moduli di Magento e il suo stesso core, consiglio di tenere sotto controllo versione il file composer.lock per non avere sorprese durante questo step ma sapere in anticipo quali versioni verranno installate.

Ora manca qualcosa, il database a cui collegarsi! Ci viene quindi in aiuto Bitbucket che permette la creazione di un servizio, ovvero un secondo container docker, collegato a quello che esegue i comandi.

Torniamo sul file di configurazione e aggiungiamo al fondo del file bitbucket-pipelines.yml quanto segue

definitions:
  services:
    mysql:
      image: mysql
      environment:
        MYSQL_DATABASE: 'magento'
        MYSQL_ROOT_PASSWORD: 'root'

In questo modo stiamo aggiungendo un container MySQL con un database già creato “magento” e una password per l’utente root.

Aggiungiamo questo servizio alla dichiarazione della pipeline

01_staging:
      - step:
          script:
            ...
          services:
            - mysql

Ora possiamo collegarci al nostro database temporaneo e caricare un dump preso dall’ambiente di staging e alleggerito dalla tabelle di log.

# Connessione al database ed esecuzione del dump

M2_DB_HOSTNAME=127.0.0.1
M2_DB_NAME=magento
M2_DB_USERNAME=root
M2_DB_PASSWORD=root

aws s3 cp s3://$CODEDEPLOY_S3_BUCKET/$CODEDEPLOY_ENVIRONMENT/dump.sql /tmp/dump-$TAG.sql # scarichiamo da un bucket S3 il file di dump
mysql -h $M2_DB_HOSTNAME -u $M2_DB_USERNAME -p"$M2_DB_PASSWORD" $M2_DB_NAME &lt; /tmp/dump-$TAG.sql # applichiamo il dump

ENV_FILE=$(cat &lt;&lt;EOF ADMIN_FRONTNAME="admin" APP_KEY="$APP_KEY" SESSION_SAVE="files" DB_HOSTNAME="$M2_DB_HOSTNAME" DB_NAME="$M2_DB_NAME" DB_USERNAME="$M2_DB_USERNAME" DB_PASSWORD="$M2_DB_PASSWORD" MAGE_MODE="production" CACHE_MODE="disable" WEBSERVER_USER="www-data" EOF ) echo "$ENV_FILE" &gt; .env
composer run-script generate-config # usiamo un modulo sviluppato da noi per creare il file di configurazione env.php 

Ora Magento è collegato al database, non ci resta che eseguire i comandi della CLI per la compilazione vera e propria

# Magento deploy
php bin/magento module:enable --all # abilitiamo tutti i moduli

php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento setup:static-content:deploy $LOCALES

rm app/etc/env.php
rm .env
rm -r var/cache/*
rm -r .git/
rm docker-compose.yml
rm Vagrantfile

Parte fondamentale delle CI/CD è la creazione dell’artefatto, ovvero un archivio contenente la versione dell’applicazione pronta per essere eseguita.

Adesso la nostra versione è pronta per il deploy. Per questo ultimo step in Bitbull utilizziamo un servizio AWS apposito chiamato 

 che con qualche configurazione ci permette di portare la nuova versione all’interno dei nostri server. È possibile con un paio di righe aggiuntive

aws s3 cp /tmp/release-$TAG.zip s3://$CODEDEPLOY_S3_BUCKET/$CODEDEPLOY_ENVIRONMENT/release-$TAG.zip
aws deploy register-application-revision --application-name $CODEDEPLOY_APP_NAME --s3-location bundleType=zip,bucket=$CODEDEPLOY_S3_BUCKET,key=$CODEDEPLOY_ENVIRONMENT/release-$TAG.zip --region $AWS_REGION

aws deploy create-deployment --application-name $CODEDEPLOY_APP_NAME --deployment-group-name $CODEDEPLOY_DEPLOYMENT_GROUP --s3-location bundleType=zip,bucket=$CODEDEPLOY_S3_BUCKET,key=$CODEDEPLOY_ENVIRONMENT/release-$TAG.zip --region $AWS_REGION

Questo comando è asincrono quindi qui la pipeline terminerà senza aspettare CodeDeploy, quindi per monitorare il progresso e controllare eventuali errori è necessario accedere alla console di AWS. Noi abbiamo collegato le notifiche di CodeDeploy al nostro Slack così da essere notificati per eventuali errori.

Salvate il file di script e quello di configurazione delle pipelines e fate una commit.

Ora che la nostra pipeline è pronta non ci rimane che eseguirla.

Andiamo ora su Bitbucket e scegliamo la commit da cui fare partire la pipeline, è possibile anche selezionare un ramo e verrà usata l’ultima commit su di esso. Troverete sulla vostra destra il comando 

, cliccate su di esso e verranno mostrate le pipeline dichiarate nel file di configurazione.

Una volta lanciata si aprirà un pannello di controllo apposito che mostrerà l’output dei comandi, nel caso di errori questo è il posto giusto per controllare qual è il problema.

Durante l’esecuzione apparirà a sinistra un bottone 

 con cui è possibile bloccarne l’esecuzione, in caso sia stata lanciata per errore. Al termine, invece, tramite il pulsante 

 è possibile eseguirla un’altra volta partendo dallo stesso commit.

Per velocizzare lo scaricamento del moduli composer è comodo utilizzare la cache della pipeline. Attenzione ad utilizzare quella di default di Bitbucket, altrimenti verranno messi in cache i moduli sotto /vendor e non verranno creati i symlinks al core di Magento creati durante il composer install. In Bitbull utilizziamo un soluzione che in parte aiuta ma non ancora ottimizzata.

Al fondo del file bitbucket-pipelines.yml aggiungiamo

definitions:
  services:
    ...
  caches:
    composercache: ~/.composer/cache

e poi all’interno della dichiarazione della pipeline

01_staging:
      - step:
          caches:
            - composercache


Nel caso usiate Slack come app di messaggistica troverete sicuro comodo creare un webhook per inviare le notifiche nel canale usato per il progetto.

Pipeline Magento2

Da qualche anno ormai l'acronimo IOT (Internet of things) è sempre più popolare. Per IOT si intende la rete dei dispositivi in grado di accedere ad Internet. Un oggetto connesso ad internet potrebbe essere ad esempio un igrometro, una pompa di calore, ma anche un sistema più complesso come una casa oppure l'insieme dei sensori di un oleodotto.

"L'Internet delle cose è una possibile evoluzione dell'uso della Rete: gli oggetti (le "cose”) si rendono riconoscibili e acquisiscono intelligenza grazie al fatto di poter comunicare dati su se stessi e accedere ad informazioni aggregate da parte di altri. Le sveglie suonano prima in caso di traffico, le scarpe da ginnastica trasmettono tempi, velocità e distanza per gareggiare in tempo reale con persone dall'altra parte del globo, i vasetti delle medicine avvisano i familiari se si dimentica di prendere il farmaco. Tutti gli oggetti possono acquisire un ruolo attivo grazie al collegamento alla Rete.” (Wikipedia)

Ma veniamo a noi, cosa c’entra Magento in questo discorso?

Giorni fa mi sono trovato in un negozio in stazione, ho provato delle scarpe. Avrei voluto comprarle ma poiché non avevo spazio (e volontà) per portarle dietro ho abbandonato l'idea. In questo caso sarebbe stato interessante per me se il canale fisico e quello web del negozio fossero stati integrati. In treno, successivamente, pensavo che un dispositivo fisico che avesse fatto da trigger per l'

 sullo store web avrebbe potuto risolvere il problema. Se avessi potuto trasferire dal canale fisico a quello web il mio interesse, successivamente dal treno o da casa avrei potuto ordinare e pagare l'oggetto e riceverlo in un secondo momento.

L'idea è quella dei single-purpose buttons. In sostanza il button è programmato (eventualmente pre-configurato) per eseguire un'azione predeterminata. L'assunzione è che si riesca ad autenticare il customer per utilizzare il suo carrello.

In questa primo post introdurrò solo la parte strettamente software, ovvero l'interfaccia su protocollo MQTT all'api di Magento. Per connettere il button fisico a Magento ci serviremo degli strumenti di AWS. Come da qualsiasi ricetta partiamo dagli ingredienti:

"AWS IoT è una piattaforma cloud gestita che consente a dispositivi connessi di interagire in modo semplice e sicuro con applicazioni nel cloud e altri dispositivi. AWS IoT è in grado di supportare miliardi di dispositivi e migliaia di miliardi di messaggi, ed è in grado di elaborare e instradare tali messaggi agli endpoint di AWS e ad altri dispositivi in modo sicuro e affidabile. Con AWS IoT, le applicazioni rimangono collegate e comunicano con tutti i dispositivi, in qualsiasi momento, anche quando non sono collegati.” la descrizione da 

AWS IOT è un ecosistema di strumenti che consente a versioni cloud di oggetti di interagire tra di loro e con il mondo esterno (e ovviamente con il resto di AWS), seguendo delle regole (rules).

 che potrebbero essere visti come degli alter ego cloud degli oggetti fisici, ne mantengono lo stato e rispondono agli eventi. Ogni Thing ha un endpoint RESTful su protocollo HTTP e una serie di endpoint per poter soddisfare il protocollo di messaggistica leggero 

. Non approfondisco ma il protocollo MQTT e AWS IOT meritano qualche lettura.

Quello che ci interessa è creare una Thing che rappresenterà il pulsante fisico che andremo a creare. Dalla console di AWS IOT sotto 

 è possibile trovare le Things già create. In alto a destra 

Creiamo la nostra Thing. Per semplicità la chiamerò semplicemente button. Per poter organizzare/categorizzare le Things si possono creare dei tipi 

Quando creata, la Thing sarà accessibile dal registro. Cliccandoci sopra andremo ad una pagina di gestione dell'oggetto. Particolarmente interessanti sono le sezioni Shadow, Interact e Activity. In Shadow si può vedere lo stato attuale dell'oggetto nel cloud. In Interact si sono i diversi EndPoints RESTful e MQTT. In Activity si possono vedere le interazioni con l'oggetto, i messaggi scambiati e le variazioni di stato. In questa fase il log sarà vuoto, in una fase attiva dell'oggetto la pagina Activity si presenterà così:

Nell'esempio dello screenshot si può vedere che è stato richiesto un update dello stato e l'oggetto JSON state rappresenta il nuovo stato. Ad ogni click il button fisico farà un update dello shadow passando i parametri necessari all'Add To Cart (da notare che non ci sono parametri riguardanti il customer che per semplicità dell'esempio è stato cablato nella funziona Lambda). In questo modo la Thing potrebbe rappresentare l'insieme dei button fisici dello store riutilizzando lo state per parametrizzare la richiesta.

I parametri, ovvero il prodotto che rappresenta, saranno pre-programmati nel button fisico, mentre per ora non è stata implementata alcuna logica per l'autenticazione.

La logica di connessione tra l'ecosistema dei buttons e Magento è stata affidata ad una funziona AWS Lambda. Non mi soffermo su Lambda. In seguito il codice per l'add to cart.

La funzione si occupa di fare il login, recuperare il carrello e aggiungere l'item. Per farlo utilizza le API REST di Magento 2. In termini architetturali probabilmente si potrebbe migliorare, magari scomporla, ma per l'esempio è più pratica così.

Poiché la funzione utilizza request, per poterla far girare bisogna scaricarne lo zip dalla console di Lambda e con 

 installare la dipendenza request, zippare di nuovo il tutto compresa la cartella 

(come si vede la logica di autenticazione va completamente sviluppata, per ora la funzione Lambda ha all'interno una cablatura con i dati. Non mi soffermerò in questo post)

Per poter far girare la funzione Lambda ad ogni update dello stato bisogna creare una rule che farà da trigger. La rule va configurata come in basso.

La logica con cui selezionare gli update di stato andati a buon fine è abbastanza semplice. Unico punto a cui fare attenzione è il topic da monitorare, i topic possibili sono quelli visti nella pagina di configurazione della Thing sotto la voce Interact.

A questo punto la controparte cloud del button è completa e testabile indipendentemente dal device fisico.

La funzione Lambda è atomica e può essere testata dalla console di AWS. Nella pagina della funzione, click su 

Se tutto è andato a buon fine nel carrello di Magento ci sarà uno zaino in più.

Se non ha funzionato in Cloud Watch di AWS sotto Logs ci saranno i log della funzione Lambda. Per testare invece la Thing, nella pagina del button scheda _Activity > MQTT Client _possiamo fare 

 sul topic monitorato dalla rule $aws/things/button/shadow/update/accepted. L'input è lo stesso JSON dell'input della funzione Lambda.

: il publish esaudirà la query della Rule che sarà il trigger della funzione Lambda, risultato ci sarà un nuovo zaino nel carrello di Magento dell'utente demo.

 vedremo come realizzare il button fisico con ESP8266 e Arduino IDE.

Game of things: magento button [part 1/2]

“Daje deploya, poi lunedì ce pensamo” è il tormentone di 

, la divertente parodia di uno sviluppatore approssimativo e caciarone su twitter.

In realtà rischiamo un po’ tutti di essere Aggile Giggi quando rilasciamo in produzione se non ci dotiamo di processi e strumenti atti a rendere il deploy quanto più sicuro possibile.

Parliamo di test. Il rischio di errore, quando si rilascia in produzione, non potrà mai essere azzerato ma potrà essere ridotto il più possibile introducendo nel flusso di lavoro dei 

Facile a dirsi, molto meno a farsi. Quello che vogliamo suggerire oggi è un punto di partenza, un tool che permette di avere una buona copertura di test di regressione in tempo zero e senza eccessivo sforzo.

 è una buona soluzione di partenza a un costo contenuto. Già con il piano free si possono far girare un centinaio di test al mese, che naturalmente non bastano se se ne vuole fare un uso regolare.

Per partire, dalla Dashboard, creiamo una nuova Suite. Poi potremo fa girare i vari test singolarmente o uno dopo l’altro.

La creazione degli scenari è molto semplice grazie a una comoda 

Le azioni e le asserzioni registrate ce le ritroviamo all’interno della GUI di Ghost inspector dove potranno essere comodamente editate.

I test possono inoltre essere esportati e importati nel formato di 

Per ciascuna Suite possiamo definire delle variabili da utilizzare all’interno dei test, oppure ricavarle da elementi presenti nel DOM o, ancora, eseguire del Javascript.

Dopo aver eseguito i test, Ghost inspector fornisce il dettaglio degli errori trovati in console, il video del test eseguito, il dettaglio di eventuali test falliti e persino, in caso di regressioni, una comparazione di screenshot.

Tutto questo senza scrivere una riga di codice.

I test possono essere eseguiti via API e integrati con 

 per includere il test all’interno di flussi automatizzati.

La funzionalità di questa piattaforma sono davvero tante, basta dare un’occhiata alla 

 per rendersi subito conto delle potenzialità che ha.

Quello dei test è un tema ampio e complesso che non pretendiamo di esaurire suggerendo un tool, ma sicuramente grazie a Ghost Inspector quando “lunedì ce pensamo” possiamo farci il weekend un po’ più a cuor leggero 🙂

Test automatici in 0 minuti con Ghost Inspector

Ghost Inspector. Automatic test in 0 minutes

Se si deve progettare un nuovo tema utilizzando un task runner, potrebbe risultare molto comodo integrare un sistema di live reloading combinato con il task watch, sopratutto se si utilizzano più schermi.

: è un plugin gulp che fa un update live dei file. Si possono specificare manualmente i file oppure collegarlo al task watch per aggiornare i file modificati. Se i file da aggiornare sono file CSS, verrà fatto un injection dei nuovi file (verranno quindi sostituiti istantaneamente i nuovi file nel codice della pagina senza necessariamente ricaricarla), altrimenti verrà ricaricata la pagina (i javascript richiedono necessariamente un reload della pagina).

Per funzionare però non basta modificare il proprio gulpfile, ma è necessario che sul browser utilizzato per lo sviluppo sia installato un plugin specifico che stia in ascolto sui cambiamenti del livereload server.

Maggiori informazioni potete trovarle sulla pagina del pacchetto NPM 

https://www.npmjs.com/package/gulp-livereload

: al contrario di Livereload, BrowserSync utilizza un javascript all’interno della pagina che permette di aggiornare i file css e js senza necessariamente installare un plugin sul browser. Il tool però non si limita a questo: essendo la sua funzione primaria quella di “sincronizzare” i browser, l’aggiornamento dei file viene propagata a ogni browser che ha aperta la medesima pagina. Inoltre, sempre avendo aperta la stessa pagina su diversi browser, il tool si occuperà di sincronizzare tutte le azioni fatte: dal semplice scroll a un click specifico o alla compilazione di un form, viene tutto replicato istantaneamente su tutti i device.

A questo link potete trovare un confronto fra i due metodi:

https://www.slant.co/versus/5065/5066/~livereload_vs_browsersync

Stando a queste premesse e questo confronto, BrowserSync sembra vincere a mani basse. In realtà vi sono alcune problematiche:

Per ovviare a questi problemi, sui nostri ultimi progetti sono stati integrati entrambi, sfruttando i punti di forza di entrambi e bypassando le problematiche presentate per il live reloading:

Ecco un esempio del risultato ottenibile, usando anche delle config per attivare e disattivare i due plugin:

// Active Live reloading

var browserSync  = require('browser-sync').create();
var livereload   = require('gulp-livereload');
var config = {
appendLiveReload: false,  // Enable Live Reload
browserSyncOn: false      // Enable BrowserSync
};
var BrowserSyncConfig = {
    //host: "thedoublef.local/", // Override host detection if you know the correct IP to use
    // proxy: "http://yourproject.local",
    //port: 8080
    ghostmode: { clicks: true, forms: true, scroll: true },
    logPrefix: "Bitbull_Gulp",
    open: false, // Decide which URL to open automatically
    reloadOnRestart: false,
};
gulp.task('browser-sync', function () {
    // Docc generated files will be saved in the `docs` directory
    if(config.browserSyncOn == true) {
        browserSync(BrowserSyncConfig);
    }
});

gulp.task('watch', function() {
browserSync.init(BrowserSyncConfig);
var server = livereload();
gulp.watch(['css/style-dev.css', 'images/**/*']).on('change', function(file) {
    if (config.appendLiveReload) { server.changed(file.path); }  // Use LiveReload
    else { browserSync.reload(); }                               // Use BrowserSync

});
gulp.watch(['js/dev-script.js','fonts/**/*']).on('change', function(file) {
    if (config.browserSyncOn) { browserSync.reload(); }          // Use BrowserSync
    else { server.changed(file.path);}                           // Use LiveReload
});
});


Bitbull

Tools

Chatbull: Colleghi Fantastici e Dove Trovarli

Prepare for Magento Future

Pipeline Magento2

Game of things: magento button [part 1/2]

Test automatici in 0 minuti con Ghost Inspector

Live reloading con Gulp e Magento

Stop wasting time with the stupid google page speed (╯°□°）╯︵ ┻━┻

L’inverno sta arrivando, Laravel 5.4 invece è giunto!

API REST per TEST