La vita del programmatore, molte volte, è costellata da numerosi compromessi che si devono raggiungere per "far contento" il cliente, a discapito di molti altri aspetti: pulizia del codice, ottimizzazione dei processi, sicurezza, ridondanza delle informazioni etc etc
La "soluzione perfetta" non esiste e occorre capire questa cosa il prima possibile, per evitare di combattere contro i mulini a vento e perdere molto del tempo dedicato ad un progetto, per convincere gli altri che, quanto pensato, non è la soluzione migliore che si possa scegliere.
A volte, soprattutto quando il budget non è sufficiente, è necessario accettare questi compromessi per riuscire a portare in porto un progetto.
Un compromesso che spesso mi capita di scegliere è quello di non modificare le strutture dati e le applicazioni che vengono utilizzate all'interno di un'azienda, a meno che non ci sia una situazione tale da rendere obsoleta, nel breve tempo, una soluzione che viene utilizzata giornalmente.
Questo significa che spesso mi trovo a lavorare con architetture che non si parlano fra di loro, nelle quali è necessario fare il lavoro di "system integrator", creando flussi dati fra applicazioni diverse, dove non sempre i tracciati sono chiari o documentati e spesso occorre scomporre e studiare come sono gestiti i dati per poterli migrare fra un sistema e l'altro.
Passaggio dei dati
In un mondo reale il concetto di "passaggio indolore" non esiste. Quando si passano dei dati da un programma all'altro, molto spesso, ci si trova a dover far combaciare strutture completamente diverse e a dover inventare dati, deducendoli da quelli presenti.
Ecommerce
Da un cliente mi sono scontrato con l'esigenza di far dialogare il gestionale Moda prodotto da Accord, un'azienda di Verona, col suo e-commerce sviluppato in WordPress e Woocommerce.
C'erano due mondi che si scontravano: da un lato il gestionale interno, progettato e pensato per essere utilizzato in un negozio, e dall'altro il mondo "del Web", tutta immagine e colore.
Nel primo mondo la descrizione di un prodotto può essere ridotta ai minimi termini: non occorre neppure una foto, dato che si trova ben inscatolato e visibile all'interno del punto vendita.
Nel secondo mondo le persone arrivano "ignoranti" e devono essere istruite su tutte le caratteristiche di quello che andranno ad acquistare: non possono toccare il prodotto, leggere quanto c'è scritto su una scatola o chiedere a un commesso.
Diciamocelo chiaramente: la vendita online è gestita in modo completamente diverso rispetto alla vendita al dettaglio.
Arricchimento dati
Il primo problema che ho dovuto risolvere è stato quello dell'arricchimento dati: non volevo sporcare le tabelle presenti all'interno di Moda con nuovi campi, per evitare di rendere non più aggiornabile il prodotto sul server aziendale.
Per quello ho scelto di realizzare una nuova struttura dati che utilizzasse solamente il codice univoco del prodotto, arricchito con nuovi dati maggiormente orientati al web.
Su questa struttura dati ho poi realizzato un piccolo gestionale in grado di censire le immagini scattate sui singoli prodotti ed arricchirle con le corrette descrizioni: famiglia, marca, modello e colore.
Chiaramente, maggiore era il lavoro di correzione del "gestionale web", maggiore era il tempo che trascorreva fra l'inserimento di un nuovo prodotto e la sua messa online.
Per tale motivo il primo passo è stato quello di istruire le persone addette all'inserimento dati in Moda, in modo avessero maggior cura nella compilazione delle parti descrittive del prodotto.
Una volta realizzata la gestione dei dati aggiuntivi eravamo pronti per la creazione dei flussi verso Wordpress.
Esportazione prodotti
Il secondo passo era quindi quello di aggiornare WooCommerce con i nuovi prodotti inseriti in SQL Server ed ora esportabili in CSV, tramite un programma che, ciclicamente, verificava aggiornamenti e produceva flussi dati.
Per questo compito è stato scelto WpAllImport, un apposito plugin di esportazione/importazione dati su Wordpress, che fosse compatibile con Woocommerce.
Tramite questo plugin la creazione di nuovi prodotti, il loro aggiornamento prezzi e giacenze è stato completamente automatizzato.
Sincronia delle immagini
Un aspetto importante dei software di e-commerce è quello di rappresentare al meglio i prodotti che si intende vendere. Quando si lavora nel fashion questo aspetto assume un ulteriore peso: presentare bene il prodotto è sicuramente un un motivo che può motivare l'acquisto.
Il modo più semplice per presentare bene i prodotti è quello di scattare delle ottime foto, pensate e nominate in modo "SEO", facilmente ricercabili e trovabili all'interno dei motori di ricerca.
Il fatto di avere delle immagini con nomi "SEO Friendly" cozzava però con la nomenclatura delle immagini che si era scelto di utilizzare, basata sul semplice codice prodotto.
Questo approccio facilitava il lavoro di chi doveva fotografare i prodotti all'interno del negozio, ma peggiorava di molto l'algoritmo di sincronizzazione fra il software di arricchimento e WordPress.
Per andare a risolvere questa integrazione ho realizzato un meccanismo di aggiornamento FTP, in grado di sincronizzare una cartella locale con una remota, anche in presenza di nomi di file differenti, ma riconducibili allo stesso prodotto.
L'effetto era quello di avere un programma che, mentre sincronizzava, ricomponeva un nome SEO friendly, usando parte delle descrizioni utilizzate nel prodotto.
Tutto bene?
Non proprio. All'inizio tutto è andato alla perfezione. In presenza di pochi prodotti il sito era velocissimo.
Col passare del tempo le prestazioni sono però miseramente degradate.
Non tanto per problemi di WordPress e WooCommerce, quanto per le prestazioni inaccettabili che si avevano durante le fasi di aggiornamento prezzi e giacenze.
Il sito contava ormai oltre 30.000 prodotti e aggiornare anche solo un centinaio di giacenze era una operazione che durava anche svariati minuti.
Lo stesso valeva per l'aggiornamento prezzi: fino a che gli aggiornamenti erano pochi, nessun problema, quando occorreva cambiare i prezzi di un intero fornitore, o peggio, quando iniziavano i periodi dei saldi, l'aggiornamento prezzi era assolutamente ingestibile.
La soluzione
Per riuscire ad accelerare questi aggiornamenti ho iniziato a studiare le strutture WordPress e WooCommerce, sia tramite la documentazione online, ma soprattutto tramite lo studio dei sorgenti dei due prodotti.
Dopo aver capito quali campi andavano modificati, per riuscire ad avere un aggiornamento atomico delle informazioni, mi sono permesso una modifica ad un paio di indici WordPress, non pensati per un uso massivo come nel nostro caso.
Fatto questo ho realizzato un plugin WordPress/WooCommerce in grado di assorbire un numero infinito di chiamate di aggiornamento, estremamente ottimizzato per questa problematica.
Il risultato è stato quello di riuscire ad aggiornare i prezzi e giacenze al ritmo di 1000 prodotti al secondo, dalle 4000 alle 6000 volte meglio dell'importazione tradizionale.
Risultato finale
Il risultato finale di questo lavoro è un sito realizzato con WordPress e Woocommerce, con oltre 30.000 prodotti per circa 6000 immagini, in continua espansione.
Il sistema comprende un meccanismo di travaso dei nuovi prodotti ed una sincronia di giacenze e prezzi, in grado di aggiornare l'intero archivio in meno di 30 secondi ed i singoli delta in meno di mezzo secondo.
Conclusioni
A volte non è facile far dialogare ambienti diversi e la soluzione perfetta per pochi dati non lo è quando i dati aumentano a dismisura.
Quando però tutto funziona le soddisfazioni iniziano ad arrivare ed è bello vedere un sistema orchestrato su prodotti diversi, funzionante come se fosse un unico corpo.