Ho qualche dubbio sull’opportunità di pubblicare sullo store ufficiale … dovrei informarmi su burocrazia e costi.

L’Aero Club d’Italia (AECI) mette a disposizione un’applicazione desktop per simulare l’esame di conseguimento dell’attestato VDS (Volo da Diporto o Sportivo). Utile, certo – ma decisamente più comodo avere qualcosa in tasca, da usare anche lontano dalla scrivania. Non a caso esistono già alcune app per smartphone, tutte però a pagamento.

Ho voluto quindi fare un esperimento: quanto tempo ci vuole per replicare le funzionalità dell’app di AECI in formato mobile, usando un modello AI gratuito come strumento di sviluppo?

Il risultato

In circa una giornata di lavoro ho ottenuto un prototipo sostanzialmente funzionante. Lo strumento usato? Qwen 3 Plus, recentemente disponibile gratuitamente su OpenRouter, abbinato a Claude Code.

La qualità del modello è evidente: rispetto a Nemotron 3 Super rappresenta un netto passo avanti in termini di comprensione del contesto e qualità del codice generato. Poterlo usare gratuitamente sembra quasi troppo bello per essere vero – e probabilmente questa finestra non durerà a lungo. Consiglio di sfruttarla finché c’è.

Prova l’app (è open source)

Il codice è disponibile su GitHub: github.com/b0sh-net/vdsexamapp

Chiunque voglia provarla, migliorarla o creare opere derivate è il benvenuto. Il progetto è aperto a contributi e modifiche di ogni tipo.

Ho voluto quindi riprovare con Nemotron-Cascade-2, ma le sue richieste hardware si sono rivelate eccessive per la mia macchina. Incuriosito comunque dall’ecosistema di modelli NVIDIA, ho scoperto che Nemotron 3 Super è disponibile gratuitamente su OpenRouter — e ho deciso di metterlo alla prova con lo stesso compito.

Quasi 21 milioni di token dopo, e con una spesa effettiva di 0$, l’applicazione non è ancora priva di bug. Eppure, in qualche modo, sembra più vicina a qualcosa di concreto rispetto a quanto ottenuto con Qwen3.5. Il dettaglio più incoraggiante? Non si è ancora bloccato su un errore irrisolvibile. Con qualche altra sessione di test e qualche milione di token in più, potrebbe davvero riuscire a chiudere il lavoro.

Resta però evidente una cosa: siamo ancora molto lontani dall’idea romantica di “mi faccio un’app semplice, senza scrivere una riga di codice, in pochi minuti”. Forse ci proverò anche con Claude Sonnet, se mi avanza qualche credito a fine mese.

Il progetto è pubblico: puoi scaricarlo e testarlo sul repository GitHub.

L’impressione è che sì, si possa fare. Il modello configura tutto, scarica i framework, e dietro mio suggerimento si costruisce una lista di task da completare uno alla volta. Gli chiedo poi di riverificare il lavoro svolto, e in circa un quarto d’ora l’applicazione è pronta. In teoria.

Gli chiedo di riverificare tutto…

Il problema? Ha usato una versione del framework non ancora compatibile con Expo Go per i test diretti sul telefono. Da lì è partita una serie infinita di prompt di debug per abbassare la versione e aggiornare tutte le API interne, apparentemente diverse tra una release e l’altra.

Il risultato rimane comunque notevole, soprattutto considerando che tutto è generato da un modello da soli 9 miliardi di parametri, che gira su una scheda video nata per i videogiochi e tutt’altro che all’ultimo grido. Forse se non lo avessi forzato a passare dalla versione 55 alla 54 di React Native me la sarei cavata con meno litigi. Ma il limite vero sembra essere sempre lo stesso: la rifinitura del codice generato. O funziona subito, oppure ci vuole dieci volte il tempo che si impiegherebbe a scriverlo a mano.

Come piccolo aiuto ho agganciato Context7 come MCP server, per evitargli di allucinare le API dei framework — ma con successo solo parziale.

