Come ottenere un prodotto digitale di qualità evitando i problemi dei contratti a corpo

Alcuni clienti preferiscono ricevere offerte a corpo dai loro fornitori, nella convinzione di poter rimuovere l’incertezza in termini di costo, tempistiche e funzionalità dei progetti. I clienti sono soddisfatti nel pensare di poter mantenere il controllo su questi aspetti, senza tuttavia rendersi conto che così facendo perdono il controllo sulla qualità.

Cosa ci vuole per realizzare un prodotto digitale di alta qualità? Innanzitutto, i prodotti migliori sono il risultato di uno sforzo collaborativo tra cliente e fornitore poiché è necessaria l’esperienza di entrambi. Inoltre, è indispensabile poter adattare un progetto agli inevitabili cambiamenti che ci saranno in corso d’opera, come avviene e come in realtà deve essere in un prodotto digitale.

Non è necessario che tutte le funzionalità siano completamente definite all’inizio del progetto, che è il momento in cui quest’ultimo è meno conosciuto: sia il cliente che il fornitore sono nella posizione di poterle dettagliare meglio solo man mano che passa il tempo.

Continua a leggere

Come evitare i tre errori più comuni nella progettazione di un prodotto digitale

Navigando molti siti e applicazioni web, l’esperienza è spesso poco piacevole: alcune volte l’interfaccia è poco intuitiva o troppo pesante, l’aspetto è sgradevole, l’applicazione non risponde come dovrebbe o è lenta in modo frustrante. Anche se di solito gli utenti non sono in grado di indicare uno specifico problema, si rendono conto lo stesso che qualcosa non funziona nel modo migliore e non tornano più.

Anche uno solo di questi problemi può far sprofondare il tuo prodotto, ed è necessaria una grande capacità su tutti questi fronti per realizzare qualcosa di veramente speciale. E’ per questo motivo che un’attenzione quasi fastidiosa ai dettagli del design, dell’esperienza utente, dell’architettura dell’informazione, della tecnologia e dell’infrastruttura è fondamentale per il successo dei progetti dei nostri clienti.

Continua a leggere

Git Flow – Un modello di branching per git che funziona

Continua a leggere

Come gestire ambienti di sviluppo e produzione con AngularJS

Una prassi comune lavorando nel mondo server-side è definire diversi ambienti di esecuzione e di deploy per le proprie applicazioni. Solitamente troviamo almeno un ambiente dedicato allo sviluppo ed un altro che rappresenta l’ambiente di produzione. I vari ambienti si differenziano utilizzando diversi valori per parametri comuni quali le credenziali di accesso al database, l’attivazione degli strumenti di log, il modello di autenticazione, ecc.

Uno dei primi ostacoli che si incontrano lavorando con un framework client-side come AngularJS è quello di trovare un meccanismo per poter differenziare l’ambiente di esecuzione della propria applicazione senza poter contare sugli strumenti abituali disponibili lato server.

In questo articolo mostreremo una possibile soluzione realizzata collaborando assieme a PhotoSì e Fabio Masini basata sulla riscrittura dei nostri file sorgenti tramite task Grunt che valorizza determinate variabili JavaScript a seconda che si voglia eseguire la nostra applicazione in un ambiente di sviluppo o in un ambiente test.

In particolare vedremo come utilizzare diversi endpoint REST a seconda dell’ambiente di esecuzione che vogliamo utilizzare.

Continua a leggere

Il PHP 7 diventa severo

Come tutti sappiamo PHP è stato concepito come linguaggio a tipizzazione dinamica: visto da una parte dello scenario come pro, dall’altra come contro.

Nonostante l’esistenza di diversi linguaggi con tale caratteristica quest’ultima è stata per diverso tempo motivo di critica. E’ chiaro che lo sviluppo con certi linguaggi aiuta a scrivere codice più pulito, ma di certo è difficile affermare che la tipizzazione dinamica sfoci in codice spazzatura.

Così come le critiche a PHP spesso sono incomplete o riferite a codice deprecato, così accade per la tipizzazione; per esempio PHP ha e ha avuto per diverso tempo diverse modalità per trattare con i tipi ed è possibile garantire che uno specifico tipo venga utilizzato in uno specifico punto del codice.

Anche il type hinting è stato utilizzato per molto tempo, anche se in modo incompleto.

Con PHP7 sarà possibile far sì che le funzioni e i metodi accettino parametri di determinati tipi.

Andiamo più nello specifico: i principali RFC del nuovo PHP7 sono fondamentalmente tre:

  1. Type hinting scalare;
  2. Dichiarazione di tipi di ritorno;
  3. Gestione delle eccezioni.

Continua a leggere