Blog on Melabit

Dieci anni!

Mon, 18 Dec 2023 06:00:00 +0000

Dieci anni fa nasceva MelaBit, questo piccolo blog dedicato al mondo Apple, della programmazione e della scienza con un pizzico di nostalgia per il retrocomputing. Sembra ieri quando pubblicai il mio primo articolo, e invece eccoci qui, nel 2023, a festeggiare il primo decennio di vita di questo spazio online.

In tutti questi anni MelaBit è cresciuto insieme a me e a tutti voi lettori, che mi avete sostenuto con i vostri commenti, le condivisioni e il tempo che dedicate a leggere i miei articoli.

In questi dieci anni ho avuto il piacere di raccontare le novità di Apple e dei sistemi operativi, scoprire insieme a voi linguaggi di programmazione e software utili e condividerete riflessioni sulle innovazioni tecnologiche. Ho potuto viaggiare nel tempo parlando di mitici computer del passato ed esplorare alcuni affascinanti ambiti della scienza.

Voglio ringraziare ognuno di voi per aver reso MelaBit quello che è oggi. Grazie ai miei primi lettori, a chi è arrivato negli anni e a chi ci seguirà in futuro. Il viaggio continua, tutti insieme!

Post Scriptum. Per l’immagine di copertina ho lasciato fare all’IA di Microsoft (eh già!). Secondo me ha fatto un buon lavoro, ma alcune alternative erano altrettanto valide, come si può vedere qui sotto. Peccato solo per gli strafalcioni nell’ultima immagine, sarà pure artificiale ma un ripassino di grammatica questa intelligenza dovrà pur farlo!

Da melabit a melabit: conclusioni

Wed, 03 Jul 2019 06:00:00 +0000

“Dopo tutto questo parlare di hosting, domini, provider e cloud, si può sapere cosa hai deciso alla fine di fare per questo blog?”

Sono consapevole di contraddire quello che avevo scritto alcuni anni fa ma, dopo aver soppesato tutte le alternative, mi sono reso conto che la cosa migliore da fare in questo momento era cambiare il meno possibile, per cui ho deciso di continuare ad usare WordPress, ospitato questa volta su una piattaforma di hosting tradizionale.

Per ora niente generatori di siti statici come Jekyll (che nonostante tutto continua a piacermi tantissimo), Grav o Hugo, niente CMS alternativi, magari più veloci ed efficienti di WordPress. Passare dalla “gabbia” dorata di Wordpress.com – nella quale devo solo occuparmi di scrivere e a tutto il resto ci pensa Automattic – ad una piattaforma autogestita è già abbastanza complicato per volersi imbarcare in una transizione ancora più radicale. Qualche anno fa sarebbe stato più facile, ma in questo momento è un rischio che non voglio (e che non ho nemmeno il tempo di) correre.

– Fonte: Amador Loureiro su Unsplash.

Senza dimenticare che negli ultimi tre anni ho avuto modo di sperimentare a fondo la stabilità e l’affidabilità di WordPress gestendo un sito (semi)professionale con un carico di lavoro nettamente superiore a quello prodotto da questo blog e con editor multipli, interventi sul forum, un gran numero di utenti registrati, infinite richieste di supporto tecnico nonché (potevano mancare?) innumerevoli attacchi al sito. WordPress si è comportato benissimo, perché buttare via questa esperienza sul campo?

Non nascondo di essere stato attratto a lungo dall’ipotesi “WordPress + Raspberry Pi”, mi intrigava moltissimo l’idea di gestire tutto autonomamente, ma poi ho deciso che il gioco non valeva la candela e ho lasciato perdere.

Ormai è tutto pronto o quasi. Il nome c’è, l’hosting pure, ho anche scelto un tema nuovo e più adatto (spero!) a mostrare i contenuti disponibili, manca solo il tocco finale, la pressione del classico bottone di avvio. Se non ci sono imprevisti ~~luglio~~ settembre dovrebbe essere il momento buono.

Ma niente è per sempre e non è detto che, dopo aver completato questa prima transizione, non decida di farne un’altra più radicale adottando Jekyll, la piattaforma che considero ancora la più vicina al mio spirito di programmatore, seppur solo part-time.

Da melabit a melabit, la serie completa degli articoli

Da melabit a melabit: andare sul cloud

Mon, 24 Jun 2019 06:00:00 +0000

– Fonte: Daniel Falcão su Unsplash.

Il cloud computing è ovunque e ci sono decine di servizi diversi che ci permettono di usare un computer virtuale situato da qualche parte nel mondo come se fosse il computer fisico che abbiamo sulla scrivania. In questo campo i grossi calibri sono Amazon AWS, Google Cloud, Microsoft Azure, Red Hat OpenShift (in rigoroso ordine alfabetico), ma ci sono anche i servizi offerti da fornitori di servizi di hosting come SiteGround, DreamHost o Netsons oppure da provider più orientati al mondo degli sviluppatori come Digital Ocean, Codenvy, Heroku, UpCloud.

Descrivere tutto quello che fanno questi servizi è impossibile, le opzioni e le configurazioni sono tante e tanto diverse che cercare di orientarsi fra le varie possibilità fa letteralmente girare la testa (provate a districarvi nel sito di Amazon AWS e poi ditemi). Ma rimanendo a quello che ci interessa qui, tutti questi servizi mettono a disposizione un computer virtuale ospitato sull’onnipresente cloud dove possiamo installare un sistema operativo (generalmente Linux) e tutte le applicazioni necessarie per realizzare il nostro sito web.

Anche in questo caso valgono considerazioni analoghe a quelle fatte una settimana fa per il Raspberry Pi, con l’ovvia differenza che ora non dobbiamo preoccuparci degli aspetti legati all’hardware, visto che la macchina fisica e l’indirizzo IP sono forniti dal fornitore di servizi di cloud computing (in realtà la nostra macchina fisica non esiste nemmeno, il nostro computer virtuale sul cloud è solo un contenitore Docker ospitato insieme a mille altri su un server di un qualche datacenter).¹ A noi rimarranno comunque alcuni oneri importanti, come ad esempio quello di aggiornare e mantenere in sicurezza il sistema operativo e i pacchetti software che utilizziamo per realizzare il sito web.

Ma oltre a non doverci preoccupare di gestire l’hardware, il vero vantaggio di ospitare il sito su un servizio di cloud computing è quello di essere liberi di utilizzare per il sito il software che preferiamo, senza i vincoli stabiliti dai normali fornitori di servizio di hosting che normalmente danno la possibilità di scegliere solo fra un certo numero di applicazioni predefinite, selezionate fra quelle più popolari.

Se per il nostro sito vogliamo usare un CMS come Wordpress, Drupal, CMS Made Simple o Kirby non fa nessuna differenza, anzi un servizio di hosting tradizionale può essere preferibile perché ci permette di concentrarci sui contenuti, lasciando tutta la gestione del sito al fornitore del servizio di hosting. Ma se vogliamo utilizzare dei CMS meno diffusi come Ghost o Postleaf oppure dei generatori di siti statici come Jekyll, Hugo, Grav o Hexo,² la soluzione cloud ci offre una flessibilità impareggiabile, nettamente maggiore di quella offerta da un normale servizio di hosting.

Tutto questo però ha un prezzo da pagare. Un servizio di hosting decente può costare anche solo qualche decina di euro all’anno, per usufruire di un computer (anche se solo virtuale) nel cloud la cifra da sborsare è nettamente maggiore, dell’ordine di almeno 20-30 euro al mese (con variazioni enormi fra le offerte dei diversi provider).

Prima di scegliere fra hosting e cloud bisognerà quindi valutare realisticamente quello che vogliamo fare con il sito web (un blog personale è ben diverso da un sito di commercio elettronico), tenendo bene in conto dell’impegno richiesto per mantenerlo in forma e delle competenze tecniche necessarie per gestire un servizio mediamente complesso come questo. Trascurare quest’ultimo punto in particolare potrebbe significare dover spendere cifre nettamente maggiori per rimediare ai problemi di configurazione, o peggio di sicurezza, che potrebbero danneggiare gravemente non solo il sito ma anche la nostra immagine. In questo campo i costi non sono solo quelli che si vedono sul cartellino del prezzo.

Da melabit a melabit, la serie completa degli articoli

Il nostro unico problema sarà quello di associare l’indirizzo IP al nome di dominio (ma in genere lo stesso fornitore del nome di dominio ci mette a disposizione gli strumenti per farlo da soli). ↩︎
Dei primi tre ne ho scritto parecchio anche qui, chi vuole può leggere i vecchi articoli su Grav, Hugo e Jekyll. ↩︎

Da melabit a melabit: fare da sé?

Tue, 18 Jun 2019 06:00:00 +0000

– Fonte: Glen Carrie su Unsplash.

Non avrei mai immaginato che sarebbe passato un anno intero prima di riuscire a scrivere ancora di trasferimento del blog, hosting e così via. Nel mezzo c’è stata una transizione lavorativa improvvisa e quasi inaspettata oltre che vari impegni familiari improrogabili e non sono riuscito a fare di più. Ma abbiamo già perso troppo tempo, quindi meglio venire subito al dunque.

Fare da soli

