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.
Le specifiche PSR-7 descrivono una proposta di standardizzazione delle interfacce per i messaggi HTTP.
Come sappiamo, il protocollo HTTP, attraverso le specifiche redatte dal W3C, definisce una serie di regole di comunicazione che vengono implementate dalle applicazioni client e server che lo adottano.
A prima vista niente di nuovo sotto il Sole dunque, ma cerchiamo insieme di comprendere l’insieme di problematiche che sono al centro di questo nuovo dibattito che riguarda gli standard di codifica del linguaggio PHP.
Controllare il tasso di coverage dei test è un’attività frequente tra gli sviluppatori.
Numerosi sono i fattori che hanno reso il code coverage popolare:
- è una metrica facile da comprendere;
- si misura senza difficoltà;
- è oggettiva e imparziale;
- è universale (applicabile a tutti i paradigmi di programmazione).
Ma al di là di questi vantaggi, possiamo affermare che una test suite con un’alta percentuale di coverage sia realmente efficace?
Quando un test è efficace?
Una test suite è considerata efficace se consente di rilevare una grande quantità di failure; d’altronde, ciò è proprio la finalità ultima del software testing.
La massima efficacia è realizzabile solo applicando testing esaustivo ma, siccome ciò è spesso impraticabile, ci si accontenta di test più semplici con un’efficacia inferiore.
È importante notare che, a differenza del coverage, il livello d’efficacia viene stabilito soggettivamente dallo sviluppatore.
A ben più di uno sviluppatore sarà capitato di incappare nel comune errore MySQL server has gone away!, magari seguito da un eccezione lanciata da una delle classi PDO, come ad esempio PDOStatement::execute(): Error reading result set’s header.
Nella maggior parte dei casi, quando questo avviene in ambiente PHP, siamo connessi in maniera persistente (per fortuna!) ed a causa di una esecuzione troppo lunga, la connessione col server MySQL va in timeout. Lunghi tasks in batch, chiamate a ws non particolarmente rapidi, carichi elevati del server, sono alcuni degli scenari possibili.
Gli operatori ternari sono diffusi in molti linguaggi di programmazione e permettono di esprimire con una sintassi breve logiche condizionali. Per utilizzarli propriamente in PHP è però necessario conoscerne il comportamento.
Vediamo un esempio
var_dump(true ? 'a' : 'b' ? 'c' : 'd'); // OUTPUT: string(1) "c"
Se state pensando che il risultato di questa espressione sia ovvio, vediamo cosa succede ad esempio in javascript
console.log(true ? 'a' : 'b' ? 'c' : 'd'); // OUTPUT: a
Bene, mentre in PHP il risultato è dato da:
- true è vero, ritorna a
- a castato a bool è vero, stampa c
In javascript invece il ragionamento è diverso:
