Maggio è arrivato e, come accade ogni anno, si sta rivelando un mese ricco di conferenze per i Bitbulli…. ma è anche un ottimo mese per visitare la città di Verona dove, da parecchi anni a questa parte, il 

 organizza quattro giorni di full immersion dedicati a sviluppatori Javascript e PHP.

Treno presto venerdì mattina ed eccoci all'Hotel San Marco per dare il cambio ai colleghi che hanno partecipato al JsDay nelle giornate di mercoledì e giovedì (

La scaletta dei talk prevedeva circa 20 interventi divisi in due track (

), oltre agli interventi di apertura e chiusura evento, ad alcuni workshop e spazi per unconference talks.

In alcuni casi è stato difficile scegliere quale sala presenziare; noi abbiamo deciso di seguire principalmente interventi focalizzati su strumenti e tecniche da utilizzare nel lavoro quotidiano ma non è mancato lo spazio per approfondire argomenti meno pratici.

Tra le novità presentate hanno riscosso grande interesse il talk su Xdebug 3 tenuto dallo stesso creatore, 

: un'escursione del suo funzionamento e una presentazione delle configurazioni e funzionalità della nuova versione che è stata totalmente riscritta e uscirà nei prossimi mesi.

Un altro talk su un argomento ricco di aspettative è stato quello su MySql 8, tenuto da 

: per questo talk sarebbe stato utile un workshop per testare tutte le novità che sembrano promettere un gran salto di qualità, 

, un'estensione php utile per raccogliere dati sul contenuto della memoria in modo da profilare le applicazioni alla ricerca delle cause dei memory leak. La parte più interessante è stato l'approfondimento su come PHP gestisce la memoria e su come sia possibile riconoscere (e fixare) gli odiosi memory leaks. 

Non è mancato lo spazio per un talk legato al mondo dell'e-commerce, tenuto da 

, dedicato all'approfondimento dei concetti di state machine e state workflow con un esempio di utilizzo del Workflow Component di Symfony, 

, è stato quello sull'utilizzo di Docker in modalità multi-stage e multi-environment. Un talk ricco di spunti, codice, dimostrazioni... forse troppo ricco per il poco tempo a disposizione ma sicuramente da 

Ho descritto brevemente i talk che mi hanno maggiormente coinvolta; tantissimi sono stati gli altri argomenti: si è parlato di Domain-Driven-Design ed Event Storming, di applicazioni Serverless con PHP e Bref, di API e microservizi con diversi talks e anche un workshop tenuto da Enrico Zimuel, di 

creazione di plugin avanzati per Wordpress

Come non menzionare il keynote di chiusura, tenuto da 

 (inventore di PHP) che ci ha accompagnato in un viaggio lungo 25 anni con partenza dalla nascita di PHP e arrivo ad oggi; alla chiusura di questo PhpDay 2019 siamo alla versione 7.3.4 con l'impegno richiesto a noi sviluppatori di tenere aggiornate le versioni di software per sfruttare tutte le nuove potenzialità e la sicurezza.

Infine, un aspetto da non sottovalutare di questa conferenza, e che merita sempre essere ricordato, è l'eccellente organizzazione dell'evento da parte del GRUSP: puntualità della scaletta dei talk, velocità nel check-in, location, servizio di ristorazione di ottimo livello, qualità dei talk veramente alta, social night di livello, simpatia degli organizzatori e infine, permettetemi di menzionarlo: magliette ricordo della conferenza con fit da donna (non scontato :))

Phpday 2019

Quest’anno, per la prima volta, ho deciso di partecipare al 

 che si è tenuto a Milano il 10/11 maggio 2017.

Normalmente prediligo gli eventi a carattere tecnico, più in linea con il mio ruolo, ma questa volta ho voluto osservare a 360° l’ambito in cui operiamo tutti i giorni, che è in continua e veloce trasformazione.

Ho quindi abbandonato i colleghi sviluppatori che hanno partecipato, negli stessi giorni, a JsDay ([qui il resoconto]({{< ref "/blog/jsday-2017/index.md" >}})), PhpDay ([qui il resoconto]({{< ref "/blog/phpday-2017/index.md" >}})), Meet Magento Olanda per fare compagnia al nostro CEO Daniele che, come ogni anno, è in prima linea quando si tratta di fare networking commerciale e sicuramente il Netcomm Forum è un’occasione unica per questo scopo.

La fiera si è aperta con una plenaria di presentazione dell’attuale scenario e-commerce con particolare attenzione alla situazione Italiana.

Il dato generale è confortante: gli Italiani acquistano sempre di più online, cresce la confidenza, di conseguenza aumentano frequenza e volumi di acquisto. Di pari passo con l’aumento degli acquisti online si registra anche un aumento degli acquisti offline.

Il dato meno confortante è che l’offerta e-commerce dall’Italia è ancora bassa: solo il 22% degli acquisti da parte di Italiani avviene su siti di merchant Italiani e a livello europeo i merchant Italiani coprono solo il 4/5 % dell’offerta globale.

Nel primo intervento, tenuto dal presidente Netcomm Roberto Liscia, sono stati presentati i fattori principali che stanno caratterizzando l’evoluzione del commercio elettronico.

 come elementi chiave di un modello denominato “unified commerce”: ad oggi sono aumentate le famiglie digitali ovvero i nuclei con almeno un componente classificabile come “millennial”, grazie all’evoluzione di media e telecomunicazioni siamo costantemente connessi, aumentano gli “Everywhere shoppers” ovvero i compratori che utilizzano tutti e tre i principali device digitali – pc, smartphone, tablet – con un’esperienza di acquisto senza limite di spazio e di tempo.