Abbiamo già visto come scegliere il servizio di hosting, cioè l’azienda (o provider) che gestisce l’infrastruttura hardware e software su cui si basa il nostro sito web e che lo rende raggiungibile attraverso la rete. Un provider ha un certo costo, che per un blog personale o un sito web di un professionista o di una piccola azienda può andare da un minimo di 20-30 euro a qualche centinaia di euro all’anno, a seconda del provider, dei servizi scelti e del livello di supporto desiderato. A fronte di questa spesa assolutamente ragionevole, utilizzare un provider permette di delegare la gestione di tutta l’infrastruttura hardware, l’aggiornamento del sistema operativo e del software su cui si basa il sito, la sicurezza, il backup e così via, a degli esperti professionisti (si spera!), lasciando a noi solo il compito di gestire i contenuti veri e propri del sito.

Ma… e se volessimo lo stesso fare da soli? Magari perché vogliamo imparare a gestire un server. Oppure perché vogliamo provare diverse soluzioni prima di decidere come realizzare definitivamente il nostro sito. Perché siamo restii a far gestire il nostro sito da un provider che domani potrebbe scomparire. Per semplice curiosità o perfino perché vogliamo riutilizzare come server web un vecchio computer lasciato a marcire in cantina.

Cominciamo dalla fine. Se sperate di poter fare quello che era così comune agli albori del web, prendere un computer ormai vecchio e poco performante e fargli gestire il vostro piccolo sito web, mi dispiace ma dovete ricredervi. Il web di oggi è molto diverso da quello di 15-20 anni fa, è infarcito di JavaScript, di contenuti dinamici, di CSS, di decine di altre tecnologie completamente sconosciute anche solo cinque o sei anni fa. Un computer vecchio, con un processore obsoleto, poca RAM, con un hard-disk lento come una lumaca, non ce la fa più a gestire in modo efficiente il web odierno, a meno di non ostinarsi a realizzare un sito vecchio (anzi, vecchissimo) stile, con le pagine scritte in HTML puro e collegate manualmente l’una all’altra. Un sito come quelli di GeoCities o giù di lì.

Raspberry Pi

Per fortuna per un sito web non serve nemmeno una workstation superpotente con processore Xeon e decine di gigabyte di RAM, è sufficiente un computer moderno anche se a basso costo.

E fra i computer a basso (o meglio, bassissimo) costo disponibili sul mercato, il più interessante è senza alcun dubbio il Raspberry Pi, il microcomputer grande poco più di un pacchetto di sigarette (si può dire ancora?) che ha prodotto una vera e propria rivoluzione fra i cosiddetti maker, che lo usano per i progetti più svariati e a volte incredibili, dai semplici sistemi domestici di videosorveglianza o intrattenimento a progetti avanzati di monitoraggio ambientale, robotica o intelligenza artificiale.

Se il Raspberry Pi va bene per queste applicazioni, a maggior ragione può essere usato per implementare un NAS, un servizio cloud personale o un server web casalingo (dove con questo termine intendo indicare in generale un blog personale o un sito di un professionista o di una piccola azienda).

Io ho provato a trasferire questo blog sul mio Raspberry Pi 3 B e ha funzionano tutto perfettamente, molto meglio di quanto mi sarei potuto aspettare. Per farlo, ho installato Raspbian (la versione di Debian GNU/Linux specifica per il Raspberry Pi) scegliendo la versione Lite senza interfaccia grafica,¹ ho installato e configurato Wordpress seguendo queste istruzioni stringate ma molto chiare e infine ho trasferito tutto il contenuto del blog usando il plugin di esportazione installato di default in Wordpress. Più o meno due ore di lavoro, andando piano e controllando bene quello che stavo facendo.

I risultati sono andati oltre le più rosee aspettative: la velocità di accesso al blog era indistinguibile da quella garantita dall’hosting attuale su Wordpress.com e anche l’utilizzo del backend, cioè del sistema di gestione di Wordpress (articoli, file allegati, plugin, utenti e così via), non faceva assolutamente rimpiangere quello a cui sono abituato ormai da tanti anni.

A chi volesse provarci a sua volta e non ha già un Raspberry Pi a disposizione, consiglio di acquistare il modello più recente, il Raspberry Pi 3 B+ (costa 32 euro su Amazon, qualcosa di più su PiHut), e una scheda micro SD veloce da almeno 16-32 GB, tenendo conto che la velocità della scheda è molto più importante della capienza.

Pro e contro

Il Raspberry Pi è perfetto per imparare a gestire un server web e il sistema Linux associato oppure per fare delle prove con diversi CMS o generatori di siti statici prima di scegliere quello che vogliamo usare per il nostro sito.

Il Raspberry Pi non ha nemmeno bisogno di essere collegato ad un monitor e ad una tastiera e mouse, ma può essere gestito senza problemi da remoto tramite l’interfaccia ssh (naturalmente bisogna avere dei rudimenti di conoscenza del Terminale, cosa comunque necessaria per chiunque voglia imparare a gestire Linux e un sistema server). In più è molto piccolo, messo in un case come questo o questo fa la sua figura e può essere tenuto tranquillamente in bella vista sulla scrivania o accanto al router.

Ma anche se, come io stesso ho potuto verificare, funziona molto bene con Wordpress e probabilmente anche con qualunque altro CMS o sistema statico che ci possa venire in mente di installare, usare un Raspberry Pi come sistema definitivo sul quale ospitare un server web (ma anche un NAS o un cloud casalingo) richiede di curare attentamente una serie di dettagli niente affatto trascurabili. È importante tenere presente che, anche se l’articolo è focalizzato sull’uso del Raspberry Pi, le considerazioni che seguono valgono in parte per qualunque computer che possiamo voler usare come server web.

Il processore del Raspberry Pi genera poco calore e non ha bisogno di un dissipatore o di una ventola. Ma il microcomputer è progettato per essere usato per qualche ora e poi spento, cosa succede se lo teniamo acceso 24 ore su 24? Ci sarà bisogno di montare un dissipatore metallico o una ventola, oppure di usare un case metallico adatto a dissipare il calore prodotto dal processore (io ho fatto così).

Le schede SD utilizzate dal Raspberry Pi come memoria di massa sono notoriamente fragili e poco adatte ad un uso prolungato. Ci sono soluzioni che permettono di utilizzare un disco esterno meccanico o SSD (o anche due) al posto della scheda SD, sono molto interessanti ma richiedono un minimo di manualità e di esperienza per installare e configurare il tutto.
Alimentare un server con un alimentatore da parete e il suo fragile connettorino microUSB ha un livello di affidabilità decisamente scarso. Se poi aggiungiamo un disco esterno, è facile che la potenza fornita dall’alimentatore USB diventi insufficiente. Molto meglio usare un alimentatore ad hoc, magari insieme ad un case adatto ad ospitare tutti i componenti come questo (si veda anche la figura qui sotto). Purtroppo, mettere insieme una cosa del genere richiede un livello di manualità e di esperienza ancora più elevato.

– Fonte: The Stuff We Build, Raspberry Pi Web Server.

Sempre in tema di alimentazione elettrica, per usare il Raspberry Pi come server è indispensabile aggiungere una batteria tampone, adatta a tenere il Raspberry Pi alimentato anche in assenza di corrente elettrica, meglio se associata ad un piccolo UPS per il router (se va via la corrente di casa e il router si spegne, tenere alimentato il Raspberry Pi non serve comunque). Il solo UPS può anche andare bene per alimentare i due dispositivi, bisogna solo controllare che abbia una potenza sufficiente ad alimentare il router ed il Raspberry Pi per diverse ore.
Un server web ha bisogno di un nome di dominio e di un indirizzo IP associato. Per il nome di dominio c’è poco da fare, va richiesto necessariamente ad una azienda intermediaria (registrar) come Register.it, GoDaddy, Cloudflare, Google Domains e costa circa 10-15 euro all’anno (spesso molto meno il primo anno). Al nome di dominio bisogna associare l’indirizzo IP del nostro sito, che in genere è gestito direttamente dal provider del servizio di hosting. Se vogliamo fare da soli dobbiamo riuscire ad ottenere in qualche modo un indirizzo IP personale. Purtroppo i normali provider telefonici che usiamo per accedere ad internet da casa o dall’ufficio, Wind/Infostrada, Vodafone o simili, ci assegnano degli IP dinamici, che possono cambiare nel tempo, mentre a noi serve un IP statico, da associare una volta per tutte al nome di dominio. Scordatevi i servizi di DNS dinamico come DynDNS, OpenDNS o NoIP e simili, questi possono andar bene per accedere di tanto in tanto alla videosorveglianza o ai dispositivi IoT di casa, non certo per un server web. L’unico provider che conosca che fornisce facilmente un IP statico ai clienti è Fastweb, basta chiederlo ed è anche gratuito.
Da non dimenticare la questione dell’aggiornamento e della messa in sicurezza del sistema operativo e dei pacchetti software che utilizziamo per realizzare il sito web. Linux è intrinsecamente un sistema operativo sicuro, ma ciò non toglie che bisogna preoccuparsi di aggiornarlo frequentemente, nonché di aggiornare tutti i pacchetti software di contorno, in particolare quelli utilizzati per il sito web, in modo da evitare non solo che il sito finisca sotto il controllo di qualche script kiddie che non ha di meglio da fare, ma soprattutto che il nostro microcomputer diventi una base di partenza per i malintenzionati della rete per effettuare attacchi mirati a più vasta scala.

Conclusioni

Come è facile notare le mie perplessità sull’uso del Raspberry Pi come server web casalingo (così come di qualunque altro computer usato per questo scopo) sono soprattutto di natura hardware, e in fondo riflettono il fatto che questo microcomputer nasce come sistema sperimentale o di sviluppo, non come sistema affidabile da tenere in funzione 24 ore su 24.

