Il frontend di Magento2 ha una griglia? No. O meglio, non per il frontend, l’unica cosa che ha è un mixin per “facilitare” la struttura di layout classici a 1, 2 o 3 colonne. Ecco perché nella documentazione non c’è nulla a riguardo.

Posto che saranno molto rari i casi i cui sarà necessario usarlo, il mixin che fa la magia si trova alla riga 107 di 

.lib-layout-column(@_total-columns, @_order, @_width)

Al mixin passiamo il numero totale delle colonne che compongono il layout (da 1 a max 3 colonne), l’ordine che la singola colonna occupa all’interno della griglia e la larghezza della stessa (in pixel, rem, pt o percentuale).

Magento2 applica una soluzione ibrida, utilizzando il buon vecchio floating per strutturare il layout e flexbox per definire l’ordine.

Ma cerchiamo di capire come funziona e come farlo funzionare.

Intanto, ciò che determina l’utilizzo di flex oppure no è la variabile 

 settata a true (o false) alla riga 10 del file 

_lib/web/css/source/lib/variables/_responsive.less

Questo mixin va utilizzato per ogni colonna all’interno del div che comprende la griglia:

.div1 {
  .lib-layout-column(3, 2, 33.333%);
}
.div2 {
  .lib-layout-column(3, 3, 33.333%);
}
.div3 {
  .lib-layout-column(3, 1, 33.333%);
}

la quale regola per singola colonna viene compilata all’incirca così:

.div1 {
  width: 33.333%;
  display: inline-block;
  -ms-flex-order: 2;
  -webkit-order: 2;
  order: 2;
}
.div2 {
  width: 33.333%;
  float: right;
  -ms-flex-order: 3;
  -webkit-order: 3;
  order: 3;
}
.div3 {
  width: 33.333%;
  float: left;
  -ms-flex-order: 1;
  -webkit-order: 1;
  order: 1;
}

che distribuirà i div in questo modo e in questo ordine

Ma se non si dichiara nel div contenitore che si tratta di una griglia flex tramite il mixin 

 questi div vengono allineati tramite float e non flex (lasciando per altro il contenitore ad altezza zero perchè non c’è un clearfix applicato) simulando l’ordine flex, motivo per il quale funziona solo con un max di tre colonne. Se invece lo si dichiara, l’ordine usato per distribuirli utilizza flex.

.lib-layout-column(@_total-columns, @_order, @_width) {
   @_units: "px","%","em","rem","pt";
   ._lib-set-column-width(length(@_units), @_width);
   .lib-flex-degradation(@_total-columns, @_order);
   & when (@use-flex = true) {
       .lib-vendor-prefix-order(@_order);
   }
}

questo è il mixin usato sopra per generare le colonne. Usa il flex-degradation 

 mentre applica l’ordine di flexbox solo nella condizione in cui sia abilitato.

.lib-flex-degradation(@_total-columns, @_order) when (@_order = 1) {
   float: left;
}

nel caso l’ordine del div sia 1 a prescindere dal totale delle colonne dichiarate lo flotta a sinistra.

.lib-flex-degradation(@_total-columns, @_order) when (@_order = @_total-columns) {
   float: right;
}

se l’ordine invece corrisponde al totale colonne lo flotta a sinistra. Questo fa sì che, sia che ci siano 2 sia che ci siano 3 colonne, sarà flottato a sinistra.

Ma lo sarà anche con una colonna sola :/

E con quattro? Con quattro anche lo flotta a sinistra a ma cosa succede alle colonne centrali?

.lib-flex-degradation(@_total-columns, @_order) when (@_total-columns = 3) and (@_order = 2) {
   display: inline-block;
}

l’ultimo è lui, che appunto verifica che se il totale è 3 (non 4 e non più di 4) e l’ordine è 2 lo mette in display:inline simulando così gli eventuali ordini invertiti (sempre nel caso in cui flexbox non sia supportato). Ma questo funziona appunto soltanto sul secondo elemento di 3 motivo per cui per una griglia da 4 colonne o più (quella che si vorrebbe poter usare nel listing dei prodotti per esempio) non funziona perché questa condizione non verrebbe mai eseguita.

Per cui il tentativo di fallback sui float in assenza di flex è marginalmente coperto soltanto per la costruzione di un layout di max 3 colonne, motivo per cui si chiama lib-layout-column e non .lib-grid-column.

Con flex è chiaro che funziona, ma tu te la senti di usare solo flex?

Ma quindi, che griglia usa magento sul frontend?

.page-products {
   .products-grid {
       .product-item {
           width: 100%/3;
       }
   }
}

Magento_Catalog/web/css/source/module/_listings.less

Pare che invece ci sia una griglia nell’admin che qualcuno ha suggerito di portarsi a frontend: 

https://magento.stackexchange.com/questions/134723/how-to-use-magento-2s-less-grid-system

Ma a questo punto, per copiarmi tutta quella roba, sarei più propensa a crearne una piccolina ad hoc.
<hr/>