Questa guida documenta il processo completo per configurare correttamente l’inoltro da un dominio custom gestito con Postfix e Webmin verso Gmail, risolvendo i problemi di autenticazione SPF/DKIM che causano il blocco con errore 550 5.7.26.

Il problema: Gmail rifiuta le email inoltrate

Attivando l’inoltro automatico dal proprio server di posta verso Gmail, si riceve quasi immediatamente un bounce con questo errore:

text550-5.7.26 Your email has been blocked because the sender is unauthenticated.
Gmail requires all senders to authenticate with either SPF or DKIM.
DKIM = did not pass
SPF [dominio-originale.com] with ip: [IP-del-tuo-server] = did not pass

La causa è strutturale: quando il server di posta inoltra un messaggio, il mittente nell’envelope (Return-Path) rimane quello originale (es. mittente@dominio-esterno.com), ma l’IP che effettua la consegna è quello del tuo server. Gmail verifica l’SPF del dominio originale contro l’IP del tuo server — e ovviamente fallisce, perché il tuo server non è autorizzato a inviare per conto di domini terzi.

La soluzione: SRS + SPF sul dominio di inoltro

La soluzione completa richiede tre interventi:

1. SRS (Sender Rewriting Scheme) — riscrive il mittente envelope usando il tuo dominio
2. Record SPF sul tuo dominio che autorizzi il tuo IP
3. Record DMARC per migliorare la reputazione del dominio

Step 1: installare e configurare postsrsd

SRS è un meccanismo che riscrive l’indirizzo mittente nell’envelope da mittente@dominio-esterno.com a SRS0=HASH=TT=dominio-esterno.com=mittente@tuo-dominio.com. In questo modo Gmail verifica l’SPF contro il tuo dominio, che puoi controllare.

Installa il demone postsrsd:

bashapt install postsrsd

Durante l’installazione specifica il tuo dominio (es. tuodominio.com). Il file di configurazione si trova in /etc/default/postsrsd. Verifica che i parametri principali siano corretti:

textSRS_DOMAIN=tuodominio.com
SRS_EXCLUDE_DOMAINS=tuodominio.com
SRS_SECRET=/etc/postsrsd.secret

Verifica che postsrsd sia in ascolto sulle porte corrette:

bashss -tlnp | grep postsrsd
# Output atteso:
# LISTEN 0 10 127.0.0.1:10001 ...
# LISTEN 0 10 127.0.0.1:10002 ...

Step 2: configurare Postfix per usare SRS

Aggiungi queste direttive a /etc/postfix/main.cf (in Webmin: Servers → Postfix Mail Server → Edit Config Files):

textsender_canonical_maps = tcp:127.0.0.1:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:127.0.0.1:10002
recipient_canonical_classes = envelope_recipient,header_recipient

Riavvia i servizi:

bashsystemctl restart postsrsd && postfix reload

Step 3: configurare il forwarding in virtual_alias_maps

Il forwarding non deve essere gestito tramite ~/.forward dell’utente locale, perché quel meccanismo bypassa la sender_canonical_map e quindi SRS non viene applicato. La configurazione corretta va in /etc/postfix/virtual.

Per mantenere la consegna locale e inoltrare a Gmail simultaneamente, usa la sintassi multi-destinatario:

textutente@tuodominio.com    utente-locale, destinatario@gmail.com

Aggiorna la mappa e ricarica:

bashpostmap /etc/postfix/virtual
postfix reload

Step 4: aggiungere il record SPF

Se non è già presente, aggiungi un record TXT SPF sul dominio radice (@) nel DNS:

textv=spf1 ip4:IP-DEL-TUO-SERVER mx ~all

Verifica la propagazione con:

bashdig TXT tuodominio.com +short

Step 5: aggiungere il record DMARC

Aggiungi un record TXT per _dmarc.tuodominio.com:

textv=DMARC1; p=none; rua=mailto:admin@tuodominio.com