Anche dal punto di vista puramente economico non mi sembra una grande idea: fra Raspberry Pi, UPS, case e accessori vari si rischia di superare facilmente il costo di un servizio di hosting pluriennale, con in più i tanti grattacapi descritti.

Il Raspberry Pi invece è imbattibile come sistema didattico ed è di sicuro uno dei migliori acquisti che si possano fare in questo momento, una specie di ritorno ai tempi eroici degli anni ‘80 quando chi comprava un computer come il Commodore 64, lo Spectrum o, per i più fortunati, l’Apple II doveva rimboccarsi le maniche e imparare i rudimenti della programmazione e magari anche dell’elettronica per usarlo al meglio. È una vera fortuna che quei tempi siano tornati, oggi.

Da melabit a melabit, la serie completa degli articoli

La versione ideale per un server web al quale, dopo la configurazione iniziale, si accede quasi esclusivamente tramite l’interfaccia web. ↩︎

E sono cinque!

Tue, 18 Dec 2018 06:00:00 +0000

Oggi il blog compie cinque anni. Purtroppo me ne sono ricordato solo all’ultimo momento e non ho avuto il tempo di fare una analisi dettagliata come mi ero ripromesso di fare. Pazienza, magari ci sarà occasione in una circostanza meno “tonda”.

Una cosa che mi colpisce sempre è che, nonostante il blog sia in italiano, ben il 10% degli accessi provenga da fuori Italia. Chissà cosa riescono a capire i poveri visitatori che leggono gli articoli tramite Google Traduttore!

Un’altra cosa che mi colpisce è che, oltre ai tanti lettori affezionati che non mi stancherò mai di ringraziare per la loro immensa pazienza, circa due terzi dei vsitatori arrivano al blog tramite i motori di ricerca. Anzi, tramite Google, gli altri motori di ricerca, anche Bing o DuckDuckGo (e mi dispiace soprattutto per quest’ultimo), praticamente non esistono. Il che significa da un lato che il blog si posiziona abbastanza bene nelle ricerche sul web (anche se io non faccio nulla per spingere in su la SEO del blog), dall’altro che gli articoli hanno una vita piuttosto lunga e vengono cercati e letti anche molti anni dopo la pubblicazione. L’articolo più letto in assoluto quest’anno, Usare un Mac con PowerPC oggi è del 2016 e ha un numero di letture che tende a crescere ogni mese. Lo stesso sta succedendo all’articolo più letto pubblicato nel 2018, Ma il Fusion Drive serve ancora?, che ogni mese ha più che raddoppiato il numero di letture rispetto al mese precedente.

Fra le cose che non mi piacciono c’è quella di aver diminuito fortemente la cadenza di pubblicazione dei nuovi articoli, passando dai due articoli a settimana del 2014 a un solo articolo ogni dieci giorni di quest’anno. Sono valori medi, ma riflettono bene la scarsa velocità con la quale riesco a pubblicare nuovo materiale. Non che mi manchino gli spunti e le idee, anzi, quello che mi manca è il tempo per scrivere in pace e poi per rivedere quello che scrivo. In compenso la lunghezza media di ciascun articolo è cresciuta significativamente nel tempo, anche se non so se questa sia una cosa positiva o no.

Altra cosa che non mi piace è il numero di commenti, che si è ridotto anch’esso in modo molto significativo. Dal picco di circa 550 commenti del 2015 si è scesi ad appena 159 nel 2018, nonostante nello stesso periodo di tempo il numero di visitatori sia quasi raddoppiato. Mi piacerebbe che ci fosse maggiore interazione con chi legge il blog, e vorrei anche sapere se posso fare qualcosa per favorire questa interazione.

Prima di concludere, un piccolo consiglio di lettura. Ho scoperto da poco il libro Automate the Boring Stuff with Python, che si può leggere gratuitamente sul web o comprare in edizione elettronica o cartacea sul sito della casa editrice o sul solito Amazon. È una vera bomba, ed è pure perfettamente in tema con la serie dedicata al Terminale e allo scripting di questo periodo. Consigliatissimo!

Da melabit a melabit: la scelta del dominio

Tue, 05 Jun 2018 06:00:00 +0000

Se la scelta del servizio di hosting più adatto alle nostre esigenze è difficile, ancora più complicata è la scelta del nome di dominio (o solo dominio), cioè del nome univoco assegnato ad un sito web, che lo caratterizza e lo rende facile da ricordare, come ad esempio www.google.com, www.debian.org oppure www.nomesito.it.

Breve lezioncina preliminare (sono noioso, ma bisogna pure capirsi). Un dominio è composto da tre parti separate da punti: la prima parte è il noto acronimo www (cioè world wide web), una specie di marchio di riconoscimento del web (come la @ per la posta elettronica) che ormai viene usato sempre più di rado.¹

La parte finale è detta dominio di primo livello (o TLD, Top Level Domain) e serve ad identificare la tipologia del sito web (.com per i siti commerciali, .org per quelli senza scopo di lucro) oppure la nazione dove opera il sito (.it). Però, dopo la liberalizzazione dei TLD, queste definizioni sono diventate sempre meno significative.

Infine la parte di mezzo è il nome dell’host (google, debian oppure nomesito negli esempi di sopra), la parte del nome di dominio che caratterizza veramente il sito.

Aggiungendo il metodo di accesso, http:// o ormai quasi sempre la versione sicura https://, si ottiene l’URL, cioè la stringa univoca https://www.nomesito.it, che permette al browser di accedere al sito web desiderato.

Finita la lezione, veniamo alla parte più significativa dell’articolo: come si fa a scegliere il nome di dominio più adatto per il nostro sito? Le regole di base sono già tutte in questo articolo, inutile ripeterle un’altra volta.

Per una volta voglio usare un approccio più pratico e raccontare come e perché ho scelto proprio melabit come nome di dominio per questo sito, applicando senza nemmeno saperlo alcune delle regole contenute nell’articolo appena citato. Tre regole in particolare: volevo un nome di dominio che fosse breve e facile da scrivere, e che una volta letto non sembrasse qualcosa di diverso e imprevisto. Perché la ragione conta, ma il caso ha sempre il suo bel daffare a metterci i bastoni fra le ruote.

La primissima idea di tenere un blog personale non è mia, ma dell’amico Lucio Bragagnolo, che molto gentilmente mi aveva invitato ad aprirne uno su Macworld Italia. Si doveva chiamare “iLife of Brian”, un bel gioco di parole con il nickname che uso più o meno sempre su internet (con qualche variazione).² Ho ancora il testo del post di presentazione, che non ho mai pubblicato perché intanto Macworld ha chiuso su due piedi.

Ci ho pensato e ripensato e alla fine ho deciso di fare da solo. Ma senza più l’ombrello protettivo di Macworld ho escluso immediatamente di chiamarlo “iLife of Brian”, i motori di ricerca non l’avrebbero mai trovato. Provate a cercare “iLife of Brian” su Google (ma anche su Bing, su DuckDuckGo, su quello che vi pare), vi verrà fuori solo e sempre qualcosa dei monumentali Monty Python. Il confronto era improponibile.

Allora ho preso il fidato nvALT, che uso molto più di Notes per buttare giù degli appunti veloci, e ho cominciato a buttare giù una serie di nomi per il blog. Poi li ho messi in ordine (si può fare a mano, ma sapere usare un po’ il Terminale può essere utile anche per queste cose) e mi sono messo a cercare su internet se erano disponibili o no.

C’è voluto un po’ di tempo e di pazienza, e alla fine è venuta fuori questa lista. Nella colonna di sinistra sono finiti tutti quelli già utilizzati, un vero peccato perché alcuni erano veramente carini. Rimanevano quelli della colonna di destra.

A questo punto ho cominciato a tagliare. Alcuni nomi erano troppo lunghi e complicati (mactechbit, openappletech), spesso troppo anglosassoni per un blog destinato volutamente ad un pubblico italiano (openmactools, toolsformac). Poi c’erano i nomi troppo caratterizzati verso aspetti molto particolari del mondo Mac (melaprog, scientificmac) mentre io volevo mantenere la possibilità di di scrivere di tutto quello che mi piaceva (e mi interessava). Tagliati anche loro senza pietà.

Alla fine mi ero deciso per melaperta. Poi quasi per caso, mentre lo ripetevo mentalmente, mi sono accorto che poteva essere scambiato per un sito per adulti (provate anche voi e ditemi). Avrebbe fatto molto bene alle statistiche di accesso, lo so, ma ho tagliato anche melaperta senza pietà.

Il nome immediatamente successivo era l’unico che non aveva controindicazioni, ed è così che è nato melabit.

Per approfondire

Host-academy, Cos’è un dominio?, 2018.
Nicola Losito, 22 consigli per la scelta del tuo prossimo nome a dominio, 2017.
ReteLab, Come scegliere un nome di dominio, 2016.
Andrea Di Rocco, Come scegliere un dominio per il tuo nuovo sito web, 2016.

Da melabit a melabit, la serie completa degli articoli

Dato che ormai il web è diventato onnipresente, l’acronimo www non è più indispensabile per riferirsi ad un sito, e quindi si può usare solo google.com (detto dominio nudo o naked) al posto di www.google.com. ↩︎
Nickname che deriva sia dal film più famoso dei grandi Monty Python, sia dal nome di uno dei fisici con cui più ho avuto a che fare, Brian Josephson, uno capace di vincere un premio Nobel pubblicando un solo articolo significativo. Tanto che subito dopo si è praticamente rimbambito. ↩︎