È quindi importante che vengano fornite al cliente continuità e convergenza nell’esperienza di acquisto fisica e digitale e che l’utilizzo del canale online diventi consuetudine.

Gli attori principali di questo processo di trasformazione sono i retail, fisici e digitali.

I retail fisici assumono un ruolo sempre più importante nel supportare i processi e servizi legati a logistica e fulfillment (magazzini, ritiri nei punti vendita, resi).

I retail digitali devono predisporsi alla 

trasformazione da negozio digitale a piattaforma tecnologica

, ovvero creare una infrastruttura competitiva in grado di guidare il cliente nel percorso di acquisto, supportarlo nella scelta, fornire strumenti di pagamento sicuri e veloci, una logistica snella e un customer care che sia reale strumento di informazione e confronto.

L’attenzione dei retail dovrà sempre di più focalizzarsi sul servizio offerto per soddisfare il bisogno del cliente finale più che sul prodotto venduto.

Durante la presentazione sono stati portati come esempio i nomi di alcune aziende che si sono affermate come leader nel loro settore di riferimento, senza essere in realtà proprietarie del prodotto venduto: si pensi ad AirBnb, WhatsApp, Netflix, Uber…

Il mercato B2C in Italia, previsioni 2017

Il secondo intervento della plenaria ha visto sul palco Riccardo Mangiaracina, Direttore Scientifico dell’Osservatorio eCommerce B2C, che ha presentato l’analisi del mercato B2C in Italia dal punto di vista della domanda e dell’offerta, con particolare attenzione agli elementi di innovazione e ai dati di chiusura del 2016 confrontati con le previsioni per il 2017.

2016: il mercato cresce del 20%. L’acquisto di prodotti cresce del 25%, quello dei servizi 8%.

2017 – previsione: crescita complessiva del 16% circa, equamente distribuita tra beni e servizi.

I servizi che registrano maggiore crescita rimangono il turismo (biglietteria, ospitalità) e le assicurazioni, con particolare crescita dei comparatori di prezzo.

I settori merceologici di prodotto con maggiore crescita sono: informatica ed elettronica, abbigliamento, food&grocery (registra un +40% grazie a tanti nuovi ingressi nel mercato e ad alta crescita per food delivery e spesa online), arredamento, editoria.

Uno dei dati previsionali più interessanti è la distribuzione della crescita per canali di acquisto: si prevede un 23% degli acquisti via smartphone e 8% via tablet (rispettivamente 9% e 18% nel 2016).

La composizione del mercato conta circa 3/4 degli acquisti fatti su siti Italiani e 1/4 su siti stranieri (import) mentre per le modalità di pagamento si riconfermano carta credito e PayPal a coprire il 96% delle transazioni.

Per quanto riguarda l’offerta si registra che il 70% del mercato è coperto dai primi 20 operatori e di questi ben 10 sono aggregatori: gli aggregatori complessivamente hanno un peso del 40% del mercato.

L’export per l’Italia cresce del 21% e il settore di traino di questa crescita è l’abbigliamento.

Infine, relativamente alle aree di innovazione, sono state citati alcuni elementi chiave già identificati nel talk di Roberto Liscia:

Durante le due giornate ho partecipato ad alcuni workshop e visitato gli stand dei diversi operatori presenti.

Tra gli operatori ho notato una grande presenza di aziende che offrono soluzioni nell’ambito di:

Per quanto riguarda i pagamenti il grande protagonista è stato Amazon, con la presentazione di Amazon Pay tramite uno stand ed un workshop dedicati; ovviamente la curiosità è tanta con il modulo per Magento1 già disponibile.

In realtà erano tanti gli operatori presenti, e con alcuni ho raccolto anche delle informazioni tecniche nonostante, come è tipico di questa tipologia di eventi, la maggior parte delle “chiacchiere” si fa con profili commerciali poco adatti a scendere nel dettaglio implementativo.

Per le spedizioni ho notato la presenza di nuovi operatori, personalmente non ho approfondito molto la tematica e mi sono soffermata allo stand di 

 con cui ho già lavorato (bene) e che ringrazio per aver invitato me e Daniele all’evento.

Il filone marketing è sempre di grande attualità e componente fondamentale di un progetto e-commerce: anche in questo caso tanti workshop e operatori specializzati su temi come e-mail marketing, marketing automation, social network, fino ad arrivare alla parola dell’anno “chatbot”.

Si fa sempre più stretto il rapporto tra marketing e tecnologia e l’importanza dei dati raccolti per predire il comportamento degli utenti e per aumentare la reputazione dei brand.

Per quanto riguarda la gestione del catalogo prodotti ho trovato grande presenza di soluzioni per motori di ricerca, abbastanza allineate tra loro rispetto alle funzionalità offerte.

I temi su cui mi sono soffermata maggiormente sono stati la presentazione di uno strumento PIM (Product Information Management), per la precisione <a href="https://www.akeneo.com/" target="_blank">Akeneo</a>; una piattaforma che gestisce i feed di catalogo, <a href="https://www.lengow.com/it" target="_blank">Lengow</a>; una piattaforma per la gestione centralizzata di inventario di catalogo e ordini per aziende che vendono su diversi marketplace, che si chiama <a href="http://www.cloudstore.srl/" target="_blank">CloudStore</a>.