Il valore p=none abilita la modalità di solo monitoraggio: non blocca nulla, ma comunica a Gmail che il dominio ha una policy DMARC, migliorando la reputazione nel tempo.

Verifica finale

Invia una mail di test verso l’indirizzo che punta al tuo server e controlla i log:

bashjournalctl -u postfix --since "5 minutes ago" | grep -E "gmail|SRS|status"

Nei log di postsrsd dovresti vedere la riscrittura SRS:

textpostsrsd: srs_forward: <mittente@dominio-esterno.com> rewritten as <SRS0=HASH=TT=dominio-esterno.com=mittente@tuodominio.com>

Nei log di Postfix dovresti vedere la consegna andata a buon fine:

textstatus=sent (250 2.0.0 OK ... gsmtp)

Conclusione

La dismissione del POP3 fetch di Gmail costringe a un setup più corretto e moderno, che in realtà è anche più robusto: SRS + SPF + DKIM + DMARC è la configurazione raccomandata per qualsiasi server di posta che faccia forwarding verso provider che applicano strict authentication come Gmail. Una volta configurato, il sistema è completamente trasparente e non richiede manutenzione.

Cosa succede davvero in azienda

Uno studio recente su circa 200 dipendenti di una tech company ha mostrato che l’uso di strumenti generativi non ha tagliato ore o task, ma ha aumentato il ritmo, il numero di attività e il tempo complessivo speso al lavoro. Invece di sostituire compiti, l’AI li ha moltiplicati: chi prima delegava o rinunciava a certe attività ora le avvia da solo, spesso in parallelo, perché “tanto è facile”.

Il paradosso dell’efficienza

L’illusione è che, se un’attività richiede meno sforzo, si può fare di più senza problemi. In realtà, la somma di tanti piccoli compiti “semplificati” crea un flusso continuo di lavoro che aumenta la fatica cognitiva e il rischio di burnout. Il problema è che questo carico è spesso invisibile: non è un nuovo progetto ufficiale, ma una serie di micro‑attività auto‑generate, alimentate dall’entusiasmo iniziale per la sperimentazione con l’AI.

Perché serve una progettazione intenzionale

Se non si ridefiniscono ruoli, flussi e aspettative, l’AI diventa un acceleratore silenzioso di pressione, non uno strumento di liberazione. Per chi lavora con tecnologia e software, la lezione è chiara: non basta integrare modelli e tool; bisogna decidere cosa smettere di fare, quali decisioni restano umane e quali processi devono sparire, non solo diventare più veloci.

Questo post prende spunto dall’articolo “AI Doesn’t Reduce Work—It Intensifies It” pubblicato su Harvard Business Review nel febbraio 2026.

Nei primi tentativi ho seguito la strada più logica: scaricare un modello da Hugging Face e inserirlo nella cartella condivisa di Home Assistant. Ho creato via SSH la directory /share/piper e ci ho copiato i due file necessari del modello (il .onnx e il relativo .onnx.json).

All’inizio Piper non partiva nemmeno: dai log compariva un errore esplicito VoiceNotFoundError: giorgio. Il motivo era banale ma insidioso: avevo il file di configurazione col nome sbagliato (es. giorgio.json invece di giorgio.onnx.json). Dopo aver rinominato correttamente il file, l’add-on ha ripreso ad avviarsi senza errori.​

Il problema vero è arrivato dopo: la voce “Giorgio” non compariva in nessuna lista, né nella configurazione dell’add-on, né nella selezione della voce dell’assistente vocale (pipeline). Ho provato anche a rinominare i file con uno schema più “standard” (tipo it_IT-giorgio-…), riavvii e reload dell’integrazione, ma niente.​

A quel punto ho capito il limite: l’elenco delle voci mostrato nell’interfaccia dipende dal catalogo voices.json, che l’add-on scarica automaticamente e aggiorna all’avvio (nei log si vede il download e il salvataggio in /data/voices.json). Quindi sì, potrei entrare nel container e modificarlo, ma dovrei poi bloccare o gestire gli aggiornamenti (o accettare che le modifiche vengano sovrascritte). Troppo rischio e troppa manutenzione per un “semplice” cambio voce.​