Da melabit a melabit: la scelta dell'hosting

Mon, 21 May 2018 06:00:00 +0000

Dopo l’introduzione generale di un mese fa (è già passato un mese!), eccoci subito a quello che forse è il passo più difficile della transizione, la scelta del servizio di hosting. Nella maggior parte dei casi, per avere una presenza su internet dobbiamo appoggiarci ad una azienda (provider) che ci mette a disposizione il server che ospita il sito (il servizio di hosting propriamente detto) e tutta l’infrastruttura hardware e software che rende il sito raggiungibile attraverso internet.

Ho letto da qualche parte che scegliere un servizio di hosting è come sposarsi: bisogna scegliere il partner, stabilire una relazione e sperare che duri nel tempo. E come nel matrimonio, separarsi non è mai facile né privo di conseguenze negative. Non so quanto sia vera la parte riguardante la separazione (dal provider), ma posso testimoniare che la semplice scelta del servizio-partner si è dimostrata molto più complicata di quanto potessi immaginare. Ho pensato quindi di elencare le linee guida che ho seguito per la scelta, sperando che possano essere utili anche a qualcun’altro.

Prima di iniziare un piccolo disclaimer: questi consigli sono adatti a chi voglia mettere su un blog o un sito web per un professionista o una piccola azienda, magari anche un piccolo sito di commercio elettronico. Chi ha bisogno di gestire un sito web di livello superiore farà meglio a rivolgersi altrove, i principi di base sono più o meno sempre gli stessi ma cambia parecchio il peso che si da ai vari fattori. E poi, è più che probabile che in questi casi non vi basti più un normale servizio di hosting condiviso (shared hosting) ma che abbiate bisogno di un server virtuale privato (VPS) o perfino di un server “fisico” vero e proprio (dedicated hosting).

Su internet le guide alla scelta dell’hosting non mancano, purtroppo per la maggior parte non sono altro che degli spot pubblicitari per questo o quel provider. Fra tutte quelle a cui ho dato una occhiata, l’unica che mi sento di consigliare è questa guida di SitePoint: c’è anche qui un po’ di pubblicità, ma almeno quelli di SitePoint lo ammettono onestamente.

Avere pazienza. Non sto scherzando, è una cosa fondamentale. I provider che forniscono servizio di hosting sono centinaia, se non migliaia (nel mondo). Ognuno di loro a parole fornisce un servizio esemplare, una assistenza immediata, un prezzo stracciato. Nella maggior parte dei casi sono delle balle o perlomeno delle affermazioni, diciamo così, piuttosto esagerate. Di conseguenza dovete rassegnarvi a navigare a lungo in rete, per cercare di capire cosa offrono (e soprattutto cosa non offrono) i vari provider e se quello che vi danno serve veramente.

Niente è per sempre. Niente è per sempre, soprattutto su internet. Un certo numero di aziende nascono, crescono e prosperano. Ma tante di più chiudono malamente dopo pochi anni. Come potete fidarvi di provider semisconosciuti che offrono servizi di hosting a vita, da pagare ovviamente sempre in anticipo, magari allettandovi con lo zuccherino di uno sconto mai visto?

Provare il servizio. Sono invece molto interessanti i provider che offrono pagamenti su base mensile o bimestrale. Si spende di più, è vero, ma si può provare direttamente la qualità del servizio offerto. E dopo un mese o due di prova sul campo, potrete decidere a ragion veduta se rimanere con quel provider passando ad una tariffazione annuale o se cambiare aria in cerca di qualcosa di meglio. E poi, se un provider decide di copiare Netflix e di farsi pagare ogni mese, secondo me sa il fatto suo ed è sicuro che il servizio che offre non fa fuggire i clienti dopo i primi trenta giorni. Proprio come Netflix.

Tenere i piedi per terra. Forse è una banalità, ma prima di scegliere questo o quel contratto bisogna fare due conti e valutare quanto spazio occuperà il vostro sito (oggi e nei prossimi anni). Con “spazio” intendo proprio lo spazio occupato sul disco rigido del server dai testi, dalle immagini e magari dai documenti allegati nonché, se usiamo un CMS dinamico come Wordpress, Drupal o, Dio ce ne scampi!, Joomla, dal database associato. Altrettanto importante è valutare il numero di utenti che visiteranno il sito. Inutile acquistare un servizio di hosting con spazio su disco “infinito” e banda di traferimento dati altrettanto “infinita” se poi non vi serve. A parte che l’infinito qui non esiste, a che vi serve tutto questo spazio se oggi avete solo dieci pagine e cento visitatori al giorno? Meglio iniziare con un contratto base, assicurandosi di poterlo aggiornare prontamente quando ce ne sarà bisogno. Anche perché i servizi di hosting forniti dai vari provider cambiano molto velocemente seguendo l’evoluzione tecnologica, per cui è probabile che, quando avrete veramente bisogno di più spazio e di più banda, riuscirete a spuntare prezzi e condizioni decisamente più convenienti di quelli odierni.

Ciò che è veramente importante. Tre parole: HTTP2, SSL, backup. Se il provider non vi garantisce queste cose fondamentali, andate da un’altra parte. E se ve le fa pagare a parte, valutate bene se vi conviene o se non è meglio rivolgersi altrove. In tutti i casi, su questo non ci piove, dovete averle tutte e tre. Per il backup in particolare, non fidatevi del provider e fate voi stessi un backup periodico del sito in aggiunta a quello automatico, che in ogni caso deve essere almeno giornaliero (penso comunque che nessun provider oggi possa pensare di stare sul mercato con qualcosa di meno). Perché? Perché non potete mai essere sicuri che il backup del provider funzioni finché non succede il fattaccio e in quel malaugurato caso è meglio avere una seconda alternativa. Ma anche perché potete essere ancora meno sicuri che un bel(?) giorno il provider non chiuda tutto all’improvviso, lasciandovi senza servizio e pure senza backup.

Ciò che è abbastanza importante. Server che usano dischi SSD al posto di quelli meccanici. Ho qualche dubbio che facciano veramente la differenza, vista la scarsa qualità delle linee dati del nostro Paese (che me ne faccio di un server che legge velocissimamente i file dal disco se poi ci vuole un sacco di tempo per trasmetterli a destinazione?), però i dischi SSD sono più affidabili di quelli meccanici, quindi: perché no?

Ciò che è piuttosto importante. Se il provider vi offre una CDN o dispone di più server sparsi per l’Europa (come è sufficiente per un sito italiano) o per il mondo, fateci un serio pensierino sopra, soprattutto se il prezzo è onesto. La velocità su internet è tutto, se il sito ci mette più del dovuto a caricare i testi e le immagini, i visitatori si scocciano e scappano via. Non ci vuole molto, basta un ritardo di due o tre secondi. Le nostre linee dati si danno già parecchio da fare per rallentare la velocità di accesso ai siti (l’avete già letto prima), per cui è consigliabile stare sul sicuro e ridurre per quanto è possibile gli altri colli di bottiglia. Non è male poter avere un accesso al server anche tramite SSH, ma solo se sapete già usare il Terminale, del Mac o di Linux, perfino quello di Windows (finalmente dalle parti di Microsoft si sono decisi a metterne uno decente).

Ciò che è incontrollabile. Tante guide che ho letto prestano molta attenzione (troppa attenzione, secondo me) ad aspetti come l’affidabilità del servizio di hosting, la velocità nel rispondere alle richieste di aiuto, la qualità del supporto tecnico, la reputazione dell’azienda. Purtroppo sono tutti fattori sui quali non potete avere il minimo controllo, almeno finché non provate il servizio per qualche mese (anche per questo è utile poter iniziare con dei pagamenti mensili). In teoria la reputazione aziendale può essere valutata leggendo qualche recensione sul web o dando una occhiata a quello che dicono i social. In teoria. Nella pratica le recensioni sono inutili, nel 99.99% dei casi sembrano, e sono, solo pubblicità. Sull’affidabilità di quello che compare sui social è inutile sprecare tempo e parole.

Sicurezza. Dovrei consigliarvi di scegliere un provider che curi particolarmente bene la sicurezza dei server e della infrastruttura di rete. Che disponga degli strumenti software adatti a respingere le principali tipologie di attacchi e che soprattutto sappia usarli. Che aggiorni rapidamente i software che girano sui server e magari anche quelli utilizzati dai siti web dei clienti, in modo da riparare velocemente alle vulnerabilità, agli errori di programmazione, che vengono scoperti ogni giorno e che possono essere sfruttati dai tanti malintenzionati che girano per il web. Purtroppo tutto ciò è forse ancora meno controllabile a priori della qualità del servizio offerto dal provider, e in questo caso anche i mesi di prova iniziale non bastano a darvi informazioni utili su questo aspetto (fondamentale!) del servizio. In questo caso particolare, una azienda nota e attiva da parecchi anni è potenzialmente preferibile ad una startup appena nata, ma non è neanche detto a priori, magari i gestori della startup sono particolarmente esperti in questo campo e possono agire con una rapidità ed una efficienza impossibili per una azienda di grosse dimensioni. Insomma, la questione sicurezza è veramente spinosa, l’unica cosa che mi sento di consigliare è quella di provare a verificare se il provider che avete scelto è stato soggetto ad attacchi nel passato e come ha reagito. È un consiglio molto debole, lo so, spero che qualcuno abbia delle idee migliori.

