Il cliente o l’utente ha autonomia sulle parti che fanno realmente parte del suo lavoro quotidiano.
Portfolio · Come lavoro
La parte visibile è importante.
La parte visibile è importante.
Ma deve anche funzionare bene nel tempo.
Un sito, un gestionale o un programma possono sembrare progetti molto diversi. Il metodo però è lo stesso: capire come si lavora, costruire ciò che serve davvero e lasciare qualcosa che possa essere usato, mantenuto e fatto crescere.
Un progetto completoQuello che si vede e quello che deve funzionare dietro.
01Quello che si vedePagine e schermate devono essere chiare e piacevoli da usare.
02Come si lavoraRegole, passaggi e controlli devono seguire il lavoro reale delle persone.
03Le informazioniDati, contenuti e copie di sicurezza devono restare ordinati e protetti.
04Consegna e continuitàIl progetto deve poter essere aggiornato, spiegato e, quando possibile, trasferito altrove.
La parte visibile è l’interfaccia.
La parte importante è ciò che ci puoi fare.
La grafica deve essere curata e coerente, ma il valore del progetto sta soprattutto nella possibilità di usarlo, gestirlo, mantenerlo e farlo evolvere senza trasformare ogni modifica in un intervento sul codice.
Un’interfaccia mostra informazioni. Un’applicazione permette alle persone di lavorarci sopra.
Autonomia controllata
Gestibile, senza riempirlo di opzioni inutili.
Le parti modificabili vengono scelte in base alle attività reali. L’obiettivo è dare autonomia dove serve, senza costringere il cliente a imparare strumenti complessi che non userà.
Modificare dati, testi, immagini e informazioni previste dal progetto.
Gestire impostazioni e attività previste senza dover chiedere una modifica tecnica ogni volta.
Mostrare funzioni diverse a seconda di chi sta usando il sistema.
Proteggere le parti delicate che non devono essere modificate per errore.
Non tutto deve essere modificabile. Limitare le parti delicate rende il progetto più coerente e riduce il rischio di errori durante la gestione quotidiana.
Software consolidato
Non tutto ciò che ha molti anni
Non tutto ciò che ha molti anni
deve essere riscritto da zero.
Se un programma continua a essere usato dopo molti anni, spesso significa che la sua logica è solida e che contiene una parte importante del modo di lavorare dell’azienda. Il limite può essere l’ambiente in cui gira, non necessariamente il programma che c’è dentro.
Conservare ciò che funziona
Procedure, controlli, dati e abitudini operative possono avere più valore della tecnologia con cui sono nati. Prima di sostituirli, verifico cosa vale davvero la pena mantenere.
Togliere i limiti
Browser, mouse, finestre reali, utilizzo da più dispositivi e accessi contemporanei possono rendere più comodo un software esistente senza obbligare l’azienda a cambiare tutto nello stesso momento.
Evolvere per passi
Una volta ottenuta una base moderna e funzionante si può decidere con più calma se cambiare interfaccia, archivi o altre parti, affrontando ogni evoluzione solo quando porta un vantaggio concreto.
Harbour come ponte verso il web.
Per applicazioni nate con Clipper/xBase utilizzo anche Harbour: consente di recuperare molta della logica già collaudata e accompagnarla verso ambienti moderni e applicazioni web. È un approccio che uso quando permette di ridurre tempi, rischi e riscritture inutili.
Un progetto non dovrebbe obbligarti
a restare con chi lo ha sviluppato.
Quando il progetto lo consente, tengo separati il programma, i contenuti, il dominio, la posta e il server che lo ospita. In questo modo un cambio di fornitore non deve significare ricominciare da zero.
Il cliente resta proprietario delle proprie scelte.
Il cliente riceve ciò che serve per continuare a usare e mantenere il progetto. Se un domani cambia server o fornitore, l’obiettivo è poterlo spostare senza doverlo rifare.
Il dominio può restare al cliente, la posta può restare presso il suo fornitore e il sito può essere ospitato dove è più conveniente.
Server del cliente
Quando l’ambiente è compatibile, il progetto può essere installato sui server scelti dal cliente.
Server MB Studio
Se il cliente preferisce, il progetto può essere ospitato e gestito anche sull’infrastruttura MB Studio.
Trasferibile non significa “funziona ovunque senza controlli”. Il nuovo server deve essere adatto al progetto, ma non deve appartenere a un fornitore specifico.
Un’applicazione gestibile richiede anche una documentazione gestibile.
Una parte spesso trascurata nei progetti software è la documentazione. Nei miei progetti viene trattata come parte della soluzione, non come un allegato generico prodotto alla fine.
La stessa applicazione viene spiegata in modo diverso a chi deve svilupparla, a chi deve usarla e a chi deve gestirla professionalmente.
Architettura, file, dati, sicurezza, configurazione, deploy, manutenzione, riferimenti tecnici e punti di estensione.
Istruzioni semplici per svolgere attività e modifiche previste senza dover conoscere PHP, JSON o la struttura interna del progetto.
Una visione più gestionale: servizi attivi, privacy, dati da preservare, procedure di aggiornamento, responsabilità e controlli.
Consegna adattata al destinatario. Non un manuale unico per tutti, ma documenti e livelli di approfondimento coerenti con chi dovrà realmente usarli.
Gli strumenti cambiano.
Il criterio resta la semplicità.
Non parto dalla tecnologia. Scelgo gli strumenti in base al problema, a dove dovrà funzionare il progetto e a quanto dovrà essere semplice mantenerlo.
La tecnologia è un mezzo, non il titolo del progetto.
Un gestionale, un sito e un programma per uso interno possono richiedere strumenti diversi. Quello che conta è che la soluzione sia chiara, solida e adatta al lavoro che deve svolgere.
GlossarioParole tecniche,
Parole tecniche,
solo per chi vuole approfondire.
Non serve conoscere questi termini per capire i progetti. Li raccolgo qui, in forma semplice, quando può essere utile sapere cosa significano.
Apri glossarioChiudi glossario 23 voci · organizzate per argomento
Design e interfaccia
Termini relativi a ciò che l’utente vede e alle azioni proposte dall’interfaccia.
Call To Action: un comando o collegamento che propone un’azione precisa, come inviare una richiesta o aprire una funzione.
Visualizzazione ingrandita di immagini o contenuti sopra l’interfaccia corrente, senza perdere il contesto di navigazione.
Uso e comportamento
Concetti che descrivono come l’applicazione reagisce alle condizioni operative.
Il comportamento alternativo previsto quando una funzione o un servizio non è disponibile.
La parte amministrativa o applicativa che gestisce dati, configurazioni e operazioni non esposte nell’interfaccia pubblica.
Cross-Site Request Forgery: un tipo di attacco in cui un sito tenta di far eseguire a un utente autenticato un’azione non richiesta. Un token CSRF serve a verificare che la richiesta provenga realmente dal modulo previsto.
Un campo nascosto agli utenti ma visibile ai bot automatici. Se viene compilato, il sistema può riconoscere e bloccare con maggiore probabilità un invio indesiderato.
Sviluppo e modernizzazione
Parole che possono comparire quando si parla di software esistente e della sua evoluzione.
Un ambiente compatibile con il mondo Clipper/xBase che può aiutare a portare software esistente verso sistemi moderni, conservando quando conviene una parte importante della logica già sviluppata.
Un formato di archivio molto usato da applicazioni xBase e Clipper. In alcuni progetti può essere mantenuto durante la prima fase di modernizzazione per evitare una migrazione dei dati non ancora necessaria.
Un sistema dedicato alla gestione di basi dati. Può offrire vantaggi importanti, ma introdurlo richiede progettazione, migrazione e verifiche: per questo va scelto quando porta un beneficio concreto al progetto.
Gestione e contenuti
Termini relativi a configurazione, dati e strumenti di amministrazione.
Un sistema generalista di gestione dei contenuti. Nei progetti su misura preferisco esporre soltanto le funzioni amministrative realmente necessarie.
Formato leggero per strutturare e memorizzare dati e configurazioni quando è adatto al volume e alla natura del progetto.
Pubblicazione e infrastruttura
Server, installazione, trasferibilità e dipendenze dell’applicazione.
La pubblicazione tecnica dell’applicazione: file, configurazioni, permessi e controlli necessari nell’ambiente di destinazione.
Il server o servizio che ospita un’applicazione web. Può cambiare senza cambiare necessariamente l’applicazione.
Due web server molto diffusi. Possono richiedere configurazioni differenti pur ospitando la stessa applicazione PHP.
L’insieme delle tecnologie, dei linguaggi, dei componenti e dei servizi scelti per realizzare e far funzionare un’applicazione.
Il protocollo standard usato per l’invio della posta elettronica. Nel sito indica il servizio configurato per spedire in modo controllato i messaggi del modulo contatti.
La riscrittura degli URL richiesti dal browser verso percorsi o risorse interne dell’applicazione, utile per ottenere indirizzi più leggibili e instradare correttamente le richieste senza cambiare la struttura visibile all’utente.
In IIS è l’ambiente isolato in cui viene eseguita un’applicazione web, con processi, identità, permessi e impostazioni proprie.
Una situazione in cui il progetto rimane vincolato a un fornitore o infrastruttura specifica e diventa difficile trasferirlo altrove.
Visibilità e motori di ricerca
Termini relativi alla scoperta e all’indicizzazione delle pagine pubbliche.
Uniform Resource Locator: l’indirizzo con cui una risorsa web, per esempio una pagina, viene identificata e raggiunta dal browser.
Search Engine Optimization: insieme di attività tecniche e sui contenuti che aiutano i motori di ricerca a comprendere, indicizzare e presentare correttamente le pagine pubbliche.
File che elenca gli URL pubblici considerati rilevanti e aiuta i motori di ricerca a scoprirli.
La scansione automatica delle pagine effettuata dai crawler dei motori di ricerca.