Morale: voce custom ok per esperimenti, ma per una configurazione stabile dell’assistente vocale ho preferito restare su voci ufficialmente supportate dal catalogo

Strumenti utilizzati

• Hardware: Anker PowerConf (speaker + microfono USB), Raspberry Pi (HA OS 2026.2.1).
• Software:
  • Assist Microphone (add-on principale per input/output audio).
  • openWakeWord (wake word “Hey raspy”).
  • Wyoming Faster Whisper (STT locale).
  • Piper TTS (“Riccardo low”).

Config Assist Microphone finale:​

textsound_enabled: true
noise_suppression: 5
auto_gain: 3
mic_volume_multiplier: 3
sound_volume_multiplier: 1
debug_logging: true

Passi della configurazione

1. PowerConf USB: Riconosciuto come alsa_input.usb-Anker_PowerConf.mono-fallback / alsa_output.usb-Anker_PowerConf.analog-stereo (ha audio info).
2. Add-on installati:
   • openWakeWord.
   • Faster Whisper.
   • Piper TTS.
   • Assist Microphone (input/output PowerConf).
3. Pipeline (Impostazioni → Assistenti vocali):
   • Wake word: openWakeWord → “Hey raspy”.
   • STT: Faster Whisper.
   • TTS: Piper → “Riccardo low”.
4. Test: “Hey raspy, che ora è?” → wake word, trascrizione, TTS dal PowerConf.

Difficoltà e soluzioni

• PowerConf riconosciuto ma ALSA vuoto (arecord -l vuoto): sudo alsa force-reload + restart PipeWire. Confermato con pactl list sources short.
• openWakeWord instabile (1/20): YAML config: textthreshold: 0.2 trigger_level: 1 debug_logging: true
  • Assist Microphone auto_gain: 3, mic_volume_multiplier: 3 → ~70-80% affidabile.​
• Errore “assistente non connette a HA”: Impostazione corretta URL di Home assistant in Configurazione → Rete
• Whisper lento (10-20s): Funziona locale; opzione futura Whisper Cloud.​

Risorse utili

• HA Voice pipeline​
• openWakeWord config​
• Wyoming docs​
• Nabu Casa STT remoto

Funziona per comandi base, wake word migliorato ma non perfetto. Whisper locale gratuito ma lento.
L’ agente di conversazione e’ stato realizzato con Extended OpenAI Conversation, una estensione disponibile su HACS che permette di usare LLM di altre provider diversi da OpenAI. La scelta e’ stata per un proxy OpenWebUI che a sua volta rimanda a Groq.

Penso passero a Whisper cloud in quanto le limitate risorse del raspberry permettono di far girare solo un modello piccolo (tiny e small.int8) che non solo e’ lento ma anche impreciso, specie con la lingua italiana per la quale non e’ disponibile un modello specifico ma si deve usare il modello internazionale.

Ora, da qualche tempo l’app è stata letteralmente riempita di pubblicità e per motivi diversi è tornata quindi ad essere inutilizzabile, MA qualche brava persona ha rilasciato dei firmware modificati per fare tante belle cose.

In base al modello si può trovare il firmware modificato su:

• YI HACK V5: https://github.com/alienatedsec/yi-hack-v5
• YI HACK MSTAR: https://github.com/roleoroleo/yi-hack-MStar
• YI HACK ALLWINNER: https://github.com/roleoroleo/yi-hack-Allwinner

Per quanto riguarda ho utilizzato esclusivamente il firmware Yi Hack V5 su due telecamere Yi Dome e una Yi Outdoor. L’obbiettivo era rendere le telecamere integrate con HomeAssistant.

Il risultato è lontano dall’essere perfetto per via delle limitazioni dell’hardware delle telecamere, veramente essenziale, dal fatto che si usa una scheda microsd come file system con tanto di memoria virtuale e che i firmware modificati non sono bugfree (ma cosa lo è?).