Prezzo chiaro. Questa cosa la metto alla fine, in modo che sia più evidente. Non so a voi, a me danno profondamente fastidio quei provider (e sono tanti, anche fra i più quotati, come Bluehost, SiteGround o per stare in Italia, Aruba o 1&1) che propongono un prezzo molto basso per il primo anno, che poi si duplica (o si triplica) negli anni successivi. Un sito web non è un affare di un solo anno, e anche il servizio di hosting dovrebbe essere una relazione a lunga scadenza. Un provider lo sa benissimo e, se fa così, mi da l’impressione di essere un furbetto che applica la stessa politica di marketing di un supermercato. Con la differenza che ci vuol poco a cambiare supermercato, mentre trasferire il sito da un provider all’altro è una faccenda molto più complicata.

Trasferimento. Se avete già un sito web e volete cambiare provider, siate consapevoli che trasferire il sito, fra DNS, dominio, email, database, CMS (e di tante altre cose che ora non mi vengono in mente), non è facilissimo. Se avete conoscenze tecniche sufficienti e tempo a disposizione fatelo pure da voi, in tutti gli altri casi vale decisamente la pena affidarsi al provider che avete scelto. Costa un po’ ma dubito che ve ne pentirete.

Da melabit a melabit, la serie completa degli articoli

È proprio una sporca faccenda, WordPress.com!

Mon, 23 Apr 2018 18:00:00 +0000

È successo anche a me, e proprio come l’avevano descritto Roberto e katsiematsi.

Giorni fa mi è arrivata una email che segnalava la pubblicazione di un nuovo post su Socket 3, uno dei blog che seguo di più in questo momento, che come Melabit si appoggia al servizio gratuito di WordPress.com.

In genere leggo i post sul Mac, ma questa volta il titolo mi aveva incuriosito e ho toccato il link per leggerlo subito sul telefono. Poi per qualche motivo mi sono distratto, forse per una telefonata, forse per una email arrivata sull’account “istituzionale”. E quando ho guardato di nuovo lo schermo del telefono ho trovato questo,

insieme all’inevitabile SMS che mi informava che, fortunello!, ero stato iscritto al servizio Every Play, 5 euro alla settimana per ricevere qualche giochino idiota.

Iscritto senza volerlo, è chiaro, e senza aver accettato nulla. Non è la prima volta che succede a me o ai miei familiari, ma in genere succede con degli SMS fasulli, mentre questa volta la colpa sta di certo nell’aver visualizzato il post su WordPress.com.

Di questo sono sicuro al 100%: ho toccato il link, si è aperto il browser alla pagina del post, che a sua volta ha caricato la pagina di Every Play, come si vede chiaramente nella prima immagine, dove il numero 2 in alto a destra è il numero di pagine aperte nel browser.

Poiché mi sono distratto, non sono sicuro se è comparso sul telefono qualche avviso a tempo che mi ha iscritto dopo tot secondi di inattività. Ma se anche fosse andata così (improbabile), sta di fatto che mi sono ritrovato iscritto ad un servizio a pagamento, inutile e costoso, senza aver mai accettato esplicitamente nulla!

È chiaro che ho annullato immediatamente l’iscrizione, cosa confermata dal secondo SMS mostrato qui sotto.

Ora, a parte la seccatura e i 5 euro rubati, quello che è successo è stata una vera fortuna,¹ perché dimostra oltre ogni dubbio che c’è davvero qualcosa che non va nel modo in cui WordPress.com gestisce la pubblicità inserita nei blog, almeno quando si usa lo smartphone. Ho provato in tutti i modi, senza riuscirci, di far comparire pubblicità “cattiva” su Melabit usando i browser che ho sul Mac e sull’iPad, mentre la pistola fumante si trovava sul telefono.

A ben pensarci è naturale, mettendo annunci truffaldini sul telefono si possono sottrarre immediatamente soldi dal credito della SIM mentre con le altre piattaforme bisogna usare metodi più visibili, con i quali è più difficile portare a termine la truffa.

Quello che è meno naturale è che WordPress.com non riesca a prevenire fattacci come questo che, sono sicuro, saranno stati segnalati da tantissimi utenti di tutto il mondo.

Ed è stata una vera fortuna anche avere la presenza di spirito di fare gli screenshot proprio mentre le cose stavano succedendo. ↩︎

Da melabit a melabit: introduzione

Mon, 16 Apr 2018 06:00:00 +0000

Come promesso, con questo post inizia la descrizione quasi in tempo reale del passaggio del blog da WordPress.com ad un servizio di hosting più flessibile.¹

Come ho già scritto tempo fa, WordPress.com offre un servizio impeccabile, comodissimo per chi vuole iniziare ad avere una presenza sul web. Il servizio è affidabile e ragionevolmente veloce, gli aggiornamenti sono automatici, praticamente non bisogna occuparsi di nulla tranne che di scrivere. È veramente difficile chiedere di più ad un servizio gratuito come questo.

Il vero limite di WordPress.com, che tutto sommato è anche la sua forza, è la mancanza di flessibilità. Con l’account gratuito non si possono installare altri plugin oltre a quelli previsti da Automattic, l’azienda che gestisce lo sviluppo e la commercializzazione della piattaforma di blogging (open source) più diffusa al mondo.

Una cosa comprensibile per motivi di sicurezza e affidabilità, ma che naturalmente dopo un po’ risulta troppo limitante, perché impedisce di estendere le funzioni del blog oltre i confini ristretti stabiliti da Automattic.

Idem per i temi. WordPress.com ne offre parecchi, sia gratuiti che a pagamento e ad un prezzo più che onesto, ma oltre quelli non si può andare, prendere o lasciare.

Infine c’è la questione della pubblicità, di cui ho scritto di recente, con annessi servizi di profilazione di ciò che i frequentatori del blog fanno online. Forse quello che è successo ad alcuni lettori può essere considerato un evento eccezionale o particolarmente sfortunato. Ciò non toglie che la presenza di annunci pubblicitari alla fine degli articoli, pur se giustificabile,² falsa un po’ troppo l’immagine del blog, e lo mette quasi sullo stesso piano di quelle decine e centinaia di siti che ospitano contenuti raffazzonati alla bell’e meglio con il solo scopo di guadagnare dagli annunci che ne infarciscono le pagine.

Per tutte queste ragioni è arrivata l’ora di cambiare, passando ad un servizio di hosting che consenta di gestire in proprio la piattaforma e di utilizzare finalmente il nome di dominio personale, melabit.com/posts/it, lasciato in sospeso per troppi anni.

In linea di principio, la cosa più semplice sarebbe quella di utilizzare uno dei piani a pagamento offerti da WordPress.com. Purtroppo dei tre piani disponibili i primi due, Personale e Premium, offrono (molto) poco di più rispetto al piano gratuito e praticamente servono solo per rimuovere la pubblicità e per usufruire di un dominio personalizzato e dei temi premium. Mentre il piano Business, l’unico che consente di installare tutti i plugin e i temi che si desidera, a 25 euro al mese è decisamente troppo caro per un piccolo blog come questo, costruito nei ritagli di tempo e con il solo scopo di mettere a disposizione qualche contenuto di buona (si spera!) qualità.

L’unica opzione ragionevole è quindi di cercare un servizio di hosting con un buon rapporto qualità/prezzo e una affidabilità provata, e che naturalmente permetta di far girare la piattaforma software scelta per il blog.

Ma questa è una storia che riguarda la prossima puntata.

P.S. Questo post l’ho scritto a mano in macchina, mentre aspettavo mia figlia. Una esperienza molto vecchio stile ma anche molto efficiente, ci ho messo meno di mezz’ora a buttarlo giù. Perché a mano posso scrivere malissimo (io stesso a volte riesco a capire a fatica quello che ho scritto) ma molto più velocemente che con la tastiera. Perché tanto so di dover copiare il testo sul computer e quindi non mi preoccupo troppo degli errori. Perché tutte le correzioni e gli spostamenti del testo di vedono chiaramente, e si continua a vedere anche il testo originale non corretto (una specie di controllo di versione rudimentale). Una esperienza da ripetere (e di cui riparlare, più avanti).

Da melabit a melabit, la serie completa degli articoli

Ma anche più complesso da gestire. ↩︎
Automattic dovrà pur cercare di recuperare, almeno in parte, i costi del servizio gratuito. ↩︎

È una sporca faccenda, WordPress.com: profilazione

Sat, 07 Apr 2018 06:00:00 +0000

Mentre cercavo di far comparire le inserzioni pubblicitarie alla fine dei miei post, mi sono reso conto di quanti servizi di profilazione (tracker) esterni a WordPress.com mettano il naso nelle pagine del blog.

Ci sono naturalmente gli onnipresenti social, collegati tramite i pulsanti di condivisione, e c’è Google Analytics, che lo stesso WordPress.com utilizza per misurare i parametri di accesso al sito.

Ma poi ci sono una serie di servizi dai nomi più oscuri ma significativi – DoubleClick di Google, Adapt.tv e Advertising.com, entrambe costole di AOL e quindi di Verizon, AppNexus, che applica tecniche di machine learning per rendere “la pubblicità digitale più predittiva ed intelligente”, Criteo, che “aiuta a costruire esperienze personalizzate per gli acquirenti”, SkimLinks, ovvero “fai soldi con i tuoi contenuti”, BidSwitch e Demandbase di cui vi risparmio la filosofia di marketing – che analizzano tutto quello che facciamo con il browser, le ricerche effettuate, i link seguiti, le pagine che leggiamo, per costruire una immagine sempre più precisa di noi, delle nostre abitudini e di quello che ci piace, con un solo e unico obiettivo: sapere tutto di noi per presentarci degli annunci pubblicitari mirati e quindi sempre più efficaci.