Ho scelto queste tematiche perché sono quelle su cui ho riscontrato maggiore sensibilità da parte dei clienti con cui ho lavorato negli ultimi 6 mesi.

Un po’ per passione e un po’ per curiosità mi sono soffermata a vedere la demo di 

, un macchinario (corredato da relativo software) per la fotografia di prodotto a 360° e 3D: mi hanno stupito la semplicità e velocità di utilizzo del software più che il macchinario in sé che non è proprio una tecnologia nuova.

Infine tanti gli operatori che offrono soluzioni di sviluppo tecnologico per piattaforme e-commerce. I framework più nominati sono stati Magento, PrestaShop, Demandware.

Tanti anche gli operatori che offrono servizi di hosting specializzato per ospitare e ottimizzare piattaforme e-commerce, tra questi anche 

La partecipazione alla fiera per me è stata un’esperienza positiva, che ha soddisfatto la mia curiosità e sicuramente da replicare una volta all’anno: si tratta di un evento non-tecnico ma si trovano parecchie persone con cui parlare di tecnologia.

Per un profilo come il mio, che non può evitare di porre attenzione alle esigenze del cliente a 360°, l’evento è un’occasione per approfondire degli argomenti sempre di più oggetto di integrazione tecnica tra sistemi, che è poi il nostro mestiere e la nostra specializzazione.

E poi una volta ogni tanto è curioso uscire dal proprio guscio prettamente “pratico” e aprirsi a visioni più “concettuali” e ci si rende conto veramente di quanto è articolato, ricco e in evoluzione il settore in cui lavoriamo.

Inoltre la partecipazione a questo tipo di eventi, anche solo come visitatori, dà una certa visibilità all’azienda: ogni anno Daniele garantisce la presenza di Bitbull, quest’anno ci siamo presentati con i nuovissimi biglietti da visita aziendali, molto apprezzati.

Infine, come già accennato, il Netcomm Forum è sempre occasione per creare networking tra aziende e per rivedere vecchie amicizie e persone con cui ci sono state o ci saranno collaborazioni.

Netcomm Forum 2017

Qualche settimana fa ho partecipato all’<a href="https://aws.amazon.com/it/awsomedaysitalia-2016/" target="_blank">AWSome Day</a> a Padova, evento gratuito organizzato da Amazon Web Service; si è trattato di una giornata di formazione e consulenza dagli esperti AWS, rivolta a IT Manager e sviluppatori che hanno iniziato a utilizzare le soluzioni di  Cloud Computing di Amazon o che, come me, sono (anzi – erano) totalmente ignoranti sull’argomento.

Il taglio dell’evento era sicuramente entry-level, quindi perfetto per me che conoscevo questa tecnologia solo per sentito dire e che sono curiosa di approfondire, anche perché AWS è la nostra infrastruttura di riferimento per i servizi di hosting evoluti.

Ho preso un sacco di appunti con l’intenzione di condividere i contenuti di questa giornata con alcuni colleghi che, come me, sentono parlare di AWS ma non sono mai entrati nel merito della soluzione. Alla fine ho pensato che il nostro primo strumento di diffusione della conoscenza, internamente ed esternamente all’azienda, è il blog quindi perchè non trasformare dei sommari appunti in un vero e proprio articolo?

Il Cloud Computing è una tecnologia che mette a disposizione, tramite la rete Internet, servizi basati sull’erogazione di risorse hardware e software con formula on demand.

Le risorse erogate comprendono, ad esempio: potenza di calcolo, spazio di archiviazione, strumenti di trasmissione dati e veri e propri servizi applicativi.

Un’azienda che necessita questo tipo di risorse per erogare i propri servizi online può appoggiarsi ad un provider di servizi cloud per acquistare e configurare un set di risorse, con la garanzia di poter ampliare questo set nel tempo in base alle esigenze di business e di capacità del sistema.

Le caratteristiche che hanno reso il Cloud Computing una tecnologia di successo sono:

<li style="font-weight: 400">
contenimento dei costi
</li>
<li style="font-weight: 400">
scalabilità del sistema
</li>
<li style="font-weight: 400">
garanzia della sicurezza
</li>

 principalmente si elimina l’esigenza di gestire un’infrastruttura IT personale, dall’acquisto dell’hardware e del software alla manutenzione del sistema passando dall’esigenza di avere in azienda figure specializzate. Inoltre il concetto di Cloud Computing si accompagna al concetto di flessibilità del costo in base alle reali risorse utilizzate (costo a consumo).

 possibilità di ampliare o diminuire le risorse a disposizione in base alla capacità richiesta per sopportare il carico garantendo stabilità al sistema; ad esempio incrementare le risorse a disposizione all’aumento della mole di dati da gestire, oppure all’aumento del traffico verso un servizio online.

 un buon service provider si occupa di mettere in atto tutte le pratiche necessarie per garantire il rispetto delle policy di sicurezza, la protezione dei dati memorizzati nel cloud e la conformità con una serie di certificazioni necessarie per la messa in opera di servizi che richiedono adeguati livelli di sicurezza (crittografia dei dati, autenticazione, antivirus, cifratura dei dischi ecc…)

Le principali tipologie di tecnologia Cloud sono così classificate:

<li style="font-weight: 400">
DaaS (Data as a service): il provider eroga e gestisce unicamente lo storage dati
</li>
<li style="font-weight: 400">
SaaS (Software as a service): il provider eroga e gestisce un servizio software
</li>
<li style="font-weight: 400">
IaaS (Infrastructure as a service): il provider eroga e gestisce l’infrastruttura di sole risorse hardware
</li>
<li style="font-weight: 400">
PaaS (Platform as a service): il provider eroga e gestisce l’infrastruttura hardware corredata dalle risorse software che permettono di avere una soluzione integrata per l’erogazione di applicazioni
</li>

Il cloud AWS è un sistema PaaS distribuito e disponibile in 190 paesi, suddivisi in aree geografiche (regions). Attualmente sono attive 14 regioni ma nel prossimo anno è prevista la nascita di altre 4.

Ogni regione comprende diverse zone di disponibilità (AZ – Availability Zone): le zone di disponibilità sono a tutti gli effetti dei data center distribuiti che permettono di replicare le applicazioni in modo da garantire scalabilità e disponibilità in caso di guasti su una particolare zona.

La scelta della regione da cui erogare i propri servizi e applicazioni dovrebbe essere dipendente dalla provenienza della maggior parte dei visitatori.

Componenti AWS, traduciamo un po’ di sigle

Nel sistema AWS quasi ogni componente o servizio è identificato, o meglio riconosciuto, da una sigla. Vediamo di far luce sulle principali.

E’ il primo componente nato in Amazon: si tratta di un servizio di archiviazione di risorse accessibili e condivisibili. E’ particolarmente adatto all’archiviazione di risorse statiche (storage, backup, media, componenti software da scaricare al boot per il delivery di macchine EC2).

<li style="font-weight: 400">
le risorse vengono archiviate all’interno di buckets, ovvero contenitori logici su cui è possibile impostare i permessi di accesso
</li>
<li style="font-weight: 400">
ad ogni risorsa salvata è associata una chiave all’interno del bucket
</li>
<li style="font-weight: 400">
le risorse archiviate sono disponibili via http e puntando alla url del servizio e alla chiave dell’oggetto e sono anche accessibili via rest/soap API tramite protocollo https
</li>
<li style="font-weight: 400">
non ha limiti di storage
</li>
<li style="font-weight: 400">
servizio scalabile, durevole e affidabile
</li>
<li style="font-weight: 400">
gestisce versioning e lifetime delle risorse
</li>
<li style="font-weight: 400">
le chiamate a S3 sono tutte crittografate con una chiave tramite un servizio
</li>
<li style="font-weight: 400">
si può attivare il logging di accesso alle risorse
</li>
<li style="font-weight: 400">
si possono configurare eventi (al get/put delle risorse)
</li>
<li style="font-weight: 400">
si paga lo spazio occupato
</li>

Per approfondimenti: <a href="https://aws.amazon.com/it/s3" target="_blank">https://aws.amazon.com/it/s3</a>

Si tratta dell’infrastruttura che consente di disporre on demand di istanze di macchine virtuali configurabili in base alle proprie necessità.

E’ possibile ridimensionare, accendere e spegnere le istanze in base all’esigenza di potenza di calcolo necessaria per far fronte al carico: la prima caratteristica è quindi la scalabilità in termini di capacità di carico.

Per attivare una macchina si può partire da un’immagine (

) o da un template precedentemente salvato, che è a tutti gli effetti un “modello di macchina”.

Si scelgono quindi il sistema operativo (Linux / Windows), l’availability zone in cui accendere la macchina, la dimensione della macchina selezionando famiglia (famiglie: T2, M3, M4, C3, C4, R3, G2, I2, D2), l’architettura della macchina configurando RAM, CPU, dischi di storage e rete.

Successivamente si procede alla configurazione dell’istanza specificando le regole di shutdown, il monitoraggio, i permessi di accesso e altre specifiche.

Il self-configuration della macchina mette a disposizione due importanti strumenti:

<li style="font-weight: 400">
Metadata: tutte le informazioni associate alla macchina. in qualsiasi momento si può verificare lo status dell’istanza interrogando i Metadata.
</li>
<li style="font-weight: 400">
User Data: informazioni da mandare all’istanza in modo che vengano eseguiti degli script al boot della macchina.
</li>

<li style="font-weight: 400">
alta scalabilità
</li>
<li style="font-weight: 400">
possibilità di sfruttare il servizio di Auto-Scaling: vengono accese in automatico delle istanze in base a logiche da noi definite; possiamo impostare metriche sulle risorse (ad es cpu) o su fasce orarie in base al traffico previsto
</li>
<li style="font-weight: 400">
accesso di root alla macchina
</li>
<li style="font-weight: 400">
possibilità di definizione di una chiave di accesso alla macchina via ssh
</li>
<li style="font-weight: 400">
massimo controllo della risorsa (sotto il profilo hardware e software)
</li>
<li style="font-weight: 400">
possibilità di gestire dei tag sulle risorse in modo da identificarle all’interno del cloud
</li>
<li style="font-weight: 400">
possibilità di configurare security groups
</li>
<li style="font-weight: 400">
possibilità di sfruttare il bilanciamento di traffico mediante Elastic Load Balancing
</li>
<li style="font-weight: 400">
usa hardware intel xeon sempre aggiornato
</li>
<li style="font-weight: 400">
si pagano solo le risorse utilizzate (dal momento in cui accendo la macchina)
</li>

