Introduzione: il mio processo di apprendimento

Utilizzo Obsidian come centro della mia knowledge base, ma ho sempre trovato che prendere appunti da fonti online fosse un processo macchinoso. Articoli approfonditi, video tecnici e thread di discussione finivano spesso per diventare segnalibri dimenticati o note frammentarie, difficili da ritrovare e riutilizzare.

Lo scenario è familiare: trovo un articolo illuminante e vorrei integrarne i concetti chiave nel mio vault di Obsidian. Le opzioni più semplici, però, presentano diversi ostacoli:

• Copia-incolla: Restituisce un testo con formattazione caotica, link interrotti ed elementi di layout superflui.
• Screenshot: Si perdono nel rullino fotografico dello smartphone, senza un contesto chiaro.
• Segnalibri: Dopo una settimana, il motivo per cui ho salvato quel link è già svanito.
• Appunti manuali: Interrompere la lettura, perdere la concentrazione e tentare di sintetizzare al volo è dispersivo e inefficiente.

Lo stesso problema si ripresenta, amplificato, con i video di YouTube. Estrarre i concetti chiave da una conferenza o qualcosa di simile, richiede di:

• Riascoltare più volte passaggi specifici.
• Trascrivere manualmente i punti salienti.
• Riorganizzare le informazioni in un formato coerente.

È un metodo frustrante che scoraggia l'apprendimento attivo.

La mia soluzione: due click per un markdown pulito

Annotiquo è un'estensione per Chrome progettata per risolvere questo specifico problema: estrarre il contenuto di una pagina web e convertirlo in Markdown pulito, pronto per essere archiviato.

Come funziona:

1. Apri l'articolo o il video di tuo interesse.
2. Clicca sull'icona dell'estensione e seleziona "Copia Testo".
3. Incolla il contenuto direttamente in Obsidian: pulito, ben formattato e privo di distrazioni.

Non sono richieste configurazioni complesse o registrazioni. L'estensione riconosce il tipo di contenuto e applica autonomamente il parser più adeguato.

L'impatto sul lavoro quotidiano

L'adozione di questo strumento ha migliorato concretamente la mia gestione delle informazioni:

• Per gli articoli: Il contenuto principale viene estratto senza barre laterali, pubblicità o menu. La formattazione Markdown si integra nativamente in Obsidian, preservando link e struttura.
• Per i video YouTube: L'estensione estrae automaticamente le trascrizioni (se disponibili), organizzandole con titolo, descrizione e metadati. In pochi secondi, puoi avere una versione testuale di una discussione di ore.
• Per thread e discussioni: Viene catturato solo il flusso principale della conversazione, mantenendo la struttura e i riferimenti essenziali.

L'Evoluzione: dall'estrazione alla sintesi intelligente

Se inizialmente Annotiquo é nato come semplice strumento di estrazione, non appena completata questa parte ho subito notato una ovvia evoluzione: creare una sintesi dei contenuti estratti. La web app associata introduce proprio questa funzionalità: la estrarre i contenuti chiave tramite intelligenza artificiale.

Invece di archiviare un articolo tecnico di 3.000 parole, ora posso generare un riassunto di 300 parole che ne cattura i concetti fondamentali. Un video di un'ora può essere condensato in un estratto testuale di 5 minuti con i punti salienti.

Ovviamente questo ha un costo, ma con un sistema a crediti è tuto trasparente e flessibile: paghi solo per l'uso effettivo, senza canoni mensili che gravano anche nei periodi di inutilizzo. E in ogni caso é possibile gratuitamente estrarre il contenuto completo per gestirlo manualmente o con un altro strumento.

Risultati concreti

Dopo un paio di mesi di utilizzo quotidiano, sono soddisfatto. I benefici sono evidenti:

• Knowledge base più ricca: La mia libreria di Obsidian si popola di note dense e strutturate.
• Ricerca più efficace: Posso confrontare e analizzare fonti diverse all'interno di un unico documento.
• Percorsi di apprendimento chiari: Video e articoli su uno stesso argomento si trasformano in una risorsa unificata e coerente.
• Minore attrito: È scomparsa l'esitazione nel decidere se "valga la pena prendere appunti".

A chi si rivolge Annotiquo?

Ho sviluppato Annotiquo principalmente per risolvere un'esigenza personale, ma ho intuito presto che il problema é condiviso da molti. Se anche tu hai un workflow simile al mio, credo che questo strumento possa esserti estremamente utile.

Direi che profilo ideale è chi:

• Utilizza strumenti come Obsidian, Notion o Roam per il knowledge management.
• Consuma regolarmente contenuti tecnici online (articoli, video, documentazione).
• Desidera trasformare il consumo passivo di informazioni in apprendimento attivo.
• Percepisce il divario tra "contenuto interessante" e "nota realmente utilizzabile".

A differenza di altri strumenti che puntano a reinventare da zero il modo in cui prendi appunti, Annotiquo vuole essere a supporto del sistema che già utilizzi, eliminando gli attriti nel punto esatto in cui si creano.

Se ti riconosci in questa descrizione, ti invito a provare. Trovi tutto il necessario sul sito ufficiale: annotiquo.com:

• L'estensione per Chrome è gratuita e funziona anche offline.
• Con l'iscrizione alla web app, riceverai 10 crediti gratuiti per testare la sintesi con AI, senza alcun impegno.

Continua

Questo articolo è il primo di una serie dedicata al progetto. Il mese prossimo pubblicherò un'analisi più tecnica, in cui racconterò le scelte architetturali e le tecnologie dietro lo sviluppo di Annotiquo.

Il contesto dell'esperimento

L'idea era semplice: prendere un progetto di media complessità e vedere fino a che punto riuscivo a delegare il lavoro di sviluppo all'intelligenza artificiale. Non parliamo di semplici snippet di codice o refactoring minori, ma di architettura, implementazione di feature complete e debugging.

Il risultato? Un mese di lavoro intenso che mi ha fatto capire molte cose su come l'AI può (e non può) aiutarci nel nostro lavoro quotidiano.

La regola d'oro: specificità estrema

La prima lezione, e probabilmente la più importante, è che con l'AI la vaghezza è il nemico numero uno. Se con un developer junior puoi permetterti di dire «implementa un sistema di autenticazione» e aspettarti che faccia le domande giuste, con l'AI questo approccio porta dritto al disastro.

Ogni feature va descritta come se stessi scrivendo documentazione per qualcuno che non ha mai visto il progetto. I Product Requirement Documents dettagliati non sono un lusso, ma una necessità. L'AI ha bisogno di sapere esattamente cosa fare, come farlo e — soprattutto — cosa non fare.

Specificare cosa non vuoi è altrettanto importante quanto dire cosa vuoi: evita iniziative creative che poi dovrai sistemare a mano.

Il paradosso delle tecnologie popolari

L'AI performa molto meglio su stack mainstream e ben documentati. Ha senso: è stata addestrata su montagne di codice pubblico, tutorial e documentazione di React, Node.js, Python e simili.

Quando ho provato a usare librerie più di nicchia o pattern architetturali meno comuni, la qualità delle soluzioni proposte è calata drasticamente: API inventate, approcci teoricamente corretti ma impraticabili.

La lezione: se vuoi massimizzare l'efficacia dell'AI, punta su tecnologie con grandi community e documentazione abbondante. Non è il momento di sperimentare con quella nuova libreria experimental trovata su GitHub.

Debugging: dove l'AI mostra i limiti

Il debugging è stata l'area più frustrante. L'AI è bravissima a scrivere codice che sembra sensato, ma quando qualcosa va storto la sua capacità di analisi sistematica lascia a desiderare.

Spesso si fissa su una singola ipotesi e continua a proporre variazioni dello stesso approccio sbagliato. In questi casi conviene fermarsi, analizzare il problema da soli, e poi dare all'AI indicazioni molto specifiche su cosa cercare e dove.

Code Creep: Ogni ciclo di debug con l'AI — direi il 99 % delle volte — si traduce nell'aggiunta di nuovo codice: patch, controlli extra, logging ridondante. Il risultato è un gonfiarsi costante della codebase, con effetti negativi su leggibilità e futura manutenzione. Tenere la situazione sotto controllo richiede refactoring frequenti e una sorveglianza umana costante.

Test: tra copertura e soluzioni apparenti

Di fronte a test falliti, l'AI spesso «risolve» il problema aggiungendo eccezioni, mock o log per mascherare l'errore invece di correggere il bug reale.

Questo porta a un falso senso di sicurezza: i test passano, ma il difetto di fondo rimane.

Gestione della complessità architetturale

Per singole funzioni o moduli isolati i risultati sono spesso eccellenti. Ma mantenere coerenza in un'intera applicazione è un'altra storia.

L'AI tende a ottimizzare localmente piuttosto che globalmente: crea funzioni perfette per il contesto immediato, che però introducono inconsistenze o duplicazioni altrove.

Soluzione: definire chiaramente pattern e convenzioni prima di iniziare, e richiamarli costantemente quando chiedi nuove implementazioni.

Velocità vs Qualità: trovare il giusto equilibrio

La velocità di sviluppo con l'AI può essere impressionante, ma c'è un trade‑off importante: il codice generato funziona spesso al primo colpo, ma non sempre è quello che avresti scritto tu.

A volte mancano ottimizzazioni, altre la struttura non è ideale per future estensioni. Devi decidere quando accettare una soluzione «abbastanza buona» per procedere e quando invece investire tempo nel raffinare ciò che l'AI ha prodotto.

Lessons learned e prossimi passi

Dove l'AI brilla

• Boilerplate e setup iniziale di progetti
• Implementazione di pattern ben consolidati
• (Con supervisione) scrittura di test unitari
• Refactoring di codice esistente

Dove serve ancora la mano umana

• Decisioni architetturali complesse
• Debugging di problemi non ovvi e prevenzione del Code Creep
• Ottimizzazioni di performance
• Sicurezza, gestione degli errori edge‑case e reale copertura dei test

Conclusioni pratiche

Se stai pensando di integrare l'AI nel tuo workflow di sviluppo, inizia gradualmente. Usala per accelerare le parti più meccaniche, ma mantieni sempre il controllo sulle decisioni architetturali critiche.

Investi tempo nella documentazione: più specifico sei nei prompt, migliori saranno i risultati. E ricorda: l'AI è uno strumento, non un sostituto del tuo giudizio da developer esperto.

Il progetto di cui parlo in questo articolo è online su annotiquo.com. L'estensione del browser è in fase di revisione, ma conto di pubblicarla a breve: l'ho creata principalmente perché ne avevo bisogno io, e spero possa tornare utile anche ad altri.

Continuerò questo esperimento nei prossimi mesi, esplorando nuovi approcci e condividendo ciò che imparo, iscriviti alla newsletter se vuoi seguirmi in questo percorso. Nel frattempo, spero che queste riflessioni ti siano utili se decidi di provare qualcosa di simile nel tuo team.

Ho seguito il corso di IBM su edX, "Mastering Generative AI Agents with RAG and LangChain". È pensato per sviluppatori, data scientist e tech lead che vogliono capire come costruire applicazioni AI concrete, andando oltre la semplice chiamata a un'API come ChatGPT. Il corso è strutturato in moduli brevi, con un buon equilibrio tra spiegazioni teoriche, esempi pratici e laboratori interattivi. Non è pensato per chi parte da zero, ma è molto utile se hai già una base e vuoi mettere ordine tra strumenti, concetti e workflow.

Cosa vuol dire usare RAG

RAG (Retrieval-Augmented Generation) è un'architettura che permette a un LLM di integrare informazioni esterne, aggiornabili e contestualizzate, al momento della generazione. Questo evita di dover riaddestrare il modello ogni volta che cambiano i dati. In pratica, il processo è diviso in due fasi:

1. Retrieval: una query dell’utente viene trasformata in un embedding e confrontata con un insieme di documenti indicizzati. Si recuperano quelli più rilevanti.
2. Generation: i documenti recuperati vengono passati come contesto al modello, che genera una risposta più precisa e informata.

Questo approccio consente di usare modelli generalisti (come GPT o LLaMA) per rispondere a domande su contesti molto specifici, ad esempio un manuale tecnico interno o una raccolta di policy aziendali.

Perché è utile

Il vantaggio principale è la flessibilità: puoi aggiornare i dati in tempo reale senza dover modificare il modello. È anche più scalabile e meno costoso rispetto al fine-tuning. Tuttavia, la qualità delle risposte dipende molto da come segmenti i documenti, dalla qualità degli embedding e dalla struttura del database vettoriale.

Prompt engineering: ancora fondamentale

Anche se oggi abbiamo strumenti più sofisticati, il prompt resta il modo più immediato per guidare un LLM. Il corso dedica una sezione interessante al prompt engineering, mostrando diverse strategie:

• Prompt a zero, uno o pochi esempi (zero-shot, one-shot, few-shot)
• Prompt strutturati con esempi guidati
• Prompt chain-of-thought, che aiutano il modello a ragionare a passi
• Tecniche di auto-verifica come la self-consistency

Viene anche data attenzione agli strumenti che aiutano a creare prompt riutilizzabili e modulari, come i template di LangChain, e a testarne l’efficacia in contesti diversi.

LangChain: mettere insieme i pezzi

LangChain è il framework open source che il corso usa per orchestrare modelli, prompt, retrieval, memoria e strumenti esterni. L’idea alla base è semplice: creare applicazioni AI componibili, in cui puoi collegare vari moduli (chains, tools, memory, agents) in modo flessibile.

Puoi ad esempio:

• Creare una catena di prompt che processano input passo dopo passo
• Usare agenti per decidere in autonomia quale tool usare in base al contesto
• Integrare chiamate a database, filesystem, API o plugin esterni

LangChain è molto utile quando hai bisogno di costruire qualcosa di più articolato di una singola risposta testuale: ad esempio, un assistente con memoria, un sistema che interroga fonti strutturate o una pipeline che coinvolge più modelli.

Lavorare con i documenti: la pipeline RAG

Una parte molto concreta del corso riguarda la gestione dei documenti: è qui che LangChain e RAG si incontrano davvero. Il flusso tipico è questo:

1. Caricamento: prendi documenti da fonti diverse (PDF, API, file locali...)
2. Segmentazione: li dividi in porzioni più piccole, chiamate chunk
3. Embedding: trasformi ogni chunk in un vettore numerico che rappresenta il suo significato
4. Indicizzazione: salvi i vettori in un database (es. FAISS)
5. Ricerca: quando arriva una domanda, cerchi i chunk più simili nel vector DB
6. Composizione del prompt: costruisci il prompt da dare al modello con i risultati più rilevanti

FAISS, usato nel corso, è una libreria pensata per eseguire ricerche efficienti di similarità su grandi insiemi di vettori numerici. È veloce e abbastanza facile da usare, anche se richiede attenzione per configurarlo bene in produzione.

In sintesi: vale la pena?

Il corso è ben fatto, strutturato in modo chiaro e con contenuti aggiornati. Non promette miracoli, ma ti dà una visione realistica di cosa serve per costruire applicazioni AI moderne: modelli, sì, ma anche dati, retrieval, orchestrazione e prompt ben progettati. È utile se:

• Hai già fatto qualche esperimento con gli LLM e vuoi passare a soluzioni più complete
• Ti interessa capire come integrare i modelli con dati aziendali
• Vuoi valutare tecnologie come LangChain e capire se fanno al caso tuo

In ogni caso, ti lascia qualcosa in mano: idee, strumenti, esempi concreti e una roadmap da seguire per costruire applicazioni AI più solide e mantenibili.

Risorse utili

Se vuoi approfondire alcuni degli argomenti trattati nel corso, ecco alcune risorse che ho trovato particolarmente utili durante lo studio:

• Corso IBM su edX – Mastering Generative AI Agents with RAG and LangChain
• LangChain Documentation – https://docs.langchain.com/
• FAISS GitHub – https://github.com/facebookresearch/faiss
• OpenAI Cookbook – https://github.com/openai/openai-cookbook
• Hugging Face Transformers – https://huggingface.co/docs/transformers/index

Questi link offrono una buona base sia per iniziare che per approfondire a seconda del livello di esperienza.

Alla prossima, e buon lavoro con il codice!

L'email continua a essere uno degli strumenti più usati — e purtroppo più vulnerabili — in ambito business. Nonostante l'emergere di piattaforme moderne che offrono alternative più sicure e tracciabili, l'email rimane centrale nella comunicazione tra aziende. E proprio per questo, anche nel 2025, continua a rappresentare un vettore significativo per attacchi di phishing, spoofing e spam.

Il protocollo SMTP, nato in un contesto molto diverso dall'attuale, non prevede meccanismi robusti per l'autenticazione del mittente. Da qui la necessità di tecnologie come SPF, DKIM e DMARC.

Vediamole da vicino, con lo sguardo tecnico di chi le implementa.

SPF: una whitelist basata su IP

Sender Policy Framework (SPF) permette al dominio mittente di dichiarare esplicitamente quali IP sono autorizzati a spedire email per suo conto. Funziona tramite un record DNS TXT che specifica gli IP (o i domini) autorizzati.

Benefici concreti: SPF è relativamente semplice da implementare in ambienti controllati. Per esempio, se tutta la posta esce da Google Workspace o da un relay SMTP aziendale noto, SPF può aiutare a bloccare tentativi di spoofing di base.

Le difficoltà reali:

• SPF verifica l'IP dell'MTA che spedisce la mail, non l'header "From" visibile all'utente. Quindi non previene attacchi di spoofing più sofisticati.
• Il limite di 10 lookup DNS può diventare un ostacolo quando si utilizzano molti servizi terzi (CRM, strumenti di marketing, piattaforme di invio notifiche...).
• Alcuni mailserver possono gestire in modo non uniforme i risultati SPF softfail.

Best practice:

• Minimizzare le deleghe. Evitare SPF troppo permissivi o con +all.
• Monitorare i servizi che inviano per conto del dominio. Se cambiano IP, l’SPF va aggiornato.
• Validare la configurazione con strumenti come MXToolbox o Dmarcian.

DKIM: firma crittografica per le email

DomainKeys Identified Mail (DKIM) si basa su una firma crittografica del contenuto della mail e di alcuni header. Il dominio pubblica una chiave pubblica nel DNS, che viene usata per verificare la firma inserita nel messaggio.

Benefici concreti: DKIM aggiunge integrità e autenticazione: se il messaggio è stato alterato in transito o inviato da un servizio non autorizzato, la firma fallisce.

Le difficoltà reali:

• Non tutti i provider configurano DKIM correttamente di default.
• La selezione degli header da firmare può causare fallimenti inaspettati (es. se un mail gateway modifica i campi "Subject" o "From").
• La gestione delle chiavi RSA richiede attenzione: lunghezza, rotazione e revoca devono essere parte di un processo strutturato.

Best practice:

• Usare chiavi da almeno 2048 bit.
• Firmare almeno i campi From, Subject, Date e i contenuti MIME.
• Testare gli invii reali verso provider principali (Gmail, Outlook, Apple Mail) per verificare compatibilità e deliverability.

DMARC: il coordinatore tra SPF e DKIM

Domain-based Message Authentication, Reporting & Conformance (DMARC) coordina SPF e DKIM e introduce una policy su come trattare i messaggi che falliscono i controlli. Inoltre, fornisce report aggregati e forensi.

Benefici concreti:

• Permette di specificare azioni (none, quarantine, reject) in base alla conformità di SPF/DKIM.
• Rende visibile cosa succede realmente grazie ai report aggregate.

Le difficoltà reali:

• I report sono in formato XML e spesso richiedono strumenti terzi per essere analizzati.
• Richiede che SPF o DKIM siano aligned con il dominio visibile nel From. Questo è un aspetto spesso trascurato.
• Una policy aggressiva impostata troppo presto (es. p=reject) può bloccare email legittime.

Best practice:

• Iniziare con p=none e monitorare per almeno 1-3 mesi.
• Analizzare i report con strumenti come Postmark, Dmarcian, o soluzioni open source come OpenDMARC.
• Procedere per gradi verso quarantine e solo successivamente verso reject.

Esempio pratico: configurazioni DNS

Immaginiamo un dominio che utilizza Google Workspace per l’invio della posta e anche una piattaforma di newsletter esterna (es. Mailchimp).

Record SPF:

@ IN TXT "v=spf1 include:_spf.google.com include:servers.mcsv.net -all"

Record DKIM (Google):

google._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0G..."

Record DMARC:

_dmarc IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@tuodominio.it; adkim=s; aspf=s"

Questi record sono solo un punto di partenza: ogni servizio esterno ha le sue indicazioni specifiche e, in alcuni casi, può essere necessario configurare chiavi DKIM dedicate o subdomini separati.

Un percorso sostenibile per l’adozione

In uno scenario ideale, SPF, DKIM e DMARC sarebbero configurati su ogni dominio. Nella realtà, la loro adozione richiede pianificazione, test approfonditi e monitoraggio costante. L’approccio più efficace è procedere per fasi:

1. SPF first: è il più semplice da introdurre e spesso già supportato dai provider principali.
2. DKIM second: richiede più attenzione ma offre un salto di qualità sulla sicurezza.
3. DMARC last: va introdotto con policy leggere e strumenti di osservabilità.

Coinvolgere DevOps e SecOps è fondamentale: un record DNS errato può compromettere la deliverability delle email transazionali o addirittura bloccare comunicazioni cruciali con clienti e partner.

Conclusione: equilibrio tra sicurezza e affidabilità

SPF, DKIM e DMARC sono strumenti validi e ormai indispensabili per proteggere la reputazione email di un dominio. Tuttavia, la loro implementazione richiede un approccio strutturato e multidisciplinare: non bastano configurazioni iniziali corrette, serve anche una manutenzione continua.

Chi desidera mantenere un dominio affidabile e costruire una reputazione solida deve investire in questi standard. Il risultato si traduce in una migliore deliverability, una riduzione delle frodi e una comunicazione aziendale più credibile.

In definitiva, garantire che un’email arrivi a destinazione e sia considerata legittima non è solo una questione tecnica, ma un investimento strategico per la propria organizzazione.

I modelli vision in locale stanno guadagnando popolarità grazie ai loro vantaggi in termini di privacy e controllo sui dati. A differenza delle soluzioni cloud, questi modelli consentono di eseguire elaborazioni direttamente sui dispositivi locali, garantendo tempi di risposta rapidi e una maggiore sicurezza. Questo è particolarmente utile in settori dove i dati sensibili devono rimanere all’interno delle infrastrutture aziendali.

Applicazioni Pratiche

I modelli vision in locale trovano ampio impiego in diversi settori, tra cui:

• Sorveglianza e Sicurezza: Riconoscimento facciale o identificazione di oggetti sospetti senza inviare dati a server remoti.
• Controllo Qualità Industriale: Monitoraggio in tempo reale delle linee di produzione per identificare difetti.
• Riconoscimento Foto per Ricerca: Utilizzo di modelli vision per etichettare immagini, organizzarle per contenuto e facilitarne la ricerca all'interno di archivi digitali.