Tenendo conto di tutto, l’home page di Melabit viene tracciata da ben 16-17 servizi di profilazione diversi, con un forte impatto negativo nella velocità di accesso al sito, come ci si accorge facilmente se si prova ad usare uno dei tanti strumenti di analisi delle prestazioni disponibili in rete, come WebPagetest.org, GTmetrix o Pingdom.

Tanto per fare un confronto, ecco quello che compare guardando l’home page di un sito semi-istituzionale, sempre in WordPress ma ospitato su un servizio di hosting a pagamento, che ho messo su da un anno con alcuni colleghi. Niente servizi di profilazione opachi e indesiderati, solo Google Analytics, che sarà pure invasivo, ma che almeno è stato attivato appositamente per contare gli accessi al sito.

Forse possiamo ancora a difenderci.

È una sporca faccenda, WordPress.com

Tue, 03 Apr 2018 18:00:00 +0000

Mentre leggevano uno degli ultimi articoli pubblicati, Roberto e katsiematsi (😃) si sono ritrovati abbonati senza volerlo ad uno di quegli stramaledetti servizi a pagamento di loghi, suonerie o giochini insulsi, veri e propri furti consentiti da una legislazione perlomeno distratta.

Con l’iPhone è un attimo, arrivati in fondo all’articolo basta toccare senza volere l’annuncio cattivo per ritrovarsi alleggeriti di parecchi euro (e con il fastidio di doversi anche dare da fare per annullare l’abbonamento).

Non avevo idea che WordPress.com, la piattaforma gratuita che ospita il blog, consentisse inserzioni di questo tipo. L’interfaccia di amministrazione del sito mi avvisa che ci potrebbero essere degli annunci pubblicitari alla fine dei post, ma non dice nulla sul tipo di annunci mostrati, né tantomeno mi consente di sceglierli o di vietarli, a meno di non passare ad uno dei piani a pagamento (tante grazie, preferisco fare da me).

Ma anche senza essere amministratore, Firefox (il browser che uso normalmente) non mi fa vedere gli annunci pubblicitari, che vengono bloccati a priori dall’ottimo uBlock Origin, una delle estensioni indispensabili per qualunque browser.

Solo se disattivo esplicitamente l’estensione vedo finalmente gli annunci alla fine degli articoli, in questo caso assolutamente benigni.

Nonostante usi la modalità di navigazione anonima, ho la netta impressione che WordPress sappia lo stesso chi sono, sarà un caso ma gli annunci che mi fa vedere sembrano dedicati proprio a me. Le cose non cambiano se uso Safari o Chrome sul Mac o iOS. Con Android invece la pubblicità è più generica, forse perché lo uso poco e il sistema ha meno informazioni sulle mie abitudini di navigazione.

Sia quel che sia, è arrivata l’ora di abbandonare WordPress.com. Un po’ di pubblicità mi sta bene, è ragionevole che WordPress.com voglia guadagnare qualcosa in cambio del servizio di hosting gratuito che mette a disposizione, ma un conto è vedere un annuncio con Cannavacciuolo, un altro è farsi incastrare senza volere da qualche servizio a pagamento ai limiti della legalità.

Ci pensavo da tempo, anzi da troppo tempo, l’ho anche scritto più volte, ma alla fine ha sempre prevalso la pigrizia. Anche perché il piano gratuito di WordPress.com sarà anche limitato (e credetemi, lo è!) ma evita di dover affrontare un sacco di fastidi collegati alla gestione del sito, dagli aggiornamenti allo spam agli inevitabili problemi di sicurezza.

Ma come dicevo prima, il dado è tratto, fra poco sarà attivo melabit.com/posts/it, un dominio che ho acquistato da anni ma che ho lasciato dormire per tanto, troppo tempo. Sarà anche una buona occasione per raccontare quasi in diretta i dettagli della transizione che, come ho già verificato, non sarà facilissima e nemmeno indolore.

Come sempre, stay tuned.

Compleanno con permessi

Sun, 18 Dec 2016 06:00:00 +0000

Oggi melabit compie tre anni. Per l’occasione ho chiesto all’amico Lux il permesso di ripubblicare un mio vecchio intervento sul suo (bellissimo) blog Ping, chiuso purtroppo con la cessazione della pubblicazione dell’edizione italiana di Macworld.

Perché pubblicare di nuovo questo articolo dopo più di sei anni?

Innanzi tutto perché quello che c’è scritto è ancora attuale e, come ha scritto a suo tempo Lux con il suo stile inimitabile, può essere utile per “avvicinarsi agli incantesimi Unix che danno vita al mondo magico di Mac OS X”, una cosa a cui tengo sempre moltissimo. Magari oggi proporrei di usare sul Mac launchd al posto di cron, anche se quest’ultimo rimane la soluzione più generica, valida su un qualunque sistema Unix.

C’è poi un motivo più personale: proprio dopo questo intervento ho cominciato a pensare che tenere un blog non fosse un’idea proprio fuori dal mondo. Ci ho messo un po’ (come sempre!) a realizzarla, ma dopo tre anni devo ammettere che è stata un’ottima decisione, le soddisfazioni non sono mancate.

Introduzione

L’articolo rispondeva all’esigenza di un lettore di Ping di cambiare automaticamente i permessi di determinati tipi di file contenuti in una cartella del Mac. Cosa ci può essere di meglio del Terminale per fare queste cose?

Ho lasciato praticamente inalterato il testo originale, limitandomi a correggere alcune imprecisioni e ad aggiungere qualche dettaglio qui e là.

Me li do io i permessi

Premessa #1: il Terminale in Mac OS X si trova in Applicazioni > Utility. Una volta lanciato può essere configurato in molti modi (tramite le Preferenze) perdendo quell’aspetto un po’ triste e troppo serioso che spaventa l’utente normale.

Dopo l’avvio, il Terminale presenta il cosiddetto prompt, che su OS X mostra tipicamente il nome del computer, la cartella dove ci si trova e il nome dell’utente. L’ultimo carattere del prompt è normalmente il $. Nel Terminale i comandi vengono inseriti dopo il simbolo $ su quella che viene definita la riga di comando e si eseguono premendo il tasto Invio.

Il Terminale di OS X esegue di default la cosiddetta shell bash, uno strumento potentissimo per interagire con il sistema operativo. La shell bash può essere usata direttamente, scrivendo i comandi uno ad uno sulla riga di comando e leggendone il risultato direttamente nel Terminale.

Oppure si possono scrivere degli script, piccoli programmi nel linguaggio di bash nei quali si inseriscono in sequenza i comandi da far eseguire alla shell, che si dimostrano molto utili per automatizzare delle operazioni che eseguiamo ripetutamente sul Mac.

Premessa #2: perché usare i comandi di bash invece di Automator o di AppleScript? Beh, innanzitutto perché bash è multipiattaforma e quindi funziona su Linux e, volendo, anche su Windows. E poi semplicemente perché bash mi piace!

Lanciamo quindi il Terminale (magari configurandolo prima, io consiglio almeno di aumentare le dimensioni della finestra a circa 100×40 per stare comodi e di scegliere un tema grafico più accattivante di quello bianco e un po’ spento di default) e iniziamo a lavorare.

Creiamo innanzi tutto una cartella ~/bin, dove il carattere ~ (tilde, ALT+5) indica per convenzione sui sistemi basati su Unix la cartella Inizio (detta anche Home) dell’utente che sta usando il computer in questo momento. Per farlo da Terminale, digitiamo (ATTENZIONE, come già detto $ indica solo l’ultimo carattere del prompt e NON va mai inserito nei comandi seguenti):

$ cd
$ mkdir bin
$ chflags hidden bin
$ cd bin

Il primo comando serve per essere sicuri di partire dalla Home, il secondo crea una nuova cartella bin nella Home, il terzo la nasconde al Finder e l’ultimo comando ci fa spostare nella cartella bin appena creata.

In teoria siamo liberi di salvare i nostri comandi bash in una qualunque cartella del Mac e possiamo anche usarne una già esistente. Ma usare la cartella bin nella nostra Home rispetta le convenzioni dei sistemi Unix e mi sembra preferibile.

A questo punto usiamo nano (un editor testuale molto semplice installato di default sul Mac) per editare lo script bash cambia_permessi, nel quale inseriremo i comandi veri e propri che ci servono per cambiare i permessi dei file contenuti nella cartella nella quale verrà eseguito lo script:

$ nano cambia_permessi

Non preoccupatevi per l’interfaccia un po’ ostica di nano, qui ci basta usare solo due comandi, CTRL+O per salvare il file editato e CTRL+X per uscire da nano. Dimenticavo: CTRL+O significa premere contemporaneamente il tasto CTRL, l’ultimo in basso a sinistra sulle tastiere Mac (nei portatili è a fianco di fn), e il tasto O. Analogamente per CTRL+X.

Torniamo al nostro file cambia_permessi. A questo punto bisognerebbe copiare a mano le linee mostrate qui sotto. Ma OS X è furbo e il copia e incolla funziona anche nella finestra del Terminale, per cui è sufficiente selezionare tutte le linee mostrate qui sotto, copiarle e poi incollarle nella finestra del Terminale dove è attivo nano:

#!/bin/bash
#
DIR=~/scansioni/
FILES=*
PERM=u+rw
#
if [ -d $DIR ]; then
	cd $DIR
	chmod -R $PERM $FILES
	cd