Griglia Less in Magento2

 Multi-Source Inventory module will extend Magento 2 adding, among other things, drop shipping functionality and opening new possibilities to merchants.

The purpose of the Multi-Source Inventory (MSI) module is that of allowing Magento merchants to define 

 of Magento Open Source (formerly known as Magento CE).

 to stay in the loop of its development progress.

 is a retail method in which merchants don't keep a supply of the items they sell but delegate this activity to 

, namely third-party companies like manufacturers, wholesalers or even other retailers.

Two scenarios are possible when a merchant delegates the supply chain management to drop shippers:

To let a merchant work with drop shippers, an e-commerce platform needs to provide him or her the ability to 

 which the items come from; furthermore, the platform has to provide applicability of both the scenarios described above.

Consider the case of a Magento merchant that sells a part of his items through drop shippers.

 and eventually one or more sources for goods handled in his or her own stocks.

For sources that don't have item quantity limitations, the merchant will allow 

 meaning that customers will be able to purchase products supplied from that source regardless of their stock availability.

Magento 2.2 already comes with backorders functionality both at global and at product level; MSI will extend this possibility at the source level, to map the infinite drop shipper's stock.

, the merchant will be able to specify the quantity of each item for each source, as shown below.

To keep the quantity of items synchronized with drop shippers, MSI comes with an 

, approximately from minute 14.10 to minute 16.35.

, involving a source that offers a limited quantity of items, a stock quantity 

 mechanism guarantees to the merchant that those quantities are deducted from the remaining saleable quantity.

Applying stock reservations at the order placement allows 

 and eliminates most of the locks necessary to avoid significant breaks in stocks, keeping inventory up to date. Reservations, indeed, are 

 entities that keep track of quantities booked, deferring the complicated process of establishing from which sources products have to be picked up.

MSI's first release will likely come with a 

 but more sophisticated ones are already under analysis, not mentioning the fact that, thanks to architecture's flexibility, third-party vendors will be able to add their 

 around the development of the MSI module and the reason is simple: it's the 

 Magento core module that is developed with the 

 and, all modesty aside, it's a very cool feature that will be surely 

 your Magento 2 skills, giving your contribution to an 

Msi Module Enables Drop Shipping Magento 2

è stata introdotta tutta la parte backend del button che non è altro che un'interfaccia per le API di Magento 2. Il front: l'UI della funzionalità di aggiunta al carrello non sarà fatta, come di consueto, di HTML, CSS e JS ma di un device fisico. Il device sarà solo di esempio, l'idea di base è quella del single purpose button, il contesto non è la casa, ma il negozio.

A questo punto posso definire il mio goal: ho bisogno di un device in grado di dialogare con AWS per poter segnalare pressioni del button (che lato Amazon si traduce in uno state update).

Si potrebbero seguire diverse strade, utilizzando microcontrollori differenti e board differenti. Ad esempio potremmo utilizzare il più celebre Arduino, oppure utilizzare il GPIO del raspberry. Per il prototipo è stata scelta una board con l’ESP8266: NodeMCU. Quasi equivalente ad Arduino, ma con ESP8266 per la connessione wi-fi built-in. Per chi avesse avuto esperienze precedenti la board è programmabile con Arduino IDE.

Procediamo per gradi. Quello che andremo a costruire sono 2 moduli semplicissimi:

Il modo più semplice per seguire da questo punto per chi non abbia mai sentito parlare di breadboard, resistenze e led, sarebbe acquistare i componenti. La spesa è veramente per tutte le tasche, vi passo i link:

In alternativa si può simulare la componente elettronica utilizzando servizi come 

 (ex circuits.io). Su TinkerCAD non esistono board con ESP8266 integrato che va sostituito con Arduino + ESP8266.

Come per altre board, sul NodeMCU saranno presenti dei PIN a cui collegare i componenti esterni all'MCU. Questi PIN saranno controllabili via software in scrittura o lettura (digitale o analogico).

Questo primo modulo molto elementare serve solo a indicare lo stato dell'oggetto. E' poco più di un 

 su bread board. Ai PIN D5 e D7 del NodeMCU, collegheremo due LED. Il led rosso servirà per indicare lo stato di richiesta di aggiunta al carrello, mentre il led verde lampeggia fino al completamento della connessione Wi-Fi, dopo di che sarà fisso.

I LED hanno una polarità, il terminale più lungo è il polo positivo (anodo) mentre quello più corto è il polo negativo (catodo). Davanti ai LED va anteposto un resistore di 220 Ohm per evitare che bruci.

Sopra il modulo completo su una piccola breadboard . I 2 resistori partiranno dagli anodi dei LED e finiranno laddove posizioneremo il NodeMCU (esattamente nei PIN D5 e D7). Il jumper nero che parte dalla breadboard è sulla stessa riga dei due catodi dei LED, andrà collegato sul pin G (ground) del NodeMCU.