Implementazione con LangChain

Di seguito un esempio di utilizzo di LangChain per l'inferenza con un modello di riconoscimento immagini in locale:

from langchain import LangChain

llm = OllamaLLM(model="llava")
llm_with_image_context = llm.bind(images=[image_b64])
res = llm_with_image_context.invoke("Describe this image")

Questo esempio dimostra come utilizzare un modello di visione pre-addestrato con LangChain per il riconoscimento di oggetti. È un punto di partenza semplice e facilmente adattabile a diversi contesti applicativi.

Approfondimenti

Ecco alcuni link utili per approfondire l'argomento dei modelli vision in locale e l'uso di LangChain:

• LangChain: Documentazione ufficiale per creare catene e orchestrare modelli.
• Hugging Face: Modelli pre-addestrati per il riconoscimento di oggetti e altre applicazioni di visione.

Conclusione

I modelli vision in locale rappresentano una scelta strategica per molte aziende, consentendo di garantire privacy, velocità di esecuzione e controllo dei dati. Con strumenti come LangChain, è possibile implementare soluzioni rapide e sicure per il riconoscimento di oggetti in diversi contesti.

Un aspetto fondamentale dei modelli vision in locale è la loro implementabilità anche con budget modesti. Grazie alla disponibilità di modelli pre-addestrati open source e alla crescente potenza dei dispositivi edge, è possibile realizzare progetti efficienti senza dover investire ingenti somme. Questo approccio consente di migliorare notevolmente l'efficienza di processi aziendali come il controllo qualità, la sorveglianza o la categorizzazione automatica delle immagini, aumentando la produttività e garantendo una gestione ottimale delle risorse.

Negli ultimi anni, il concetto di Infrastructure as Code (IaC) si è imposto come una pratica fondamentale per la gestione scalabile, riproducibile e automatizzata delle infrastrutture IT. Con la crescente adozione di cloud computing e ambienti containerizzati, il provisioning manuale delle risorse non è più sostenibile: troppi errori, processi lenti e scarsa tracciabilità.

L'adozione di IaC consente di trattare le infrastrutture come codice, con file di configurazione versionabili, modulari e testabili. Questo riduce le incoerenze tra ambienti, minimizza gli errori umani e aumenta la velocità di rilascio, abilitando un approccio DevOps più solido. Con il codice al centro della gestione dell'infrastruttura, le aziende possono ottenere maggiore affidabilità e sicurezza, adottando processi che migliorano la ripetibilità delle configurazioni.

L'infrastruttura gestita con codice non solo accelera il time-to-market ma consente anche di adottare strategie di disaster recovery più robuste, eliminando le incongruenze tra ambienti e facilitando il rollback in caso di problemi. Tuttavia, sebbene i benefici siano evidenti, il percorso per adottare IaC senza intoppi presenta ostacoli tecnici e organizzativi che non vanno sottovalutati.

Sfide e Complessità di IaC

Sebbene i benefici siano evidenti, l'adozione di IaC non è priva di sfide. Il primo ostacolo è culturale: molti team IT sono abituati a gestire l'infrastruttura in modo manuale o semi-automatizzato. Il passaggio a una mentalità "code-driven" richiede un cambio di paradigma e una curva di apprendimento.

A livello tecnico, la gestione della configurazione e del provisioning attraverso codice introduce nuovi livelli di complessità:

• Gestione dello stato: strumenti come Terraform mantengono lo stato dell'infrastruttura, ma questo file di stato diventa un punto critico di fallimento. Se non gestito correttamente, potrebbe introdurre problemi di sincronizzazione tra ambienti.
• Dipendenze e orchestrazione: il deployment coordinato di risorse richiede una gestione attenta delle dipendenze. Senza una strategia chiara, si rischia di creare configurazioni difficili da mantenere e aggiornare.
• Sicurezza e permessi: definire infrastrutture via codice introduce rischi di esposizione accidentale di credenziali e configurazioni sensibili. I file di configurazione devono essere protetti da leak accidentali, preferibilmente attraverso strumenti di secret management come HashiCorp Vault o AWS Secrets Manager.
• Debugging e rollback: errori nel codice di IaC possono avere impatti devastanti sugli ambienti di produzione. Avere una strategia di rollback efficace e monitorare le modifiche è essenziale.
• Compatibilità multi-cloud: con molte aziende che adottano strategie multi-cloud, il codice IaC deve essere sufficientemente flessibile da gestire ambienti eterogenei senza eccessive personalizzazioni.

Uno studio del 2022 ([2206.10344] Static Analysis of Infrastructure as Code: a Survey) ha analizzato le tecniche di analisi statica applicate a IaC, evidenziando la necessità di strumenti più avanzati per rilevare e prevenire difetti nei script IaC, al fine di garantire la sicurezza e l’affidabilità delle infrastrutture distribuite.

Tutti questi aspetti fanno emergere una verità scomoda: IaC non semplifica l'infrastruttura di per sé, ma ne cambia la gestione, trasformando i problemi operativi in problemi software. Per questo motivo, IaC deve essere affrontato con la stessa attenzione al design, alla modularità e ai test che si applicano allo sviluppo software tradizionale.

Strumenti Principali

L'ecosistema IaC offre strumenti specializzati per ogni fase della gestione dell'infrastruttura:

Terraform

Terraform, sviluppato da HashiCorp, è uno dei tool più diffusi per la definizione e gestione dell'infrastruttura come codice. Usa il proprio linguaggio dichiarativo (HCL) per descrivere le risorse e gestisce lo stato dell'infrastruttura per garantire idempotenza e riproducibilità. Supporta molteplici provider cloud (AWS, GCP, Azure) e ambienti on-premise.

Uno dei principali vantaggi di Terraform è la sua capacità di orchestrare l'intero ciclo di vita dell'infrastruttura, dall'inizializzazione alla distruzione, con il comando terraform apply. Il suo modello dichiarativo permette di definire lo stato desiderato, lasciando al tool il compito di determinare quali azioni eseguire.

Ansible

Ansible è un tool di automazione agentless, basato su YAML, che permette di configurare sistemi, applicazioni e infrastrutture. A differenza di Terraform, che si concentra sul provisioning, Ansible è ideale per la gestione della configurazione e l'automazione operativa. Può essere utilizzato per gestire il patching, l'installazione di software e il deployment di applicazioni su ambienti server.

Essendo basato su SSH, Ansible è estremamente semplice da integrare, senza la necessità di installare agent sui nodi gestiti. Tuttavia, rispetto a strumenti più strutturati come Terraform, Ansible è meno adatto alla gestione di infrastrutture intere, eccellendo invece nell'automazione della configurazione.

Docker Swarm & Kubernetes

Se IaC si occupa del provisioning dell'infrastruttura, orchestratori come Docker Swarm e Kubernetes gestiscono il deployment e la scalabilità delle applicazioni containerizzate. Kubernetes, in particolare, è diventato lo standard de facto per orchestrare workload distribuiti, offrendo resilienza, scalabilità e automazione avanzata.

L'integrazione tra Terraform e Kubernetes consente di definire sia l'infrastruttura che i cluster containerizzati in modo coerente. Kubernetes utilizza manifest YAML per descrivere lo stato desiderato dei container, un concetto simile a quello di IaC, ma focalizzato sulla gestione delle applicazioni anziché sull'infrastruttura sottostante.

Un Approccio Graduale all'IaC

Molte aziende falliscono nell'adozione di IaC a causa di un approccio troppo aggressivo. Un'implementazione efficace deve essere graduale e mirata:

1. Identificare le aree critiche: iniziare con ambienti di sviluppo o staging prima di passare alla produzione. Adottare IaC senza una strategia progressiva può generare più problemi di quanti ne risolva.
2. Modularizzare il codice: definire componenti riutilizzabili per ridurre la complessità e favorire il riutilizzo tra progetti diversi. L'uso di moduli Terraform o ruoli Ansible aiuta a mantenere il codice pulito e manutenibile.
3. Versionare e testare: integrare il codice IaC in pipeline CI/CD con test automatici. Strumenti come terratest o kitchen consentono di validare le configurazioni prima di applicarle su larga scala.
4. Automatizzare progressivamente: partire dalla gestione delle VM, poi containerizzazione, infine orchestrazione. L'automazione deve seguire un percorso logico e sostenibile per il team.
5. Monitorare e migliorare: l'adozione di IaC non finisce con il deployment iniziale. Il monitoraggio continuo con strumenti come Prometheus e Grafana permette di individuare colli di bottiglia e migliorare le configurazioni.

L'IaC non è una soluzione plug-and-play, ma un investimento strategico. Un'adozione intelligente e progressiva permette di massimizzarne i benefici senza introdurre rischi eccessivi. Con un piano ben strutturato, IaC può diventare un pilastro fondamentale per infrastrutture IT moderne, efficienti e scalabili.

I Benefici Realistici dei Modelli AI in Locale

Privacy e Controllo dei Dati

Uno dei principali motivi per cui le aziende e i singoli sviluppatori stanno esplorando soluzioni AI in locale è la possibilità di mantenere il controllo completo sui propri dati. In un'epoca in cui la privacy è diventata una preoccupazione centrale, evitare il caricamento di dati sensibili su server remoti può essere un fattore decisivo. In particolare, con normative come il GDPR in Europa, la possibilità di lavorare con modelli di AI senza trasferire dati personali su piattaforme esterne è un vantaggio enorme. Questo controllo può ridurre il rischio di violazioni della sicurezza e migliorare la trasparenza nelle operazioni aziendali.

Riduzione dei Costi Cloud

Molti modelli AI offrono un’API cloud che consente di eseguire inferenze in remoto. Tuttavia, questi servizi spesso comportano costi ricorrenti che possono crescere rapidamente, soprattutto se il volume delle richieste aumenta. Usare un modello AI in locale, invece, permette di eliminare la necessità di pagare per l'infrastruttura cloud e per le risorse computazionali scalabili, con il vantaggio di avere costi fissi più prevedibili legati all’acquisto e gestione di hardware.

Personalizzazione e Indipendenza

Implementare un modello AI in locale consente anche una maggiore personalizzazione. Puoi scegliere il modello che meglio si adatta ai tuoi bisogni specifici, senza dover subire le limitazioni imposte dai provider di servizi cloud. Inoltre, le soluzioni in locale sono meno soggette a cambiamenti nelle politiche di pricing o nelle funzionalità, che possono influire negativamente su un servizio cloud nel lungo termine.

Le Sfide dell'Implementazione AI in Locale

Potenza di Calcolo e Hardware

Il principale ostacolo all'adozione di modelli AI in locale è il requisito di hardware specializzato. A meno che tu non stia lavorando con modelli relativamente leggeri, avrai bisogno di risorse computazionali consistenti. Le GPU NVIDIA, in particolare, sono ampiamente utilizzate per il training e l'inferenza di modelli AI grazie alla loro potenza e supporto per librerie come CUDA. Tuttavia, queste soluzioni possono risultare costose e richiedono una gestione accurata del sistema. Le macchine basate su architettura ARM come quelle con Apple Silicon (M1, M2) sono anche un'opzione interessante, soprattutto per sviluppatori che già utilizzano hardware Mac, ma sono ancora limitate rispetto alle GPU NVIDIA in termini di performance puramente AI-driven.

Se hai intenzione di utilizzare un modello di grande scala o di lavorare con dataset complessi, non sarà sufficiente un normale laptop. Avrai bisogno di una workstation potente o di un server equipaggiato con GPU appropriate, e anche in questo caso il costo dell'infrastruttura potrebbe essere proibitivo per alcuni.

Gestione e Installazione del Software

Anche se i modelli AI sono ormai molto più accessibili, l’installazione e la gestione di questi sistemi in locale possono risultare complicati. Molti sviluppatori, abituati a lavorare con API cloud, potrebbero trovarsi in difficoltà con la configurazione e l'installazione dei modelli. Le dipendenze software, la compatibilità hardware, e le impostazioni specifiche per ogni tipo di modello richiedono attenzione e competenze tecniche.

Conclusioni: Un Approccio Realistico all'AI in Locale

L’adozione di modelli AI in locale offre indubbi vantaggi in termini di privacy, controllo e riduzione dei costi operativi. Tuttavia, non è una soluzione senza sfide. Le risorse hardware necessarie possono essere costose e le difficoltà tecniche nell'installazione e gestione del software non devono essere sottovalutate. Detto ciò, per molti sviluppatori e aziende, i benefici superano di gran lunga gli ostacoli.

Se sei pronto a fare il salto, soluzioni come Ollama e OpenWebUI, abbinate a hardware adeguato, possono semplificare notevolmente il processo. L'adozione di AI in locale è una mossa pragmatica che risponde a esigenze reali, ma richiede un certo impegno per essere implementata correttamente. Con la giusta preparazione, però, puoi sfruttare appieno il potenziale dei modelli AI, ottenendo il massimo in termini di efficienza, privacy e costi.

The update includes:

• A cleaner, more focused design that puts content first
• A new professional logo that represents my values as a digital craftsman
• Improved navigation to help you find projects and insights
• Ghost CMS powering the site, bringing modern publishing features like:
  • Better content management
  • Native newsletter capabilities
  • Improved reading experience
  • SEO optimization out of the box
  • Member management for future community features

Coming soon:

• A newsletter to share regular insights and updates
• More detailed case studies of real-world solutions

My goal remains unchanged: sharing practical insights and measured results from my software engineering journey.

Take a look around and let me know what you think! Your feedback helps me improve and create more valuable content.

Pausa festiva e informazioni utili  📅

Dal 23 dicembre 2024 al 6 gennaio 2025 mi prenderò una pausa per dedicare del tempo alla famiglia e ricaricare le energie. Per chi ha progetti in corso, sono a disposizione fino al 22 dicembre per organizzare al meglio le attività e assicurarci che tutto proceda senza intoppi.

Riflessioni sul 2024 ✨

Quest'anno è stato ricco di soddisfazioni e crescita professionale. Ho avuto il privilegio di lavorare con clienti che mi hanno dato fiducia e colleghi che hanno arricchito il mio percorso con le loro competenze. Ogni progetto è stato un'opportunità di apprendimento e miglioramento.

Uno sguardo al 2025 🚀

Il nuovo anno si prospetta entusiasmante, con nuove idee e progetti in cantiere. Tornerò operativo il 7 gennaio, pronto a riprendere le attività con rinnovato entusiasmo e nuove prospettive da esplorare insieme.

Auguri sinceri 🎁

A tutti voi auguro delle festività serene e un 2025 ricco di successi. Che sia un anno di crescita e nuove opportunità per tutti noi.

La verità scomoda sui costi cloud

Nella mia esperienza, quando analizzo i costi cloud di una tipica azienda media, trovo sempre lo stesso pattern: budget superati e sprechi che fino al 30% della spesa totale.

La scomposizione tipica dei costi cloud che vedo più spesso rivela un quadro interessante:

• Buona parte delle aziende ha grossi problemi nel controllo dei costi e faticano a fare previsioni accurate di spesa
• I costi di egress spesso sono la sorpresa più grande, arrivando fino al 20% del totale
• Le risorse zombie sono ovunque: VM, storage e servizi dimenticati che continuano a generare costi

L'elefante nella stanza: la complessità nascosta

La promessa del cloud è quella di semplificare la gestione dell'infrastruttura. La realtà che vedo ogni giorno è che spesso si sostituisce complessità hardware con complessità software - e quest'ultima può essere molto più insidiosa da gestire.

Ho notato che circa tre quarti delle organizzazioni con cui lavoro riportano la complessità come principale sfida, specialmente quando si parla di sicurezza e governance.

Quando on-prem ha ancora senso: casi d'uso reali

Nella mia pratica, ho identificato tre scenari dove l'infrastruttura on-premise risulta ancora vantaggiosa:

1. Workload prevedibili e stabili
   Ho visto ripetutamente come le applicazioni con carichi prevedibili possano costare fino al 30% in meno on-premise su un periodo di 3 anni.

2. Dati con alta località
   Quando lavoro con applicazioni data-intensive, la gestione locale dei dati spesso riduce drasticamente non solo i costi ma anche la latenza.

3. Requisiti di compliance stringenti
   Nel settore finanziario e sanitario, ho visto la gestione della compliance su cloud aumentare i costi operativi anche del 40%.

L'importanza di un'analisi pragmatica

Nel mio lavoro quotidiano, utilizzo questo framework decisionale che si è dimostrato efficace:

1. Calcolo del TCO su 3 anni includendo:

   • Costi hardware/software
   • Costi operativi (personale, energia, spazio)
   • Costi di rete
   • Costi di migrazione e training

2. Analisi dei pattern di utilizzo:

   • Variabilità dei carichi
   • Requisiti di scalabilità
   • Località dei dati
   • Vincoli di compliance

3. Valutazione delle competenze interne:

   • Expertise esistente
   • Costi di formazione
   • Disponibilità sul mercato

Lezioni apprese sul campo

Dopo centinaia di progetti, queste sono le mie principali osservazioni:

1. Il cloud non è un risparmio automatico
   Quasi metà dei progetti che ho seguito hanno riportato costi superiori alle aspettative iniziali.

2. La complessità si sposta, non scompare
   La maggior parte degli sviluppatori con cui lavoro considera la complessità del cloud una delle sfide più significative.

3. L'ibrido non è un male
   Le implementazioni di maggior successo che ho visto sono quasi sempre ibride, con un mix intelligente di cloud e on-premise.

Conclusione: verso un approccio equilibrato

La realtà che ho toccato con mano è che non esiste una soluzione universale. Il cloud è fantastico per molti scenari, ma non è la risposta a tutto. Il mio consiglio? Partite dai dati, non dal marketing. Analizzate i vostri workload specifici, calcolate i costi reali (non teorici) e prendete decisioni basate sulla vostra realtà, non sui trend del momento.

Nel dubbio, iniziate piccolo e scalate gradualmente. L'approccio incrementale, per quanto meno sexy, vi permetterà di validare assunzioni e costi prima di committare risorse significative.

Il cloud è uno strumento, non un obiettivo. E come tutti gli strumenti, ha il suo posto e le sue limitazioni. La vera abilità sta nel saperlo utilizzare nel modo giusto, al momento giusto, per il workload giusto.

• Website

• Codemotion learning

• Website

•  Article
•  GitHub

•  Article (italian)
•  Telegram
•  GitHub

•  Article (italian)

•  Article (italian)
•  GitHub

Why Reverse Engineer IoT APIs?

Before diving into the technical details, you might wonder why someone would want to reverse engineer an IoT device's API. There are several legitimate reasons:

• Understanding device security and privacy implications
• Developing custom integrations with home automation systems
• Learning about network protocols and IoT communication patterns
• Troubleshooting device issues
• Creating documentation for undocumented APIs

The Setup

For this exploration, I used a combination of common networking tools and my home network setup, which includes:

• An OpenWRT router (providing advanced networking capabilities)
• A MacBook Pro (as the analysis platform)
• The target IoT device
• Basic networking tools: tcpdump, Wireshark, and mitmproxy

The beauty of this setup is that it's relatively simple and accessible to anyone with basic networking knowledge and a willingness to learn.

Network Traffic Analysis Approach

My journey began with passive network analysis. Instead of immediately attempting to intercept traffic, I first observed the device's communication patterns. This non-intrusive approach is crucial for several reasons:

1. It helps understand the device's normal behavior
2. It reveals the frequency and types of communications
3. It identifies the endpoints the device communicates with
4. It provides insights into the protocol patterns used

Using OpenWRT's capabilities, I set up a remote packet capture using tcpdump and streamed it directly to Wireshark on my Mac. This elegant solution allowed me to capture and analyze traffic in real-time without storing large capture files on the router:

ssh user@openwrt.local tcpdump -i lan host 192.168.123.123 -U -s0 -w - | sudo /Applications/Wireshark.app/Contents/MacOS/wireshark -k -i -

This command creates a powerful pipeline where:

• tcpdump captures packets on the router's LAN interface
• The capture is filtered to focus only on our IoT device
• The data is streamed directly to Wireshark for real-time analysis

Man-in-the-Middle Analysis

After understanding the basic communication patterns, I moved to a more active analysis approach using mitmproxy. This powerful tool allows us to intercept and inspect HTTPS traffic, which is increasingly common in IoT devices:

mitmproxy --set tls_version_client_min=SSL3

The use of mitmproxy with a custom certificate provides several advantages:

• Ability to inspect encrypted traffic
• Possibility to modify requests and responses for testing
• Better understanding of the API structure and authentication mechanisms
• Real-time interaction with the device's communication

Man-in-the-Middle (MITM) analysis is a technique where network traffic is intercepted and analyzed as it passes between two points - in our case, between an IoT device and its server. Think of it as being a "postal inspector" who can open, read, and even modify letters being sent between two parties, all while both parties believe they're communicating directly with each other.

1. Traffic Interception:

   • The MITM proxy positions itself between the IoT device and the internet
   • All traffic is routed through this proxy instead of going directly to its destination
   • This is typically achieved by configuring network settings or DNS

2. SSL/TLS Handling:

   • For encrypted traffic (HTTPS), the proxy acts as two participants:
     • It presents itself as the server to the IoT device
     • It presents itself as the device to the server
   • This allows it to decrypt, inspect, and re-encrypt the traffic

3. Traffic Analysis:

   • Once intercepted, the traffic can be:
     • Viewed in real-time
     • Logged for later analysis
     • Modified before being forwarded
     • Replayed or duplicated for testing

Best Practices and Ethical Considerations

While reverse engineering can be an exciting technical challenge, it's important to approach it responsibly:

1. Always work with devices you own: Never attempt to reverse engineer devices or networks without explicit permission
2. Keep security in mind: Document any vulnerabilities you discover and report them responsibly
3. Respect privacy: Be mindful of any personal data you might encounter during analysis
4. Document everything: Good documentation helps both your understanding and potential future reference
5. Stay legal: Ensure your activities comply with local laws and regulations

Tools & References

For those interested in exploring IoT reverse engineering, here are the official resources for the tools used in this article:

Core Tools

• Wireshark (wireshark.org)
  • The world's foremost network protocol analyzer
  • Features a rich GUI interface
  • Supports deep packet inspection and analysis
  • Available for Windows, macOS, and Linux
• tcpdump (tcpdump.org)
  • Command-line packet analyzer
  • Standard in most Unix-like operating systems
  • Perfect for remote capture and analysis
  • Lightweight and powerful
• mitmproxy (mitmproxy.org)
  • Free and open source interactive HTTPS proxy
  • Features both command-line and web interfaces
  • Perfect for API inspection and modification
  • Extensive documentation for advanced usage

Additional Resources

• OpenWRT (openwrt.org)
  • Open-source router firmware
  • Extensive networking capabilities
  • Perfect for advanced network analysis
  • Large community and documentation