fi

Salviamo lo script premendo CTRL+O ed usciamo da nano con CTRL+X.

Cosa significano questi comandi? Il più importante è chmod, che cambia i permessi di tutti i file contenuti nella cartella ``~/scansioni/` in modo che siano leggibili e scrivibili dall’utente attuale del Mac. Il resto è solo roba di contorno.

Quello che è ancora più importante è che lo script è totalmente parametrico: basta cambiare i valori di DIR, FILES e PERM per adattarlo alle proprie esigenze.

Per esempio, se la cartella ~/scansioni/ contenesse vari tipi di file e si volessero cambiare i permessi dei soli file pdf lasciando gli altri file invariati, la riga FILES=* diventerebbe FILES=*.pdf.

Non è finita. Controlliamo prima di tutto di avere veramente fatto tutto bene con il comando:

$ cat cambia_permessi

che dovrebbe mostrare sullo schermo lo script appena inserito.

Per semplificarci la vita, rendiamo lo script eseguibile con il comando:

$ chmod u+x cambia_permessi

Bisogna notare che con questo comando abbiamo reso eseguibile lo script solo per l’utente attuale del Mac. I motivi li tralascio per brevità, ma credetemi, è decisamente meglio fare così.

Un ultimo passo necessario. In questo momento, per cambiare i permessi dei file nella cartella ~/scansioni/ bisogna eseguire a mano il comando dal Terminale:

$ ~/bin/cambia_permessi

(anche se, per come è configurato di default OS X, usare soltanto $ cambia_permessi, senza scrivere esplicitamente il percorso dove è salvato lo script basta e avanza).

Ciò è sicuramente molto più comodo di cambiare uno ad uno i permessi dei file, ma si può fare di meglio.

Qui entra in gioco cron, uno strumento che esegue dei comandi stabiliti dall’utente a intervalli di tempo predefiniti. Sembra una cosa un po’ cretina, ma in realtà permette di far fare al computer un mare di cose automaticamente. Purtoppo la sintassi di cron è orrenda. E questo post sta diventando troppo lungo.

Cercherò di sintetizzare ma se qualcuno è interessato posso scrivere qualcosa in proposito. (Nel frattempo l’ho fatto, chi fosse interessato può leggere questo articolo dettagliato su cron.)

Diciamo che vogliamo che ogni cinque minuti lo script cambia_permessi venga eseguito automaticamente. Dal solito Terminale dobbiamo allora eseguire i comandi:

$ export EDITOR=/usr/bin/nano
$ crontab -e

La prima riga serve ad evitare di usare l’editor preimpostato, vi, vn vero reperto archeologico che sarebbe bene dimenticare una volta per tutte. Dovrebbe invece aprirsi il solito nano, in cui dobbiamo incollare esattamente la riga seguente:

*/5 * * * * ~/bin/cambia_permessi

(prima e dopo ciascun asterisco è presente una tabulazione), eventualmente aggiungendola in coda ai comandi già presenti.

Salviamo con CTRL+O e usciamo da crontab con CTRL+X.

Ovviamente se vogliamo che lo script venga eseguito più o meno frequentemente, basta cambiare il valore */5 in, diciamo, */2 o */15 (per eseguire lo script ogni 2 o 15 minuti). Per casi più complicati basta leggere qui.

Abbiamo finito. Sembra complicato, ma credetemi, è molto più lungo da leggere (e da scrivere!) che da mettere in pratica.

Nota finale

Per chi ha paura del Terminale e soprattutto di cron, un programma potente ma, bisogna ammetterlo, ben poco user-friendly, ecco una soluzione aggiuntiva, farina di Lux.

Aggiungo solo una piccola nota per gli inesperti di Terminale che si scontrano con cron (e, su Snow Leopard, con launchd). Una scorciatoia artigianale consiste nel definire un evento ricorrente dentro iCal e, nelle informazioni relative, stabilire che in occasione dell’evento va eseguito uno script.

Molto pratica se si ha bisogno di ripetere uno script una o due volte al giorno al massimo, in tutti gli altri casi temo che finirebbe per riempire all’inverosimile il proprio Calendario, con conseguenze che francamente mi sfuggono.

Due anni

Fri, 18 Dec 2015 06:00:00 +0000

Oggi il blog festeggia il secondo compleanno. Sono riuscito a ricordarmene, anche se purtroppo negli ultimi mesi ho avuto veramente poco tempo da dedicarvi.

Mi fa molto piacere che quest’anno il numero degli accessi sia raddoppiato rispetto al 2014 e che si mantenga abbastanza costante nel corso delle settimane e dei mesi. Significa che gli articoli durano nel tempo e vengono letti anche dopo parecchi mesi dalla pubblicazione.

La metà dei visitatori è costituita da lettori fedeli, che ricevono gli aggiornamenti via email o visitano il blog periodicamente. Li ringrazio tutti per l’attenzione e la pazienza, a volte la pubblicazione dei nuovi post è veramente troppo aleatoria.

L’altra metà ci arriva tramite i motori di ricerca. Praticamente solo Google, ma ci sono anche una ventina di accessi rispettivamente da Bing o Yahoo e perfino qualcuno che ha usato Libero, Virgilio o DuckDuckGo.

Anche la distribuzione geografica degli accessi è piuttosto interessante. Come è ovvio la stragrande maggioranza proviene dall’Italia e dalla Svizzera (italiana?), ma ci sono centinaia di visite dagli USA e dai principali paesi europei, nell’ordine Regno Unito, Francia, Germania e Spagna.

Ci sono comunque visitatori da quasi tutto il mondo. Mancano solo i paesi dell’Africa centrale, il Medio Oriente e la Cina. Quasi un miliardo e mezzo di abitanti ma nessun cinese interessato al blog, forse mi devo preoccupare. ;)

[caption id=“attachment_2277” align=“aligncenter” width=“605”] Distribuzione geografica degli accessi al blog nel 2015.[/caption]

Chiuso per trasloco

Fri, 26 Jun 2015 16:00:00 +0000

Niente post questa settimana.

Sto traslocando in un ufficio più grande e la cosa sta andando per le lunghe, ben al di là di quanto avevo previsto. Anche perché è impossibile avere un aiuto. Anzi, sbagliato, è meglio non avere un aiuto. Tanto il servizio di pulizie dell’istituto, pagato puntualmente ogni mese, è praticamente inutile, anzi forse è persino controproducente.

E allora meglio armarsi di scopa e strofinacci e pulire finalmente la stanza dopo anni di sciatteria e trascuratezza, sistemare i mobili e gli scaffali, sballare l’iMac e ricollegare le decine di cavi, hard-disk e ammennicoli vari. Cercare insomma di preparare un ambiente appena appena confortevole.

Ovviamente la sera, tornato a casa, sono troppo stanco per mettermi alla tastiera a scrivere per il blog.

Per fortuna almeno l’appuntamento domenicale non salterà. A presto. ;)

Risposte

Tue, 14 Apr 2015 06:00:00 +0000

Come promesso, ecco alcune risposte ai commenti del post del 1° aprile. Come si dice, meglio tardi che mai.

Se può essere utile a mantenere melabit in vita mi rendo disponibile a fornirti un tot di post al mese/anno/lustro. Certamente diversi dai tuoi, meno tecnici…

Non c’è nemmeno bisogno di dirlo, tutti i contributi sono sempre benvenuti. L’email la conoscete… ;)

poi magari fra tutti ne parliamo meglio, ma potremmo far diventare questo posto ancora più interessante…

Da concerto solista a sinfonia. Magari!

fare post più brevi, dividendoli post lunghi MA tecnicamente interessanti in “pillole” piccole, veloci, magari consecutive, che pubblichi in maniera ravvicinata —- così sono più facili da leggere, i 40/50 secondi per leggerle e RILEGGERLE chiunque li trova anche sull’autobus, i 5 minuti per una lettura impegnata, anche mentalmente, sono più rari e complicati.

L’idea è interessante, anche se la trovo piuttosto difficile da mettere in pratica. A volte gli argomenti sono piuttosto complicati ed è difficile dividerli più di quanto faccia già. E poi c’è un fatto più tecnico connesso ai rimandi fra un pezzo di post e l’altro: con Wordpress bisogna farli a mano, ed è facile sbagliare. Dovrei proprio decidermi a passare a Jekyll, ma quello che manca in questo periodo è proprio il tempo per farlo.

Comunque magari ci provo una prossima volta e vediamo che succede.

devi promuoverli e promuoverti su tutti i canali disponibili (pagina Facebook, twitter, Google plus e molto altro ancora….) e INTERAGIRE sui social (scoprirai che è questa la parte impegnativa, altro che scrivere i post

Guarda, è già tanto che i post finiscano in Google+, e solo perché è tutto automatico (anche se mi sono accordo solo da poco che era possibile farlo). No, no, sui social no, non mi fanno impazzire e non avrei nemmeno il tempo né tanto meno la voglia, per seguirli.

non passare le nottate a rifinire allo sfinimento i singoli post, che così escono più tardi e in numero minore di quanto auspicabile. questo lo puoi fare, perché sono già di altissimo livello, vanno STRABENE anche con un 40% abbondante di rifinitura in meno

Grazie per gli apprezzamenti, ma purtroppo non posso farci niente, io correggo e ricorreggo quasi allo sfinimento tutto quello che scrivo. La prima versione la butto lì di getto, con frasi scritte alla buona solo per non farsi scappare un concetto, rivedendo e riscrivendo poi tutto finché non ha un senso logico (almeno spero!) Non potrei fare diversamente. Dovresti guardare un lungo articolo (scientifico, non preoccupatevi…) che ho in preparazione: ogni volta i fogli diventano blu… E già, perché sono vecchio stile e per correggere preferisco decisamente usare i fogli stampati.

Perché a volte, uno dei problemi di scarsa interazione e commento è che al di là di generici apprezzamenti, non c’è altro da dire, hai davvero esaurito l’argomento in ogni suo aspetto… o meglio, non lasci spazio a repliche che non siano di livello totalmente impegnativo, perché più che suggerire uno spunto di dialogo hai già detto o lasciato intendere tutto quello che c’è da dire, e l’interlocutore… non sa che altro aggiungere

Questo è uno spunto veramente utile, su cui si può lavorare. Grazie.

le balene però non sono pesci… Ma vengono pescate

Pescare il più grande mammifero che vive sulla Terra (con la T maiuscola) è un po’ dura. Ne sa qualcosa il capitano Achab :D

Provocazione o pesce d'aprile?

Thu, 09 Apr 2015 06:00:00 +0000

Ora posso dirlo, il mio ultimo post era una vera e propria provocazione, travestita da subdolo pesce d’aprile.

Mi chiedevo veramente da tempo se avesse senso continuare a trattare temi piuttosto lontani (se non proprio ortogonali) rispetto all’usuale flusso di notizie che si trova ogni giorno nei vari blog e forum dedicati al mondo Apple (e non solo).

In fondo, come ho scritto, che senso ha passare tante serate a scrivere e a limare un post se poi non lo legge nessuno (o quasi)?

E quale giorno migliore per tastare il terreno che il primo aprile?

La risposta di chi ha la pazienza di seguire questo blog è andata decisamente al di là delle mie aspettative: accessi triplicati rispetto alla media ma soprattutto tanti commenti, tanti consigli e proposte da considerare con attenzione.

Che dire? L’interesse c’è, la vera sfida è riuscire a stimolarlo sempre di più.

Le risposte dettagliate ai commenti in un prossimo post. Questo, fra un viaggio di lavoro e le feste pasquali, è già troppo in ritardo.

Tutto ha una fine

Wed, 01 Apr 2015 06:00:00 +0000

Questo blog ha poco più di un anno di vita. È nato con lo scopo di trattare temi legati “al Mac, alla programmazione e all’open source, con puntatine nella scienza e nella tecnologia in generale”, sforzandosi di essere diverso dalla pletora dei siti italiani di informazione sul Mac e sul mondo Apple, tutti uguali uno all’altro, tutti concentrati a presentare come ultime notizie delle banali rimasticature di quanto già apparso sui siti internazionali (tranne ottime eccezioni).

Purtroppo questa iniziativa è stata un completo fallimento. Poche visite, pochissimi commenti, ancor meno citazioni da altri siti e da altri blog. Un sostanziale disinteresse della comunità Apple italiana. Un fattore di impatto prossimo a zero.

Colpa mia ovviamente. È chiaro che i temi trattati sono risultati poco interessanti e che il livello tecnico e comunicativo dei post era troppo scarso per riuscire ad emergere.

Quindi è ora di dire basta e di chiudere definitivamente il blog. Non ha senso passare serate e notti a limare un post se poi nessuno o quasi lo legge. O se il post più visualizzato in assoluto risulta essere quello che insegna a installare Office su Yosemite.

Mi dispiace veramente farlo, ma tutto ha una fine.

Prima di chiudere voglio però ringraziare di cuore tutti quelli che mi hanno seguito fedelmente, nonostante la periodicità ballerina e la prolissità inaudita dei post.

Finalmente potrò dedicarmi alla mia vera passione serale: seguire le vicissitudini di volti noti sbarcati su isole lontane o ascoltare le ultime voci della canzone italiana.

And the winner is...

Wed, 31 Dec 2014 06:00:00 +0000

Riassunto delle puntate precedenti. Wordpress.com è un’ottima piattaforma di blogging, ed ha il grosso vantaggio di liberare l’utente da tutte le preoccupazioni riguardanti la manutenzione del proprio blog. Non è però una piattaforma che si adatta bene al mio modo di lavorare, e ne ho già scritto diffusamente alcuni mesi fa. Però cosa scegliere fra le varie tipologie disponibili: wiki o CMS o piattaforme di blog, siti statici o siti dinamici? Per vari motivi mi sono orientato verso un generatore di siti statici, un programma che prende una serie di file di testo, di immagini e di documenti e li converte in un sito web completo secondo un tema grafico predefinito. In rete ci sono letteralmente decine e decine di generatori di siti statici ed il loro numero cresce molto rapidamente: erano 289 all’inizio di agosto, oggi sono ben 388! Come orientarsi in questo marasma? Basandomi su una lista di caratteristiche irrinunciabili (almeno per me), ne ho provati e scartati parecchi, buon ultimo Hugo, promettente ma rivelatosi alla fine piuttosto immaturo.

In realtà avevo deciso subito. Tutte le prove che ho fatto mi sono servite solo ad esplorare il più possibile il territorio, a provare le alternative e a verificarne i vantaggi e gli svantaggi.

La scelta più ragionevole, date le premesse, era solo una: Jekyll.

Per due ragioni fondamentali: prospettive di sviluppo del codice a medio-lungo termine e disponibilità di documentazione abbondante e di buona qualità. Senza queste due caratteristiche non si va avanti. Tutti gli altri generatori di siti web statici possono anche apparire interessanti, ma impallidiscono se li si confronta a Jekyll su questi due aspetti.

Tanto per fare un esempio: che senso avrebbe avuto scegliere uno dei tanti progetti giocattolo di un singolo programmatore? Può anche essere eccellente, ma quante sono le probabilità che continui ad essere sviluppato fra uno, due, tre anni? Magari fra sei mesi il programmatore si stanca e passa ad altro, non rispondendo più alle richieste di supporto o di correzione degli inevitabili errori. Che si fa, allora? Oppure: come si può cercare di configurare ed estendere il sistema prescelto se non esiste della buona documentazione, se magari l’unico modo per capire cosa fa il programma è analizzarne i sorgenti (auguri)?

Infatti fra i 388 generatori di siti statici elencati oggi da Static Site Generators, ben 171 non sono aggiornati da almeno un anno e 225 da sei mesi. E solo una settantina ha ricevuto un aggiornamento nell’ultimo mese. Insomma, ci sono circa 320 progetti censiti che in realtà sono morti, inutili, da scartare a priori.

I primi due generatori di siti web statici nella lista di StaticGen, Jekyll e il suo derivato Octopress, hanno ricevuto insieme su GitHub più di un terzo delle stelle – cioè delle manifestazioni esplicite di interesse nel progetto – guadagnate da tutti i 67 progetti elencati nel sito.¹ Non sarà che sono ritenuti così interessanti perché sono fatti bene e sono (relativamente) facili da usare e da metterci le mani?

Ora rimane solo da rimboccarsi le maniche, configurare Jekyll e trasportare il blog sulla nuova piattaforma.

Ma prima di allora, auguro a tutti coloro che pazientemente seguono questo blog un 2015 felice e, se possibile, migliore dell’anno che ci stiamo lasciando alle spalle!

Immagino che StaticGen censisca solo i progetti sviluppati attivamente. Probabilmente non è un caso che, se si considerano attivi solo i progetti aggiornati nell’ultimo mese, i numeri di Static Site Generators e di StaticGen concidano. Sarebbe interessante verificare se i progetti sono veramente gli stessi. ↩︎

Per un click in più

Sat, 14 Jun 2014 06:00:00 +0000

Oops! Tim Cook tweets photo of Mac production line running Windows – PCWorld

Accidenti! Tim Cook twitta una foto della linea di produzione del Mac [Pro] su cui gira Windows – PCWorld

Grande scandalo, a leggere l’articolo. Come è possibile che il Mac (Pro) sia prodotto usando Windows?

Peccato che chi lo ha scritto non abbia nessuna nozione del fatto che (purtroppo) la maggior parte delle macchine industriali siano controllate da programmi software molto specifici (e costosi!) i quali, proprio per la loro specificità, sono scritti solo per un ben determinato sistema operativo. In questo settore il concetto di multipiattaforma non esiste. Si compra la macchina con il software associato e stop. Avviene lo stesso per sistemi diversissimi dai bancomat alle macchine automatiche per il caffé.

Qui Windows fa la parte del leone. La sua ampissima diffusione, con la conseguenza che la maggior parte dei programmatori lo sa usare, insieme al basso costo dei PC da usare per lo sviluppo e poi in produzione lo rendono una scelta quasi inevitabile. Del resto in questi casi quello che importa non è il sistema operativo ma l’applicativo che ci si fa girare sopra (spesso l’unica applicazione installata).

E nonostante ciò, anche in questi casi Windows fa ogni tanto le bizze e va in crash, esattamente come nel PC di casa. Come si potrebbe vendere un bel contratto di assistenza, altrimenti?

Insomma, l’articolo dice solo ovvietà. Ma fra le righe parla male di Apple.

Tanti, tanti bei click assicurati.

Chissà...

Thu, 12 Jun 2014 06:00:00 +0000

Negli ultimi sette giorni si è piazzata al secondo posto nel numero di accessi a questo sito, scavalcando USA e Turchia, la… Citta del Vaticano!

Sarei veramente curioso di sapere chi… ;)