Parlare di metodologie di lavoro in azienda è una cosa piuttosto complessa, soprattutto perché non è possibile generalizzare un modo di lavoro che sia universalmente valido. Sento sempre più persone dire “con SCRUM avrai risultati assicurati”. Lo trovo piuttosto riduttivo.
In sostanza, sempre più persone hanno tradotto i valori ed i princìpi promossi dal manifesto agile in una serie di “ricette” pronte da seguire fedelmente per ottenere buoni risultati. Cosa c’è di “agile” in tutto ciò? E’ come cucinare con un robot da cucina…
Ecco perché sono sempre più convinto che la vera ricetta del successo nei progetti sia qualcosa che si scopre “assaggiando” gli ingredienti che mettiamo nella ricetta (andrò avanti con la metafora della cucina, siete avvisati!).
L’adozione di strategie DevOps ha portato negli ultimi anni ad incrementare le aree coperte da tool di monitoring in maniera tale da avere un feedback in tempo reale dello stato dell’infrastruttura su cui si basa la propria applicazione, così da poter rispondere pro-attivamente a situazioni critiche. Su tale fronte infatti si sono visti comparire i tool più disparati che permettono la raccolta di informazioni, sia dei server o delle istanze su cui vengono eseguite le applicazioni (ad esempio CPU, memoria o disco), che le applicazioni stesse (ad esempio tempi medi di risposta, numero di query eseguite, tempo di esecuzione delle query, ecc. ecc.).
Definizione:
Il principio OPEN/CLOSE fa riferimento all’acronimo SOLID. introdotto da Michael Feathers che riporta alcune buone pratiche di programmazione ad oggetti ancora di forte attualità.
OPEN/CLOSE (la O dell’acronimo), nella sua definizione più generale indica che: un modulo (un oggetto, una classe o un gruppo di funzioni) debba essere aperto alle estensioni ma chiuso alle modifiche.
Questo principio tuttavia non è altro che la formalizzazione e il raggruppamento di concetti e linee guida già presenti da tempo nella programmazione ad oggetti.
Tra i molti strumenti utili presenti in Xcode, il testing framework XCTest è certamente uno dei più rilevanti, non solo per l’importanza intrinseca dello Unit Testing in generale, ma soprattutto per la facilità con la quale è possibile scrivere ed eseguire test direttamente dall’IDE out-of-the-box, senza la necessità di installare componenti di terze parti o impostare una particolare configurazione per i progetti.
In effetti Xcode, al momento della creazione di un nuovo progetto, oltre a creare un target per il binario principale crea automaticamente anche un target di test, cioè un bundle aggiuntivo che può essere caricato nel bundle principale per poter fisicamente eseguire i test una volta avviata l’app. Nell’immagine seguente è possibile vedere come, in un progetto appena creato, sia già presente il test bundle, in questo caso chiamato AwesomeAppTests.xctest:
Le ACL (Access Control List) sono un strumento molto potente per poter definire l’accesso a risorse con una granularità molto fine. Nel quotidiano abbiamo già modo di utilizzarle per definire i permessi per accedere a file su Unix o quali pacchetti far passare attraverso un firewall o ancora l’accesso a database.
In Symfony le ACL sono disponibili out-of-the-box nel caso di installazione completa e permettono la definizione delle regole di accesso a risorse tramite ruoli e maschere. Mentre i ruoli rappresentano dei sottoinsiemi degli utenti di una data applicazione (amministratori, backoffice, business analyst) e possono essere visti come delle etichette da assegnare ad un utente, le maschere sono la rappresentazione numerica delle azioni che possono essere effettuate dagli utenti aventi determinati ruoli. Per tornare all’esempio del filesystem Unix, i ruoli possono essere Owner, Group o Others mentre le maschere sono ad esempio 7 (lettura, scrittura e esecuzione) indicato per ciascun ruolo.
