Writing Style - giobidev

Questo documento descrive lo stile di scrittura usato su giobidev, con esempi concreti e linee guida.

Tono e Voce

Caratteristiche principali:

  • Informale, diretto, personale
  • Sarcasmo leggero ma presente
  • Niente marketing-speak o frasi fatte
  • Come se stessi spiegando a un collega davanti a un caffè
  • Ammette dubbi e limiti (“non lo so”, “potrei sbagliarmi”)

Esempio BUONO:

Mo te lo spiego, perché questa è una di quelle cose che sembrano innocue finché non succede il casino.

Esempio CATTIVO (troppo formale):

In questo articolo analizzeremo le motivazioni per cui questa configurazione può risultare problematica.

Struttura delle Frasi

Usa periodi più lunghi con subordinate

NON fare:

HTTP = Tutto in chiaro.
La password viaggia sulla rete.
Chiunque può intercettarla.
È pericoloso.

SÌ fare:

HTTP = Tutto in chiaro: quando accedi a phpMyAdmin via HTTP, la password viaggia in chiaro sulla rete, il che significa che chiunque sia sulla stessa rete WiFi può intercettare il traffico e leggere tutto.

Punteggiatura: meno punti, più due punti e punto e virgola

Due punti per introdurre spiegazioni:

phpMyAdmin standard non ha nessun limite tentativi login: puoi provare 10.000 combinazioni senza che nessuno venga avvisato.

Punto e virgola per collegare frasi correlate:

Non stai decidendo tu se far entrare gente; la porta è aperta sulla strada, chiunque passa può provare a entrare.

Virgole per subordinate:

Script automatici scansionano tutti gli IP di internet cercando phpMyAdmin esposti, e quando trovano il tuo provano le solite combinazioni.

Evita liste puntate troppo frammentate

NON fare:

Problemi:
- HTTP
- IP pubblico
- Nessun firewall
- Nessun 2FA

SÌ fare (integra nel testo):

Ora immagina di metterlo sulla strada principale (IP pubblico, raggiungibile da chiunque), con la porta sempre aperta (HTTP, nessuna encryption), con la chiave appesa fuori (form login esposto, nessun 2FA), e con un bel cartello luminoso “ARCHIVIO AZIENDALE”.

Analogie e Metafore

Usa analogie concrete del mondo reale, non astratte:

BUONO (concreto):

È come urlare la combinazione della cassaforte mentre entri nel magazzino: chi sta fuori ti sente e se la segna.

CATTIVO (astratto):

È come rendere pubbliche informazioni riservate in un contesto non sicuro.

BUONO (relatable):

È come lasciare la macchina aperta in centro. Non serve essere Ferrari. Basta non chiudere le portiere.

Anticipa Obiezioni

Metti le obiezioni comuni come sottotitoli:

## "Ma Tanto Siamo Piccoli, Chi Ci Attacca?"

Questa è la mia preferita. La sento almeno una volta al mese.

**Nessuno vi attacca direttamente. Siete solo un IP nella lista.**

Usa il corsivo implicito con virgolette:

“Ma tanto è solo per uso interno” “Siamo una piccola azienda” “Non è mai successo niente”

Esempi Pratici

Apertura articolo

BUONO:

Vedo ancora troppi server con phpMyAdmin esposto direttamente su http://123.123.123.123/phpmyadmin/: HTTP senza HTTPS, IP pubblico, accesso diretto.

E ogni volta che lo vedo penso: “Ma vi rendete conto di cosa state facendo?”

Mo te lo spiego, perché questa è una di quelle cose che sembrano innocue finché non succede il casino.

CATTIVO:

In questo articolo parleremo di phpMyAdmin e dei rischi di esporlo su HTTP. Analizzeremo i problemi di sicurezza.

Chiusura articolo

BUONO (con twist):

Ah, e questo post? Human Review: 80%, l’ho scritto quasi tutto io.

(O forse no. Come fai a saperlo?)

BUONO (diretto):

Mo sai.

CATTIVO:

Speriamo che questo articolo vi sia stato utile. Grazie per aver letto.

Voce Personale

Usa esperienze dirette:

BUONO:

Questa è la mia preferita. La sento almeno una volta al mese.

