Portale per la promozione territoriale di attività di consulenza.
Un progetto che mi rende particolarmente orgoglioso per il fatto che l’ho concepito imprenditorialmente e sviluppato tecnicamente da solo e da autodidatta in un epoca in cui internet, per come lo conosciamo ora, esisteva da poco più di una decina di anni.
Una storia piccola, rispetto a realtà che, nello stesso periodo, hanno fatto numeri decisamente maggiori. Ma una storia completa che va dall’idea, alla realizzazione, alla monetizzazione, fino alla vendita, intervenuta nel 2019.
Insomma, un piccolo passo per l’umanità ma un giant step per il sottoscritto.
Nel 2005 registrai il dominio AttestazioneSOA.it con l’intenzione di pubblicizzare la mia attività di tecnico/commerciale nell’ambito dell’Attestazione SOA, cioè la certificazione delle imprese del settore delle costruzioni obbligatoria per l’esecuzione di opere pubbliche.
Realizzai un portale informativo, scarno nella grafica e prettamente destinato a fornire un quadro esaustivo sull’argomento, e lo indicizzai con una grande attenzione alla SEO (per quelle che erano le regole del momento). Il portale è ancora online e tuttora saldamente in prima posizione su Google per tutte le principali ricerche in tema di Attestazione SOA.
Il risultato fu sorprendentemente positivo: registravo migliaia di visualizzazioni mensili (erano moltissime per un argomento così di nicchia) e arrivavano richieste di contatto da ogni parte di Italia, per le quali, mi resi subito conto, non ero sufficientemente strutturato.
Mi sembrò una buona idea (e oggi posso assolutamente confermare che lo fu) offrire, dietro compenso, la possibilità ai miei competitor di promuovere la propria attività nelle province in cui operavano, tenendomi l’esclusiva delle sole province in cui operava la mia società (cioè, di fatto, io).
Realizzai un tema WordPress ad hoc, nel quale inserii anche tutte quelle funzionalità che consentivano ai consulenti di registrarsi autonomamente e predisporre le proprie inserzioni, definendo le province di pertinenza e controllandone i risultati. Mi sembrò sensato creare un sistema di addebito dei costi di inserzione collegato al numero di visualizzazioni registrate, avendo cura che l’addebito intervenisse solo alla prima visualizzazione (lo stesso visitatore non generava più addebiti se consultava più volte le inserzioni, anche su più province).
Fu quindi necessario predisporre anche un sistema di pagamento di ricariche e lo creai utilizzando PayPal come gateway di pagamento. Diedi poi la possibilità ai consulenti di differenziare la propria inserzione in base alla provincia (utile, per esempio, per consulenti con più sedi a livello nazionale) e mettere comodamente online/offline l’inserzione su ciascuna provincia, con un semplice switch.
Visto il successo dell’iniziativa, creai il portale gemello CertificazioneAziendale.it dedicato alla certificazione di sistemi qualità; con un flag nel pannello di controllo di AttestazioneSOA.it il consulente poteva decidere di comparire, gratuitamente, anche su CertificazioneAziendale.it nelle stesse province opzionate su AttestazioneSOA.it.
Elaborai anche un sistema per cui il consulente potesse assicurarsi la possibilità di comparire in prima posizione nei risultati di ricerca rispetto ad altri consulenti presenti nella medesima provincia e dietro pagamento di una fee di visualizzazione più alta rispetto a quella che garantiva unicamente la presenza nella provincia.
Realizzai anche una sezione del pannello di controllo nel quale il consulente potesse verificare da quali città (e IP) provenivano le viste che gli avevano procurato l’addebito di una fee e tutte le ulteriori visite dello stesso potenziale cliente che non avevano generato un costo.
Misi in piedi anche un sistema di notifica che avvisava il consulente che il proprio credito era in esaurimento, ma realizzai anche un’ulteriore funzionalità che, a credito esaurito, invogliava il consulente a ricaricare quando la provincia in cui la sua inserzione non era più visibile (a causa del credito esaurito o del fatto che fosse stata spontaneamente messa offline) registrava un tot numero di visite.
La versione attualmente online risale al 2010; la proprietà ha fatto capo a Sviluppo Europa (la mia S.r.l.) fino al 2019, poi il portale è stato venduto a due dei consulenti che, per anni, avevano rinnovato la loro presenza online.
CRM per l'organizzazione dei dati degli iscritti a una fondazione milanese.
È stato il primo vero progetto (retribuito) che ho realizzato da freelance nel periodo in cui avevo deciso di chiudere il capitolo con l’attività da consulente e prima di diventare dipendente di una software house.
Ne vado molto fiero per due aspetti: il primo è che l’ho scritto in codice puro, senza uso di framework, il secondo è che l’ho curato, anche graficamente, nei minimi particolari.
Attualmente è ancora utilizzato dal cliente.
La richiesta iniziale era di poter far confluire in un unico ambiente le liste degli iscritti a una Fondazione milanese che provenivano da fonti eterogenee (l’accreditamento al foyer, i soggetti che si registrano alla Wi-Fi, gli accessi alla sala lettura, i contatti ricevuti via form e altre ancora).
L’obiettivo era di poter filtrare i dati secondo criteri differenti rispetto alla loro provenienza per poter estrarre liste personalizzate ed effettuare comunicazioni mirate tramite un servizio di newsletter esterno alla piattaforma.
Il progetto era interessante, il cliente era importante e io avevo l’entusiasmo di chi poteva finalmente mettere a reddito una passione che lo aveva accompagnato negli ultimi anni.
Ero stimolato dal fatto di poter dare un’impronta originale anche dal punto di vista estetico e fare sì che la grafica si adattasse al cliente e non viceversa, come spesso accade.
Scrissi il mio personalissimo framework, inconsapevolmente ispirato a bootstrap: definii una serie di classi che mi permisero di costruire graficamente gli elementi in modo semplice e intuitivo, nonché di consentire una perfetta fruizione della piattaforma anche da smartphone. E devo dire che il risultato è oggettivamente piacevole.
Anche in termini strutturali, credo di essere riuscito a mantenere il CRM il più ordinato e pulito possibile, senza compromessi sull’usabilità.
Pensai che fosse utile fare in modo che qualunque contatto immesso nel CRM avesse una password per accedere al proprio profilo e gestire le proprie preferenze, al fine di garantire a chiunque di ricevere solo le comunicazioni per lui realmente interessanti.
Si impose poi la necessità di gestire anche gli eventi a cui i contatti avessero preso parte, nonché di estendere il numero e la tipologia di filtri utilizzabili per effettuare le estrazioni. Con essi arrivò anche la richiesta di poter definire tipologie di contatti (partner, visitatori, fornitori, etc.), professioni (con relativi ruoli) e altri elementi funzionali a una profilazioni più efficiente.
Si concretizzò anche la necessità di gestire accessi al CRM con criteri gerarchici: una tipologia di utenza che potesse effettuare unicamente la consultazione, un’altra che potesse importare dati (da CSV) e una terza che avesse facoltà di operare liberamente e un’ultima, quella del titolare del dato, che potesse operare solo sulle proprie informazioni.
Intendiamoci: so di non avere scritto un programma di calcolo delle rotte spaziali per la Nasa, ma ne sono comunque fiero, anche perché era la dimostrazione che ero riuscito a trasformare una passione in un lavoro e che in quel lavoro riuscivo anche a metterci un entusiasmo decisamente maggiore rispetto ad ogni lavoro fatto in precedenza.
Sistema di trading automatizzato di criptovalute.
Sono molto orgoglioso anche di questo progetto, anche se non si è (ancora) dimostrato vincente, nonostante le interessanti premesse.
Mi ha insegnato cosa sia l’overfitting, ovvero l’errore di basare una funzionalità di automatizzazione esclusivamente o eccessivamente sui dati su cui la si concepisce e addestra.
Sì, ok, l’argomento è un po’ inflazionato. Credo che chiunque si intenda un po’ di codice abbia provato o pensato di provare a realizzarne uno, nell’illusione di vedere crescere il proprio capitale senza fare nulla.
Io, lo ammetto, avevo un po’ la stessa ambizione, ma ero anche animato da due stimoli più nobili: cimentarmi in qualcosa di nuovo, che potesse darmi qualche conoscenza tecnica in più (raramente mi ero imbattuto in progetti di interazione tramite API), nonché mettere in pratica una mia personalissima teoria di trading che mi frullava in testa da un po’ e che volevo capire se fosse un’idea geniale o una cazzata immane. Al momento la storia sancisce impietosamente questo secondo esito, per cui no, non sarò io il Warren Buffet del nuovo millennio.
Nel 2017, quando ricevetti l’offerta di assunzione da DkR, seppi che uno dei soci era attivo proprio nello sviluppo di un sistema di trading automatizzato di criptovalute. Fino ad allora non mie ero mai interessato di Bitcoin e compagnia bella, ma era un po’ che ragionavo su come poter delegare la gestione di un portafoglio azionario a un algoritmo di trading e, come detto sopra, ero convinto di poter applicare una teoria che si sarebbe potuta rivelare geniale se non altro per l’elementare principio su cui si basa. Per cui seguii con avidità gli sviluppi del progetto che purtroppo, pochi mesi più tardi, venne abbandonato.
Decisi allora di provare a creare il mio personale sistema di trading. Per sommi capi, il sistema opera nel seguente modo. Il server lancia ogni minuto l’esecuzione di una serie di funzioni che interagiscono, tramite API, con un noto Exchange di criptovalute e:
- acquisiscono il valore attuale di cinque criptovalute
- calcolano lo scostamento del valore attuale rispetto a determinati momenti del passato, da due minuti a due ore fa
- in base a una serie di regole, decidono se è un buon momento per acquistare, vendere o mediare
- inviano l’ordine all’exchange e ne verificano il completamento
Lato test, il sistema consente di lanciare delle simulazioni basate su andamenti storici utili a validare la bontà delle regole di acquisto, vendita e mediazione.
In un primo momento i risultati non sembrano essere sorprendenti, per cui applico una logica che chiunque sconsiglierebbe in modo categorico, ma io mi ci intestardisco e decido di implementarla comunque. Applico il raddoppio della posizione a ribasso, fino a cinque volte. In pratica investo 1, poi compro altre 2 quando perdo X, poi compro altre 6 quando perdo Y e così via, per cinque volte.
Qui la sorpresa. I test restituiscono il 100% di operazioni positive, con un potenziale guadagno di tutto rispetto. Applico un po’ di fine tuning, verifico quanto le regole che ho studiato siano attendibili su tutte e cinque le criptovalute e il risultato non cambia: 100% di vendite in positivo e guadagno percentuale a due cifre.
Decido di passare all’azione; spengo la sandbox a mi sposto sul trading vero e proprio. Per alcuni mesi l’andamento è esattamente quello dei test e il guadagno si attesta sul 20% annuo, poi il crollo totale del mercato con Bitcoin che, in sei mesi, passa da 60.000 a 15.000 euro, quindi registra una perdita del 75%. Parallelamente i primi Exchange iniziano a saltare e la cronaca inizia e riportare notizie inquietanti su gestioni piuttosto allegre di Exchange anche blasonati.
Per farla corta, mi sale il panico all’idea di perdere anche quel 50% del capitale che mi era rimasto e così decido di chiudere tutte le posizioni, ovviamente registrando una perdita significativa.
Di lì a poco, le criptovalute si riprendono leggermente e l’Exchange su cui baso il trading non va a gambe all’aria. Se avessi tenuto duro, avrei limitato le perdite, ma del senno di poi sono piene le fosse.
Comunque non mi sono ancora arreso e, per il momento, vado avanti a raccogliere i valori in tempo reale e calcolare gli scostamenti delle stesse cinque criptovalute.
Warren Buffet, trema.
Interruttori wi-fi comandati da un'applicazione custom
Quest’ultimo progetto non ha mai ufficialmente visto la luce, ma ne parlo volentieri perché è tra i progetti che catturano di più l’interesse del mio interlocutore, quando lo racconto.
Il tutto parte da un’esigenza elementare: i sensori di umidità comunicano unicamente se di recente ha piovuto, non se a breve pioverà.
Ho iniziato a utilizzare interruttori Wi-Fi più per necessità che per vezzo.
In giardino arrivava un solo cavo elettrico controllabile dal centralino e non c’era la possibilità di tirarne un secondo, ma io avevo necessità di controllare due elementi distinti: i lampioni e l’irrigazione.
Mi affidai a due interruttori Wi-Fi Shelly e acquistai una elettrovalvola a 220v. Tutto perfetto, controllavo entrambi gli elementi con l’Applicazione mobile Shelly, ma si presentò immediatamente un’esigenza specifica: come fare in modo che gli orari di esercizio si adattassero alle condizioni meteo?
Per l’irrigazione avrei potuto inserire un sensore di umidità nella catena, ma se la pioggia fosse arrivata dopo l’orario previsto per l’irrigazione? Per l’illuminazione avrei potuto acquistare un sensore crepuscolare, ma che gusto ci sarebbe stato?
Insomma, la faccio breve. L’idea era di realizzare un semplice script che ogni 5 minuti andasse a interrogare OpenWeatherMap, ad acquisire e a interpretare le condizione meteorologiche, in modo tale da:
- anticipare l’accensione dei lampioni, quando le condizioni metereologiche segnalavano nuvole, pioggia o nebbia (Shelly mi consente di utilizzare il tramonto come parametro, ma non offre variabili connesse alle condizioni meteo)
- saltare l’irrigazione notturna quando la combinazione tra pioggia (passata o in arrivo) e temperatura lo consentisse
Già che c’ero, ho pensato che potesse essere una buona idea tracciare anche la posizione degli smartphone di tutti i componenti della famiglia, per avere notizia del fatto che:
- in casa ci fosse qualcuno o meno
- uno dei componenti della famiglia si stesse avvicinando a casa o allontanando da casa
Quanto sopra mi sarebbe tornato utile in un secondo momento, cioè nel momento in cui avrei affidato a Shelly anche il comando della caldaia. L’idea era di spegnerla nel momento in cui veniva rilevato che tutti i membri della famiglia fossero in allontanamento dalla casa (oppure fermi a una distanza congrua) e di riaccenderla nel momento in cui un componente della famiglia si stesse avvicinando a casa.
Come ulteriore scenario, sarebbe stato possibile regolare automaticamente la temperatura della caldaia in base al membro della famiglia presente in casa o di ritorno verso essa.
Per il tracciamento degli smartphone mi è venuto in soccorso il mio collega Alessandro, detto il Capitano, con una micro applicazione mobile che funzionava in modo ineccepibile.
Quando tutto l’ambiente era pronto, la parte più divertente, se vogliamo, è stata di definire tutte le regole utili a gestire le varie casistiche: di quanto anticipare l’accensione dei lampioni in presenza di una determinata percentuale di nuvole o di nebbia? Che temperatura esterna doveva esserci per ritardare l’irrigazione del giardino quando due giorni prima aveva abbondantemente piovuto? A che distanza da casa si poteva spegnere la caldaia e come definire se uno dei membri stesse realmente andando a casa, piuttosto che a trovare un’amico che vive nel circondario?
Mi ci sono scervellato un po’, fino ad arrivare ad avere qualcosa di stabile e soddisfacente; poi però si poneva il problema di creare un’interfaccia grafica e, perché no, tradurre il tutto in una applicazione mobile. Quindi il grosso del lavoro era ancora da realizzare e tempo a disposizione ne avevo sempre meno.
Il risultato è che tutto l’impianto è ancora lì, perfettamente funzionante ma temporaneamente parcheggiato.
Nel frattempo mi è scappata la mano con gli interruttori Wi-Fi e ora comando la tenda da sole, l’accensione e lo spegnimento di alcuni apparecchi della casa, svariate luci, il tutto anche attraverso Echo di Alexa.
Però i lampioni si accendono sempre troppo tardi, quando piove.