Per approfondimenti: <a href="https://aws.amazon.com/it/ec2/" target="_blank">https://aws.amazon.com/it/ec2/</a>

Sono volumi di storage (dischi) montati sulle istanze EC2.

Risiedono nella medesima availability zone dell’istanza EC2 su cui vengono montati e sono particolarmente adatti come storage per dati che richiedono alta persistenza (indipendentemente dallo stato della macchina a cui sono collegati). Sono quindi adatti per l’utilizzo come file system primario o per lo storage di database o per memorizzare e gestire dati ad alta frequenza di lettura/scrittura.

Su una singola istanza EC2 possono essere montati diversi volumi EBS, un singolo volume EBS può però servire una singola istanza EC2 alla volta.

Per alti carichi di input/output su un disco si può scegliere la tipologia Provisioned IOPS SSD per garantire maggiori performance di I/O sul disco.

Tramite il servizio Amazon EBS Snapshot si possono gestire i backup dei dischi e bisogna fare attenzione alla tipologia di IP collegati, per garantire la persistenza degli indirizzi IP di riferimento in caso di azioni stop/start sull’istanza EC2 su cui è montato il volume.

Per approfondimenti: <a href="https://aws.amazon.com/it/ebs/" target="_blank">https://aws.amazon.com/it/ebs/</a>

Si tratta di un ambiente privato virtuale, logicamente isolato all’interno di AWS, in cui far risiedere le istanze EC2.

Di default Amazon crea una rete privata VPC per l’account utente, assegnando i servizi AWS attivi; è sempre possibile configurare le caratteristiche della rete VPC o crearne di nuove.

Altamente personalizzabile: è possibile selezionare gli intervalli degli indirizzi IP, configurare una VPN hardware con la propria rete aziendale e definire i permessi di accesso alla VPC.

E’ anche possibile creare delle subnet, o sottoreti: una subnet è sempre legata ad una availability zone.

La VPC prevede diversi livelli di sicurezza con possibilità di configurare:

<li style="font-weight: 400">
Security-groups: legati alle istanze EC2 lanciate all’interno della VPC. Funzionano come se fossero dei firewall che regolamentano il traffico outbound/inbound all’interno della VPC. Agiscono a livello di singola istanza EC2 e sono stateful.
</li>
<li style="font-weight: 400">
ACL per filtrare il traffico a livello di subnet, controllano il traffico in base al tipo di accesso (inbound/outbound) e sono stateless.
</li>

Per approfondimenti: <a href="https://aws.amazon.com/it/vpc/" target="_blank">https://aws.amazon.com/it/vpc/</a>

Amazon mette a disposizione alcuni servizi per la gestione di database: motori di database relazionali / nosql, sistemi di caching, servizi di migrazione dei databases nel cloud.

<li style="font-weight: 400">
Amazon Dynamo DB: database no sql fully managed; è possibile tarare il provision (size read/write) in base alla previsione di utilizzi
</li>
<li style="font-weight: 400">
Amazon RDS: gestore di database relazionale (db engine supportati: mysql, mariadb, microsoft sql server, postgres, oracle). Le istanze di database girano sotto la VPC, servizio scalabile e deployabile su diverze availability zones. E’ possibile configurare backup automatici configurando schedulazione e retention.
</li>
<li style="font-weight: 400">
Amazon Aurora: database relazionale compatibile con MySql ma (a detta di Amazon) estremamente performante
</li>
<li style="font-weight: 400">
Amazon ElastiCache: servizio di caching che implementa i motori Redis e Memcached; servizio scalabile e distribuibile.
</li>

Per approfondimenti: <a href="https://aws.amazon.com/it/products/databases/" target="_blank">https://aws.amazon.com/it/products/databases/</a>

E’ il sistema di monitoraggio di Amazon; ha una serie di metriche (ad es utilizzo cpu di una particolare istanza o gruppo di istanze) per monitorare le risorse AWS istanziate all’interno della propria VPC.

E’ possibile agganciare allarmi alle metriche per effettuare un’azione come ad esempio inviare una notifica email o agganciare una nuova macchina all’autoscaling group.

Si possono creare metriche custom aggiuntive a quelle Amazon (custom metrics).

Il servizio fornisce report grafici e statistiche sullo stato operativo delle risorse monitorate.

Per approfondimenti: <a href="https://aws.amazon.com/it/cloudwatch/" target="_blank">https://aws.amazon.com/it/cloudwatch/</a>

Amazon fornisce un servizio web e un’applicazione per accedere alla console di gestione delle risorse AWS.

Per iniziare ad utilizzare AWS è necessario registrare un account gratuito e collegare una carta di credito; ricordiamoci che, al netto dei servizi gratuiti per il primo anno, il resto delle risorse istanziate e utilizzate saranno addebitate in base alla politica di pricing scelta.

Dalla console AWS è possibile configurare il proprio account, è possibile accendere / spegnere / configurare risorse e accedere alle statistiche del sistema di monitoraggio.

E’ anche possibile configurare il networking (VPC, ACL, Security groups) e tutte le regole relative a sicurezza, identità e gestione degli accessi alle risorse (utenti, gruppi e ruoli IAM, utenti federati)

Per approfondimenti: <a href="https://aws.amazon.com/it/console/" target="_blank">https://aws.amazon.com/it/console/</a>