Conclusion

Reverse engineering IoT device APIs is an enlightening exercise that combines networking knowledge, security understanding, and problem-solving skills. While the tools and techniques might seem complex at first, they provide valuable insights into how our connected devices work.

This exploration is just the beginning – there's much more to discover in the world of IoT communication. Whether you're a developer looking to create custom integrations, a security researcher interested in device behavior, or simply a curious technologist, understanding how IoT devices communicate can open up new possibilities for home automation and device integration.

Did you find this IoT reverse engineering journey interesting? This is just one of many technical adventures I share regularly. Subscribe to my newsletter to receive:

• In-depth technical tutorials and walkthroughs
• Tips and tricks for network analysis and security
• Early access to new articles and exclusive content
• Real-world case studies and problem-solving approaches
• Code snippets and tool recommendations

In the fast-paced world of DevOps and cloud-native applications, continuous integration and deployment (CI/CD) pipelines are the backbone of efficient software delivery. GitLab CI, Docker, and Kubernetes have emerged as powerful tools in this ecosystem, each bringing its own strengths to the table. However, combining these technologies to create a seamless build and deploy pipeline can be challenging, especially when it comes to building Docker images within a Kubernetes environment.

GitLab CI offers robust automation capabilities, Docker provides consistent and portable environments, and Kubernetes excels at orchestrating containerized applications. The challenge lies in bridging these technologies effectively, particularly when building Docker images as part of your CI pipeline running in Kubernetes.

Traditionally, tools like Kaniko have been used to build Docker images without requiring a Docker daemon. While Kaniko is a powerful solution, it's not always the best fit for every scenario. In this article, we'll explore an alternative approach: using Docker-in-Docker (DinD) with GitLab CI's Kubernetes executor to build Docker images directly within your Kubernetes cluster.

This method leverages GitLab Runner's Kubernetes executor and the Docker-in-Docker technique to create a flexible and powerful build environment. By the end of this article, you'll understand how to:

1. Set up GitLab Runner with the Kubernetes executor
2. Implement Docker builds in your GitLab CI pipeline
3. Build and push Docker images from within Kubernetes

Let's dive in and explore how to harness the power of GitLab CI, Docker, and Kubernetes to create an efficient and scalable build pipeline.

2. Understanding the Docker-in-Docker (DinD) Approach

Docker-in-Docker (DinD) is a technique that allows you to run Docker inside a Docker container. This approach is particularly useful in CI/CD environments where you need to build Docker images as part of your pipeline, but you don't have direct access to the host's Docker daemon.

How Docker-in-Docker Works

In a typical Docker setup, containers interact with the Docker daemon running on the host machine. With DinD, we create a container that has its own Docker daemon. This container can then be used to build, run, and manage other Docker containers independently of the host system.

The process works as follows:

1. A Docker container is started with its own Docker daemon.
2. This container has the ability to create and manage other Docker containers and images.
3. Within your CI/CD pipeline, you interact with this containerized Docker daemon to build your application images.

Advantages of Docker-in-Docker

1. Isolation: DinD provides an isolated environment for building and testing Docker images, reducing potential conflicts with other processes on the host system.
2. Flexibility: It allows you to use Docker commands in your CI/CD pipeline without needing to modify the host system or rely on shared Docker resources.
3. Security: By isolating the Docker build process, you can potentially enhance security by limiting the impact of compromised build scripts.
4. Consistency: DinD ensures that your build environment is consistent across different CI/CD runners, as it's contained within a Docker image itself.

Potential Drawbacks and Considerations

1. Performance: Running Docker inside Docker can have some performance overhead compared to using the host's Docker daemon directly.
2. Complexity: DinD adds another layer to your CI/CD setup, which can increase complexity and potential points of failure.
3. Storage: Each DinD container has its own storage, which means you may need to manage caching and cleanup more carefully to avoid excessive disk usage.
4. Security Considerations: While DinD can enhance security through isolation, it also requires running containers with elevated privileges, which should be carefully managed.

DinD in GitLab CI and Kubernetes

In the context of GitLab CI and Kubernetes, we'll be using DinD to create a Docker build environment within our Kubernetes-based CI runners. This approach allows us to leverage Kubernetes for scaling our CI/CD infrastructure while still maintaining the flexibility to build Docker images as part of our pipeline.

By understanding the DinD approach, we can better appreciate how it enables us to build Docker images within a Kubernetes environment, providing a powerful alternative to tools like Kaniko.

3. Setting Up the Kubernetes Executor

The Kubernetes executor for GitLab Runner allows you to use Kubernetes to run your CI/CD jobs. This section will guide you through the process of setting up and configuring the Kubernetes executor to support Docker-in-Docker (DinD) builds.

3.1 Overview of GitLab Runner's Kubernetes Executor

The Kubernetes executor creates a Pod for each GitLab CI job. This Pod contains the following containers:

1. A helper container to handle Git operations
2. A container for the CI job itself
3. Additional service containers as needed (in our case, a Docker daemon container)

3.2 Prerequisites

Before setting up the Kubernetes executor, ensure you have:

• A running Kubernetes cluster
• kubectl installed and configured to access your cluster
• Helm installed (optional, but recommended for easier installation)

3.3 Installing GitLab Runner in Your Kubernetes Cluster

You can install GitLab Runner using Helm or by applying Kubernetes manifests directly. Here's how to do it using Helm:

1. Add the GitLab Helm repository:

   helm repo add gitlab https://charts.gitlab.io

2. Install GitLab Runner:

   helm install --namespace gitlab gitlab-runner gitlab/gitlab-runner \ --set gitlabUrl=https://gitlab.com/ \ --set runnerRegistrationToken=<your-runner-token>

Replace <your-runner-token> with your actual GitLab runner registration token.

3.4 Configuring the Executor for DinD

To enable Docker-in-Docker builds, you need to modify the GitLab Runner configuration. Create a values.yaml file with the following content:

gitlabUrl: https://gitlab.com/ 
runnerRegistrationToken: "<your-runner-token>" 
runners:   
	config: |    
	[[runners]]      
	[runners.kubernetes]        
	image = "ubuntu:20.04"        
	privileged = true      
	[[runners.kubernetes.volumes.empty_dir]]        
	name = "docker-certs"        
	mount_path = "/certs/client"        
	medium = "Memory"   

Apply this configuration:

helm upgrade --install --namespace gitlab gitlab-runner gitlab/gitlab-runner -f values.yaml

3.5 Explaining the Configuration

• privileged = true: This allows the runner to use Docker-in-Docker.
• volumes.empty_dir: This creates a shared volume for Docker certificates.
• services: This specifies the Docker-in-Docker service container.
• helpers.image: This sets the GitLab Runner helper image.

3.6 Verifying the Setup

To verify that your Kubernetes executor is set up correctly:

1. Go to your GitLab project's CI/CD settings.
2. Check that the runner is registered and active.
3. Run a simple pipeline to test the setup.

With this configuration, your GitLab Runner in Kubernetes is now ready to handle Docker-in-Docker builds. In the next section, we'll look at how to implement Docker builds in your GitLab CI pipeline using this setup.

4. Implementing Docker Builds in GitLab CI

Now that we have our Kubernetes executor set up with Docker-in-Docker capabilities, let's implement Docker builds in our GitLab CI pipeline. This section will guide you through creating a .gitlab-ci.yml file, defining stages and jobs, and configuring the Docker service.

4.1 Creating a .gitlab-ci.yml File

In the root of your project, create a file named .gitlab-ci.yml. This file will define your CI/CD pipeline.

4.2 Defining Stages and Jobs

Let's start with a basic structure for our pipeline:

stages:   
	- build  
	- test  
	- deploy 

variables:   
	DOCKER_TLS_CERTDIR: "" 
	
build:   
	stage: build  
	image: docker:20.10.16  
	services:    
		- docker:20.10.16-dind  
	before_script:    
		- docker info  
	script:    
		- docker build -t my-app:$CI_COMMIT_SHA .    
		- docker push my-app:$CI_COMMIT_SHA 

test:   
	stage: test  
	script:    
		- echo "Run your tests here" 

deploy:   
	stage: deploy  
	script:    
		- echo "Deploy to Kubernetes here"

4.3 Explaining the Configuration

Let's break down the key components of this configuration:

• stages: Defines the pipeline stages: build, test, and deploy.
• variables:
  • DOCKER_TLS_CERTDIR: "": This disables TLS for the Docker daemon, which is fine for CI/CD environments but not recommended for production.
• build job:
  • image: docker:20.10.16: Uses the Docker image as the base for this job.
  • services: - docker:20.10.16-dind: Specifies the Docker-in-Docker service.
  • before_script: Runs docker info to verify the Docker setup.
  • script: Contains the Docker build and push commands.

4.4 Configuring the Docker Service

The services section in the build job is crucial for enabling Docker-in-Docker:

services: - docker:20.10.16-dind

This starts a Docker daemon inside the job's container, allowing us to use Docker commands in our script.

4.5 Building the Docker Image

In the script section of the build job, we use standard Docker commands:

script: - docker build -t my-app:$CI_COMMIT_SHA . - docker push my-app:$CI_COMMIT_SHA

• docker build: Builds the image using the Dockerfile in your project root.
• $CI_COMMIT_SHA: A GitLab CI variable containing the commit SHA, used here as the image tag.
• docker push: Pushes the built image to a registry (you'll need to configure authentication, which we'll cover in the next section).

4.6 Adding Authentication for Docker Registry

To push images, you'll need to authenticate with your Docker registry. Add these lines to your build job:

before_script: - docker info - echo "$DOCKER_PASSWORD" | docker login -u "$DOCKER_USERNAME" --password-stdin $DOCKER_REGISTRY

Make sure to set DOCKER_USERNAME, DOCKER_PASSWORD, and DOCKER_REGISTRY as CI/CD variables in your GitLab project settings.

With this configuration, you now have a mimimal GitLab CI pipeline that can build Docker images using Docker-in-Docker within a Kubernetes environment.

7. Conclusion

Throughout this article, we've explored a powerful approach to building Docker images and deploying them to Kubernetes using GitLab CI, all without relying on Kaniko. Let's recap the key points we've covered:

1. We started by understanding the Docker-in-Docker (DinD) approach, which allows us to build Docker images within our CI/CD pipeline running in Kubernetes.
2. We then set up the Kubernetes executor for GitLab Runner, configuring it to support DinD builds.
3. We implemented Docker builds in our GitLab CI pipeline, creating a .gitlab-ci.yml file that defines our build, test, and deploy stages.

This approach offers several advantages:

• Flexibility: By using DinD, we maintain the full capabilities of Docker in our build process, allowing for complex multi-stage builds and custom Docker commands.
• Familiarity: For teams already comfortable with Docker, this method leverages existing knowledge and tools.
• Integration: This setup integrates seamlessly with GitLab CI and Kubernetes, creating a smooth workflow from code commit to deployment.

However, it's important to note that this method isn't without its considerations:

• Resource Usage: Running Docker inside Docker can be more resource-intensive than alternative methods like Kaniko.
• Security: While we've discussed security best practices, running containers in privileged mode (as required for DinD) needs careful management.

As with any CI/CD solution, the key to success is continuous improvement. Regularly review your pipeline, gather feedback from your team, and stay updated with the latest best practices in the rapidly evolving world of DevOps.

Remember, the goal of CI/CD is to enhance your team's ability to deliver value to your users. Whether you choose this DinD approach, Kaniko, or another method, the most important factor is that it meets your team's needs and helps you deliver high-quality software efficiently and reliably.

By mastering these techniques, you're well-equipped to build robust, efficient CI/CD pipelines that can handle complex Docker builds and Kubernetes deployments. As you implement and refine this process, you'll be contributing to a faster, more reliable software delivery lifecycle for your organization.

É arrivato il momento di una pausa!

Sarò in vacanza in due periodi questa estate: dal 15 al 21 luglio e dal 19 al 30 agosto.

Durante queste date non sarò disponibile per nuove richieste o per lavorare su progetti in corso. Vi chiedo gentilmente di considerare queste date per eventuali scadenze o necessità. Se avete qualcosa di urgente, vi prego di farmelo sapere in anticipo così da poter pianificare al meglio.

Auguro anche a voi delle splendide vacanze, sperando che possiate godervi un po' di relax e divertimento!

Grazie mille per la vostra comprensione. Ci sentiamo presto!

I recently encountered such an issue on a project I'd been working on. The problem only showed up in production, and it took me digging into Docker Compose resource limit specifications to find the solution. By tuning Docker resources and limiting them in specific ways, we were able to replicate the bug and finally fix it.

Docker Resources: Taming the Beast

Docker provides runtime options that allow you to fine-tune container running resources. By default, containers have no resource constraints, using as much of a given resource as the host's kernel scheduler allows. However, this can be problematic in production environments where resources are limited.

Fortunately, Docker offers ways to control how much memory or CPU a container can use by setting runtime configuration flags with the docker run command. The official documentation explores when and why you should set such limits, as well as the potential implications of doing so: Runtime options with Memory, CPUs, and GPUs | Docker Docs.

Dynamic Resource Management: The Power of docker update

But what about containers that are already running? Can we still tune their resources? Thankfully, the answer is yes. Docker's update command allows you to dynamically update container configuration and prevent containers from consuming too many resources on your host.

With a single command, you can place limits on a single container or multiple containers at once. Simply provide a space-separated list of container names or IDs.

Find out more here: docker container update | Docker Docs

Compose Resources: Orchestrating Constraints

When using Docker Compose as an orchestrator, you can specify resource constraints in the resources section of your Compose file. This allows you to configure physical resource constraints for your containers.

You can specify limits and reservations for resources such as memory, CPUs, and GPUs. These constraints are enforced by the platform, ensuring that containers don't consume more than their allocated share.

For example:

• limits: The platform must prevent the container from allocating more.
• reservations: The platform must guarantee the container can allocate at least the configured amount.

You can read all the details on: Compose Deploy Specification | Docker Docs

Conclusion: A Cohesive Development Environment

Docker provides a powerful way to create development environments that closely mirror production settings. By leveraging Docker Compose and its resource management capabilities, you can ensure that your containers run efficiently and effectively.

Make sure to drop your email down here to get new articles as they are published!

As an indie software developer, I frequently have to deploy monitoring solutions for software I develop or support. I recently had the pleasure of exploring the evolution of Grafana from a visualization tool to a comprehensive monitoring suite with various modules. In this article, we'll dive into its collector and explore the journey of migrating to the new Alloy agent.

Introducing Alloy Collector

Alloy is the latest addition to the Grafana ecosystem, offering enhanced performance and scalability for data collection. Unlike its predecessor Flow Agent, Alloy introduces a more efficient and robust data ingestion mechanism. It's an open source distribution of the OpenTelemetry Collector that's 100% OTLP compatible.

Grafana Agent proved to be flexible, performant, and compatible with multiple ecosystems. Then they launched Promtail for Loki logs and the Grafana Agent Operator for Kubernetes-specific cases. It worked but the many options made it harder to determine which agents to use.

Grafana Agent and Grafana Agent Operator are deprecated and will enter into Long-Term Support beginning today (April 9, 2024). This means both projects will no longer receive new feature updates, as all future innovation will be focused on Alloy. Grafana Labs recommends to begin planning a transition towards the new Grafana Alloy collector.

Show me the code: deploy Alloy Collector

Using Alloy requires a minimal setup:

• grab your distribution package or binary
• create a service to auto start or use the distribution's provided one
• create a configuration file to manage some log/metrics ingestion and forward it to your Grafana instance of choice.

Given you installed the, let's say, Debian package you'll go ahead and create a configuration file in /etc/alloy/config.alloy:

prometheus.exporter.self "integrations_alloy" { }

discovery.relabel "integrations_alloy" {
  targets = prometheus.exporter.self.integrations_alloy.targets

  rule {
    target_label = "instance"
    replacement  = constants.hostname
  }

  rule {
    target_label = "alloy_hostname"
    replacement  = constants.hostname
  }

  rule {
    target_label = "job"
    replacement  = "integrations/alloy-check"
  }
}

prometheus.scrape "integrations_alloy" {
  targets    = discovery.relabel.integrations_alloy.output
  forward_to = [prometheus.relabel.integrations_alloy.receiver]  

  scrape_interval = "60s"
}

prometheus.relabel "integrations_alloy" {
  forward_to = [prometheus.remote_write.metrics_service.receiver]

  rule {
    source_labels = ["__name__"]
    regex         = "(prometheus_target_sync_length_seconds_sum|prometheus_target_scrapes_.*|prometheus_target_interval.*|prometheus_sd_discovered_targets|alloy_build.*|prometheus_remote_write_wal_samples_appended_total|process_start_time_seconds)"
    action        = "keep"
  }
}

prometheus.remote_write "metrics_service" {
  endpoint {
    url = "{{ grafana_metrics_url }}"

    basic_auth {
      username = "{{ grafana_metrics_id }}"
      password = "{{ grafana_cloud_token }}"
    }
  }
}

loki.write "grafana_cloud_loki" {
  endpoint {
    url = "{{ grafana_logs_url }}"

    basic_auth {
      username = "{{ grafana_logs_id }}"
      password = "{{ grafana_cloud_token }}"
    }
  }
}

loki.relabel "journal" {
  forward_to = []

  rule {
    source_labels = ["__journal__systemd_unit"]
    target_label  = "unit"
  }
  rule {
    source_labels = ["__journal__boot_id"]
    target_label  = "boot_id"
  }
  rule {
    source_labels = ["__journal__transport"]
    target_label  = "transport"
  }
  rule {
    source_labels = ["__journal_priority_keyword"]
    target_label  = "level"
  }
  rule {
    source_labels = ["__journal__hostname"]
    target_label  = "instance"
  }
}

loki.source.journal "read" {
  forward_to = [
    loki.write.grafana_cloud_loki.receiver,
  ]
  relabel_rules = loki.relabel.journal.rules
  labels = {
    "job" = "integrations/node_exporter",
  }
}

This can be a nice starting point, it will:

• get metrics from the instance and tag/label them;
• grab the journal logs and tag/label them;
• push everything to Grafana Cloud (as long as you replace placeholders with real credentials).

Migrate to Alloy

If you are currently using Grafana tools, such as Grafana Agent or Grafana Agent Operator, Grafana Labs has converters and tools for moving to Grafana Alloy:

• Migrate from Operator
• Migrate from Prometheus
• Migrate from Promtail
• Migrate from Grafana Agent Static
• Migrate from Grafana Agent Flow

If you are using vanilla OpenTelemetry Collector:

• Migrate from OpenTelemetry Collector

In my experience they are not 100% plug-and-play but they will help for sure.

Closing Thoughts

I'm thrilled to have migrated my project to Alloy Collector. Grafana Cloud's free tier offers a great starting point for small-scale deployments, and the option to switch to an on-premise setup provides flexibility. For those still using Flow Agent, it's time to make the jump to Alloy and reap the benefits of improved performance and scalability.

Find more here:

• From Agent to Alloy: Why we transitioned to the Alloy collector and why you should, too | Grafana Labs
• Introducing an OpenTelemetry Collector distribution with built-in Prometheus pipelines: Grafana Alloy | Grafana Labs
• Grafana Alloy | Grafana Alloy documentation

With many and more features, full open-source development and standard compatibility it will be my monitoring solution of choice for the time being.

Feel free to subscribe down below to stay in touch I'll make sure to report if things will change in that regard.

Are you tired of adding tools to your Kubernetes clusters? Do you want a more integrated and straightforward approach to ingress control? Look no further than Caddy, an Nginx, Traefik, and HAProxy alternative. In this article, we'll explore how Caddy could simplify your Kubernetes management tasks while providing advanced features like caching and automatic HTTPS.

As someone who is using Nginx as ingress for K8S with cert manager to manage HTTPS, I understand the struggle of managing multiple tools for cluster routing. Following the principle of "https-anywhere," we need an ingress controller that can handle both Kubernetes service access types and automatic HTTPS. I tried Traefik thinking it was the solution, until i discovered it has no cache support on the community version and rolled back to Nginx. Then I stumbled upon Caddy thanks to Paul Butler – The hater’s guide to Kubernetes. This led me on a journey to discover Caddy, a lightweight and modern ingress controller that offers the features we need without the bloat of other solutions.

Simple, easy, fast, fun

Caddy is incredibly easy to use and set up, thanks to its simple and intuitive configuration file format. You can easily create and manage ingress rules, and Caddy provides a fun and interactive way to monitor your cluster's traffic flow. With Caddy, you don't need extensive knowledge of networking protocols or Kubernetes configurations; it takes only minutes to set up and start enjoying the benefits of this solution.

Full-fledged: cache, Acme client

One area where Caddy outshines other ingress controllers is its built-in caching mechanism. This feature allows you to offload some of the traffic load from your Kubernetes services to Caddy's cache, ensuring a smoother and faster experience for your users. Additionally, Caddy integrates with the popular Acme client, enabling automated SSL/TLS certificates management for your services. With these features, you can simplify your cert management tasks and avoid the headaches of dealing with multiple tools for this critical aspect of ingress control.

Modern and well-documented

Caddy is modern in every sense of the word: its syntax, configuration file format, and overall design are all tailored to provide an enjoyable development experience. The official documentation is also top-notch, featuring a comprehensive guide on how to get started with Caddy as well as detailed descriptions of all available configurations options. By following their guidelines, even less tech-savvy users can set up and manage Caddy efficiently and effectively.

Closing/Reference

While I'm not using Caddy yet for my existing projects, I plan to give it a try for new endeavors. By leveraging its simple configuration syntax, built-in caching capabilities, and Acme support, we can significantly simplify our Kubernetes management tasks and enhance user experience. Follow me on Twitter for future updates and feel free to drop your email for any further inquiries!

Resources:

• Caddy server official documentation - https://caddyserver.com/docs/
• Caddy ingress controller for Kubernetes - https://github.com/caddyserver/ingress
• GitHub repository for Caddy server - https://github.com/caddyserver/caddy
• Caddy getting started documentation - https://caddyserver.com/docs/getting-started

Understanding Kubernetes service access types has been tough for me. It felt confusing and overwhelming at times. So, I decided to write this article to help others who might feel the same way. My goal is to break down these concepts into simpler terms. I hope to make it easier for you to get a handle on how to use these services in your own projects. Let's dive into the three main types of Kubernetes services: ClusterIP, NodePort, and LoadBalancer, providing insights into their use cases, advantages, and limitations.

ClusterIP: Internal Service Access

Overview

ClusterIP is the default Kubernetes service type, making it a fundamental concept for new Kubernetes users to grasp. It assigns a unique IP address to the service within the cluster, enabling pod-to-pod communication. This IP address is reachable only from within the cluster, making ClusterIP services an excellent choice for internal communication between different services in your application.

Use Cases