Pero si riesce ad avere un flusso video in tempo reale, la notifica dei movimenti, e la registrazione del video del movimento. Senza perdere le funzionalità dell’app proprietaria. Magari in un prossimo articolo scenderò un po più in dettaglio sia per Home Assistant (che ho installato su un raspberry pi 5 nuovo) sia sulle telecamere.

Ogni tanto non parlo di tecnologia, programmazione e cose simili ma anche di altre cose che mi piacciono, come ad esempio i viaggio che faccio.

Destinazione più recente: Praga, poco prima di natale. La città è veramente molto bella, ma nel periodo scelto è (ancora di più) un giocattolo per turisti.

Negozi, cibo, bancarelle e ovviamente una quantità infinita di turisti ovunque. Ultimamente sembra che le persone siano aumentate. C’è ressa sempre e ovunque. Sarà ovviamente una impressione … o forse sempre meno gente sta a casa a fare nulla e invade tutte le possibili destinazioni turistiche vicine o lontane. Ci sarà un’analisi del fenomeno da qualche parte.

Comunque ritornando a Praga, la paura più significativa, ovvero freddo e maltempo non si è concretizzata. Si possono trovare racconti di gelidi giorni di dicembre con temperatura anche sotto i 10 gradi e neve, nella mia esperienza no. Temperature sempre positive anche se di poco, niente neve e cielo, alle volte, azzurro. Ma dovrebbe essere fortuna non garantisco.

Altra informazione interessante è che gli spostamenti con auto con conducente (evito deliberatamente di usare la parola taxi) richiesti tramite app sono abbastanza economici, 18-20 euro per l’aeroporto, 6-10 euro per gli spostamenti interni alla città. Se non cercate il risparmio estremo possono essere una valida alternativa ai mezzi pubblici, che non ho provato e dei quali non saprei dire gran che.

Qualcosa sulle attrazioni turistiche.

La città vecchia e il quartiere di Mala Strana sono molto belli anche per passeggiare senza una meta precisa. In particolar modo la città vecchia non e’ particolarmente grande e quindi ci si imbatti un po in tutti i punti caratteristici senza stare a pianificare itinerari precisi.

Il Ponte Carlo è sempre pieno di gente. Quando accendono le luci, che sono a led e non lanterne vere e proprie, è decisamente sconsigliato esserci se si soffre la ressa.

Il castello e la cattedrale e la cattedrale di San Vito sono molto belli. Vale il biglietto per vedere l’interno, soprattutto per la cattedrale. E’ probabile trovare lunghe code per entrare ma scorrono velocemente. Non demotivatevi.

Quartiere ebraico e cimitero dall’esterno non sono particolarmente interessanti a mio parere e il costo del biglietto (unico per tutto…) forse è un po’ alto per quello che offre.

Albergo e ristoranti

Ho dormito due notti al Falkensteiner Hotel di cui posso dire solo bene. Buona posizione, staff gentile e disponibile per migliorare l’esperienza con check in anticipato e check out ritardato. Colazione stupenda. Presente anche una piccola SPA.

La prima cena l’ho fatta da Ribs of Prague tutto molto buono, solo attenzione che la cipolla fritta e’ letteralmente enorme. Buon rapporto qualità prezzo. Consigliata la prenotazione.

La seconda cena invece è stata da Vytopna Railway Resturant che propone un menu a base di hamburger con la particolarità di essere serviti mediante trenini giocattolo che corrono per tutto il locale. Divertente, molto fotografabile, cibo buono. Il prezzo, decisamente orientato ai turisti, tiene conto del successo del locale e della sua particolarità. Obbligatoria la prenotazione molto anticipata.

Costi in generale

Praga era famosa per essere una destinazione economica. Non lo è più. Rimane leggermente meno cara di altre capitali europee, ma da italiano ho avuto la sensazione di spendere come se fossi a Milano, Roma, etc.

Qualche altra foto