Esiste AWS Free Tier che è il piano gratuito sfruttabile per avvicinarsi al mondo AWS senza dover sostenere dei costi.

In base al tipo di servizio esistono diverse politiche di pricing, approfondibili a questo link: <a href="https://aws.amazon.com/it/pricing/services/" target="_blank">https://aws.amazon.com/it/pricing/services/</a>

Sarebbe impossibile in un articolo esplorare l’intera gamma di prodotti AWS, per questo rimando al <a href="https://aws.amazon.com/it/" target="_blank">sito web ufficale</a> che spiega in modo dettagliato le caratteristiche di ogni servizio e offre dei tutorial per iniziare ad utilizzare questa tecnologia.

Registrandosi al servizio si può accedere al <a href="https://aws.amazon.com/it/free/" target="_blank">piano gratuito di AWS</a> della durata di 1 anno che permette l’utilizzo free (con alcune limitazioni) della maggior parte dei servizi.

AWS for dummies

In Bitbull, quando partiamo con lo sviluppo di un nuovo progetto, per prima cosa ragioniamo su come “fare a pezzi” il progetto stesso, ovvero identifichiamo i componenti software che è necessario integrare per dare vita all’applicazione.

Il vantaggio principale che offre questo approccio è il 

, facilmente reperibile da repository pubblici, testato e manutenuto dalla community di sviluppatori, oppure da repository privati. La conseguenza è una 

pacchettizzare e rendere disponibili anche i propri moduli

, seguendo uno standard condiviso. Inoltre risulta agevole l’

aggiornamento dei singoli componenti a nuove versioni.

Nel mondo PHP il concetto di “aggregazione di componenti di codice riutilizzabili e disponibili su repository” non è recente: in passato era molto in voga l’utilizzo di PEAR che è un sistema di distribuzione di librerie PHP open-source, raccolte in un repository ufficiale quasi considerato un framework.

La principale differenza pratica tra PEAR e Composer è che il primo viene configurato globalmente sulla macchina in cui è installato e quindi le stesse librerie sono disponibili per tutti i progetti (con evidenti esplosioni di euforia degli sviluppatori che si trovano a gestire i conflitti di versione tra progetti diversi), mentre il secondo prevede sia delle configurazioni globali a livello di macchina, sia configurazioni locali di progetto.

Inoltre PEAR è decisamento obsoleto, come indicato già due anni fa da <a href="http://fabien.potencier.org/the-rise-of-composer-and-the-fall-of-pear.html" target="_blank">Fabien Potencier nel suo blog</a>.

Scegliamo un tool in base alla flessibilità e alla propensione al rinnovamento e quindi, ad oggi, ci focalizziamo su Composer!

: consente di dichiarare la lista delle dipendenze del progetto e le regole con cui si occuperà di scaricare e installare/aggiornare per noi questi pacchetti software all’interno del progetto.