(Per chi non ha mai utilizzato una breadboard: le linee orizzontali rispetto alla foto delle 2 metà della breadboard sono un circuito, nel senso che ogni foro è connesso con gli altri sulla stessa riga)

Il button sarà collegato al pin D2 del NodeMCU. Il PIN sarà configurato per ricevere input, diversamente dai PIN collegati ai LED che saranno di output. Un 

 è un pulsante che se premuto mette in collegamento 2 parti di un circuito. Non mantiene uno stato.

Ha quattro piedini. Su 2 dei piedini ci andrà l’alimentazione a 3v e la messa a terra (con resistore 10 Kohm). Mentre un altro dei piedini sarà collegato al PIN D2 del NodeMCU per leggerne lo stato. Anche questo modulo sarà molto elementare:

Prima di di collegarlo sulla messa a terra del NodeMCU, va anteposto un resistore di 10 kOhm. Il jumper in rosso sarà per l’alimentazione di 3v, il nero al PIN G come di consueto mentre il jumper blu sarà collegato al PIN D2 del NodeMCU.

Anche se molto elementare, il device è stato pensato modulare. A questo punto, I 2 moduli sopra, isolati su 2 mini breadoard vanno uniti. In basso il risultato finale.

Per poter programmare il device con l'IDE di Arduino ci sono alcune operazioni da fare preliminari. Nel video che segue viene spiegato come poter programmare NodeMCU con Arduino IDE.

Per quanto riguarda la parte software del button, è sufficiente trovare un po' di letteratura su Arduino e ESP8266 e qualche esercizio su TinkerCAD. Io sono partito da questo 

. Il programma consiste di  3 files. Due di questi conterranno le costanti con i dati di ambiente e relative dichiarazioni. Nei file di libreria keys.h e keys.c andranno inserite le costanti contenenti i dati di autenticazione alla rete Wi-Fi e ad AWS.

Nel file aws-esp.ino invece inseriremo il codice che consente all’ESP8266 su NodeMCU di gestire il LED e il button fisico e in più è collegato ad AWS. 

Probabilmente ho saltato alcuni passaggi e sono stato molto leggero sugli altri, comunque ecco il risultato.

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

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]

La ragione per cui in magento2 bisogna usare una sintassi così lunga per creare una media query (da qui in avanti “mq”):

.media-width(@extremum, @break) when (@extremum = 'min') and (@break = @screen__m) { … }

@media screen and (min-width: 1024px) { … }

nativa di css va ricercata nel modo in cui i less vengono assemblati e compilati da Magento2.

, vuole evitare migliaia di @media query 

 sparsi per tutto il codice, ma preferisce raggruppare in un unico punto tutte le regole di una specifica media query. Il che 

Un po’ come si faceva prima dell’avvento dei preprocessori.

Vi sarà sicuramente capitato di dover aggiungere un breakpoint al vostro layout. Di default Magento predispone questi:

@screen__xxs: 320px;
@screen__xs: 480px;
@screen__s: 640px;
@screen__m: 768px;
@screen__l: 1024px;
@screen__xl: 1440px;

lib/web/css/source/lib/variables/_responsive.less

Supponiamo di voler aggiungere una mq fra l’abisso del 

 col valore di 1280px (in _variables.less aggiungiamo 

Non basta andare nel nostro less e mettere:

.media-width(@extremum, @break) when (@extremum = 'min') and (@break = @screen__ml) { … }

perché questo non è un mixin, ma una specie di 

, che nello specifico linguaggio di Less viene chiamato 

Questa mq così non verrà aggiunta perché questa istruzione è incaricata “soltanto” di verificare una corrispondenza che restituisca 

) passati e non trovandola non eseguirà le regole contenute.

Allora, presi dallo sconforto, si potrebbe decidere di ricorrere ai metodi tradizionali ed aggiungere le mq nella modalità standard quindi con:

che sì, stavolta aggiunge le nostre regole MA le inserisce nell’ordine sbagliato nella cascata, nello specifico prima di tutte le altre mq generando così conflitti e override di regole CSS.

Per tentare di risolvere il problema si potrebbe allora pensare di correggere solo per quel dato less le altre mq generate col mixin guard di modo che l’elemento interessato all’interno di quel modulo, essendo già nell’ordine corretto nel less, venga restituito nello stesso ordine nel css, evitando così eventuali conflitti.

Quindi supponendo di avere un less con questo flow:

.media-width(@extremum, @break) when (@extremum = 'min') and (@break = @screen__m) {
   .mini-cart {
      color: red;
     }
}
.media-width(@extremum, @break) when (@extremum = 'min') and (@break = @screen__ml) {
   .mini-cart {
      color: blue;
     }
}

Bitbull

Magento 2

Griglia Less in Magento2

Msi Module Enables Drop Shipping Magento 2

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

Pipeline Magento2

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

Breakpoint, media query e mixin guard su Magento2

Mage Titans Italy 2017

Sviluppare un Widget con Magento2 e RequireJs

Logging su Magento 2