ClusterIP services are ideal for scenarios where you do not need external traffic to reach your application components. Examples include backend services like databases or internal APIs that should only be accessible to other components within the same Kubernetes cluster.

Advantages

• Isolation and Security: Since ClusterIP services are only accessible within the cluster, they offer an additional layer of security by isolating internal network traffic from external access.
• Simplicity: Being the default service type, ClusterIP services are straightforward to set up, requiring minimal configuration.

Limitations

• Internal Access Only: The major limitation of ClusterIP is that it cannot be accessed from outside the Kubernetes cluster, making it unsuitable for services that need to be exposed to the internet or external networks.

NodePort: External Access via Nodes

Overview

NodePort is a type of Kubernetes service that makes your service accessible from outside the Kubernetes cluster by opening a specific port on all nodes (VMs or physical servers) of the cluster. Traffic that is sent to this port is forwarded to the service. The NodePort service type extends the functionality of ClusterIP by adding a layer that allows external access.

Use Cases

NodePort services are useful when you need external access to your application but do not have a LoadBalancer available or for testing purposes. They are also helpful in environments where direct access to each node is possible.

Advantages

• External Access: NodePort services allow external clients to access services running inside the Kubernetes cluster, offering a straightforward method to expose your application to the outside world.
• Flexibility: They provide a simple way to access services from outside the Kubernetes cluster, especially in environments where a LoadBalancer might not be available or necessary.

Limitations

• Port Management: Since NodePort services require opening a specific port across all nodes, managing these ports and avoiding conflicts can become challenging as the number of services grows.
• Scalability: Directly exposing services through NodePort can lead to scalability issues, as it bypasses the more sophisticated load balancing capabilities of a LoadBalancer service.

LoadBalancer: Cloud-Provider Integration for Scalability

Overview

The LoadBalancer service type integrates Kubernetes with the cloud provider's load balancer, allowing for automatic creation and management of an external load balancer. This load balancer distributes external traffic to the Kubernetes services, offering a seamless way to expose services to the internet.

Use Cases

LoadBalancer services are ideal for production environments where you need to expose your application to the internet reliably and scalably. They are commonly used for front-end web applications, APIs, or any service that requires robust, scalable external access.

Advantages

• Scalability and Reliability: LoadBalancer services leverage the scalability and reliability of cloud provider platforms, providing a high level of availability for your applications.
• Simplicity: The process of exposing a service to the external internet is simplified, as the cloud provider automatically handles the creation and configuration of the load balancer.

Limitations

• Cost: Utilizing LoadBalancer services can incur additional costs, as cloud providers charge for the load balancing resources that are provisioned. Usually to avoid greater costs you will create a LoadBalancer service for the ingress only, then the ingress (like Traefik or Nginx) provides cluster smart routing.
• Cloud-Dependent: This service type is dependent on the cloud provider's infrastructure, making it less suitable for on-premises or bare-metal environments.

Conclusion

Understanding the differences between ClusterIP, NodePort, and LoadBalancer services in Kubernetes is crucial for architects and developers looking to efficiently design and deploy applications. Each service type offers unique advantages and is suited to different use cases, from internal cluster communication to exposing applications to the external world. By leveraging these services intelligently, you can ensure that your applications are scalable, secure, and accessible according to your needs.

Introduction to the GPT Store

The GPT Store marks a revolutionary step in the AI world, introducing a unique platform where innovative GPTs crafted by community developers come to life. This initiative by OpenAI transforms how we access and leverage Generative Pre-trained Transformers (GPTs), making cutting-edge AI technology more accessible. The store serves as a digital marketplace, showcasing a diverse range of GPT applications, from enhancing productivity to revolutionizing education and lifestyle sectors. It's not just a store; it's a gateway to the future of AI, where tech enthusiasts can explore the possibilities of GPTs.

The Vision and Impact of the GPT Store

The GPT Store embodies OpenAI's vision of AI technology accessible. It's designed to be a breeding ground for innovation and creativity in AI. By making GPTs more accessible, the store is set to significantly impact various industries, from small businesses leveraging AI for growth to educators integrating advanced technology into learning. It's a shift towards more inclusive and widespread use of AI. The GPT Store is changing how we use AI.

Features and Offerings of the GPT Store

The GPT Store stands out for its diverse range of offerings, catering to various needs and industries. Key features include:

• Variety of Applications: From chatbots to content creation tools, the store houses GPTs designed for multiple purposes.
• User-Friendly Interface: It offers an intuitive platform, making it easy for beginners to explore and use GPTs.
• Community-Centric Approach: The store encourages submissions from developers, creating a vibrant community of AI enthusiasts and innovators.

This diversity not only showcases the versatility of GPTs but also opens up endless possibilities for users to integrate AI into their projects and workflows.

Community and Developer Engagement

A cornerstone of the GPT Store is its commitment to fostering a robust community. It's a place where developers, from seasoned AI experts to beginners, can contribute their GPT creations, share insights, and learn from each other. This engagement:

• Encourages Innovation: By pooling diverse ideas, the store accelerates innovation in AI applications.
• Supports Learning and Development: New developers find a supportive environment for honing their skills.
• Facilitates Collaboration: The platform enables collaborations, leading to more refined and effective GPT solutions.

This, hopefully, vibrant ecosystem not only enriches the store's offerings but also propels the AI field forward by harnessing collective creativity and knowledge.

Looking Ahead: The Future of AI with the GPT Store

As we look to the future, the GPT Store is poised to play a pivotal role in shaping AI's trajectory. Its potential to democratize AI development suggests a future where AI integration becomes standard across various sectors, fostering innovation and efficiency. I can foresee:

• Wider Adoption in Everyday Solutions: GPTs will likely become integral in daily tech solutions, enhancing user experiences.
• Advancement in AI Research and Development: The store could become a hub for groundbreaking AI research.
• Community-Driven AI Evolution: The collective contributions will continuously refine and advance GPT applications.

Find out more here: Introducing the GPT Store.

Un caloroso augurio di buone feste!

Vi ringrazio per il sostegno nell'ultimo anno. Approfittiamo della stagione festiva per rilassarci e accogliere il nuovo anno con entusiasmo.

Buone feste e felice Anno Nuovo!

Estendo a voi i miei auguri per un periodo di festività sereno e un nuovo anno di gioia e successo. Ricordate di celebrare la bellezza della vita!

Vacanze

Sarò in vacanza dal 22 dicembre al 7 gennaio con accesso limitato alle e-mail. Ritornerò riposato e pronto per assistervi il 7 gennaio.

A warm holiday wish!

Thank you for your support over the past year. Let's use the holiday season to relax and welcome the new year with enthusiasm.

Happy Holidays and a Joyful New Year!

I extend to you my wishes for a peaceful holiday season and a new year of joy and success. Remember to celebrate the beauty of life!

Holidays

I will be on holiday from December 22nd to January 7th with limited access to emails. I will return rested and ready to assist you on January 7th.

Introduction to Kubernetes

Kubernetes, often abbreviated as K8s, is an open-source container orchestration platform that automates the deployment, scaling, and management of applications. As a pivotal aspect of DevOps, it allows expansive control over containerized applications and services. Kubernetes' proliferating popularity is indicative of its robust framework and broad ecosystem. However, Kubernetes is a double-edged sword—its sheer complexity can be overwhelming.

This complexity can, nevertheless, be tamed with the right tools. These are the tools, from command-line interfaces to visualizers, I use to simplify the interaction with Kubernetes.

These utilities make Kubernetes more approachable without undermining its powerful functionalities.

Mastering Kubernetes With 'kubectl'

kubectl is your gateway to interacting with Kubernetes. This command-line tool communicates with Kubernetes clusters (groupings of nodes), executing commands through the Kubernetes API. You can use kubectl to deploy applications, inspect resources, and manage your cluster.

For instance, with a single kubectl apply command, you can deploy an application onto your Kubernetes cluster. Moreover, kubectl also helps with debugging and updating applications in real time, making it indispensable in the DevOps stack.

However, remember, kubectl is a very sharp tool: use kubectl config use-context to make sure you're running commands on the right cluster!

Simplifying Kubernetes Configuration With 'kustomize'

kustomize is a standalone tool used for customizing Kubernetes configurations. It manipulates the configuration directly, side-stepping templating and maintaining the original YAML structure. This results in cleaner, more maintainable configurations.

Let's say you want to alter the number of replicas of an object across different environments (dev, staging, and prod). Instead of having separate YAML files for each environment, 'kustomize' allows you to apply changes directly, maintaining a single source of truth.

Despite the emergence of helm, kustomize still holds its ground due to its simplicity, underline 'Kubernetes native' philosophy, and seamless integration with kubectl.

Enhancing Kubernetes Development Workflow With 'skaffold' and 'kompose'

skaffold and kompose are tools that supercharge the Kubernetes development workflow.

skaffold automates the process of building, pushing, and deploying applications to a Kubernetes environment. It handles the workflow, allowing you to focus on writing and maintaining applications.

kompose, on the other hand, is a conversion tool. With a simple kompose convert command, you can transform Docker Compose files into Kubernetes resources. This allows developers already versed in Docker to make a smooth transition to Kubernetes.

Visualizing Kubernetes With 'k9s'

k9s provides a terminal-based UI to interact with your Kubernetes cluster. It helps you to visualize and manage your applications in real time. With the capability of viewing logs, events, and pods on the fly, k9s serves as an invaluable tool for tracking and monitoring your Kubernetes.

Conclusion

Kubernetes is a powerhouse, but its complexity can be intimidating. These tools—kubectl, kustomize, skaffold, kompose, and k9s—make Kubernetes a lot more approachable.

When used in harmony, they can propel your DevOps to new heights, encapsulating the essence of what Kubernetes was intended - automating, simplifying, and iterating. At the end of the day, continuous learning and utilisation of such tools can help to unravel the true potential of Kubernetes.

Python has established itself as as a reputable language in the realms of scripting and programming. Of all the sectors, data science stands out as one where Python has shown great promise, mainly attributable to its library Pandas. Arguably, one of the most utilized Python libraries for data manipulation, Pandas have grown in popularity, given its powerful features and direct compatibility with Excel for Python coding. This has enabled it to reach a wide audience, making data science fascinating and simpler.

Setting up Python

The journey to harnessing the power of Pandas starts with setting up Python and importing the library. Once this is done, users can embark on the journey to explore and manipulate data efficiently.

Leveraging IDE

For Python programming, one can use Jupyter Lab, a powerful Integrated Development Environment (IDE). You can delve into this more comprehensively on Project Jupyter | Home.

Colaboratory – A Gem from Google

If you wish to avoid setting up an environment, Google has made it easier with Colaboratory. You can explore more about it here: Welcome to Colaboratory - Colaboratory.

Power of Pandas

Pandas is an open-source, Python library providing high-performance, easy-to-use data structures and data tools. While it resembles a spreadsheet allowing users to manipulate and analyze structured data, understanding every aspect of Pandas can feel like learning a new language. Let's shed some light into some of its core features.

Working with the Pandas DataFrame

One of the first steps is understanding the pandas DataFrame. This two-dimensional labeled data structure has columns that potentially hold different types of data. It’s a lot like a database or a spreadsheet and versatile enough to accommodate various data formats.

Reading and Writing Functions

Pandas simplifies the process of reading in various file types and writing your DataFrame to files or databases. It’s a hassle-free way to manage data processing, allowing you to focus more on data analysis.

Exploring Your Data

Understanding your data is vital - a task made easy by built-in functions such as 'head', 'tail', and 'sample'. These functions allow you to quickly explore your data set, seeing both the big picture and the crucial details.

Boolean Expressions and .loc Method

Another important concept is understanding how to filter data using Boolean expressions with the .loc method. This method provides a way to select data based on specific conditions.

Querying Data

The '.query' function takes data filtering further. This method allows you to filter data based on complex logic statements and conditions. It's a more dynamic way to retrieve data.

Summarizing Data

To draw conclusions from your data, employing several summarization methods may quickly analyze your data. This allows us to perform aggregate functions such as mean, sum, and count with ease.

Grouping Data

Pandas' 'groupby' method is particularly useful when working with categorical types. This allows specific column groupings, providing a structured and organized way of viewing data.

Creating New Columns

Creating new columns based on operations on existing columns is another key part of data wrangling. With this, we can generate new fields from our data that provide additional insights.

Sorting Data

You can sort your data through specific column types using the 'sort_values' method. This provides a streamlined way of organizing your data for easier analysis.

Handling Missing Data

Working with real data means dealing with missing values. On such occasions, methods like 'dropna' and 'fillna' come in handy, allowing you to handle missing values in an effective way.

Combining Data

Lastly, the option to stack together or merge data frames using methods such as 'concat' and 'merge' helps in creating a comprehensive dataset.

In conclusion, mastering pandas involves understanding these essentials but also requires continuous practice. For a better understanding, this Learning Pandas? Start Here - YouTube tutorial delivers an excellent starting point for your journey into mastering Pandas. It covers all these concepts and more, demonstrating how they come together for data manipulation and analysis.

PandasAI – Simplifying Data Science

The data science field is constantly evolving, and for those fans of Pandas, exciting news awaits: PandasAI. This new Python library for data science integrates AI into data analysis, making it conversational and even more interactive.

After setting up an OpenAI API key and installing necessary libraries such as Pandas, PandasAI, and OpenAI, you're set to explore the immense power of PandasAI. Like all things, PandasAI has its weaknesses, struggling with complex queries. Despite its limitations, it's noteworthy that this tool provides a robust framework for interacting with data frames in a conversational manner.

So what?

In conclusion, Python and Pandas provide a great avenue for harnessing the power of data in a simpler yet powerful way. Combining this with innovations such as PandasAI unlocks the future of data science, one filled with promises of more efficient and reliable data analysis.

As long as everything is all right

My job involves a lot of things, but managing infrastructure as code using Ansible holds a special spot in my heart. Each day is driven by the thrill of seeing ansible's efficiency and how easily it simplifies tasks over the traditional scripts.

Not limited to just managing infrastructure, Ansible has proven invaluable for an assorted variety of tasks. From configuration management, application deployment, to orchestrating complex IT tasks. It plays a crucial role in interconnecting my systems.

A key integration that has caught my attention is its ability to invoke Terraform. Yes, that's right! Using Ansible, you can automate your Terraform procedures, making it an even more powerful tool in your IT toolbox.

When you encounter a problem

Using Ansible is not all smooth sailing though. When confronted with errors, the Ansible command output can quickly turn into a jigsaw puzzle. The output is often cluttered and almost unreadable. Navigation through the maze of code to correct the issue becomes a significant challenge.

I used to refrain from directly tackling this problem, opting for the lengthy process of copy-pasting the command output into an editor to simplify it and make the errors easier to spot. Every time I did this, I wished for a better solution.

Discovering Ansible stdout callback plugins

My prayers for a more readable output were answered when I stumbled upon Ansible stdout callback plugins. These plugins handle Ansible's output in various ways to meet your needs.

Okay, it's not really a trick, but it looks like one. A quick change to my ansible.cfg file by adding stdout_callback = yaml drastically impacted the readability of the command output. It brought life to the previously chaotic mess. The output display, transformed through YAML, was crisp, clean, and straightforward to comprehend.

Trying out stdout_callback plugins

If you too are intrigued and want to explore stdout callback plugins for yourself, here are the steps to do it:

1. Go to your Ansible Configuration file ansible.cfg
2. Under the defaults section, add stdout_callback = yaml.

This simple addition will transform your Ansible output, making it much more readable and easy to manage.

Harness the power of Ansible stdout callback plugins. They not only make your results more readable, but they also save you the hassle of having to manually format your output, making your work with Ansible more intuitive and error-free!

Onward with Ansible

Incorporate the efficiency of Ansible in your daily tasks and experience its potential beyond just managing infrastructure. Don’t forget to try invoking Terraform with Ansible and employing stdout callback plugins for a smooth workflow experience. It has greatly improved my job as a devops, and I am confident it will do the same for you.

Happy ansible-ing!

Introduction to Autonomous AI Agents

Artificial Intelligence (AI) continues to revolutionize the technology landscape, with one of the most promising advancements being Autonomous AI Agents. Autonomous AI agents are systems powered by AI that can make decisions on their own and take actions to achieve specific goals, without any human intervention. Given their ability to self-direct, they are at the cutting edge of AI development. This article will delve deeper into the concept of autonomous AI agents, their connections with other AI technologies, the challenges they face, and their future implications.

Understanding the Concept: Autonomous AI Agents

An autonomous AI agent performs actions and makes decisions independently, based on its perception of the environment or the state of affairs. Autonomy and 'agenthood' are vital elements for these systems. In simple terms, autonomy gives them the freedom to decide, while 'agenthood' implies the agent's capacity to act, consequently affecting its environment.

An autonomous AI agent consists of three major components. Firstly, it perceives the environment, gathering information through sensors or other data input methods. Secondly, it takes autonomous decisions based on the perceived information, typically using AI algorithms. Lastly, it performs actions to meet its objectives, affecting its surroundings in the process, via tools.

Related Concepts & Technologies

The concept of Autonomous AI Agents isn't isolated. It's closely tied with other AI technologies from Neural Networks to Machine, Deep and Reinforcement Learning. These technologies provide the underpinning for the functioning of an autonomous AI agent.

Machine Learning helps systems learn from data, Deep Learning facilitates processing of complex data, and Reinforcement Learning enables the agent to learn from its actions and their results, improving over time.

Autonomous AI Agents: Challenges and Limitations

Contrasting with Autonomous AI agents are Non-autonomous AI agents. These rely heavily on constant human input to make decisions and perform actions. While autonomous AI agents have the advantage of decision-making freedom and efficiency, they're also more complex and pose ethical issues.

Developing and implementing autonomous AI systems isn’t without challenges. They present technical challenges like the need for high computational power and dealing with vast and dynamic data sets. Ethical challenges arise from the system's ability to make decisions that might affect human life and well-being. Similarly, they also pose regulatory challenges, as laws need to evolve to encompass these sophisticated AI systems.

The Future of Autonomous AI Agents

The future of autonomous AI agents looks promising, however a focus on AI Transparency and Explainability, Ethics, Regulation is necessary. With rapid advancements, the need for AI systems to be transparent and explainable is crucial. Alongside, ethical and regulatory considerations need to keep pace with technology.

In conclusion, Autonomous AI Agents hold immense potential to disrupt numerous sectors and transform how we interact with technology. Understanding, nurturing, and regulating these agents responsibly will be pivotal in shaping a future where humans and AI collaborate effectively.

Since RoR 4, the management of JavaScript in Ruby on Rails has undergone several evolutions over the years. Initially, the Rails asset pipeline, powered by Sprockets, handled JavaScript files along with other static assets. Then came the Webpacker gem in Rails 5.1, offering a more modern approach to handling JavaScript, leaning into the JavaScript ecosystem with npm and Webpack. Most recently, Rails 7 introduced a new method with Importmap, which simplifies JavaScript management by allowing direct browser imports without a package bundler.

Sprockets

Initially, Rails used a system called Sprockets to handle both JavaScript and CSS assets. This system allowed the easy management of dependencies between various files and their minification for production.

Sprockets is a component in Rails that manages your JavaScript, CSS, and image assets. It compiles and serves these assets, facilitating their easy management. Sprockets allows the organization of assets in a way that maintains dependencies between various files and also minifies them for production, thereby enhancing performance by reducing file size.

Webpacker

With the introduction of Rails 6, a new option was introduced: Webpacker. This choice was dictated by the popularity of Webpack in the JavaScript world, which offers greater flexibility and better integration with the modern JavaScript ecosystem.

Webpacker is a wrapper for Webpack, a popular JavaScript module bundler. It's used in Rails to manage JavaScript, allowing for the integration of modern JavaScript features and libraries into a Rails application. With Webpacker, you can write your JavaScript in a modular way and bundle it for efficient delivery to the client.

Importmap

With Rails 7, the Rails team introduced another option: importmap. This is a more modern method for handling JavaScript, which avoids the need for transpiling or bundling. Importmap leverages standard JavaScript modules (ESM), making the use of modern JavaScript packages simpler.

While it appears quite straightforward, it intentionally lacks many features supported by the previous asset pipeline implementation. That's why I personally favor a more JavaScript-centric approach on the frontend side.

JsBuilder/CssBuilder and Propshaft

Choosing JSBuilder/CSSBuilder and Propshaft over Importmap may be beneficial for complex applications with many dependencies. These tools provide robust asset management, offering features like code minification and optimization (like treeshacking).

JSBuilder and CSSBuilder are tools used in Ruby on Rails for managing JavaScript and CSS assets. They allow efficient organization and optimization of code. Propshaft, introduced in Rails 7, is an asset pipeline responsible for handling static assets. It simplifies tasks such as asset compression, fingerprinting for cache busting, and serving assets in both development and production environments.

Together, JSBuilder/CSSBuilder and Propshaft provide a comprehensive solution for managing all types of assets within a Rails application. This combination allows for streamlined and efficient asset management.

Bibliography

• GitHub - rails/sprockets: Rack-based asset packaging system
• GitHub - rails/importmap-rails: Use ESM with importmap to manage modern JavaScript in Rails without transpiling or bundling.
• GitHub - rails/propshaft: Deliver assets for Rails

How to and guides

• GitHub - rails/importmap-rails: Use ESM with importmap to manage modern JavaScript in Rails without transpiling or bundling.
• How to use Import Maps in Rails 7 (with examples)
• TIL: Using ActiveAdmin with importmap-rails | by Henrik Hauge Bjørnskov | Medium

Coming from Visual Studio Code

For Visual Studio Code (VS Code) users who are seeking to expand their coding capabilities, exploring Vim can be a transformative experience. Vim, a powerful and highly customizable text editor, offers a unique approach to code editing that focuses on efficiency, speed, and minimalism. While VS Code provides a rich and user-friendly integrated development environment (IDE), Vim takes a different approach by providing a lightweight and keyboard-centric editing experience. By delving into Vim, VS Code users can unlock a new level of productivity, fine-grained control over their editing workflow, and a wealth of plugins and configurations that can be tailored to their specific needs. Embracing Vim within the VS Code ecosystem can prove to be a rewarding journey, empowering developers to refine their coding skills and streamline their workflows.

Trying out Vim, the easy way

For Visual Studio Code (VS Code) users who are interested in exploring Vim but prefer to stay within the familiar confines of their IDE, the Vim plugin for VS Code offers a seamless transition into the world of Vim. With the Vim plugin, developers can enjoy the benefits of Vim's powerful editing features and productivity enhancements directly within their VS Code environment. The plugin provides a Vim emulation layer, allowing users to leverage Vim's renowned modal editing, efficient navigation, and advanced text manipulation commands—all without having to leave the comfort of their beloved VS Code. This integration provides an excellent opportunity for VS Code users to dip their toes into the Vim ecosystem, gradually adopting Vim's principles and gradually discovering the immense productivity gains it offers. Whether you're a seasoned Vim user or a curious newcomer, the Vim plugin for VS Code provides a convenient bridge that allows you to harness the power of Vim without sacrificing the familiarity and convenience of your preferred IDE.