Di solito subito prima di chiamarmi dicendo “ci hanno bucato”.

CATTIVO:

Molti utenti sostengono che…

Terminologia Tecnica

Quando usarla:

  • Se il termine è standard e breve: usalo
  • Se richiede spiegazione: spiega inline, non in parentesi

BUONO:

Man-in-the-middle: chiunque sulla stessa rete WiFi può intercettare il traffico

CATTIVO:

MITM attack (attacco Man-in-the-Middle, ovvero un tipo di attacco informatico in cui…)

TL;DR Style

Ogni articolo finisce con un TL;DR conciso:

## TL;DR

phpMyAdmin esposto su `http://IP-pubblico/phpmyadmin/` è:

❌ **HTTP** → Password in chiaro sulla rete
❌ **IP pubblico** → Chiunque può provare ad accedere
❌ **Path standard** → Bot lo trovano automaticamente

**Fix**: VPN + HTTPS + 2FA + monitoring. Non è difficile, richiede 1 ora di setup, ti salva da disastri.

Parole e Frasi Ricorrenti

Usa:

  • “Mo te lo spiego”
  • “Zio” (quando appropriato al contesto)
  • “Cazzo” / “Cavolo” (con moderazione)
  • “Guarda”
  • “Bello, ma…”
  • “È che…”

Evita:

  • “Inoltre”
  • “Pertanto”
  • “In conclusione”
  • “Come abbiamo visto”
  • “È importante notare che”
  • “Speriamo che questo articolo”

Side Projects & AI

Filosofia sui side projects (2025-11):

L’IA mi dà modo di far prendere forma anche alle cagate, quindi cercando un minimo di fare qualcosa di sensato diventa terapeutico buttare fuori idee del genere.

Stile:

  • Sarcastico ma quieto (NON aggressivo o tranchant)
  • Periodi di media lunghezza con subordinate
  • NO tecnicismi eccessivi o simboli (+-/*)
  • Tono da “caffè con un collega”, non da “tech evangelist”

Human Review Badge

Ogni articolo ha un badge che indica quanto è stato rivisto:

human_review: 75  # Percentuale 0-100

Scale:

  • 0-30%: AI-heavy, revisione minima
  • 30-70%: Collaborazione bilanciata (maggioranza)
  • 70-100%: Scritto principalmente da umano

Nerd Level

Indica la complessità tecnica:

nerd_level: 2  # Scala 1-10

Scale:

  • 1-3: Accessibile, pochi tecnicismi
  • 4-6: Intermedio, assume conoscenze base
  • 7-8: Avanzato, assume esperienza
  • 9-10: Deep dive, per specialist

Esempi di Trasformazione

Da formale a personale

PRIMA:

Si consiglia di implementare HTTPS per garantire la sicurezza delle comunicazioni.

DOPO:

Metti HTTPS. Non è opzionale, è il minimo sindacale se non vuoi che le password viaggino in chiaro.

Da spezzettato a scorrevole

PRIMA:

phpMyAdmin è esposto. È su HTTP. L’IP è pubblico. È pericoloso.

DOPO:

phpMyAdmin esposto su HTTP con IP pubblico è pericoloso, perché chiunque può intercettare il traffico e vedere tutto in chiaro.

Da astratto a concreto

PRIMA:

Questa configurazione presenta vulnerabilità di sicurezza significative.

DOPO:

Questa configurazione è come lasciare l’archivio aperto sulla strada: prima o poi qualcuno entra e si porta via tutto.

Checklist Pre-Pubblicazione

Prima di pubblicare un articolo, verifica:

  • Tono informale e diretto (come davanti a un caffè)
  • Periodi con subordinate, non solo frasi brevi
  • Uso di due punti e punto e virgola
  • Analogie concrete e relatable
  • Anticipa obiezioni comuni
  • Voce personale presente (“la sento almeno una volta al mese”)
  • Termini tecnici spiegati inline
  • TL;DR finale presente
  • Human review e nerd level impostati
  • Chiusura con twist o frase diretta (“Mo sai”)

Ricorda: L’obiettivo è scrivere come se stessi spiegando a un collega competente, non come se stessi scrivendo un manuale o un articolo accademico. Sii diretto, onesto, e un po’ sarcastico quando serve.