Composer ha un repository ufficiale delle dipendenze, Packagist (<a href="https://packagist.org/" target="_blank">https://packagist.org/</a>), e un meccanismo nativo di gestione dell’autoload.

Questo il link al sito ufficiale del progetto: <a href="https://getcomposer.org/" target="_blank">https://getcomposer.org/</a>

Per poter utilizzare Composer dobbiamo procedere all’installazione; normalmente installiamo il tool a livello globale della macchina, posizionandolo in una cartella (ad es. usr/local/bin) specificata nella variabile d’ambiente $PATH, in modo che l’eseguibile (assicuratevi che lo sia dando i permessi necessari) sia disponibile ovunque.

Facendo riferimento all’ultima versione disponibile ad oggi e all’ipotesi di posizionare l’eseguibile Composer nella cartella ‘usr/local/bin’, in ambiente Unix (Linux, Mac OSX) sono sufficienti questi comandi:

<pre>$ sudo curl https://getcomposer.org/download/1.2.0/composer.phar -o /usr/local/bin/composer
$ sudo chmod +x /usr/local/bin/composer</pre>

L’approccio alla scomposizione del progetto in dipendenze, con Composer, si concretizza con due principali attività:

 che creiamo nella cartella di progetto e in cui elenchiamo i repository dove andare a recuperare i pacchetti e la lista di tutte le dipendenze, oltre ad alcune informazioni generali ed eventuali configurazioni avanzate sul progetto stesso. In questo file possiamo anche dichiarare degli script da eseguire al termine dell’installazione delle dipendenze.

Possiamo creare questo file manualmente oppure tramite il comando:

Per un approfondimento sullo schema del file composer.json fare riferimento a <a href="https://getcomposer.org/doc/04-schema.md" target="_blank">questo link</a>, per la lista completa dei comandi messi a disposizione dal tool fare riferimento a <a href="https://getcomposer.org/doc/03-cli.md" target="_blank">questo link</a>.

 occorre posizionarsi nella cartella in cui è presente il composer.json e lanciare da terminale il comando:

Questo comando scarica tutti i pacchetti dichiarati, li salva in una cartella chiamata “vendor” e crea un file autoload.php sotto la cartella vendor. Questo file è l’unico che necessita essere incluso negli script del progetto PHP.

Al termine della prima installazione delle dipendenze Composer crea il file 

 in cui vengono dichiarate tutte le dipendenze con indicazione della versione scaricata e installata.

Questo file può essere distribuito agli sviluppatori che vogliono replicare il progetto: sarà per loro sufficiente eseguire un composer install per assicurarsi di utilizzare gli stessi pacchetti e versioni dichiarati nel composer.lock.

Successivamente, in caso di modifica del file composer.json o di necessità di aggiornamento delle dipendenze dichiarate, andrà eseguito da terminale il comando

Questo comando scarica e installa le dipendenze che richiedono aggiornamento, rimuovendo la vecchia versione, e aggiorna il file composer.lock da distriibuire.

Come utilizziamo Composer con un progetto Magento?

Ma veniamo al sodo e vediamo come fare a pezzi un progetto Magento per poi lanciare un comando e trovarci magicamente di fronte un’applicazione funzionante (in realtà non è necessario alcun potere magico).

Parlerò dell’utilizzo di Composer con Magento 1, perchè Magento 2 ufficialmente supporta e incoraggia l’installazione tramite Composer.

Nel caso di un tipico progetto Magento, i “pezzi” a cui mi riferisco sono, ad esempio:

Come vedremo, il nostro progetto diventa a tutti gli effetti un 

 in quanto non conterrà codice PHP ma solo la definizione delle dipendenze di codice necessarie per il suo funzionamento.

Ecco il composer.json di esempio per un ipotetico progetto “magento_composer_example”:

<pre class="brush: jscript; title: ; notranslate" title="">{
"name": "bitbull/magento_composer_example",
"description": "Magento Composer Example Project",
"minimum-stability": "dev",
"authors": [
{"name": "Bitbull", "email": "devel@bitbull.it"}
],
"repositories":[
{"type": "composer", "url": "http://packages.firegento.com"},
{"type": "composer", "url": "http://packages.bitbull.it"},
{"type": "vcs", "url": "git@github.com:bitbull-team/mageploy.git"},
{"type": "vcs", "url": "git@bitbucket.org:bitbull/magento-translations-it.git"},
{"type": "vcs", "url": "git@bitbucket.org:bitbull/custom-example-modules.git"},
{"type": "vcs", "url": "git@bitbucket.org:bitbull/custom-example-theme.git"},
{"type": "vcs", "url": "git@bitbucket.org:bitbull/magento-deploy.git"},
{"type": "vcs", "url": "https://github.com/netz98/n98-magerun.git"},
{"type": "package",
"package": {
"type": "magento-module",
"name": "Acme_Module",
"version": "1.7.9",
"dist": {
"url": "https://bitbucket.org/bitbull/acme_module/get/v1.7.9.zip",
"type": "zip"
}
}
}
],
"require":{
"magento-hackathon/magento-composer-installer": "3.0.6",
"bitbull/magento-core": "1.9.2.4",
"bitbull/magento-cookienotice": "1.0.0",
"bitbull/magento-translations-it": "1.0.0",
"firegento/psr0autoloader": "dev-master",
"bitbull/composer-magento-example-modules" : "dev-master",
"bitbull/composer-magento-example-theme" : "dev-master",
"inchoo/php7": "1.0.3",
"bitbull/magento-deploy": "1.0.0",
"n98/magerun": "1.97.21"
},
"require-dev": {
"aleron75/webgriffe_tph-pro": "dev-master",
"pug-more/mageploy": "1.2.0"
},
"config": {
"secure-http": false
},
"extra":{
"magento-root-dir": ".",
"magento-deploystrategy": "symlink",
"magento-deploystrategy-overwrite": {
"bitbull/magento-core": "copy"
},
"magento-force": true,
"auto-append-gitignore": true
},
"autoload": {
"psr-0": {
"Bitbull": "lib/"
}
},
"scripts": {
"post-update-cmd": [
"Bitbull\Deploy\Magento::generateLocalXml",
"Bitbull\Deploy\Magento::setMaintenanceMode",
"Bitbull\Deploy\Magento::flushCache",
"Bitbull\Deploy\Magento::runUpgradeScripts",
"Bitbull\Deploy\Magento::reindexAll",
"Bitbull\Deploy\Magento::unsetMaintenanceMode"
],
"post-install-cmd": [
"Bitbull\Deploy\Magento::generateLocalXml",
"Bitbull\Deploy\Magento::setMaintenanceMode",
"Bitbull\Deploy\Magento::flushCache",
"Bitbull\Deploy\Magento::runUpgradeScripts",
"Bitbull\Deploy\Magento::reindexAll",
"Bitbull\Deploy\Magento::unsetMaintenanceMode"
]
}
}
</pre>

Vediamo nello specifico il significato delle principali direttive inserite nell’esempio; per la documentazione ufficiale e completa fate riferimento a <a href="https://getcomposer.org/doc/04-schema.md" target="_blank">questo link</a>:

La libreria magento-hackaton/magento-composer-installer

Questa libreria è la prima che includiamo in tutti i nostri progetti Magento poiché è studiata appositamente per installare moduli Magento tramite Composer, risolvendo alcune problematiche di integrazione.

è in grado di riconoscere e processare solo le dipendenze che rappresentano moduli Magento

; nel file composer.json delle singole dipendenze va impostata la tipologia di pacchetto specificando “magento-module”:

<pre class="brush: jscript; title: ; notranslate" title="">{
"name": "bitbull/magento-translations-it",
"type": "magento-module",
}
</pre>

Per noi il core Magento, il tema, tutti i moduli e la libreria che usiamo per le operazioni di deploy sono di tipo “magento-module”.

Per quanto riguarda il core di Magento, una soluzione alternativa è l’utilizzo del plugin <a href="https://github.com/AydinHassan/magento-core-composer-installer" target="_blank">Magento Core Composer Installer</a>, che nasce proprio per gestire il core di Magento come dipendenza installata con Composer, semplificando il mapping e ottimizzando la gestione del .gitignore.

Di default, in fase di installazione delle dipendenze, Composer scarica nella cartella vendor i file delle dipendenze; magento-composer-install replica questi file all’interno della root Magento in modo da creare la struttura di files e cartelle tipica di una installazione Magento standard.

Il metodo con cui rende disponibili i file dipende dalle configurazioni 

<pre class="brush: jscript; title: ; notranslate" title="">{
"extra":{
"magento-root-dir": ".",
"magento-deploystrategy": “symlink”,
"magento-deploystrategy-overwrite": {
"bitbull/magento-core": "copy"
},
"magento-force": true
}
}
</pre>

Nel nostro caso indichiamo di deployare i moduli magento come link simbolici all’interno della struttura delle cartelle Magento, ad eccezione del pacchetto relativo al core di Magento che viene copiato.

Normalmente utilizziamo Modman per la specifica della mappatura della posizione dei files da replicare (per approfondimenti su modman <a href="https://github.com/colinmollenhour/modman/wiki/Tutorial" target="_blank">leggi questo tutorial</a>). Ulteriori opzioni sono la mappatura esplicita all’interno del composer.json oppure indicare, sempre nel composer.json tra le configurazioni “extra”, il file package.xml del modulo compilato secondo lo standard utilizzato da Magento Connect.

Questa strategia di deploy ha un comodo risvolto pratico.

Per il tema grafico e per i moduli con le personalizzazioni di progetto normalmente lavoriamo su due repository git separati (customer-project-theme e customer-project-modules) e, durante la fase di sviluppo, referenziamo le dipendenze facendo riferimento al branch master (dev-master).

In questo modo, sotto la vendor, abbiamo a tutti gli effetti due repository git su cui effettuare aggiornamenti, commit, ecc… e con la strategia di deploy “symlink” qualsiasi modifica ai pacchetti viene replicata in tempo reale sotto il path della root Magento in modo da poter lavorare senza necessità di effettuare un’operazione di composer update.

Inoltre, per chi come noi utilizza repository git, questa libreria consente di 

aggiungere in automatico al file .gitignore

 i riferimenti a tutti i file dei pacchetti integrati nel progetto come moduli magento (riconosciuti grazie alla configurazione della proprietà type).

<pre class="brush: jscript; title: ; notranslate" title="">{
"extra":{
"magento-root-dir": ".",
"auto-append-gitignore": true
}
}
</pre>

Questa integrazione con git è molto comoda poiché consente di avere nel repository git solo i files composer.json, composer.lock, .gitignore.

Come ulteriore feature la libreria consente di 

gestione dell’autoloading delle dipendenze

, tramite l’applicazione di una patch al core Magento (file app/Mage.php) che risolve l’inclusione del file di autoloading creato da Composer sotto la cartella vendor.

Questo comportamento, attivo di default, può essere disabilitato specificando la seguente configurazione:

<pre class="brush: jscript; title: ; notranslate" title="">{
"extra":{
"with-bootstrap-patch": "false"
}
}
</pre>

Quando creiamo una nuova estensione Magento, sviluppando ad esempio un modulo o il tema del cliente, ci adoperiamo per fare in modo che sia installabile come dipendenza tramite Composer.

Per fare questo è sufficiente includere un file composer.json che identifica il pacchetto, specificandone il nome (composto da vendor-name e package-name) ed eventuali ulteriori dipendenze.

Qui sotto ad esempio il file composer.json del modulo di traduzioni Magento di Bitbull.

<pre class="brush: jscript; title: ; notranslate" title="">{
"name": "bitbull/magento-translations-it",
"description": "Magento core and transactional e-mails translations in Italian",
"license":"MIT",
"type": "magento-module",
"authors":[
{
"name":"Lorena Ramonda",
"email":"lorena.ramonda@bitbull.it"
}
],
"require": {
"magento-hackathon/magento-composer-installer": "*"
}
}
</pre>

Come possiamo notare abbiamo dovuto specificare la proprietà 

 (dove “bitbull” è la vendor name) e la dipendenza con magento-hackaton/magento-composer-installer. Non è stato necessario specificare alcun repository in quanto l’unica dipendenza da soddisfare è recuperabile dal repository Composer ufficiale, Packagist.

Per indicazioni sulla creazione di librerie fare riferimento a <a href="https://getcomposer.org/doc/02-libraries.md" target="_blank">questo link</a>.

Tutte le funzionalità che potrebbero essere messe a fattor comune su diversi progetti vengono soddisfatte con moduli esistenti (community, Bitbull, altri fornitori) , distribuiti come pacchetti singoli, e quindi indipendenti dal progetto su cui è nata l’esigenza di integrazione.

Tutti questi moduli vengono referenziati nel composer.json facendo riferimento, per la versione, ad uno specifico tag.

Bitbull

Nadia Sala

Articoli scritti da Nadia Sala

Phpday 2019

Netcomm Forum 2017

AWS for dummies

Composer: come “facciamo a pezzi” un progetto Magento

Si fa presto a dire “deploy” !

Quando le tipologie di prodotto Magento non bastano