Using Vim, the full dive

When you feel ready to fully embrace the Vim philosophy and make a complete switch, it is worth considering Neovim as your editor of choice. Neovim is a modern fork of Vim that offers improved performance, enhanced extensibility, and a more active development community. To jumpstart your Neovim journey, utilizing a configuration starter like LazyVim or Kickstart.nvim can prove immensely helpful. These starter configurations provide a solid foundation, offering pre-configured settings, keybindings, and plugins that align with best practices and optimize your workflow. By leveraging these configuration starters, you can quickly customize Neovim to suit your needs, saving time and effort in setting up your editor from scratch. With Neovim and the guidance of these configuration starters, you can embark on a seamless transition into the world of Vim, unleashing your productivity and embracing the full potential of this legendary text editor.

This guide will examine how to set up a testing environment for your Rails application frontend using Capybara and Selenium WebDriver within a Docker container. We will also discuss important considerations when choosing the appropriate configuration for your tests.

Introduction to Capybara and Selenium WebDriver

Capybara is a popular acceptance test framework for Ruby web applications that simulates user interactions with your application in a browser. It provides a high-level API that allows you to interact with your application's UI elements, navigate between pages, fill forms, click buttons, and perform other actions as if you were an actual user.

Selenium WebDriver is an open-source browser automation framework widely used for automating web browsers through programs and performing browser automation. It supports various programming languages like Java, C#, Python among others. When combined with Capybara, it enables developers to run tests across different browsers (Chrome, Firefox) without changing the test code.

Setting Up Your Testing Environment

To set up your Rails application frontend testing environment using Capybara and Selenium on Docker:

Install Docker: If you don't already have Docker installed on your system, follow the official installation guide.

Configure Capybara: In your Rails project's test directory (or spec if you're using RSpec), create or update the test_helper.rb (or spec_helper.rb) file with the following Capybara configuration:

require 'capybara/rails'
require 'capybara/minitest'

Capybara.register_driver :chrome_headless do |app|
  Capybara::Selenium::Driver.new(
    app,
    browser: :remote,
    url: 'http://chrome_selenium:4444/wd/hub',
    desired_capabilities: Selenium::WebDriver::Remote::Capabilities.chrome('goog:ChromeOptions': { 'args': %w[ignore-certificate-errors no-sandbox headless disable-gpu] })
  )
end

Capybara.default_driver = :chrome_headless
Capybara.javascript_driver = :chrome_headless

This configuration sets up a new Capybara driver called chrome_headless that uses the Selenium WebDriver to connect to a remote Chrome browser running in headless mode.

Create a Dockerfile for your Rails application, if you haven't already. The Dockerfile should include instructions to install your application's dependencies and set up the runtime environment.

Create a docker-compose.yml file in your Rails project's root directory with the following contents:

version: '3'

services:
  web:
    build: .
    command: bundle exec rails s -p 3000 -b '0.0.0.0'
    volumes:
      - .:/app
    ports:
      - "3000:3000"
    depends_on:
      - chrome_selenium

  chrome_selenium:
    image: seleniarm/standalone-chromium:4.1.2-20220227
    logging:
      driver: json-file
    networks:
      - network
    volumes:
      - /dev/shm:/dev/shm

networks:
  network:

This configuration sets up two services, web and chrome_selenium, which are your Rails application and the Selenium WebDriver running in a headless Chrome browser, respectively. The web service depends on the chrome_selenium service.

1. Start your Docker containers using the command docker-compose up.

With this setup, you can now create and run frontend tests for your Rails application using Capybara and Selenium WebDriver within Docker containers.

HTTPS Testing Considerations

When testing HTTPS-enabled applications with Capybara and Selenium, it's crucial to be aware of HSTS (HTTP Strict Transport Security) preload lists that may enforce HTTPS connections. If your application's domain is included in an HSTS preload list, any HTTP connection attempts will automatically be redirected to HTTPS by modern web browsers.

To avoid complications during testing, ensure that you're using a domain that's not included in an HSTS preload list. Chrome and Firefox use the same preload list, which can be found in the Chromium source code.

Additionally, avoid using generic or widely-used TLDs (Top-Level-Domains) which may be on the browsers HSTS preload list (SecurityEngineering/HTTP Strict Transport Security (HSTS) Preload List - MozillaWiki), the most common is .dev (which is now owned by Google - …/transport_security_state_static.json · Gerrit Code Review) but you can check the whole list in Chrome source code (Firefox uses the same): chromium/transport_security_state_static.json at master · chromium/chromium · GitHub.

The HTTP X-Forwarded-Host header is commonly used in network environments where a proxy server or load balancer is present. This header indicates the original host requested by the client. However, if an attacker manages to manipulate the X-Forwarded-Host header, they can direct the client's requests to a harmful host. This can lead to a series of security problems, such as the disclosure of confidential information and data manipulation.

A cache poisoning attack via the setting of X-Forwarded-Host occurs when an attacker sends an HTTP request with a manipulated X-Forwarded-Host header. If the server accepts this request and stores it in its cache, all subsequent requests for that resource will be directed to the harmful host specified in the X-Forwarded-Host header. This can lead to a wide range of attacks, including identity theft, data manipulation, and the spread of malware.

Turns out Ruby on Rails until version 6 is indeed vulnerable to those kind of attacks: The X-Forwarded-Host HTTP header is always trusted and is used in url_for · Issue #29893 · rails/rails (github.com)

So beware and always filter the hosts you going to receive via X-Forwarded-Host, if those are even needed. Otherwise do yourself a favour and delete the header before addressing each request.

VirtIOfs is a virtualization technology that allows faster and more efficient file sharing between the host and the guest operating systems. It uses a shared memory region to transfer data between the two systems, instead of copying files back and forth. This reduces the CPU usage and memory consumption, as well as the latency and overhead of file sharing. According to a recent benchmark by Docker, VirtIOfs can make Docker Desktop on MacOS up to 98% faster than without VirtIOfs.

Some of the benefits of using VirtIOfs for file sharing are:

• Reduced CPU usage and memory consumption: VirtIOfs eliminates the need for copying files between the host and the guest operating systems, which saves CPU cycles and memory space. This can also free up resources for other tasks and improve the overall performance of your system.
• Improved performance and responsiveness of applications: VirtIOfs enables faster file access and modification, which can improve the speed and responsiveness of your applications. For example, if you are using a web framework that reloads your code on every change, you will notice a much shorter feedback loop with VirtIOfs enabled.
• Enhanced compatibility and security: VirtIOfs supports all file system features that are supported by MacOS, such as extended attributes, hard links, symlinks, etc. This means that you don't have to worry about any compatibility issues or data loss when using VirtIOfs. Moreover, VirtIOfs uses a secure communication channel between the host and the guest operating systems, which prevents any unauthorized access or tampering with your files.

To enable VirtIOfs on Docker Desktop, you need to follow these simple steps:

• Update to the latest version of Docker Desktop and MacOS: You need to have Docker Desktop version 4.6.0 or higher and MacOS version 12.0 or higher to use VirtIOfs. You can check your current versions by going to About Docker Desktop and About This Mac in your menu bar.
• Go to Preferences > Experimental Features and check the box for Use virtiofs for file sharing: This will enable VirtIOfs as the default file sharing mechanism for Docker Desktop on MacOS. You can also toggle this option on or off for individual containers by using the --mount flag with the type=virtiofs option.
• Restart Docker Desktop and enjoy the speed boost: After enabling VirtIOfs, you need to restart Docker Desktop for the changes to take effect. You should notice a significant improvement in the file sharing speed and performance of your applications.

Here are the official release announcement: Speed boost achievement unlocked on Docker Desktop 4.6 for Mac | Docker

VirtIOfs is a game-changer for developers who use Docker Desktop on their Macs. It can make your development experience faster, smoother, and more enjoyable. If you haven't tried it yet, I highly recommend you to give it a shot and see for yourself how much difference it can make.

Here's a step-by-step guide on how to integrate ChatGPT with Alfred, written by ChatGPT itself:

1. Install the Alfred app on your Mac if you haven't already.
2. Create a new workflow in Alfred by clicking on the "Workflows" tab in the Alfred preferences and then clicking the "+" button in the bottom left corner.
3. Add a "Script Filter" object to the workflow by double-clicking on it in the left panel and dragging it to the right panel.
4. In the "Script Filter" object, paste the following Python code, which uses the OpenAI API to send a request to the ChatGPT model and returns the response as a list of Alfred results:

import os
import requests

query = "{query}"

def send_query_to_openai(prompt):
    response = requests.post("https://api.openai.com/v1/engines/davinci/jobs",
        headers={
            "Content-Type": "application/json",
            "Authorization": "Bearer "+ os.environ["OPENAI_API_KEY"]
        },
        json={
            "prompt": prompt,
            "max_tokens": 1024,
            "temperature": 0.5,
        },
    )
    if response.status_code != 200:
        raise ValueError("Failed to send query to OpenAI")
    response_json = response.json()
    return response_json['choices'][0]['text'].strip()

def main():
    response = send_query_to_openai(query)
    print(response)

main()

5. In the "Script Filter" object, set the "Keyword" to "chatgpt" and the "Argument Placeholder" to "{query}".
6. Add an "Environment Variable" object to the workflow by double-clicking on it in the left panel and dragging it to the right panel.
7. In the "Environment Variable" object, set the "Name" to "OPENAI_API_KEY" and the "Value" to your OpenAI API key.
8. Save the workflow and give it a name, such as "ChatGPT".

Now, you can activate the ChatGPT workflow by typing "chatgpt" followed by your query in the Alfred search bar. The response from the ChatGPT model will be displayed in the Alfred results.

Note: This is just a basic example of how to integrate ChatGPT with Alfred, and you can customize the workflow further to better suit your needs.

In my specific case that wasn't working, but it's still a cool experiment. YMMV.

As a software developer, you’re probably familiar with the time it takes to build a Docker image, especially if your application is complex and requires many dependencies. But did you know that you can speed up your builds by using caching strategies?

In this article, we’ll explore the different ways to optimize your Docker builds in GitLab, by using the BUILDKIT_INLINE_CACHE, tagging with both latest and sha_commit, and using the docker-compose cache from option.

BUILDKIT_INLINE_CACHE

The BUILDKIT_INLINE_CACHE environment variable can be used to enable build caching in GitLab CI/CD pipelines. When set to 1, it allows GitLab to cache the intermediate build layers, which can significantly speed up subsequent builds. To enable this feature, simply add the following line to your .gitlab-ci.yml file:

variables:   DOCKER_BUILDKIT: 1

Tagging with both latest and sha_commit

Tagging your Docker images with both the latest and the sha_commit (the unique identifier for each commit) can also improve your build times. By tagging with the latest tag, you can ensure that your latest build is always accessible, and by tagging with the sha_commit, you can guarantee that you can access specific builds at any time.

image: docker:stable  
stages:   
    - build  
build:   
    stage: build   
    script:     
        - docker build -t myimage:latest .     
        - docker build -t myimage:$CI_COMMIT_SHA .

Using docker-compose cache from

The docker-compose cache from option allows you to cache intermediate build layers when using docker-compose. This can be particularly useful when building multi-container applications, as it allows you to cache the dependencies and intermediate layers for each container. To use this feature, simply add the following line to your docker-compose.yml file:

version: '3.7' 
services:   
    web:     
        build: .     
        cache_from:       
            - web:latest

What to expect

One of the benefits of combining these caching strategies is that you can leverage the cache without prior pulling of all the last images' layers. This means that you don't need to wait for the entire image to be pulled from the repository to start the build process. Instead, GitLab can use the cached layers from previous builds to start the build process, reducing the time it takes to complete the build.

By using the BUILDKIT_INLINE_CACHE environment variable, GitLab can cache the intermediate build layers, which can be used in subsequent builds. This means that if you make changes to your code, docker will only have to build the layers that have changed, instead of starting from scratch. This can significantly speed up your builds and reduce the time it takes to complete a build.

The docker-compose cache from option also works in a similar way, allowing you to cache the dependencies and intermediate layers for each container in your multi-container application. This means that if you make changes to one container, you don't need to rebuild all the other containers from scratch, as the cached layers can be used.

In summary, by leveraging these caching strategies, you can significantly speed up your Docker builds in GitLab, without having to wait for the entire image to be pulled from the repository. This can save you time, reduce the number of build failures, and improve the overall performance of your CI/CD pipelines.

So I found out that running a Sqlite db or really anything which requires files lock over NFS keep is really buggy when managed remotely via rpc.statd and rpc.lockd.

You can however opt for local locks, if the share is mount only by one user/server.

To enable local locks in TrueNAS, set a sysctl tunable in System->Tunables of vfs.nfsd.enable_locallocks=1. Then add local_lock=all to your NFS mount options.

That leads to an NFS share that can only be mounted by a single client safely, however that's usually the case with a database share.

Un augurio di serene feste e felice nuovo anno. Colgo l’occasione per segnalarvi che sarò in ferie dal 24/12 all’8/1.

A presto,

Andrea Casarin
andreacasarin.com
Facebook | Twitter | Linkedin

However K8S has some great ways to make sure you are on top of your cluster status, you just have to make sure you setup them right.

metrics-server

Gets resource metrics from Kubelets and exposes them through the Kubernetes Api Server via Metrics API, think at them as:

• CPU
• memory
• network usage

Used primarly for horizontal and vertical autoscaling, accessed via console with kubectl top.

kube-state-metrics

Gets metrics from Kubernetes Api Server end generates metrics about in cluster objects, think at them as:

• Resource requests and limits
• Number of objects–nodes, pods, namespaces, services, deployments
• Number of pods in a running/terminated/failed state

Used primarly as a data source for monitoring.

So what?

You may want to use both to gain observability over the cluster using some sort of service to aggregate and store those metrics then visualize in a user friendly way.

My current preferred way is via Prometheus + Grafana, or NewRelic to combine even more data (eg. logs).

While doing a simple select query I was looking for tuples which were where x != 42 trying to extract all of them regardless of x being some number or null.

That didn't work as I expected. In Postgres if you select something via where x != 42 it will not extract tuples where x is null.

So, if you are doing something like I did make sure to explicitly include null as a where condition, for example where x != 42 or x is null.

