Ovvero come abbiamo introdotto lo stack MAGNEVABBDDMP, il composite design pattern, la radio che manda sempre le stesse canzoni, i caffè della mattina, le pizze il giovedì.

Giusto poche settimane fa ci stavamo galvanizzando pensando a come siamo riusciti a fare la prima release di un MVP con un TTM record, considerando il numero di tools che abbiamo deciso di introdurre in one-go.

Abbiamo creato un CMS da zero dando un calcio nel sedere a tutti quei buoni consigli KISS, DRY e YAGNI e DRTW.

Facendo l’analisi del progetto abbiamo riconosciuto immediatamente le varie ed articolate esigenze editoriali. Esigenze che ci hanno portato naturalmente a ragionare per denominatori comuni e quindi ad un CBD.

La scelta del design pattern adatto è ricaduta facilmente sul Composite e sul Decorator. Sebbene quest’ultimo sia molto limitato per le features che avremmo voluto sviluppare, temporaneamente fa al caso nostro.

Abbiamo usato git e quindi ci serviva uno stile comune per la stesura del codice. Abbiamo deciso di adottare lo standard PSR per quanto riguarda PHP e le guidelines di Google per Javascript.

Usiamo editorconfig per portare le configurazioni sui diversi editor/IDE, dato che alcuni usano ViM, altri PHPStorm, altri Atom, altri ancora SublimeText.

Ah dimenticavo: Spaces non Tabs, fullstop.

Gestiamo il progetto con una configurazione multi-vms. Una macchina per mongo, una per il webserver, opportunamente configurate per sfruttare al meglio i pochi MB di memoria a disposizione. 1GB per il webserver, 512MB per l’istanza mongo.

MAGNEVABBDDMP (mongo, ansible, gulpjs, nginx, editorconfig, vagrant, aws, browserify, bem, docker, dokku, mustache, prerender)

MVP (minimal viable product)

TTM (time to market)

tools (strumenti software)

one-go (in una botta sola)

CMS (Content Management System)

KISS (Keep it simple stupid)

DRY (dont repeat yourself)

YAGNI (you ain’t gonna need it)

DRTW (don’t reinvent the wheel)

CBD (components based development)

features (funzionalità)