In the SSH protocol, the "ssh-rsa" signature scheme uses the SHA-1 hash algorithm in conjunction with the RSA public key algorithm. It is now possible to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K. [https://www.openssh.com/txt/release-8.7]

So you will get this error:

no matching host key type found. Their offer: ssh-rsa,ssh-dss

You can add those algorithms back, with:

HostKeyAlgorithms +ssh-rsa,ssh-dss

in /etc/ssh_config.

Of course this is a workaround, please update your keys.

I would go with https://en.wikipedia.org/wiki/Twisted_Edwards_curve, to generate such key you issue a simple command:

ssh-keygen -t ed25519

On cluster ingress (this is managed by an Nginx config map):

proxy_cache_path /tmp/nginx-cache levels=1:2 keys_zone=static-cache:32m max_size=5g inactive=7d use_temp_path=off;
proxy_cache_valid any 5m;
proxy_cache_valid 200 30m;

On application ingress (managed via deploy):

proxy_ignore_headers Set-Cookie;
proxy_cache static-cache;

Watch out for proxy_ignore_headers, these could cache cookies and/or break sessions. You could use something like:

  if ($uri ~ "/admin/") {
    set $app_nocache 1;
  }
  if ($http_cookie ~* "logged_in") {
    set $arg_nocache 1;
  }
  proxy_no_cache $cookie_nocache $arg_nocache $app_nocache;

To avoid caching dynamic pages/admin areas.

And to add a nice touch:

add_header X-Cache-Status $upstream_cache_status;

So that you can watch your response headers to check the cache status for that particular request.

Enjoy!

One of the mayor aspect of this is static assets optimization, here are a few tips I found out in my journey.

Images

PJPEG: jpeg images are loaded from top to bottom, progressive jpeg from back to front. So they will load the whole sized image and then refine it from a resolution standpoint. Thats great for browsers and users alike.

WEBP: thats a new format from Google with better compression then PNG, alpha channel and slightly better then JPG. Unfortunately it's still not widely supported.

AVIF: new better format and an open one, quite well supported but still niche. This has potential to become the new way to go.

I decided to optimize my images with GIMP by setting the smallest possibile size and removing all the extra data attached (exif, resolution, ecc). I tend to go PJPEG 90% quality when possibile, then PNG compression 9.

You can try https://squoosh.app/ to test the results for different formats.

Make then sure you set width and height to an absolute number (no 'px') to define the base size and aspect ratio, then set the responsive size via css.

Javascript and stylesheet

For JS always defer (load asynchronously execute at the end), if not possible use async (load asincrously execute as soon as loaded).

For stylesheets there is no simple way to load asynchronously, however you can trick the browser via:

<link href="style.css" rel="preload" as="style" onload="this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="style.css"></noscript>

To please Google page speed algorithm it looks like the minimum caching time is 1 year, so make sure to add a Cache-Control header to cache your static content for 1+ year (for 1 year use max-age: 31536000).

And, of course, minimize and gzip.

That's not usually an issue, however some tasks require a lock (eg. apt install pkg) thus breaking for errors or timeouts.

Ansible has some attributes to manage this situations, like:

• forks at a configuration level
• serial at a playbook level

What if you can define it on a task level? That would be great since you could then only limit tasks which actually require locks instead of slowing down everything.

Looks like it has been asked before: https://github.com/ansible/ansible/issues/12170 and, although not documented yet it's been implemented:

• https://github.com/ansible/ansible/pull/42528
• https://github.com/ansible/ansible/pull/60702

So here we go:

- name: Testcommand: 
  echo 'test'
  throttle: 1

It's an agent which you can install on your k8s cluster (or on your standard VM). It uses eBPF to collect deep data from Linux Kernel, granting the ability to monitor an application without the need of an APM (Application Performance Management). It promises a maximum 5% overhead.

The frontend uses PxL Script (which is similar to python + panda) to fetch data from backend, which is queried directly.

You can use it standalone, on premise, or for example with NewRelic (since the data stays on your host there is no cost for data ingestion).

That's a great video from Pixie explaining the technology in details: https://www.youtube.com/watch?v=shJ45UJvFR4.

Usually when defining a life-cycle policy you create a tag filter to select specifics volumes and then a schedule to snapshot them and how many you want to keep.

So it would be great to add tags to volumes provisioned by Kubernetes that way you could create a life cycle policy to backup them automatically when marked with a specific tag.

Unfortunately that's currently not possible on the standard provisioner:

• https://github.com/kubernetes/kubernetes/pull/49390
• https://github.com/kubernetes/kubernetes/issues/50898

But you can use the AWS EBS CSI driver instead of the k8s in-tree one (which looks like will be deprecated one day), then you can add tags this way:

• https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/e175fe64989019e2d8f77f5a5399bad1dfd64e6b/charts/aws-ebs-csi-driver/values.yaml

In fact the AWS EBS CSI provisioner ability to add extra tags got merged to master branch sometime in 2019 (https://github.com/kubernetes-sigs/aws-ebs-csi-driver/issues/333).

It features some tools (like markup formatting, sql formatting, md5 calculation) and will host a series of hand-picked guides and tutorials.

It aims to be a useful website for everyday development or system administration.

Most of our favorite instruments live in our editor/terminal of choice, but sometimes you just need a quick tool to be able to share or check something on the go. I've been there a few times.

I used to search Google for a json formatter or an md5 calculator from my phone, just to find out that most of those results were not usable on mobile, or slow, or both.

So I decided to assemble my own online toolset in my spare time, and that's how DevPresto began to take shape. In that regard I'd like to thanks the whole open-source community which helped me a lot.

It's a microservice based application, the backend is written in JS on NodeJS with Express, the frontend is Vue based with Nuxt.js.

It's currently running on a Kubernetes cluster deployed via Kops on AWS, it makes use of Skaffold to manage it's deployment via Gitlab CI.

Since I's a side-project I can't assure timely responses but feel free to report any bug or submit a request by email to: info at devpresto dot com, I might make it open source if it gains some traction.

Said that I decided to switch the test suite for an application I was working on to RSpec, to try and learn this different tool. I also opted in for shoulda_matchers and factory_bot which seems to be the de-facto standard.

Here are a few hints if you want to follow the same path.

One assertion per test.

That's it, write multiple tests with one assertion each, seems unpractical at firsts but it really helps in the long run.

Prefer is_expected/expects over should.

Pretty straightforward, as per documentation now is_expected is the preferred syntax.

Use subject for main testing object.

You are supposed to define a subject which serve as main test object, then expect something from it.

Use let for other objects.

With let you can define other objects which will be edge loaded for each test as they are used. If you need that object before explicitly calling it you can use let! instead.

When using callbacks after(:save) remember to save.

This one is for factory_bot actually: you'll find yourself using callbacks to define associated object in a one-to-many or many-to-many relationship. I these cases make sure to save the object in the callback too.

Use allow_value() to test custom validations.

Now on with shoulda_matchers, which has a lot of cool ways to test model validations, however if you want to test some custom ones you can simply use allow_value and test for true or false.

Remember eq() tests equality, be() tests identity.

That's easy, but often overlooked, make sure you are testing for the right thing.

Backtrace to get context.

You can add `--backtrace` to your tests to have some clue on why they are failing.

I just discovered one the hard way, while upgrading my Arch machine.

I'm using minikube for local Kubernetes development, minikube itself it's a VM which by default runs on VirtualBox (and a bunch of other platforms). It creates a host-only network plus a nat network to make the magic possibile.

The default host-only network CIDR is 192.168.99.1/24, and here comes the problem: turns out that the latest VirtualBox version has some security limitations for host only network ranges: https://www.virtualbox.org/manual/ch06.html#network_hostonly (In my case the reported error was: VBoxManage: error: Code E_ACCESSDENIED (0x80070005) - Access denied (extended info not available)).

You can either add the minikube default to the allowed ranges or change the default itself to be in the VirtualBox range.

I did the latter with a simple: minikube config set host-only-cidr "192.168.56.1/24".

Cos’é la PSD2

La direttiva dell’UE 2015/2366 (Payment Service Directive 2 – PSD2) è una nuova legge Europea che ha come oggetto il mercato dei pagamenti nell’Unione. È un’evoluzione della direttiva 2007/64/CE (Payment Service Directive – PSD).

Photo by Web Hosting on Unsplash

FinTech e Europa

Il settore FinTech non ha avuto fin’ora molto successo in Europa a differenza del mercato Americano. Molti strumenti non avevano la possibilità di funzionare qui a causa della mancanza di API per la connessione agli istituti bancari.

Attori come Intuit, con Mint sono presenti da tempo in America e permettono l’aggregazione dei dati economici presenti su diversi account per avere una visione d’insieme e per l’automazione di alcuni scenari.

In Italia (ed in Europa), purtroppo, questo é stato impossibile fino ad ora per la mancanza di interfacce macchina di comunicazione con la banca. Alcuni soggetti, come Yolt hanno aggirato il problema utilizzando l’accesso utente e “visualizzando” i dati presenti nella pagina, ma il risultato é spesso instabile e lento.

Tutto questo sarà un ricordo, con l’adeguamento delle banche alla nuova direttiva sarà possibile accedere ai dati bancari tramite interfacce dedicate.

I cambiamenti

Deloitte delinea chiaramente il perimetro della normativa nel suo ottimo documento di approccio al nuovo sistema.

Essa consiste in 6 cambiamenti fondamentali:

1. La PSD 2 include nello scope le cosiddette «one leg out» transactions in tutte le divise. Per la precedente PSD I il perimetro era limitato alle transazioni in Euro.
2. Invece di effettuare i pagamenti direttamente dalla propria banca, PSD 2 consente a player terzi di effettuare un pagamento attraverso un Payments Initiation Service Provider (PISP), che trasmette le istruzioni alla banca detentrice del conto del payer.
3. PSD 2 definisce un nuovo set di regole per aprire l’accesso a terze parti alle informazioni relative ai conti necessarie per effettuare un pagamento, favorendo il ruolo degli account aggregators (AISP).
4. PSD 2 introduce nuovi requisiti di sicurezza riguardanti l’accesso ai conti, i pagamenti elettronici e che impongono severe linee guida per l’implementazione da parte degli AISP e dei PISP.
5. Viene posto un cap alle interchange fees pari allo 0.2% e 0.3% del valore della transazione rispettivamente per le carte di debito e per le carte di credito.
6. Ulteriori trasposizioni della SEPA in legge: in PSD 2 la regolamentazione riguardante il diritto di refund per gli SDD è armonizzata con le direttiva SEPA.

I punti 2 e 3 sono senz’altro i più interessanti dal punto di vista dell’innovazione. Essi delineano una certa apertura alle nuove tecnologie da parte degli strumenti bancari che avverrà su due fronti:

• la lettura dei dati finanziari da parte di soggetti terzi;
• la possibilità da parte di soggetti terzi di agire come “intermediari” per i pagamenti digitali.

I nuovi attori

PSD2 delinea quindi la presenza di due nuovi attori, Third Party Players (TPP), nel mercato finanziario.

I TPP sono suddivisi in:

• Account Information Services Providers (AISP);
• Payment Initiation Service Providers (PISP).

Un soggetto AISP autorizzato può chiedere il permesso all’utente di connettersi al conto corrente bancario e utilizzarne le informazioni per fornire un servizio.

Le attività registrate come AISP sono autorizzate alla sola lettura delle informazioni bancarie. Possono perciò solo recuperare le informazioni ma non spostare denaro per conto del cliente.

Servizi e strumenti che generalmente possono essere offerti da un AISP sono:

• confronto di costi, gestione statistica di entrate e uscite;
• velocizzazione dell’accesso a prodotti finanziari come prestiti, mutui o investimenti.

Un soggetto PISP può chiedere il permesso all’utente per connettersi al conto corrente bancario ed effettuare pagamenti al suo posto.

Ci sono diversi motivi per i quali questo può essere utile, come:

• applicazioni che gestiscono automaticamente spese ricorrenti e risparmi;
• applicazioni che garantiscono al cliente di non superare un budget per, ad esempio, evitare gli interessi sullo scoperto.

La sicurezza prima di tutto

I TPP, dovranno seguire le stesse regole dei fornitori di servizi di pagamento tradizionali per poter operare. Si dovrà pertanto procedere con la registrazione e l’autorizzazione da parte delle autorità competenti, che vigileranno sui nuovi soggetti.

L’authority bancaria Europea (European Banking Authority – EBA), ha sviluppato un archivio elettronico in cui verranno registrate tutte le informazioni riguardanti i pagamenti e, nello specifico, sui PISP e gli AISP che avranno l’autorizzazione ad operare in UE nell’ambito della direttiva PSD2. In questo modo sarà il cliente potrà verificare se l’attività a cui sta affidando i sui dati è effettivamente autorizzata ad offrire il servizio.

La direttiva PSD2 é stata poi integrata con il regolamento delegato UE/2018/389 contenente le norme tecniche per l’autenticazione forte del cliente (Strong Customer Authentication – SCA) e gli standard aperti di comunicazione comuni e sicuri (Common and Secure Communication – CSC).

I requisiti di Strong Customer Authentication, ai quali le banche si stanno già adeguando, prevedono la combinazione di almeno due fattori di autenticazione tra i seguenti tre:

• “Knowledge factors” (conoscenza), qualcosa che solo l’utente conosce, ad esempio la password o il PIN;

• “Possession factors” (possesso), qualcosa che solo l’utente possiede, ad esempio uno smartphone o una chiavetta/token;

• “Inherent factors” (inerenza), qualcosa che é l’utente, generalmente i dati biometrici.

I requisiti di Common and Secure Communication sono invece più generici e volti ad assicurare la compatibilità tra i vari istituti e la sicurezza della trasmissione. In particolare ci si riferisce alla normativa ISO 20022 e ci si assicura che ciascuna banca provveda a pubblicare la documentazione per un canale di comunicazione standard e sicuro.

Le opportunità

PSD2 finalmente introduce alcune innovazioni nel comparto finanziario Europeo che permetteranno lo sviluppo del settore FinTech anche da questa parte dell’oceano. Le banche che attualmente non concedono l’accesso alle informazioni memorizzate nei conti dei loro clienti, con la PSD2 dovranno permettere l’accesso ai terzi che dispongono di una licenza e che sono stati autorizzati dal cliente in modo esplicito.

Le possibilità sono molte, alcune in ordine sparso:

• aggregazione di dati a scopo statistico per la finanza personale;
• riconciliazione automatica da parte di gestionali aziendali;
• intermediazione dei pagamenti a scopo di risparmi o gestione del budget.

Per chi volesse approfondire la tematica é disponibile la direttiva completa all’indirizzo: https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX:32015L2366 e le linee guida dell’autorità bancaria Europea all’indirizzo: https://eba.europa.eu/regulation-and-policy/payment-services-and-electronic-money.

Purtroppo, la normativa per diventare AISP o PISP è molto stringente, ben venga se serve a garantire la sicurezza dei clienti, d’altro canto limita molto le possibilità di innovare da parte delle imprese meno strutturate.

Fortunatamente stanno nascendo piattaforme come OpenWRKS che si ripropongono di agire come intermediari per lo sviluppo di soluzioni come quelle elencate sopra da parte di piccoli soggetti.

Credo questa sia una delle evoluzioni piú importanti del settore, almeno fino a quando le criptovalute non troveranno il loro spazio e la blockchain non sarà utilizzata più estensivamente.

I have been recently involved in a website optimization project for SEO purposes. One of its major steps was the (lossless) image optimization to improve performances and, of course, to make sure to be Google Page Speed friendly.

Google Page Speed Insights

PageSpeed Insights is a tool from Google which “analyzes the content of a web page, then generates suggestions to make that page faster”.

Photo by Jannik Selz on Unsplash

It’s the base index for every website performace optimization and might as well be the index that Google uses in its search engine to adjust a website position to reflect its performaces (https://developers.google.com/speed/).

Let’s see how much we can improve.

Our own case

The website is a simple WordPress customization backed by AWS S3 for assets storage.

AWS S3 has no computational power but transfers between S3 and EC2 are very cheap (https://aws.amazon.com/s3/pricing/) so I decided to leverage an AWS EC2 spot instance to download each image, run the optimization and upload it back to the storage.

The process is pretty straightforward, but still a bit annoying to be done manually.

The automation

I created a simple bash script to automate the whole operation. I think may be useful for someone else out there, so here it is:

To use the script just download the Gist – make a backup -, make it executable – make a backup -, customize “credentials” and “configuration” sections – make a backup – and run it with:

./s3_recursive_image_optimization.sh

In case I forgot to mention: make sure to have a backup in case anything goes wrong.

Results

We are pretty happy with what we got, a straight “A”.

Also, since we automated to whole process, in case some images will not be optimized before being uploaded in the future we can still run the script again for the new ones.

If you’re wondering how your website is doing with Page Speed and other performance metrics, you can check it for free on GtMetrix: https://gtmetrix.com/.

Update: Janis from Experte wrote me an email to let me know about their pagespeed tool. It's great. It let's you test the entire website with a single click. Go check it out at https://www.experte.com/pagespeed.

Trello, un tool di organizzazione con più di 10 milioni di utenti, è diventato uno strumento essenziale per la gestione dei miei progetti. Lo trovo un software fantastico, è molto flessibile e può essere adattato a molteplici esigenze. Inoltre è estremamente semplice da usare, tanto che spesso condivido le bacheche di progetto con il cliente che può così restare aggiornato sugli sviluppi e inserire nuovi task.

La scelta di essere minimalista ha portato il team di Trello a dei compromessi e, anche se molti sono superabili tramite “Power-Up”, senz’altro non è un tool adatto a tutti. Uno dei principali limiti è la gestione del tempo, in particolare non è possibile registrare il tempo impiegato per ciascun task.

Automazioni con Zapier

Molti software di terze parti si ripropongono di risolvere questo problema: alcuni nativamente, altri attraverso software di integrazione come Zapier.

Per chi non lo conoscesse, Zapier, come IFTTT, è un software online che permette di far comunicare diverse applicazioni allo scopo di automatizzare alcune attività; con la differenza, rispetto IFTTT, di poter creare workflow articolati con più passaggi.

Purtroppo nessuno strumento permette, attualmente, di avere un riassunto delle ore spese in un compito direttamente su Trello: è possibile avviare timer dal task ma poi è necessario consultare l’applicazione collegata per avere un resoconto.

Collegamento di Trello con Zapier

Le applicazioni integrabili con Zapier sono più di 1000 e tra queste figurano sia Trello che Google Sheets, quindi è possibile creare dei “trigger” basati su azioni eseguite dalla prima per eseguire delle operazioni sulla seconda.

L’obiettivo è che, aggiungendo un commento ad una scheda con la parola chiave: “Time: ” seguita da un tempo in minuti in una nuova riga, venga creata una nuova linea nel nostro foglio di calcolo indicante chi ha commentato, cos’ha commentato, in che scheda e il tempo indicato. Vediamo dapprima il trigger e le operazioni di estrazione dei dati.

Accediamo quindi a Zapier, clicchiamo “Make a Zap!” per iniziare e aggiungiamo la prima applicazione o “trigger”, cioè Trello:

Configuriamola per essere eseguita quando c’è un nuovo commento in una scheda, quindi procediamo con le opzioni di default avendo cura di scegliere la bacheca e l’utente per i quali eseguire l’automazione, se necessario. Aggiungiamo poi un filtro di tipo “Only continue if…” per filtrare solo i commenti che contengono un’indicazione riguardo il tempo, in questo modo:

quindi, sempre nel medesimo filtro:

aggiungiamo poi un’azione di tipo “Formatter by Zapier”, testuale:

che configuriamo come di seguito per estrarre la stringa numerica dopo la nostra parola chiave:

aggiungiamo un’ulteriore azione di tipo “Formatter by Zapier”, sempre testuale:

che configuriamo in questo modo per estrarre la stringa di testo che motiva il tempo speso:

a questo punto:

Collegamento di Google Sheets con Zapier

Abbiamo collegato Trello con Zapier ed estratto le informazioni di cui abbiamo bisogno, ora possiamo procedere con l’inserimento di questi dati nel nostro foglio di calcolo.

Creiamo un nuovo foglio di calcolo su Google Sheets, nell’esempio il foglio si chiama “Time Tracking” e le colonne sono, nell’ordine: “Who”, “Where”, “What”, “How much”; è possibile cambiare formato e nome del foglio, ma in tal caso deve essere adattata anche la configurazione di Zapier.

Procediamo quindi su Zapier creando una nuova azione di tipo Google Sheets:

selezionato “Create a Spreadsheet Row” procediamo configurandola in questo modo per selezionare il documento e foglio corretti e quindi valorizzare le colonne:

Proviamo l’integrazione

L’automazione è completa, procediamo quindi con un test.

Commentando una scheda su Trello (di una bacheca/utente abilitati) con un testo ed una riga vuota contenente la parola chiave più un valore numerico, l’automazione creerà una riga nel foglio di calcolo indicante i dati rilevanti. O almeno l’idea è questa.

Aggiungiamo un commento ad una scheda, rispettando il formato:

e, in massimo 5 minuti dovremmo vedere il risultato in Google Sheets:

Approfondimenti

Questo è solo un’esempio di ciò che è possibile creare con Trello, le possibilità sono pressochè infinite: puoi approfondire l’argomento sul sito di Zapier o, se ti serve un’integrazione più semplice, IFTTT.

Asset management

• create an asset (you just bought it),
• transfer an assets (you sold it to someone else),
• delete an assets (it’s gone),
• report as stolen or lost or broken for warranty purposes.

Photo by Héctor Martínez.

Blockchain

Photo by Thought Catalog.

Oblatum platform

Try our demo

Le applicazioni web a pagina singola (SPA o interfacce web a pagina singola SPI) sono ormai diventate una realtà e hanno superato, grazie agli avanzamenti delle tecnologie web, quasi tutte le problematiche iniziali. Tuttavia non sono ancora così diffuse, soprattutto da questa parte dell’oceano. Ho avuto il piacere di leggere un “vecchio” manifesto che rappresenta il movimento agli albori delle SPI e ho pensato di riproporlo, tradotto in italiano. Eccolo.

Photo by Danika Perkinson.

Manifesto dell’interfaccia a pagina singola

Origini della tecnologia web

Quando Tim Berners Lee ha inventato il web, stava cercando un sistema per pubblicare documenti scientifici accessibili da remoto, attraenti dal punto di vista estetico, semplici da codificare e di facile utilizzo anche per un non tecnico.

In un documento scientifico, le citazioni esterne verso altri documenti sono indispensabili in modo che il lettore, se lo desidera, possa approfondire maggiormente il tema in questione.

Per queste ragioni il World Wide Web è stato concepito come un sistema basato su una pagina (documento) con collegamenti ipertestuali.

Inizialmente il web era un mondo fatto di pagine statiche e link, ma presto la generazione di pagine dinamiche e in generale l’uso del web a servizio di applicazioni web-based ha notevolmente complicato le cose.

L’arrivo delle applicazioni web

Per tanti anni sono stati messi in campo molti sforzi per adattare il paradigma web di pagine e link al campo dello sviluppo di applicazioni. In un’applicazione web infatti la visione di Berners circa documenti statici e link non esiste.

Sono stati fatti diversi tentativi di approccio legato allo sviluppo di applicazioni:

• Modello 1: traduzione diretta dei modelli originali di pagine e link, dove le pagine sono generate dinamicamente;
• Modello 2 o MVC: qui i link non puntano direttamente a una pagina già decisa a priori, ma un controller decide quale sarà la pagina successiva in base alle operazioni eseguite nella fase di transizione di pagina;
• Modello MVC basato sui componenti (Modello 3?): sofisticata versione del Modello 2 che simula come funziona un’applicazione desktop. Si basa su componenti ed eventi: qualsiasi azione dell’utente implica la completa ricostruzione e il ricaricamento della pagina, andando a modificare parzialmente alcune parti a seconda dell’azione eseguita. La pagina e la pagina di transizione sono gestite da componenti che cambiano in base all’evento, simulando il funzionamento dei componenti della programmazione GUI desktop.

In periodi più recenti è stata introdotta la tecnica AJAX, che con l’aiuto del JavaScript consente parziali cambiamenti nelle pagine sino a ottenere nuovi dati dal server senza necessità di ricaricamento. Nonostante la tecnica di parziale cambio pagina sia di molto antecedente all’introduzione dell’XMLHttpRequest (base della programmazione AJAX) in Internet Explorer, questa è stata la sua spinta verso il successo.

Adesso milioni di siti web e di web application usano AJAX per fornire una migliore esperienza all’utente grazie a un’interfaccia più responsive che permette di evitare parzialmente il fastidioso ricaricamento delle pagine.

Nonostante l’uso massiccio di AJAX, ci sentiamo di affermare che il web segue un modello di sviluppo che potremmo chiamare “Modello 2 (MVC) arricchito con AJAX”. Quando si usa AJAX, parlare di “Modello 3” non ha così senso perché AJAX riduce di molto il bisogno della gestione di pagine basata sui componenti (non necessariamente presenti nel Modello 2), e per questo possiamo classificare l’attuale stato dell’arte dello sviluppo web come Modello 3,5. In questo modello la navigazione della pagina è parzialmente evitata nel caso di transizioni di minor stato eseguite da AJAX e JavaScript.

Quali sono gli svantaggi della navigazione e dello sviluppo basati su pagine?

Ogni sviluppatore web conosce le problematiche relative alla navigazione di pagine nelle applicazioni web. Oltre alla perdita di larghezza di banda e il tempo per il processo di ricostruzione di intere pagine, ulteriori difficoltà sono date da cache indesiderate, pulsanti di indietro/avanti, moduli disincronizzati a causa della funzione “auto-riempimento” di alcuni browser, e via dicendo. Non è così raro vedere applicazioni web che nascondono i menù e i bottoni del browser o usano frame o iframe (è il caso delle banche) per evitare criticità legate ai bottoni indietro/avanti.

Lo sviluppo basato su pagine web impone uno stile di programmazione strano, ripetitivo (con molte inclusioni) e inefficiente (sia per la larghezza di banda che per la potenza di calcolo), che non si verifica nello sviluppo desktop.

Cosa impedisce l’uso intensivo di AJAX?

Nel settore dello sviluppo web siamo abituati a distinguere due tipi di soluzioni: applicazioni web e siti web.

Nel primo caso l’applicazione AJAX è sempre più usata poiché non condivide alcuni requisiti imposti per i siti web. Nei siti web infatti l’uso intensivo di AJAX comporta dei problemi.

In siti web pubblici gli utenti sono abituati al concetto di pagina, e legati alla pagina ci sono una serie di requisiti e servizi che si trovano in ogni sito web, come:

• Bookmarking: ogni pagina web ha URL differenti, e queste URL possono essere salvate come segnalibro. Poiché AJAX può cambiare parzialmente la pagina l’URL è la stessa, e l’utente non può salvare come segnalibro una vista concreta della pagina stessa;
• Search Engine Optimization (SEO): ogni sito web aspira a essere perfettamente indicizzato dai motori di ricerca come Google. I crawlers di oggi vedono il web come web 1.0 e ciò significa che il codice JavaScript è totalmente ignorato. Quindi qualsiasi modifica parziale eseguita tramite AJAX caricata dal server non viene eseguita e non viene indicizzata dai crawler;
• Servizi basati sulle visualizzazioni di pagina: in servizi pubblicitari come Google Adsense e nelle visualizzazioni di pagina monitorate con Google Analytics, il numero di pagine caricate è estremamente importante. Ogni cambiamento anche parziale fatto con AJAX non viene contato come nuova visita;
• Finestre pop-up.

A causa di questi requisiti, l’uso massivo di AJAX non è consigliato nei siti web.

A ogni modo la differenza tra “sito web” e “applicazione web” sta diventando sempre più piccola perché ormai quasi ogni sito web è una sorta di web application…

Dovremmo rinunciare all’uso intensivo delle applicazioni AJAX?

No.

Ci sono soluzioni tecniche per ognuno dei requisiti elencati sopra.

È possibile lo sviluppo di siti web a pagina singola (SPI)?

Sì!

È il momento giusto per iniziare la transizione: ne guadagneranno sia gli sviluppatori che gli utenti. Abbiamo la tecnologia e i moderni browser sono sufficientemente qualificati per permetterci di ottenere questo obiettivo.

Per avere successo in questo “nuovo” metodo di sviluppo web dobbiamo soddisfare tutti i precedenti requisiti di ogni sito web.

Arrivederci pagine, benvenuti stati

In un’applicazione web senza JavaScript la sequenza di stato equivale alle pagine, e in un’applicazione SPI anche il più piccolo cambiamento implica un nuovo “stato” della pagina. Possiamo distinguere due categorie di stati:

• Stati fondamentali
• Stati secondari

La differenza tra uno stato e l’altro è molto importante, poiché gli stati fondamentali diventeranno pagine in caso di bisogno. La differenziazione tra fondamentale e secondario dipende dal sito web.

Per meglio capire i due stati possiamo analizzare un caso vero: la convalida di login.

In un’applicazione basata sul concetto classico di pagina, tipicamente il login è costruito usando due pagine, una per lo username e la password e l’altra che mostra le opzioni utente quando la convalida è corretta. La pagina di login verrà ricaricata mostrando alcuni messaggi di errore accanto al modulo di accesso quando l’utente compila il form con i dati sbagliati.

In un sito web a pagina singola, il login iniziale e la pagina di opzioni utente possono essere considerati gli stati fondamentali, e i messaggi di errore accanto al login gli stati secondari.

Facciamo un altro esempio, quello di un sito web basato su pagine da convertire in SPI. In questo caso gli stati fondamentali saranno le pagine e gli stati secondari quelle pagine con modifiche minori, non abbastanza importanti per il bookmarking o per essere analizzate dai crawler.

Interfaccia di pagina singola e bookmarking

Pagine differenti hanno URL differenti. Seguendo la direzione delle SPI come possiamo cambiare uno stato e allo stesso tempo l’URL senza ricaricare per far sì che gli utenti possano salvare il nuovo stato nei preferiti del browser?

C’è un trucchetto che si avvale della parte “àncora” dell’URL (“frammento hash”, “shebang” o “hashbang”). Si tratta dell’ultima parte che, se presente, segue il carattere #. L’àncora, anche conosciuta come collegamento interno alla pagina, è usata per scrollare la pagina in un esatto punto specifico con il contrassegno <a name=”ref”></a>. L’àncora, se modificata, non ricarica la pagina, quindi se il riferimento URL viene cambiato utilizzando il windows.location accanto allo stato della pagina (in questo caso il nuovo stato è “fondamentale”) con JavaScript e AJAX, non viene eseguito alcun ricaricamento. Poiché la URL e lo stato fondamentale sono stati modificati, l’utente può salvare come segnalibro la URL, che contiene le nuove informazioni di stato.

Quando l’utente vuole tornare indietro alla pagina salvata nei preferiti, lo stato di destinazione viene specificato nella parte “àncora” della URL e il server verrà sottoposto a richiesta. Purtroppo la parte di riferimento non viene inviata al server perché essa non ha nulla a che vedere con la posizione remota in HTTP, quindi avremo bisogno di un processo di post-caricamento.

Il server restituirà una pagina iniziale in cui lo stato di destinazione non è specificato, a ogni modo l’oggetto window.location contiene la URL originale inclusa l’àncora. Quando carichiamo la pagina di destinazione possiamo rilevare con JavaScript se windows.location contiene un’àncora e se questa àncora ha le informazioni richieste sullo stato di destinazione. Se è vero possiamo riscrivere la URL aggiungendo alcuni parametri normali per specificare lo stato di destinazione da caricare. Siccome la URL è effettivamente cambiata, viene eseguita una nuova richiesta al server; questa volta lo stato da caricare si trova in un parametro e il server restituisce una nuova pagina con lo stato richiesto.

Un’altra opzione, migliore delle àncore, arriverà con l’avvento dell’HTML5, l’HTML5 History API.

Interfaccia di pagina singola e Search Engine Optimization (SEO)

Il modo più semplice per far sì che il nostro sito web sia processato dai motori di ricerca è quello di offrire due differenti modi di navigazione: SPI per gli utenti e pagine per i web crawlers.

Il prossimo esempio mostra un link con questa idea:

<a href=”URL page” onclick=”return false”>…</a>

Questo link non genererà alcuna azione in un browser con JavaScript abilitato perché la navigazione è disabilitata dal “return false” sull’attributo “onclick”, ma quando un bot indicizza questo link ignora l’attributo perché il codice JavaScript non viene eseguito ed elaborerà la specifica URL come pagina successiva da processare.

Nel campo delle applicazioni SPI, le URL usate per la navigazione di pagina/stato devono contenere uno stato di destinazione, lo stesso tipo di URL usato nel bookmarking SPI che utilizza le àncore per indicare lo stato di destinazione, oppure il target viene scritto direttamente come un normale parametro, quest’ultima opzione è preferibile poiché evita una richiesta al server, ovviamente è possibile utilizzare anche URL “parlanti”.

Attualmente Google esegue già la scansione delle URL AJAX, ovvero delle URL che contengono lo stato di destinazione nella parte di riferimento che segue il carattere #! come specificato in Making AJAX Applications Crawlable, in questo caso il sito web/l’applicazione web deve restituire la pagina prevista richiesta con il parametro _escaped_fragment_.

Allo stesso tempo il framework web SPI può aggiungere un codice specifico al gestore di onclick prima di restituire “false” o può associare un processo in ascolto al link utilizzato per la navigazione della pagina/stato, registrato con addEventListener o attachEvent a seconda del browser. Questo processo eseguirà alcune azioni per comandare il server, solitamente usando AJAX, per cambiare lo stato della pagina. Quando il link viene cliccato, questa modifica di stato non è una nuova pagina perché l’attributo onclick=”… return false” evita il comportamento predefinito.

La tecnica descritta è la più semplice e immediata se si utilizzano link visibili compatibili con i bot e con SPI. Puoi sempre separare entrambe le funzioni, per esempio usando link nascosti per gli utenti ma non per i bot insieme ad altri elementi cliccabili per modificare gli stati SPI, servendoti di JavaScript invisibile per i robot.

La caratteristica più importante di un framework con funzionalità SPI è la generazione di pagine come HTML con lo stato richiesto sul tempo di caricamento e allo stesso tempo la modifica di stato deve essere eseguita con JavaScript e l’aggiornamento parziale della pagina. Questi requisiti sono fondamentali per fornire SPI e simulazione di pagina.

SPI e i bottoni indietro/avanti

I bottoni indietro/avanti rappresentano una fonte di problemi per i tradizionali siti web basati sulle pagine e dovrebbero essere proibiti il prima possibile. Nonostante gli utenti siano abituati a evitare i bottoni Indietro e Avanti quando compilano e inviano un form con i propri dati (perché questo comporta il rischio di comprare due volte lo stesso biglietto aereo o il medesimo libro), l’uso dei pulsanti Indietro/Avanti è molto diffuso.

Apparentemente il paradigma SPI rompe il tradizionale modo di navigare un sito web, perché in teoria i bottoni Indietro/Avanti non hanno senso in SPI (non vi sono pagine) e i browser non forniscono un buon controllo di questi comandi.

Non è però del tutto vero. Il comportamento Indietro/Avanti può essere simulato al posto della navigazione di pagina (e della cronologia in generale) Indietro/Avanti e può essere usato per cambiare lo stato corrente al precedente/futuro stato. In questo caso un codice JavaScript può individuare quando la parte “àncora” di una URL cambia e richiede all’applicazione di cambiare lo stato. Poiché il browser non cambia la pagina, la tua applicazione è pienamente responsabile del comportamento Indietro/Avanti, evitando i tipici problemi di inaspettato utilizzo di Indietro/Avanti quando l’utente invia un modulo. Ora in SPI non esiste tale modulo e non c’è navigazione di pagine fuori controllo dell’applicazione/sito web.

SPI e servizi basati sulle visualizzazioni di pagina

Servizi pubblicitari e contatori di pagine viste si basano sul numero di pagine caricate. In entrambi i casi puoi usare elementi iframe nascosti che contengono una pagina web vuota con gli scripts richiesti per eseguire questi servizi.

Nel caso di servizi pubblicitari come Google Adsense, l’inserimento dinamico di iframe implica il caricamento di nuovi annunci, per questo motivo ogni cambiamento di stato può comportare un nuovo caricamento dell’iframe con l’annuncio. Google Adsense sembra essere in grado di rilevare quando lo script è eseguito dentro un iframe a tiene conto del contenuto della pagina contenitrice. Potrebbe essere una buona scelta inserire un parametro che identifichi lo stato fondamentale che sta caricando l’iframe.

Nel caso del contatore di visite, possiamo usarle per monitorare le visite utente agli stati fondamentali del nostro sito web SPI. In questo caso aggiungiamo un iframe nascosto contenente una pagina web vuota con lo script di monitoraggio. Con un semplice parametro possiamo indicare quale stato fondamentale è stato visitato. Il nostro iframe dovrebbe essere globale (sempre lo stesso nella pagina). Quando la pagina viene caricata per la prima volta, lo stato fondamentale che viene caricato (specificato nella URL) dovrebbe essere indicato all’iframe con un parametro. Dopo il caricamento della pagina, ogni cambiamento di stato fondamentale dovrebbe essere notificato all’iframe modificando la URL via JavaScript secondo il nuovo stato fondamentale: questa URL comporterà un nuovo caricamento dell’iframe (che indicherà una nuova visita).

SPI e finestre pop-up

Quando viene creata una nuova finestra, il modello SPI viene compromesso. Il fondamentalismo non va bene, non ci sono problemi se lo stato di questa nuova finestra non ha niente a che vedere con lo stato della finestra genitore, in questo caso le finestre pop-up vanno bene.

Il problema si presenta quando qualsiasi azione messa in pratica sulla finestra pop-up (modale o non modale) ha una qualsiasi influenza sulla finestra genitore, e allora la coordinazione tra le pagine diventa complicata. Per esempio non c’è alcuno standard web per creare finestre modali perché il concetto di pagina è per tradizione sempre stato un elemento indipendente e perciò il suo ciclo di vita diventa difficile da coordinare da un’altra pagina.

Fortunatamente il problema può essere risolto da qualche tempo in SPI: puoi simulare finestre modali o non modali dentro la stessa pagina web, senza che alcuna finestra reale venga creata. Nel caso di finestre non modali, ogni elemento HTML con posizione assoluta può essere una “finestra non modale” e puoi creare finestre modali usando posizioni assolute, controllando lo z-index e l’opacità di elementi “sovrapposti” della pagina (“livelli modali”). Queste soluzioni sono valide in un contesto SPI.

Con un piccolo sforzo, anche lo stato che mostra una finestra modale può essere uno stato fondamentale e perciò navigabile dai bots dei motori di ricerca.

Un cambiamento culturale per gli sviluppatori web

Molti web developers (e web frameworks) pensano al web come basato sulle pagine. La riduzione a una singola pagina implica un cambiamento di mentalità davvero importante su come noi creiamo siti web e applicazioni web. Tuttavia questo cambiamento non è poi così radicale grazie ad AJAX che oggi è molto usato e ha ridotto il numero di pagine tipico dei siti web. In sostanza ci ha portati vicino al “nuovo” modello di sviluppo SPI.

Nel nuovo web SPI il tag <form> scompare e in generale scompare il bisogno di sessione utilizzata come gestore di dati che seguono sequenze di pagine. Ora la protagonista è la pagina lato client, con alcune simmetrie nel server (la pagina nel server). Infatti, poiché ci liberiamo dalla coordinazione di pagine con le sessioni, evitiamo una serie di problemi come la cattiva pratica di alcuni utenti che aprono diverse finestre con la stessa pagina. Questa pratica solitamente compromette la sessione e l’applicazione in generale.

La programmazione SPI è basata su eventi allo stesso modo del desktop, perché nel desktop molte delle applicazioni vengono eseguite nella stessa finestra e quando esistono finestre “figlio” queste sono completamente gestite dalla finestra principale e realmente modali.

Seguendo il paradigma evolutivo dello sviluppo web, questo “nuovo” approccio potrebbe essere chiamato Model 4.

Un cambiamento culturale per gli utenti?

Non molto. Con i segnalibri e la simulazione Indietro/Avanti gli utenti finali non differenziano tra un sito web SPI e lo stesso sito a pagine. Inoltre il sito SPI sarà più responsivo e verrà rimosso il tipico lampeggio e lo scorrimento della pagina di navigazione.

Fattibilità tecnica oggi

Questo manifesto non è una dichiarazione di intenti, ma l’espressione del desiderio di promuovere un “nuovo” modo di costruire siti web già reali. Lo studio tecnico di cui sopra ha sempre avuto il web framework Java ItsNat come la tecnologia base dello sviluppo di siti web SPI. Nonostante ItsNat sia stato concepito sin dal primo giorno per questo tipo di applicazioni/siti, le tecniche precedenti possono essere applicate ad altri framework web, o questi framework possono evolversi per fornire servizi per siti web SPI con requisiti di simulazione di pagina.

Alcuni requisiti di questi siti web SPI per poter sostituire i tradizionali siti web a pagine, come la simulazione di pagina di stati fondamentali sul tempo di caricamento, sono possibili esclusivamente con framework web centrici perché il rendering HTML deve avvenire sul server in fase di caricamento. L’HTML renderizzato in fase di caricamento e lo stesso inserito dinamicamente con JavaScript sono le chiavi caratteristiche di un web framework pronto a costruire siti web SPI. I framework client centrici potrebbero avere un maggior ruolo per la realizzazione dei cosiddetti stati secondari.

Il manifesto in lingua originale

Note: questa traduzione potrebbe non essere aggiornata poiché questo manifesto è “vivo”.

http://itsnat.sourceforge.net/php/spim/spi_manifesto_en.php

Con oltre il 30% delle preferenze, WordPress è una delle piattaforme più usate al mondo per la realizzazione di siti web. In questo articolo vediamo come sfruttare le potenzialità dello unit testing in WordPress per rendere il tuo sito molto più sicuro e performante.

WordPress, perché piace così tanto

Innanzitutto cerchiamo di capire come mai WordPress piace così tanto e cosa gli ha consentito di imporsi nel mercato dei CMS per lo sviluppo dei siti internet. Ecco alcuni punti di forza:

• Bassi costi: con poche decine di euro l’anno acquisti dominio + hosting e sei già pronto per l’installazione. Aggiungendo una piccola somma hai un template personalizzabile;
• Flessibilità: sebbene WordPress sia nato come piattaforma di blogging è evoluto in uno strumento flessibile che si presta alla realizzazione di siti con funzionalità molto diverse grazie agli innumerevoli plugin;
• Semplicità di utilizzo: WordPress è molto semplice da usare. In tantissimi lo scelgono per la sua rinomata facilità nell’aggiornamento dei contenuti, dal catalogo prodotti dell’e-commerce agli articoli per il blog;
• Posizionamento SEO: WordPress ha tutto ciò che serve per ragionare in ottica di posizionamento SEO già di base, inoltre alcuni plugin estendono questa possibilità fino a renderla eccellente (vedasi il famosissimo Yoast SEO);
• Community di supporto: in quanto software open source, WordPress ha un’attivissima community composta da sviluppatori e appassionati sempre pronti a dare supporto. Plugin, temi, aggiornamenti, quesiti tecnici: nei forum trovi risposta a ogni tua domanda.

Proprio la popolarità di WordPress è croce e delizia per noi sviluppatori. Perché se da un lato i clienti sono consapevoli della forza di questo strumento, dall’altro non tutti i developer lavorano con accuratezza e anzi, spesso tralasciano step importanti consegnando un prodotto che in quanto a sicurezza e performance lascia a desiderare. Per questo voglio evidenziare l’importanza dello unit testing, anche in WordPress.

Unit testing: cos’è

Lo unit testing è un’attività di test che prevede la verifica della correttezza delle singole unità di codice ed è un ottimo metodo per testare il corretto funzionamento di un sito in WordPress. L’idea di fondo è quella di creare un set di test in grado di capire se il codice, dati determinati input, risponda nel modo giusto. Per fare questo si utilizza un tool, PHPUnit, che consente al developer di verificare che lato codice il comportamento sia corretto.

Come si evince da queste breve descrizione, sottoporre WordPress a unit testing è estremamente più affidabile e approfondito dei normali test manuali che vengono di solito effettuati. Questi nella maggior parte dei casi consistono in un’analisi limitata dell’implementazione del frontend del sito, senza però andare a indagare oltre. Inoltre, non essendo automatizzati, sono soggetti ad errori umani e difficilmente ripetibili.

Unit testing in WordPress: un breve tutorial

Vediamo ora passaggio per passaggio come installare e usare PHPUnit Testing in WordPress.

Installare PHPUnit Testing

La prima cosa da fare è installare PHPUnit Testing, con il seguente comando:

composer global require phpunit/phpunit

Installare WP-CLI

WP-CLI è l’insieme degli eseguibili da linea di comando per integrare e gestire le installazioni WordPress. Questo sistema fornisce un’interfaccia di linea di comando per azioni che di solito si effettuano sia dentro che fuori l’area amministrativa. Per saperne di più visita la pagina ufficiale di WP-CLI.

Quello che a noi interessa è che WP-CLI ha semplificato di molto l’installazione di PHPUnit: per alcune operazioni è infatti molto più comodo e veloce usare linee di comando piuttosto che agire via browser. Esiste una guida molto dettagliata (in lingua inglese) che spiega come far girare unit tests; di seguito riassumo in italiano i principali step.

Per installare WP-CLI, scrivere il seguente comando:

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar 
chmod +x wp-cli.phar 
sudo mv wp-cli.phar /usr/local/bin/wp

Ora che hai installato PHPUnit e WP-CLI, useremo quest’ultimo per impostare lo unit test per il plugin.

Set up dello unit test per plugin

Accedi alla root della tua installazione di WordPress e scrivi questo comando per generare i file di test del plugin:

wp scaffold plugin-tests wp-my-test

Dopo aver generato i file di test, ecco ora la schermata con la struttura del plugin:

|-bin/
 |----install-wp-tests.sh
 |-tests/
 |----bootstrap.php
 |----test-sample.php
 |-.travis.yml
 |-phpcs.xml.dist
 |-phpunit.xml.dist
 |-wp-my-test.php

Scegli la directory del plugin e lancia l’installazione con questo script, sostituendo “username”, “password” e “host” con i dati relativi alla tua installazione:

bin/install-wp-tests.sh wordpress_test username 'password' host latest

Un consiglio: per fare queste operazioni usa un database di test.

Esegui gli unit test e verifica il risultato

Adesso puoi eseguire PHPUnit per lanciare il test di esempio e verificare il risultato:

phpunit

Se è tutto corretto dovresti ottenere:

Puoi quindi procedere con la scrittura dei tuoi test, prendi spunto da “test-sample.php” è il file che contiene il test di esempio appena eseguito.

I benefici dello unit testing in WordPress

Molti sviluppatori non usano testare in questo modo i loro progetti semplicemente perché non sanno come fare, o peggio ancora perché considerano la fase di test una perdita di tempo. Senz’altro lo unit testing in WordPress comporta un investimento di tempo, ma porta con se notevoli vantaggi:

• Hai la sicurezza che pochi o addirittura nessun bug colpiranno il tuo software;
• Risparmi tempo e denaro nelle fasi più delicate, ovvero supporto e aggiornamento;
• Eviti problemi con i clienti ed eventuali rivalse sul tuo operato.

Ecco un breve video riassunto di questo articolo (in inglese):

Per maggiori informazioni vedi il manuale di WordPress e la documentazione per PHPUnit.

Se ti serve supporto tecnico per scrivere codice e test contattami!

Internet of Things, o brevemente IoT, è un concetto molto utilizzato recentemente, ma il suo significato letterale è piuttosto ampio: si tratta di collegare oggetti, generalmente di uso comune, ad Internet per ampliarne lo spettro di utilizzo. Ma… in pratica?

Ho avuto occasione di partecipare ad un interessante corso pratico, organizzato da Lab Network, riguardo Arduino e IoT che mi ha permesso di provare con mano queste tecnologie applicandole ad una problematica comune, ovvero il controllo degli accessi.

Immaginiamo di dover garantire l’accesso ad una particolare area, stanza, sala per un tempo limitato ad un gruppo di persone: suona familiare? Bene.

Con questa tecnologia possiamo fornire un badge agli utilizzatori e controllare da un semplice pannello del browser se e quando ciascuno di essi può entrare. Il sistema, collegandosi ad Internet, verifica se il proprietario è autorizzato e, solo in caso positivo, invia il comando di apertura alla serratura.

Il sistema è composto da due elementi fondamentali: il dispositivo “IoT” (Arduino + Ethernet, lettore NFC e elettro-serratura) e il servizio remoto per la gestione degli accessi (API).

API gestione accessi

Per prima cosa predisponiamo il sistema di gestione degli accessi.

Non scendiamo nel dettaglio del software per il controllo degli accessi in quanto fuori dallo scopo primario di questo articolo; basti pensare che può essere sostanzialmente qualsiasi sistema, esistente o da creato ex-novo, che sia in grado di comunicare tramite Internet.

Ai fini del prototipo possiamo simulare questo comportamento con poche righe di codice che, leggendo un parametro GET della richiesta, lo confrontano con un codice definito come valido. Se i due codici corrisponodono la richiesta sarà approvata, in caso contrario, respinta.

Non ci resta che caricare il servizio su un server raggiungibile tramite Internet e siamo pronti a procedere.

Dispositivo IoT

Possiamo quindi passare alla creazione del nostro dispositivo, per farlo abbiamo bisogno di alcuni componenti:

• Arduino UNO + shield Ethernet;
• Adafruit PN532 NFC/RFID reader;
• Relè SRD-05VDC-SL-C;
• Tag NFC;
• Cavi, resistenze e led.

Effettuiamo il cablaggio semplicemente rispettando i datasheet; perchè il codice proposto funzioni dobbiamo però stare ad alcune scelte riguardo i pin di output di Arduino:

pin A1 => relé
pin A2 => led rosso
pin A3 => led verde
pin A4 => led giallo

A questo punto possiamo scrivere il programma di gestione del dispositivo, per farlo utilizziamo l’IDE proposto da Arduino stessa, scriviamo il codice e connettiamo il dispositivo tramite USB per caricarlo dopo averlo compilato.

Per evitare di dilungarci vi invito a scaricare il codice completo dal sito web del corso, riporterò qui solo i passaggi logici più importanti.

In una prima fase dobbiamo:

• importare le librerie,
• configurare lo shield ethernet,
• configurare lo shield nfc.

Quindi avviamo il setup e inizializziamo tutti i servizi.

A questo punto possiamo iniziare il ciclo vero e proprio, che sarà composto da tre sezioni fondamentali:

• lettura dei dati dallo shield ethernet,
• controllo del valore di risposta ed eventuale apertura della serratura,
• invio del codice NFC qualora ve ne fosse uno.

Conclusioni

La semplice soluzione proposta dal corso è un’ottima base per permettere di capire come le tecnologie IoT possano avere un’applicazione pratica e funzionale anche se, chiaramente, non è sufficiente per una situazione reale (presenta diverse problematiche di sicurezza in primo luogo).

Ritengo il progetto interessante per chi vuole fondere le competenze a livello software con l’elettronica e realizzare un prodotto reale. Inoltre, dopo i dovuti miglioramenti a livello software, sarebbe facile spaziare dalla gestione di una serratura ad altri campi come, ad esempio, l’agricoltura (illuminazione, irrigazione), l’intrattenimento (musica, video), o la domotica.

Qui un breve video del prototipo funzionante:

Se ti serve consulenza per il tuo progetto IoT contattami.

Poco più di un mese fa venni a sapere che il Team per la Trasformazione Digitale avrebbe promosso il più grande hackathon mai realizzato in Italia.

In sostanza un code sprint suddiviso in due differenti tempistiche:

• 2 giorni di sviluppo in una delle 26 sedi (in altrettante città italiane) predisposte;
• 1 mese opzionale per completare i progetti più complessi.

La partecipazione per i soli 2 giorni iniziali prevede la partecipazione alla premiazione della “fast rabbit”, decidendo di procedere anche per il mese successivo invece si accede alla cosiddetta “wise turtle”; l’obiettivo è comune: lo sviluppo di codice open source per i progetti centrali per la PA.

Non avendo mai partecipato ad un evento di questo tipo, tanto meno per un progetto così ambizioso, fui molto incuriosito. Quindi decisi di iscrivermi, almeno per i due giorni di sviluppo in sede.

Facciamo un passo indietro

Un hackathon è un evento al quale partecipano varie figure del campo informatico. Spesso lo scopo è di completare una o più sfide in un tempo limite prestabilito per concorrere alla vittoria di un premio finale.

Il promotore, Team per la Trasformazione Digitale, è tecnicamente una struttura commissariale istituita dal governo per avviare la costruzione del cosiddetto “Sistema operativo del Paese”. Il team è composto da diverse figure tecniche di altissimo livello ed esperienza internazionale.

Il focus di questo evento era il contributo alla risoluzione di problematiche legate ai principali progetti del Team, ovvero: Carta d’Identità Elettronica, La fattura elettronica, Anagrafe Nazionale della Popolazione Residente, Il Design System della Pubblica Amministrazione Italiana, I dati aperti della pubblica amministrazione, Data & Analytics Framework, Nodo di pagamento verso la Pubblica Amministrazione, Sistema Pubblico di Identità Digitale.

La challenge

La prima mattina, dopo una breve presentazione del progetto e degli sponsor, viene allestito un workspace Slack condiviso e inizia la descrizione delle challenge proposte.

Sin da subito è chiara la loro complessità, la maggior parte di esse richiedono potenzialmente un team di 3-5 persone per una tempistica vicina al mese. Non ho la possibilità di partecipare ad una sfida così lunga e non ho velleità di concorrere per il premio finale, decido quindi di selezionare una piccola challenge che posso potenzialmente completare, da solo, nell’arco di due giorni.

Da ciò che si evince in loco e sulla chat condivisa, la maggior parte dei partecipanti sono sviluppatori; al contrario sembra che i sistemisti o, per meglio dire, i DevOps, non siano così numerosi: sicuramente posso essere più utile in questo frangente.

Dopo aver spulciato il GitHub dedicato individuo una issue interessante: la creazione di un sistema di deploy in Ansible per un sistema basato su Docker che pubblica un’integrazione tra Secure the News e domain-scan.

L’obiettivo è quello di pubblicare una dashboard che visualizza la diffusione delle pratiche di sicurezza nei portali dello Stato:

• domain-scan è un sistema che unisce diversi strumenti di scansione per il web; utilizzandolo si ottiene, per ciascun dominio, la configurazione HTTPS oltre che altri dati opzionali;
• Secure the News e il sistema open-source utilizzato per il portale https://securethe.news, si tratta di un applicativo web scritto in Python su Django per la visualizzazione grafica dello stato di sicurezza (inteso come implementazione di HTTPS) di un insieme di domini.

Le difficoltà

Inizialmente la sfida mi era sembrata piuttosto semplice o quanto meno sufficientemente veloce per le mie tempistiche; dopo aver approfondito la questione leggendo il codice dei due tool noto però che il problema è di una complessità decisamente superiore.

I tool sono open-source: il primo, domain-scan, è relativamente semplice e generico; il secondo, Secure the News è stato rilasciato in seguito ad una implementazione specifica, perciò con un’astrazione limitata e relativamente poca documentazione (a meno che non si conosca Django e la mia esperienza con questo framework è pressoché nulla).

Entrambi gli applicativi offrono un esempio di deploy basato su Docker all’interno del repository, purtroppo però sono pensati solo per un ambiente di sviluppo, perciò piuttosto limitati. Decido comunque di utilizzarli come base per velocizzare i tempi e completare la sfida entro i due giorni prestabiliti.

Entro la sera del sabato domain-scan è operativo, quantomeno in locale; decido di chiudere e di dedicare la domenica a Secure the News. Il giorno successivo procedo in questo senso e per ora di pranzo ho un sistema funzionante, ma ci sono un paio di problemi:

• In primis gli ovvi problemi di prestazioni e sicurezza dell’utilizzo di un sistema pensato per lo sviluppo direttamente in produzione;
• In secondo luogo il formato di output di domain-scan non è direttamente compatibile con Secure the News.

Sono consapevole del primo punto, ma il secondo mi preoccupa: è necessario scrivere un parser per convertire l’output in un formato compatibile.

Mangio qualcosa e mi attivo subito: l’idea è di creare uno script in Python che si occupa di avviare domain-scan, convertire i risultati e importarli in Secure the News. Riesco a ad arrivare ad una bozza per le 16, ora di scadenza, ma nulla che possa neanche lontanamente andare in produzione.

La sfida però mi ha appassionato, decido quindi di ritagliarmi qualche giorno prima della fine del mese opzionale per rivedere il sistema e completarlo in ottica di una pubblicazione effettiva.

La consegna

Qualche giorno fa ho finalmente avuto un po’ di tempo da dedicarci: ho deciso di prendere come base quanto scritto in precedenza e di ridefinire il tutto in ottica di produzione, oltre, chiaramente, a completare lo script di importazione. Ecco il risultato finale.

Ho sviluppato 2 ruoli Ansible il più possibile generici per il deploy su Docker di: domain-scan e Secure the News; ho quindi creato un ulteriore ruolo che si occupasse di gestire l’integrazione dei due eseguendo (direttamente o tramite cron) lo script di import.

Quindi ho unito il tutto con un playbook con default sensibili e funzionali ad un deploy in locale, ma facilmente configurabile per un deploy remoto impostando le variabili nel playbook base e gli host nel file relativo. Ulteriori variabili opzionali sono presenti come default dei vari ruoli.

L’architettura creata da Ansibile, è così composta:

• un’istanza Docker, per domain-scan, avviata all’occorrenza;
• un cluster per Secure the News composto da multipli container Docker:
  • postgres,
  • node+python,
  • gunicorn,
  • nginx;
• uno script in python, eseguito tramite cron, che avvia il container domain-scan, converte e importa i dati in Secure the News.

Il risultato mi soddisfa: Ansible orchestra i container Docker che ora prevede, oltre all’istanza di domain-scan, anche tutti i container separati per lo stack richiesto da Secure the News. Il sistema di importazione è funzionante e testato per il test usato da Secure the News (phtts).

Consegno quindi il progetto tramite pull request, come richiesto.

Conclusioni

Questa esperienza mi ha piacevolmente sorpreso: a partire dalle due giornate in sede, in cui ho avuto l’occasione di conoscere persone appassionate e disponibili, fino alla conclusione di questi giorni, in cui ho avuto modo di apprezzare come il Team per la Trasformazione Digitale stia portando una ventata di nuovo in un frangente in cui l’Italia ha sempre peccato.

Chiaramente un evento come questo non può bastare a rivoluzionare (tecnologicamente) un paese, ma ha senz’altro dato una spinta ulteriore al progetto. Credo siamo nella direzione corretta: finalmente si vedono utilizzati software open-source su scala, metodologie competitive e strumenti moderni anche da parte di un organo statale.

All’indirizzo GitHub del progetto puoi scoprire le altre problematiche aperte e, se ti va, aiutare a risolverle.

Recentemente mi sono trovato a discutere di criptovalute con un caro amico, in particolare argomentavamo sul nostro gruppo Telegram di quanto il loro valore fosse fluttuante. In questo gruppo ci sono diversi amici comuni, più alcuni bot Telegram.

Allora mi sono chiesto: perché non realizzare un bot che fornisce il valore delle valute virtuali? Detto fatto e, per rendere il tutto più interessante, useremo un’architettura serverless.

L’idea di base è semplice: alla ricezione di un messaggio predefinito il bot recupererà il valore della valuta, quindi risponderà all’utente o al gruppo tramite Telegram.

Il tutto potrà essere eventualmente espandibile in futuro ad altre app di messaggistica o ad altre funzionalità: un’idea interessante sarebbe la possibilità di fare trading direttamente dalla chat… ma questa è un’altra storia.

Siamo pronti a cominciare, useremo Python come linguaggio di programmazione per il nostro bot e Amazon Web Services per l’architettura serverless.

Recupero valore criptovaluta

Innanzi tutto dobbiamo scrivere il codice che si occuperà di recuperare il valore di una criptovaluta, idealmente tramite API REST.

Con una veloce ricerca recuperiamo delle API pubbliche adatte a questo compito, abbiamo due alternative:

• https://coinmarketcap.com/api/
• https://min-api.cryptocompare.com

La prima è interrogabile in questo modo:

https://api.coinmarketcap.com/v1/ticker/bitcoin/

e restituisce:

[
    {
        "id": "bitcoin",
        "name": "Bitcoin",
        "symbol": "BTC",
        "rank": "1",
        "price_usd": "4145.22",
        "price_btc": "1.0",
        "24h_volume_usd": "2584150000.0",
        "market_cap_usd": "68467684788.0",
        "available_supply": "16517262.0",
        "total_supply": "16517262.0",
        "percent_change_1h": "-0.19",
        "percent_change_24h": "2.23",
        "percent_change_7d": "2.22",
        "last_updated": "1503224367"
    }
]

La seconda invece:

https://min-api.cryptocompare.com/data/price?fsym=BTC&tsyms=USD,EUR

e restituisce:

{"USD":4136.85,"EUR":3542.48}

La seconda è più comoda per il nostro scopo, con il plus di avere il valore sia in Dollari che in Euro… perfetta.

A questo punto non ci resta che scrivere il codice che, fornita la valuta di partenza e quella di destinazione, ci fornisce il valore di cambio. In Python possiamo scrivere una classe di questo tipo:

import urllib
import json

class Change:
    """Change.class."""

    PRICE_API = "https://min-api.cryptocompare.com/data/price"

    f = 'BTC'
    t = 'USD'

    def __init__(self, f='', t=''):
        """Change.__init__."""
        if(f != ''):
            self.f = f.upper()
        if(t != ''):
            self.t = t.upper()

    def get_value(self):
        """Change.get_value."""
        query = "?fsym={}&tsyms={}".format(self.f, self.t)
        value = json.loads(get_url(self.PRICE_API + query))
        try:
            return "1 {} is worth {} {}".format(self.f, value[self.t], self.t)
        except KeyError:
            return value['Message']

Il costrutture si occupa di inizializzare le variabili d’istanza con degli eventuali default per valuta di partenza e valuta di destinazione (rispettivamente BTC e EUR).

Il metodo “get_value” invia una richiesta all’api descritta sopra e ritorna una breve stringa che indica il cambio (se l’api ritorna il valore correttamente).

Interazione con Telegram

Il secondo passaggio è l’interazione con Telegram. A questo scopo sono disponibili diverse librerie, probabilmente la più famosa per Python è: https://github.com/python-telegram-bot/python-telegram-bot.

Vista la semplicità del nostro progetto e visto lo scopo prettamente didattico ci conviene però sviluppare il tutto da zero: saranno solo poche linee di codice.

Innanzi tutto dobbiamo ricevere i messaggi da Telegram per poterli processare e quindi rispondere, ci sono essenzialmente due strade:

• ascoltare gli aggiornamenti pubblicati da Telegram (es. https://api.telegram.org/botTOKEN/getUpdates);
• sfruttare la possibilità di creare un Webhook che verrà invocato da Telegram ad ogni aggiornamento (https://core.telegram.org/bots/webhooks).

Volendo creare un bot Telegram serverless utilizziamo il secondo metodo, in caso contrario dovremmo invocare il bot manualmente; per ora però non creiamo il Webhook, ci basta sapere il formato in cui riceveremo l’aggiornamento.

La notifica di un nuovo evento arriverà in JSON via POST, il formato è questo: https://core.telegram.org/bots/api#update. L’oggetto “Message” è a sua volta così strutturato: https://core.telegram.org/bots/api#message.

Ma c’è di più, nella pagina di documentazione dei Webhook, Telegram ci offre anche un insieme di esempi (già predisposti per cUrl, per altro) pronti per testare il nostro bot.

Per rispondere ad un messaggio ricevuto ci è sufficiente utilizzare l’apposito comando dell’API: https://core.telegram.org/bots/api#sendmessage. I due dati richiesti sono “chat_id” che identifica appunto la chat a cui rispondere e “text” che è la nostra risposta.

A partire da questi dati siamo in grado di scrivere il codice per gestire la richiesta e la risposta:

import urllib
import json
import os
class Telegram:
    """Telegram.class."""
    TELEGRAM_TOKEN = os.environ['TELEGRAM_TOKEN']
    TELEGRAM_API = "https://api.telegram.org/bot{}".format(TELEGRAM_TOKEN)
    TELEGRAM_REPLY = TELEGRAM_API + '/sendMessage'
    update = {}
    def __init__(self, update):
        """Telegram.__init__."""
        self.update = update
    def parse(self):
        """Telegram.parse."""
        response = ''
        if 'message' in self.update and 'text' in self.update['message']:
            words = self.update['message']['text'].split(' ')
            mode = words.pop(0)
            if mode.lower() == 'value':
                text = Change(*words).get_value()
                response = self.__reply(text)
        return response
    def __reply(self, text):
        """Telegram.reply."""
        chat = self.update['message']['chat']['id']
        return get_url(self.TELEGRAM_REPLY+"?text={}&chat_id={}".format(text, chat))

Il costrutture in questo caso popola semplicemente la variabile d’istanza con i dati ricevuti da Telegram.

Il metodo “parse” verifica se il messaggio corrisponde ad un comando del bot e in caso positivo:

• estrae le variabili e ottiene il valore richesto tramite la classe precedentemente descritta;
• risponde al richiedente tramite il metodo “reply”.

Al momento non abbiamo ancora generato un token per identificarci con Telegram, prevediamo perciò di leggerlo come variabile d’ambiente (in pieno stile “Twelve-factor App”).

Definizione bot Telegram

E’ giunto il momento di informare Telegram della nostra intenzione di creare un nuovo bot.

La creazione e configurazione (privacy, nome, immagine, ecc.) dei bot in Telegram è gestita da… un bot chiamato BotFather, per cominciare iniziamo quindi una chat con lo stesso (https://t.me/BotFather) e per creare un nuovo bot lanciamo il comando:

/newbot

Dopo aver inserito nome e nome-utente del bot (che deve terminare in “bot”), BotFather ci informa che la creazione è andata a buon fine comunicandoci inoltre il token per le richieste tramite API http:

Done! Congratulations on your new bot. You will find it at
t.me/CryptocurrencyChangeBot. You can now add a description, about section and
profile picture for your bot, see /help for a list of commands. By the way,
when you've finished creating your cool bot, ping our Bot Support if you
want a better username for it. Just make sure the bot is fully operational
before you do this.

Use this token to access the HTTP API:
382957193:AAGMyGuQFOQ0vBoNWOQTWd3GLAPwg9le6VU

D’ora in poi (fintanto che non lo cancelleremo) possiamo eseguire comandi per il nostro bot con questa sintassi (sostituendo a “TOKEN” il codice che ci è stato fornito da BotFather):

https://api.telegram.org/botTOKEN/COMMAND

Alcuni comandi sono “informativi”, ad esempio, per ottenere le informazioni di base, usiamo:

https://api.telegram.org/botTOKEN/getMe

Altri sono “dispositivi”, in seguito vedremo, ad esempio, come impostare il nostro webhook con questo comando:

https://api.telegram.org/botTOKEN/setWebhook?url=WEBHOOK_URL

Infine dobbiamo notare che di default i bot ricevono:

• messaggi diretti;
• risposte al bot stesso;
• comandi diretti.

Se volessimo ricevere anche tutti i messaggi dai gruppi dovremmo disabilitare la privacy mode, sempre tramite “BotFather”.

La documentazione completa delle API http per i bot Telegram è disponibile all’indirizzo: https://core.telegram.org/bots/api.

Deploy su AWS serverless

L’architettura serverless è estremamente vantaggiosa per microservizi con carico estremamente variabile (esattamente come il nostro bot). Il concetto è ben dettagliato da Amazon su: https://aws.amazon.com/it/serverless/.

La creazione di una semplice piattaforma serverless senza storage di dati su AWS prevede due passaggi: il primo è la creazione e configurazione di AWS Lambda per il calcolo, il secondo è la configurazione di Amazon API Gateway che richiami la nostra funzione quando invocato.

AWS Lambda

Qui è dove il nostro codice verrà eseguito, un servizio in AWS Lambda è detto funzione; per crearne una accediamo ad AWS (http://aws.amazon.com) e quindi al pannello Lambda.

Clicchiamo “Create a function”, quindi “Author from scratch” e “Next” per saltare, per ora, la creazione di un trigger; inseriamo quindi alcune informazioni di base.

Carichiamo quindi il nostro codice, definiamo i ruoli per i permessi e le variabili d’ambiente inserendo il token fornito da Telegram come “TELEGRAM_TOKEN”.

Scegliamo poi l’“Handler”, questa è la singola funzione che viene eseguita alla chiamata del servizio, deve occuparsi di:

• gestire i parametri;
• eseguire il codice necessario;
• rispondere in maniera appropriata ad AWS.

Abbiamo già visto in dettaglio il formato della chiamata che riceveremo da Telegram, Amazon API Gateway la incapsulerà nei dati della richiesta (“event”) e la inoltrerà alla nostra funzione insieme ad altri dati relativi all’ambiente (“context”), maggiori dettagli qui: http://docs.aws.amazon.com/lambda/latest/dg/python-programming-model-handler-types.html (per Python).

Per ora concentriamoci solo su “event”, il formato è questo (la richiesta Telegram è incapsulata in event[‘body’]): http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-set-up-simple-proxy.html#api-gateway-simple-proxy-for-lambda-input-format.

La nostra funzione Lambda dovrà inoltre a sua volta rispondere correttamente ad Amazon API Gateway per evitare che le chiamate vengano interpretate come errore, il formato corretto è questo: http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-set-up-simple-proxy.html#api-gateway-simple-proxy-for-lambda-output-format.

A questo punto abbiamo tutti gli elementi per comporre una semplice funzione handler che si occupi di estrarre i dati di cui abbiamo bisogno e di rispondere a dovere alla richiesta. Eccola:

def lambda_handler(event='', context=''):
    """handler."""
    response = Telegram(json.loads(event['body'])).parse()
    return {"statusCode": '200', "body": response}

La documentazione completa di AWS Lambda è disponibile qui: http://docs.aws.amazon.com/lambda/latest/dg/welcome.html.

Amazon API gateway

Una volta perfezionata la funzione Lambda è necessario definire l’endpoint che ad una determinata richiesta richiami la funzione stessa, questa è la funzione di Amazon API gateway.

Accediamo quindi al servizio e creiamo una nuova API definendo alcune impostazioni di base.

Dopo averla creata dobbiamo definire la risorsa da pubblicare. Clicchiamo su “Actions” quindi “Create Method”. Il webhook del bot Telegram, come da documentazione, invia una chiamata POST, andiamo perciò a definire una nuova risorsa di questo tipo che imposteremo per richiamare la nostra funzione Lambda:

A questo punto non ci resta altro che rendere disponibile il tutto: clicchiamo quindi nuovamente “Actions” quindi “Deploy API”, definiamo per finire il nome dell’ambiente:

Ora abbiamo a disposizione l’indirizzo che useremo come webhook su Telegram per richiamare il nostro servizio:

La documentazione qui: https://aws.amazon.com/it/api-gateway/.

Webhook Bot Telegram

E’ tutto pronto! A questo punto non ci resta che dire a Telegram a quale indirizzo riferirsi per interrogare il nostro bot: ovvero definire il “webhook”.

Per impostarlo procediamo tramite API con il comando visto sopra e, di default, Telegram notificherà tutti gli eventi della chat; se vogliamo evitare di caricare inutilmente il servizio ci conviene limitare le chiamate ai soli aggiornamenti pertinenti, è possibile farlo dettagliando il tipo di richieste durante l’impostazione:

https://api.telegram.org/botTOKEN/setWebhook?url=WEBHOOK_URL&allowed_updates=["message","channel_post"]

Possiamo poi richiedere informazioni riguardo il Webhook tramite:

https://api.telegram.org/botTOKEN/getWebhookInfo

Conclusioni

Abbiamo raggiunto il nostro obiettivo, il bot è pronto per ricevere domande e rispondere a tono.

E’ sicuramente migliorabile in diversi aspetti, il primo probabilmente è la gestione degli errori – praticamente assente – oltre che la sintassi molto basilare.

Come esperimento è comunque sufficiente per capire meglio come funzionano i bot, strumenti in rapida diffusione molto comodi per scopi informativi e ludici e recentemente in sperimentazione anche per scopi commerciali e promozionali da parte di diverse realtà.

Inoltre è stato un buon pretesto per provare la creazione di un servizio serverless: senz’altro una tecnologia molto interessante in quanto permette di creare applicazioni senza costi fissi e perfettamente scalabili, l’ideale per la sperimentazione di nuove idee.

Tutto il codice visto sopra è liberamente disponibile su GitHub all’indirizzo https://github.com/andreacasarin/CryptocurrencyChangeBot, il bot Telegram, inoltre, è attivo, per utilizzarlo è sufficiente aggiungerlo tramite questo link: https://t.me/CryptocurrencyChangeBot.

Non ha comandi diretti ma reagisce a particolari messaggi inviati, ovvero:

Value

è la forma più semplice e restituisce il valore dei Bitcoin in Dollari americani,

Value eth

restituisce il valore di Ethereum (ad esempio) in Dollari americani,

Value eth eur

infine restituisce il valore della valuta richiesta in Euro.

Se ti serve supporto per realizzare il tuo bot Telegram ingaggiami!

Spesso mi viene chiesto di cosa mi occupo esattamente e devo dire che molte volte ho anche avuto difficoltà a dare una risposta chiara. Così ho pensato di scrivere un articolo a riguardo, sperando che possa aiutarmi a mettere nero su bianco una presentazione semplice e precisa della mia occupazione.

Per la maggior parte del mio tempo mi occupo di digitale in azienda, aiuto gli imprenditori a snellire il loro lavoro tramite soluzioni informatiche.

Seguo aziende, nuove o affermate, che hanno problemi nella gestione delle informazioni. Analizzo la situazione attuale e progetto una situazione ideale definendo passaggi necessari per raggiungerla. Quindi intervengo per raggiungere gli obiettivi.

In passato si era limitati alle soluzioni locali e i prodotti più avanzati erano baluardo delle grosse aziende, ora, fortunatamente, non è più così. Agendo in modo indipendente non vincolo i miei clienti e non ho vincoli dai miei fornitori, così posso ridurre i costi fissi e proporre sempre una soluzione ad-hoc.

Per finire, vi lascio un consiglio, sperando che possa aiutarvi a scegliere, anche autonomamente, il meglio per la vostra attività.

Ormai il mercato, ed in special modo quello informatico, non ha più confini territoriali. Nella scelta di una soluzione confrontate anche i servizi offerti da grosse aziende internazionali (penso, ad esempio, a G Suite per le email aziendali, AWS per il cloud computing o Atlassian per il project management) alle proposte del vostro fornitore locale, spesso possono essere estremamente competitive per costi e prestazioni.

Se non hai già una persona di riferimento per il digitale in azienda offrimi un caffè, potremo parlare di come l’informatica può migliorare il tuo business.

Benvenuto su andreacasarin.com, questo è il mio primo post e voglio cogliere l’occasione per descrivermi e descrivere lo scopo di questo progetto.

Nel mio percorso professionale ho avuto esperienze diverse, a partire dal lavoro dipendente per piccole e grandi realtà, fino co-fondare una digital agency, Pixelperfect, nel 2011. Nel 2017 ho deciso di proseguire in una direzione diversa, votata alla massima dinamicità, e sono diventato ufficialmente un freelance.

L’informatica ed in particolare il mondo del web è una mia passione, oltre che il mio lavoro: entrambe le facce di questa medaglia mi portano ad aggiornarmi continuamente e sperimentare nuove tecnologie. Tramite andreacasarin.com sito voglio condividere proprio questo.

Pubblicherò, senza una cadenza precisa, articoli tecnici riguardo i miei progetti o opinioni riguardo le tecnologie che sto utilizzando, cercando confronti costruttivi con altri appassionati e professionisti.

Userò inoltre questa vetrina sul web per creare un piccolo curriculum e mostrare i miei progetti più interessanti per permettere a chi vuole realizzare progetti correlati di conoscere le mie referenze ed eventualmente di chiedermi supporto.

Sentiti perciò libero di contattarmi per salutarmi, esprimermi la tua opinione o propormi un progetto, faccio il possibile per rispondere a ciascun contatto che ricevo.