Free the iPhones!

Devo ammettere che la cosa più irritante per me, da quando uso un iPhone come dispositivo principale, è il fatto di non sentirmi libero di scrivere un’app ad uso e consumo personale. Sarà pure che Apple voglia proteggere il suo Store dalla pirateria o più probabilmente pura smania di controllo, ma le soluzioni finora sono poche e poco soddisfacenti.

1. donare $100 all’anno ad Apple per un certificato developer che - quando scade - porta via con sé la possibilità di continuare ad usare l’app.
2. pubblicare l’app nello Store con tutti gli annessi e connessi che - per un’app a puro consumo personale - è un onere non indifferente (oltre a dover cacciare i $100 del punto 1.)
3. usare il certificato gratuito con scadenza a sette giorni e ricompilare l’app ogni settimana; cosa aggravata dal fatto che ogni nuova versione di iOS richieda NECESSARIAMENTE GB su GB di aggiornamenti per XCode per rifirmare codice identico a quello della settimana precedente
4. usare certificati abusivi in vendita a meno di 3 caffè da Starbucks con validità di un anno e “garantiti” contro la revoca. Che, aldilà dell’essere eticamente dubbio, mette a rischio di una revoca sicura come le tasse visto che questi certificati sono usati molto comunemente per piratare app e Apple si diverte a revocarne in quantità bulk

Nessuna delle opzioni di cui sopra è per me soddisfacente e sinceramente c’è quasi la tentazione di cambiare piattaforma; almeno fino all’altro giorno.

Qualcuno ha pubblicato un’app multipiattaforma OSX/Windows con tanto di codice sorgente per generare un certificato fresco a richiesta, firmare il binario e fare l’upload su cellulare via Wi-Fi sync: mecoj**i!
Peccato solo che sia scritta in C++ e non ci sia una versione per Linux.

Il resto lo lascio all’immaginazione del lettore…

-quack

P.S. eh niente, quando si tratta di proteggere il suo controllo sulla piattaforma, Apple fa cose allucinanti. Sistemare showstopper invece può aspettare.

Containers, Containers, Containers

Dopo aver scassato il server Linux per l’ennesima volta a causa di script che non sono pensati per essere undone, mi son deciso a passare alle maniere forti. Si tratta di un problema di isolamento: installi la minchiata X che interferisce con la minchiata Y e all’improvviso l’applicazione Z smette di funzionare.

Nei grossi data-center l’isolamento viene risolto con una macchina virtuale per ogni app. Per il mio Cray-1 però sarebbe un po’ esagerato.

Il pallino mi è venuto quando ho pensato di installare a casa pi-hole (e in futuro usarlo in cascata con qualche DNS più aggressivo per evitare altra roba come il phishing) ma di dedicarci un Raspberry Pi davvero non mi andava: andrebbe alimentato e sono a corto di prese elettriche; e andrebbe connesso via LAN e sono a cortissimo di porte di rete a meno di installare uno switch che richiederebbe alimentazione aggiuntiva. E allora perché non virtualizzare?

Nel frattempo tra virtualizzazione full-plus (quella della mia Workstation Windows 10) e para-virtualizzazione, si è sviluppata una via di mezzo, quella dei containers. Ho pensato di dare un’occhiata a LXC per non dovermi sobbarcare l’onere di imparare qualcosa di profondo come Dockers da zero.

In poche parole un container LXC è una macchina virtuale in tutto e per tutto, senza la penalizzazione dovuta all’emulazione HW.

E così ho creato il mio primo container, collegatolo al bridge di rete esistente e la nuova macchina pseudo-virtuale è diventata visibile a tutta la LAN. Ci ho installato pi-hole, configurato il router assegnandovi un IP dedicato, impostato il DNS e tutta la LAN magicamente ha cominciato a filtrare pubblicità. Per sfizio ho provato anche la compatibilità binaria, copiando sul container una app scritta in Go. Anche quello ha funzionato, lasciandomi un po’ perplesso. Nell’informatica quando va tutto TROPPO LISCIO…

L’ultima prova è stata quella di esporre un intero file system dell’host al container. Rilassando un po’ la sicurezza è stato possibile anche testare che il container avesse la possibilità di modificare i file dell’host.

Next step trasformare in container tutto il trasformabile, ovvero

• un container per SAMBA e annessi e connessi
• un container per Crashplan
• un container per servizi vari ed eventuali: pi-hole e BFTS

L’obiettivo finale è quello di, una volta salvata in file la configurazione di ciascun container, ridurre al minimo l’installabile sul metallo dopo il prossimo eventuale formattone: ZFS, LXC e KVM, roba scriptabile in 10 righe o meno di bash.

-quack

Testing Forestry

Nel tentativo di ricominciare a scrivere più spesso, ho deciso di testare questo editor MarkDown che dovrebbe essere più decente rispetto a quello che ho testato finora.

Se tutto va bene, questo post dovrebbe apparire correttamente formattato. Con tanto di bollino giallo.

-quack

Pippe Mentali 2019 edition

Ho finalmente ripreso a scrivere: mi son lasciato bloccare dal fatto che ancora non posso usare - come piacerebbe a me - Open Live Writer per scrivere ed editare i post su questa nuova piattaforma. Poi guardando al backlog di cose che mi piacerebbe fare nel mio tempo libero, mi son detto tra me e me.

(leggere il labiale)

Ho appena finito una webapp, perché Dio mi salvi dalla tentazione di pagare un abbonamento developer ad Apple, scritta in GoLang per abilitare/disabilitare una restriction sul router che va ritoccata e convertita in un daemon. E poi vorrei installare Pi-Hole in un container LXC sull’ormai vetusto Cray-1. E poi cominciare ad esplorare l’idea di un paio di App Bluetooth LTE che avevo nel cassetto da mesi…

E poi… e poi…

E niente!

Effettivamente che ancora non possa scrivere su questo blog con OLW è sinceramente la cosa meno importante che mi piacerebbe veder funzionare nel 2019.

-quack

P.S. non è che questo editor poi sia eccezionale…

The Wife Zone Chart

Senza dover aggiungere altro

-quack

MoviePassing

Nella fantastica terra delle bolle silicose han tirato fuori dal cilindro un servizio chiamato MoviePass, il “Netflix” per chi vuole andare a vedere i film in un classico cinematografo.

Ci sarebbe da aprire una parantesi sul fatto che nella bobble-land molto spesso un nuovo prodotto venga semplicemente descritto “Netflix del/dei/della _____”: la dice lunga su quanto Netflix sia stato disruptive non solo come prodotto ma anche come modello di business.

In questo fantastico mondo fatato basta avere un’idea che possa sembrare disruptive e una implementazione base-base per avere accesso a capitali sterminati che permettono all’azienda di viaggiare in rosso durante la fase di lancio fino al possibile aspirato controllo del mercato.

È nato perciò un servizio che nella sua prima incarnazione costava $30/mese e permetteva di guardare un film al giorno, fatte salve eccezioni. Funziona così: al cliente viene spedita una prepagata MasterCard che tramite un’app, una volta nei pressi del teatro prescelto per la fruizione, viene caricata dell’ammontare del prezzo del biglietto, operazione definita semplicemente come “check-in”. L’evoluzione del modello di business è stata interessante da osservare ed è andata per fasi molto ben visibili:

1. LANCIO. Per $30/mese sono riusciti ad ottenere un minimo di attenzione ma scarso, scarsissimo pubblico. Un biglietto “scontato” qui si trova a circa $10, il che significa che per essere conveniente l’utente medio deve mirare a guardare almeno un film a settimana o poco più.
2. BOTTO. Hanno abbassato il prezzo a $10/mese e lanciato una campagna annuale ($100/anno) ottenendo l’attenzione che cercavano e un pubblico sterminato. È stato il momento in cui ho deciso di tentare la fortuna visto che anche con un solo film al mese ci si andava in pari; e poi era giusto il periodo dei trailer di Mission Impossible che sicuramente ci andrò a vederlo al cinema e perché no. Ho convinto un mio amico (socio) a seguirmi nell’impresa di guardare almeno un film per settimana, la domenica sera una volta esauriti gli obblighi famigliari.
3. CRISI. Ogni biglietto pagato, che al botteghino costa di solito un po’ più di $10, significa per MoviePass andare in rosso. Ci sono stati accordi commerciali alcuni andati a buon fine (pochi) altri molto male (tanti) ma la sostanza è che ogni biglietto staccato significa usare soldi degli investitori per pagare lo show ai propri clienti.
4. DISINCENTIVAZIONE 1. Coi conti in profondo rosso e aspettative di sopravvivenza non proprio rosee, forti di una base di clienti molto ampia, hanno cominciato a sfornare piani per la disincentivazione in virtù del fatto che di solito il modello subscription funziona solo in presenza di utenti occasionali che portano soldi in cassa a discapito degli altri. Nel caso di MoviePass però anche gli utenti occasionali, quelli da “un film al mese”, portano perdite. Il primo disincentivo è stato quello di proibire la seconda visione di uno stesso titolo e richiedere al tempo stesso una foto del biglietto per evitare che la gente dichiarasse di andare a vedere Bambi e comprasse il biglietto per Sterminator 5. Non una grande mossa visto gli scarsi effetti al prezzo di pubblicità negativa.
5. DISCINCENTIVAZIONE 2. Nel mentre qualcuno in MoviePass cercava accordi con la distribuzione cinematografica e i circuiti teatrali, hanno tenuto fuori programmazione alcuni blockbuster cominciando con “Mission Impossible”; un modo per dare un’idea ai loro interlocutori della loro forza. Morale della favola ce lo siam dovuti vedere pagando di tasca nostra. Il film l’hanno poi reso disponibile dopo tre settimane o più, cosa per molti utenti persino accettabile.
6. DISINCENTIVAZIONE 3. Invece che avere accesso alla proiezione di “quasi tutti i film disponibili” hanno stabilito una rotazione di circa sei titoli giornaliera, ridotto il numero di film visionabili da uno al giorno a tre al mese e rimosso l’obbligo di scattare una foto del biglietto riaprendo le porte a “false dichiarazioni”. Tutto sommato un’esperienza per molti ancora accettabile previa consultazione del calendario e adeguata programmazione dei film da guardare e quando, che non ha fermato l’emorragia finanziaria del servizio.
7. MOVIE LOTTERY. Colpo di genio finale: raggiunta giornalmente una certa quota ignota agli utenti di biglietti staccati, l’applicazione restituisce un errore al momento del check-in (“there are no movies available in your area”). Spesso basta chattare per venti minuti con il customer-care representative(*) per vedersi sbloccare l’accesso ma tanto basta per scoraggiare l’utente medio; con questa mossa l’emorragia, se non completamente bloccata, è sicuramente sotto controllo. A noi è capitato che la quota si sia esaurita nel tragitto da casa al cinema con conseguente secondo esborso del biglietto questa volta full price. È stato il momento in cui io e il mio socio, con cui avevamo raggiunto una non trascurabile media di circa tre film al mese negli ultimi periodi e media globale di poco meno di due film al mese per tutto l’anno, abbiamo deciso di cancellare il nostro account nonostante la minaccia di non poterlo riattivare per nove mesi dopo la cancellazione.

Nel frattempo sono cominciate a fiorire alternative: Sinemia, che ha un piano simile di 3 titoli al mese per $10; AMC A-List, 3 titoli alla settimana per $20.

Che fine farà quest’esperimento? Non ne ho idea. Da quello che abbiamo osservato durante certi spettacoli serali le sale sono praticamente vuote. La resistenza dei circuiti teatrali sembra davvero ingiustificata considerato il costo marginale di ogni biglietto praticamente nullo e il traffico e introiti aggiuntivi generati dall’abbonamento mensile: l’anno precedente per intenderci al cinema ci sarò andato un paio di volte ($25) contro i $120 spesi quest’anno, quindi il modello almeno sulla carta sarebbe persino solido. Ma l’industria cinematografica oppone notoriamente resistenza a cambiamenti di entità anche molto minore.

Un peccato se MoviePass dovesse morire e con loro un modello di business sicuramente più a passo coi tempi e con l’utenza moderna, che ormai i film li aspetta su Netflix.

-quack

(*) tali rappresentanti servizio clienti, chiaramente a conoscenza della policy segreta di “quota biglietti giornaliera”, continuavano a perculare gli ignari clienti ovviamente dietro obbligo aziendale, suggerendo i classici step di troubleshooting come: “ha provato a riavviare il telefono”? “ha provato a riavviare l’applicazione”? Il tutto nella speranza di scoraggiare i clienti meno pazienti ad abbandonare l’idea di usufruire del servizio regolarmente pagato.

Ventanni

Sono arrivato in questo Paese ”esattamente” vent’anni fa, per quanto esattamente si può misurare un periodo di tempo superiore a trecentosessantacinque giorni. Allora l’idea di restare così a lungo in terra straniera non passava neanche per la testa. Non a me, non ai 15 (più o meno) scalmanati arrivati in quella che credo sia stata l’unica immigrazione di italiani di massa a Redmond a opera di Microsoft.

Arrivai con un biglietto di sola andata ovviamente, che già fa un po’ timore, con un visto H1-B fresco di conio, Bari –> Venezia –> Amsterdam –> Seattle. Di quel viaggio ricordo le istruzioni stampate su un foglio A4 fronte retro con indicazioni varie su come noleggiare l’auto, dove andare, come recuperare le chiavi dell’appartamento temporaneo affidatomi e altra poca roba.

Ricordo di essere arrivato a Venezia e la tipa al bancone informarmi, con un smagliante sorriso, di non avere un biglietto a mio nome e che anticipai il costo di tasca mia: che fortuna essere uno dei pochi ad avere una carta di credito personale già allora, su insistenza di un mio amico.

Ricordo il volo Amsterdam –> Seattle, nel posto corridoio seduto di fianco ad un energumeno che, per paura di rimanere bloccato dal mio appisolarmi, mi svegliava ogni volta che mi calava la palpebra con la scusa di dover andare in bagno. Mi appisolai all’arrivo quando l’energumeno, recuperato il bagaglio a mano, si mise in fila per uscire. Venti minuti indisturbato, fui l’ultimo a lasciare l’aeromobile svegliato da un’hostess preoccupata.

Ricordo di averci messo un po’ a capire il cambio automatico, fermo nel parcheggio dell’aeroporto. Il terrore di percorrere le autostrade americane seguendo le indicazioni dal foglio di carta. Il GPS allora non aveva ancora applicazioni consumer.

E poi trovare un letto comodo, un cesto di benvenuto con qualche snack e non aver nessuna idea di cosa fare per cena. Ne di sapere con certezza nel mio jet-lag se fosse davvero cena o qualche altra cosa.

Ricordo di aver incontrato altri come me, presi forte dall’imposter syndrome che non sapevamo neanche cosa fosse. Tutti, nel definirci, abbiamo usato la stessa parola: incoscienti, arrivati per fare un’esperienza di qualche anno e rivendercela “a casa nostra”. Qualcuno è tornato, qualcuno è restato, qualche altro si è solo spostato un po’ più a Sud.

E altre cose personali che tengo ovviamente per me.

Se mi avessero chiesto allora quali fossero le probabilità di trovarmi nei panni in cui vesto oggi avrei detto quasi zero; difficilmente avrei pensato di essere ancora qui, figuriamoci poi lavorare addirittura per un’azienda nata poco prima del mio arrivo di cui allora solo pochi ne conoscevano l’esistenza.

Chissà allora fra vent’anni, fatti tutti i debiti scongiuri. Cheers!

-quack

Ciao Paul!

DuemilaDiciotto

Notizie come questa o questa (che di per sé è una notizia in quanto Microsoft non ne sembri preoccupata) mi fanno pensare che l'IBM-izzazione di Microsoft è ormai completa.

IBM è quella azienda che per Microsoft rappresentava la completa antitesi negli anni novanta. Con la mossa geniale e fortunata di tenersi i diritti di poter dare il DOS in licenza alla concorrenza, in un momento in cui i clone non esistevano perché non c'era ancora l'originale, Bill Gates ha praticamente reso l'hardware una commodity. Irrilevante quale clone tu comprassi (con Intel o AMD), l'importante è che ci girasse il DOS e tutte le sue applicazioni.

IBM non l'ha presa bene e la reazione emotiva, come ad esempio bandire il pulsante Start dalle proprie tastiere fino all'acquisto della Lenovo, non ha fatto altro che peggiorare le cose.

Undici anni fa Microsoft era data per spacciata irrilevante grazie all'arrivo del Web 2.0. Per una coincidenza astrale, il vero colpevole della moderna irrilevanza verrà rilasciato solo qualche mese dopo: Giugno 2007, il primo iPhone, prodotto che oggi giorno fattura di più di tutta l'azienda di Redmond messa insieme. E poi treni su treni, ancora non esiste l'equivalente di un prodotto come Echo/Home, persi a causa del male oscuro di Ballmer: l'arroganza.

Detta così potrebbe sembrare una cosa negativa, ma non lo è affatto. IBM è un'azienda che fattura un sacco di soldi. Il cloud può sembrare boring ma ha tantissime potenzialità. Per non parlare poi dell'AI.

Certo è che a leggere queste notizie mi è venuta tanta nostaglia degli anni novanta...

-quack

QuattroKappa

È successo l’improbabile: due televisori di “nuova” generazione, uno comprato per i mondiali del duemilasei, l’altro ricevuto in dono con l’acquisto dell’immobile, sono morti a distanza di pochi mesi. Essendo ormai quasi completamente digitali, son morti dell’unica morte analogica possibile, la circuiteria di alimentazione.

Considerata la longevità mi è sembrato il caso di passare ai 4K; su Netflix e Amazon i nuovi contenuti supportano già tale formato, nel giro di cinque anni immagino 4K saranno il nuovo default dell’intrattenimento mentre la Live TV segue (?) lentamente.

La scelta dei televisori è stata tutto sommato abbastanza semplice. Con cosa sostituire i due device Android TV un po’ meno. Alla fine ho provato Fire TV di serie su un Toshiba 50” open box. Visto che installarci Kodi è stato abbastanza semplice, molto più facile di solo qualche decina di mesi fa, mi sono convinto a sostituire anche l’altro device con un altro Fire TV 4K modello “vecchio” in saldo a metà prezzo. L’alternativa rimasta, NVidia Shield, costa ancora troppo per l’utilizzo non-ludico del giocattolo.

L’unica grana è stata scoprire che lo switch HDMI tarocco non supporta HDCP2.2 e quindi niente 4K senza collegare la scatoletta direttamente al televisore. Per fortuna ne ho trovato uno altrettanto poco costoso che avrò l’ebbrezza di provare più tardi: Thanks God for Amazon One Day delivery!

Dal punto di vista algebrico c’è da osservare che il numero di dispositivi Android o pseudo-tali in casa è rimasto inalterato. Coincidenze?

-quack

Open Source Experience

Negli ultimi tempi mi rendo conto di essere diventato un po’ più friendly nei confronti dell’Open Source; infatti sul mio Cray 1 ci gira Linux con un Pool ZFS nativo e gingillerie varie. Trovo tuttora tale configurazione estremamente economica per conservare i file più cari. Foto, ricordi, diapositive del tempo che passa.

Ritengo invece, in tutta la questione, che sia rimasta un’invariante, ovvero la necessità non tanto remota di doversi spesso e volentieri sporcarsi le mani con il codice scritto da altri che sempre molto più spesso ha il sapore del tabacco da masticare.

L’ultimo episodio si è verificato con l’upgrade di Ubuntu dalla versione 16.04 alla 18.04. Accedere al Pool ZFS causa un soft kernel panic. Ho cercato in giro qualcosa che somigliasse allo stack trace nel log di sistema ma niente.

Ho aperto un baco due mesi fa ma nessuno se l’è filato. Nel frattempo il mio sistema mi invita sempre più sovente a fare l’upgrade alla nuova fiammante 18.04.1 proponendomi un comando in grado di compiere l’operazione in un sol colpo. Sono quasi pronto per accettare l’offerta ma la paranoia ha il sopravvento. Colpo di fortuna scopro un altro sfigato affetto dallo stesso identico baco ma con ZFS debugging skill a livello di terzo dan in grado di fare un po’ di luce sulla questione.

Il baco è dovuto ad una ACL invalida ereditata dai tempi in cui il Pool girava su Solaris/OpenIndiana. Quale sia l’oggetto della questione è un mistero quasi facile da risolvere. Basta aggiungere cinque righe di debug per avere un objectid e la speranza di venirne a capo. Nel frattempo ho provato ad azzerare le ACL semplicemente spostando tutti i file, senza successo. La ACL maledetta, come già sospettavo, si annida a livello molto basso altrimenti non sarebbe in grado di mandare in crash il sistema durante l’operazione di import.

Seguo i suggerimenti di qualche developer che nel frattempo a fronte di informazioni estremamente più puntuali ha deciso di prendere a cuore la questione. A leggere le guide disponibili in giro, compilare un modulo di sistema sembrerebbe abbastanza indolore. E così scarico e modifico codice non scritto da me, per fortuna in un linguaggio familiare. Ma la patch non funziona e il codice compila anche se cancello il file per intero. Mi spiegano che su Ubuntu i moduli centrali di ZFS sono integrati nel kernel e quel codice di cui parte inutilizzata è serve solo a compilare i tool di alto livello; e che se voglio testare la patch tocca seguire una guida abbastanza complicata; oppure installare una distro che distribuisca ZFS in formato sorgente che sono quasi tutte: Debian - che però è una decina di release indietro - e poi Fedora, Red Hat, ecc. Oppure installare ZFS su Ubuntu usando DKMS anziché il repository di default. Cosa che però non funziona, per ovvi motivi, con una distro live o con i pacchetti installati sul mio server basato sulla 16.04 di default.

A questo punto non mi resta che provare nell’ordine a:

• installare Ubuntu 18.04 su una chiavetta USB e sperare di riuscire a metterci la pezza
• provare la pezza su una distro diversa
• in estrema ratio ricreare il pool ex-novo; operazione già da tempo nella mia to-do list per conformità alla “rules of three of backup”

Certo è che la pressione di sapere di non poter fare l’upgrade del sistema all’ultima versione si fa ogni giorno più pesante.

Open Source = you debug it

Se sia nello specifico sia stato un bene o un male è troppo presto per determinarlo. Auguratemi buona fortuna.

-quack

P.S. seguirà un post separato su come abbia perso i contenuti di un folder a causa di come sia stato implementato il comando mv in GNU Linux

Mark Down!

Ho sempre pensato che l’informatica fosse la branca della scienze MM.NN.FF. più razionale. Voglio dire se scrivi 2+2 e il risultato è 5, il processo per arrivare a determinare dove sia la discrepanza tra attesa e realtà è abbastanza pedissequo.

Però dove tre o più umani decidono in “commissione” o più semplicemente un Program Manager ardimentoso si lancia all’avventura, si può assistere a risultanti interessanti o addirittura spettacolari.

La storia delle mode dei “formati” è un esempio lampante, chiarissimo, cristallino.

Venti anni fa, svariati scienziati dell’informazione riuniti in un consorzio (W3C), hanno messo a punto sulla carta uno dei più popolari formati “standard”, l’XML. La spinta per l’XML veniva dall’interoperabilità, obiettivo glorioso e nobile. Se dobbiamo far parlare il sistema XYZ di Pinco con il sistema ABC di Pallo, un formato comune è necessario. L’idea di usare un consorzio esistente (il W3C appunto) buona. Partire da un formato pre-esistente passabile: immagino che qualcuno abbia pensato che si potesse usare tanta di quella conoscenza pregressa nel parsing dell’HTML per produrre strumenti pensati per processare l’XML. E poi formati su sformati e protocolli basati su XML come se stesse per arrivare la fine del mondo: SOAP, XSLT, XSD, XPath, XQuery, ecc.

A questo punto qualcosa di bizzarro: Visual Studio .Net ha bisogno di un nuovo formato per i file Solution/Project? XML! Office ha bisogno di un nuovo formato per i file? XML!

Fin qui quasi tutto ok: Visual Studio ha potuto usare una delle tante API(*) disponibili per fare il parsing e XML era già pronta, ottima scelta ingegneristica. Usare XML per Word ed Excel significa maggiore interoperabilità, perfetto.

Dopo qualche anno è arrivato JSON, nato com’è dall’esigenza di un servizio WEB di mandare dati ad uno script Javascript; con l’XML lo script dovrebbe fare il parsing dei risultati, con JSON invece no. Qualcuno ha pensato, ovviamente, di standardizzare anche se c’era ben poco da fare e - ovviamente - una cappella:

I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn’t. ( fonte ) (**)

L’aspetto spettacolare specifico di questa istanza è che Visual Studio abbia deciso di usare JSON per i file di soluzione/progetto. SENZA. NESSUN. MOTIVO. TECNICO. (***) Perché? Voglia di seguire una moda? Nell’informatica?

La decisione, in virtù anche della cappella sui commenti, era così palesemente sbagliata, che si son dovuti ricredere e tornare al buon vecchio XML.

Duemilaequalcosa, alla ribalta arriva MarkDown. L’idea è quella di codificare in formato testo un sottoinsieme di formati di formattazione del testo: grassetto, sottolineato, corsivo, ecc. e al tempo stesso preservarne la leggibilità da parte di un umano. Lanciata la moda è partito l’inseguimento, quello dei Missoni dell’informatica che, anche laddove il requisito di leggibilità umana non sia assolutamente necessario, hanno cominciato ad adottare ed abusare tale formato.

Morale della favola oggigiorno si può assistere alla totale irrazionalità di soluzioni che, per servire HTML ad un browser, pur partendo già da HTML, decidano di convertire il tutto in MarkDown.

O forse sto semplicemente diventando vecchio e facilmente irritabile.

-quack

(*) nota storica: partendo ovviamente da quella sbagliata
(**) siccome i commenti possono essere usati per turpiloquio, li aboliamo da qualsiasi linguaggio?
(***) l’obiettivo di JSON è di essere fruibile facilmente da un browser

P.S. ironia della sorte, questo post purtroppo per ora è scritto in MarkDown, ma questa è un’altra storia.

Hugo

Storia dell’ultima migrazione di piattaforma. Solo qualche giorno fa ero abbastanza soddisfatto della soluzione basata su Jekyll. In uno slancio di ottimismo mi son spinto a dire:

Speriamo di non dover pensare all’obsolescenza un’altra volta prima dei prossimi dieci anni. Ecco dieci anni sarebbe una misura giusta per rivedere magari un po’ di cose.

Ed invece.

Premessa: mi ero erroneamente convinto che GitHub Pages (GP d’ora in poi) fosse una soluzione più unica che rara. Poi mi son scontrato con un problema con la paginazione delle categorie. Oddio, neanche il supporto per le categorie è stato indolore: ho cominciato seriamente ad irritarmi in quanto ho “comprato” Jekyll con la promessa di un tool che fosse, parole loro, Simple, blog-aware, static sites.

Scopro che la versione 2 del plugin di paginazione fa questo e quell’altro, incluso generare pagine al volo per le categorie ma github pages supporta solo la versione 1. Chiedo lumi su chi bisogna corrompere per avere il supporto nativo di tale versione in GP. Mi dicono che quelli di GP non si fidano dei plugin scritti da terze parti, persino le skin son guardate con sospetto, ecc. ecc. Mi consigliano di guardare Netlify, prodotto simile a GP con supporto nativo di GitHub e massima libertà coi plugin disponibili. Fatto questo, ho sistemato il forum sfruttando l’idea di generare un post tramite le API di GitHub usando un’istanza Google Cloud. Però il dover attendere svariati minuti per un cambio di virgola o l’upload di contenuto statico che non ha nessun impatto sui file generati mi ha fatto nascere qualche sospetto. Mi son chiesto se ci fosse un flag, un qualcosa che generasse il tutto in maniera incrementale e son finito su un baco in cui si discuteva del tutto come di qualcosa di dannatamente complicato.

Il fatto che un prodotto che dovrebbe essere orientato alla generazione dei siti statici, che in full mode ci mette svariati minuti per qualcosa come poche decine di post e al tempo stesso non è stato disegnato con un meccanismo di rigenerazione un pelino più sveglio della mera forza bruta non la dice bene sulla qualità dello stesso.

Sapevo dell’esistenza di Hugo, scartato inizialmente solo perché non supportato da GP, e mi son dato un’altra occhiata. Ho fatto una piccola prova e sono rimasto allucinato. Ho deciso di “importare” i contenuti da Jekyll tramite l’apposita feature e il tutto ci ha messo meno di qualche secondo dandomi l’impressione che qualcosa fosse andato storto. Lancio il server builtin sul mio PC al lavoro che è abbastanza muscoloso e in tutto passano 222 millisecondi. Incredulo ho fatto diverse prove e niente. L’unica pecca è che Hugo non ha, a differenza di Jekyll, un tema di default e ho dovuto pescare un po’ a caso. Però… wow. Supporto nativo di tutto quello che serve ad un blog:

• tassonomie
• post postumi e con scadenza
• paginazione nativa
• auto-generazione di liste
• ricchi premi e cotillon

In una mattinata ho importato tutti i post in automatico, importato le pagine a manina, sistemato il layout delle pagine particolari e pumm! Online.

In tutto questo ho solo dovuto faticare un po’ con:

• la configurazione del feed RSS che di default include tutti i contenuti e quindi anche pagine, forum post, ecc.
• la disabilitazione di alcune feature (es. il reading time; link a post precedente-successivo; ecc.) in maniera selettiva
• capire a quale file di layout corrisponda una determinata pagina, roba secondo me inutilmente complicata

Tuttavia niente che non abbia risolto grazie a qualche ricerca su Google.

L’unica pecca di tutto l’ambaradan è il fatto che mentre la generazione via Hugo è superveloce, Netlify impiega svariati secondi nella fase di post-processing e pubblicazione. Credo che sia una feature intenzionale disattivabile solo con account premium e nel caso c’est la vie.

Last but not least: essendo Go un linguaggio compilato, per installare HuGo non c’è bisogno di installare il runtime di Go, a differenza di Jekyll che tra linguaggio e librerie è un po’ espansivo. Però non voglio pensare che il peso delle prestazioni orribili sia dovuto solo al linguaggio scelto.

In tutto questo va riconosciuto a Tom Preston-Werner, fondatore di GitHub e autore di Jekyll, il merito di aver lanciato al pubblico più vasto l’idea di un generatore statico di website.

-quack

P.S. la prossima volta starò più attento al fatto che, nella soluzione proposta con enfasi da qualcuno, ci possa essere il sospetto di bias dovuto al Muslow’s Hammer.

Nuvole

In questi giorni ho fatto un po’ di pulizia virtuale. Non solo ho spostato il blog, ma avendo scoperto l’esistenza di Google Domains che offre lo stesso servizio di GoDaddy a quasi metà prezzo senza dover per forza fare una caccia al tesoro di sconti, spostato tutti i miei domini lì.

Avevo solo un piccolo problema con una piccola webapp che, nell’incarnazione precedente, sfruttava la possibilità di girare in condivisione con il blog. Niente di che, ma quanto basta per spingermi a cercare una soluzione.

La parte statica è facilmente risolvibile, come già spiegato, tramite GitHub pages.

Per la parte dinamica ho voluto provare l’ebbrezza di codice on the cloud. Ho scelto Google App Engine perché ho cercato come parte dell’esercizio di evitare di installare Visual Studio, avendo già un ambiente di sviluppo Java based pronto per l’uopo. Il mio primo tentativo è stato quindi quello di scrivere codice per Google App Engine in Java. La prima domanda che mi è stata posta è: Standard o Flex? Flex mi è sembrata una scelta per l’appunto più flessibile e son partito da lì. Tutorial Java ben fatti ce ne sono pochi, mi son dovuto un po’ arrangiare e alla fine mi sembrava che il tutto fosse un’arrabbattata. Guardavo di lato i tutorial per .Net che sembravano tutti più semplici e ho deciso di morsicare la pallottola, installare Visual Studio e togliermi lo sfizio.

Effettivamente è stato tutto più semplice, ho scritto l’app in pochi minuti, fatto il deployment, testata, ecc. Quando poi son tornato dopo un paio di giorni a controllare i consumi (Google offre $300 per il primo anno in “prova”) ho scoperto che la mia app, praticamente sempre ferma con una media di 5 richieste al giorno dovute più che altro al testing, aveva accumulato circa 7$ di consumi in 10 giorni. Decisamente troppi, ho pensato di aver toppato qualcosa. Ed infatti…

Ho scoperto che flex, a differenza di standard, è un ambiente always-on, con CPU dedicata che consuma anche senza carico. L’alternativa standard sembra essere più load oriented. Pecca: standard non supporta .Net. Armato della prima esperienza, mi son deciso a riprovare a riscrivere l’app in Java. Qualche riga di codice in più per ovviare alle mancanze di .Net ma fa niente. L’app, che è anche un proof-of-concept, gira tranquillamente e fa perfettamente il suo dovere. Ad oggi, il piccolo carico produce una stima di circa… zero dollari, che è più o meno quello che mi aspettavo.

Tra le altre prove ho pure provato ad usare le capacità di Google App Engine di mandare email. Il primo test ha funzionato, appena ho un po’ di tempo ci aggiungo qualche riga di codice per l’antispam e avrò bello e pronto il modulo per contattarmi via email. E anche una soluzione possibilmente migliore alla forma attuale del forum, con una pagina diversa per ogni topic così come era ai tempi prima dell’HTTPS.

Speriamo di non dover pensare all’obsolescenza un’altra volta prima dei prossimi dieci anni. Ecco dieci anni sarebbe una misura giusta per rivedere magari un po’ di cose.

-quack

Welcome to my Jekyll world

Mentre la migrazione va avanti, mi limito ad appuntare qui i piani per il futuro di questa piattaforma.

Alla fine ho scelto Jekyll in quanto è la piattaforma di riferimento per le GitHub pages, una maniera di hostare pagine html (o jekyll) gratuite su GitHub. Per passare i contenuti mi sono scritto un’app in Java per convertire un dump del database SQL-server ottenuto in formato XML: cosa buffa, l’API che GoDaddy usa per esportare una query in XML l’ho scritta io diciotto anni orsono. Ovvero il codice buono invecchia bene come il buon vino. Avrei usato C# al posto di Java, ma non ho ancora installato Visual Studio e non so se voglio farlo su questa workstation; o per lo meno non ho scelto ancora quale versione installare. Ho dovuto scrivere qualche Java in più ma tra parentesi e commenti sono in tutto meno di settanta; codice ovviamente da buttare via appena finita la conversione.

L’unico problema di Jekyll è che sembra molto orientato al MarkDown (che poi ovviamente deve essere convertito in HTML!) e c’è chi è stato folle abbastanza da fare una conversione HTML –> MarkDown –> HTML. Però siccome gestisce anche i file HTML con un prologo per la parte metadata non proprio standard, ho scelto la strada più facile.

La schifezza di MarkDown è che non ho trovato ancora un editor soddisfacente e ho l’impressione che la gente spenda il tempo a scrivere i contenuti direttamente in MarkDown. Decisamente un passo MOOOOOLTO indietro rispetto al WYSIWYG di tool come Windows Live Writer.

L’altra schifezza di questa soluzione è che postare richiede un git clone di tutto il repository, inclusi file di immagine e altra bella roba.

Il mondo perfetto sarebbe quello in cui è possibile usare un tool come Windows Live Writer. Ho in mente già una soluzione-accrocchio: un piccolo server Web che implementa la MetaBlog API e semplicemente usi le API di GitHub per postare i file come necessario. Dovrebbe essere una cosa semplice che posso donare alla comunità.

-quack

Riapro

Se tutto è andato come previsto, questo dovrebbe essere il nuovo blog, moving forward.

Timeline:

1. migrazione dei post
2. abilitazione dei commenti su Disqus
3. import dei vecchi commenti
4. forum?
5. restyling
6. raffinerie varie

Auguratemi buona fortuna!

-quack

Chiudo

Dopo aver rinnovato per altri due mesi l’hosting con GoDaddy al prezzo di una birra per ogni due settimane circa, ho concluso che:

1. i blog come luogo di sano trollaggio nell’accezione positiva del termine sono stati uccisi dal Social; la qualità dei contenuti e delle discussioni, con l’aumento della quantità, si è abbassata drasticamente, motivo per cui anche lì mi sono sospeso
2. l’informazione di buona qualità su questo blog è o obsoleta o poco utile o entrambe le cose; negli ultimi anni ho avviato un processo personale di semplificazione per cui devo ricordare meno cose e per quelle c’è il buon fido OneNote nonostante i tentativi suicideschi di Microsoft
3. la voglia di scrivere c’è ancora ma l’analisi costi/benefici di qualsiasi altro piano (lasciare le cose così o migrare) è praticamente impietosa

Detto questo non è un addio ma un arrivederci. Mi piacerebbe spostarmi su una piattaforma hosted come Wordpress o Blogger. Preferirei la prima soluzione ma se c’è una cosa che vorrei mantenere è il nome del dominio e Wordpress ha costi marginalmente inferiori al fai da te. La seconda cosa che mi piacerebbe mantenere è l’aspetto grafico, perché è un’altro piccolo assaggio della farina del mio sacco (dettaglio che ho tenuto finora nascosto: i buchi del modulo continuo sono scannerizzati).

Credo che la migrazione a Blogger + Disquis sarà il prossimo step seguito da una parziale migrazione di qualche contenuto (link utili, il layout di tastiera, ecc.) e l’impostazione grafica. Mettere mano al layout con blogger va oltre il mio concetto di “fun”, quindi al momento sono anche alla ricerca di un servizio che trasformi il CSS di questo blog nell’equivalente Blogger. Se avete qualche suggerimento, lasciate un commento in calce o scrivetemi in privato.

Non ho una timeline in mente, nel momento in cui il piano diventa più chiaro, lo condividerò qui.

Nel frattempo: sono su Twitter e offline, via email.

-quack

Scripting the world

Qualche settimana fa è stata rilasciata la versione 18.04 di Ubuntu che mi interessa per via del fatto che impacchetta QEMU 2.11. Mi son procurato un SSD separato, l’ho installata dopo mille peripezie dovute al fatto che la versione server utilizza il partizionamento GPT non opzionale e quindi non avviabile sul mio vetusto Cray-1, ma ho avuto un’amara sorpresa: la versione di ZFS inclusa combinata con la versione del kernel va in crash con il mio POOL zfs. Dopo vari esperimenti dovuti al fatto che il POOL multi-tera ha priorità elevatissima, ho deciso di deviare dal selciato provando Debian. Che però impacchetta QEMU 2.8: allo stesso tempo ho scoperto che il mate desktop è più simpatico e meno ostile a XRDP ma purtroppo a me serve anche QEMU 2.11

Ho deciso di provare la tecnica del pinning, ovvero aggiungere il repository di una versione nuova e importare il package singolo. Peccato che la versione beta di Debian impacchetti QEMU 2.12 che – forse per qualche baco – di far andare la mia workstation virtuale non ne vuole proprio sapere. Persino il boot da DVD fallisce miseramente con l’errore 0xC0000225 a cui di solito si ovvìa con… un DVD di boot.

A questo punto mi è sembrato il caso di tornare alla versione 16.04 e provare lì il pinning. Un esperimento veloce veloce ha provato la correttezza di questa teoria, tuttavia nei vari tentativi mi son incasinato e ho rovinato l’installazione di Mate che non ne voleva sapere di mostrare più l’icona del cestino. Dopo che ho finalmente messo insieme tutti i pezzi rimanenti ho deciso di ridurre la manualità delle operazioni necessarie tramite uno script da tenere a disposizione nel pool. Adesso reinstallare Ubuntu 16.04 e tutti i pezzi necessari è un’operazione in tre + due passi:

1. installare il sistema da zero, senza pacchetti opzionali
2. installare zfs/importare il POOL
3. avviare lo script e seguire le istruzioni; la parte più antipatica è l’inserimento delle password per le share (4 digitazioni per ogni utente!) (*)

Gli unici due passi manuali rimanenti sono l’installazione/configurazione di CrashPlan e installazione/configurazione di MythTV. Al rilascio della versione 18.04.1 farò un altro tentativo per vedere se la compatibilità tra kernel/zfs/POOL è migliorata ed eliminare il pinning dagli step necessari.

Per ora tutto sembra funzionare a puntino e la cosa più notevole è vedere l’avvio della Workstation virtuale mettersi in moto come se niente fosse cambiato. Nell’eventualità di un HW upgrade prossimo venturo, magari con il rilascio di uno Xeon che porti in dote le fix per i vari Spectre & co. Nirvana 2018.

-quack

(*) sto pensando seriamente ad una soluzione che preveda il backup/restore di tutte le credenziali. Dovrebbe essere fattibile ma non è tutto molto ben documentato.

Il formattone

Con l’uscita della nuova versione appena sfornata di Windows 10 e con il persistere dei miei guai, ho deciso di affidarmi al formattone.

Sinceramente, sono davvero scocciato che:

1. aprire un file JPG sia diventata un’operazione che richiede un reboot
2. trovare installate applicazioni che io non ho mai chiesto, Minecraft, OneDrive, Candy Crush. Mi sembra di aver comprato un Sony qualsiasi e invece si tratta della versione PRO di Windows 10
3. spegnere l’antivirus sia un’operazione che tocca fare ad ogni riavvio. Questo dopo aver notato quante risorse assorbi il suddetto a PC “fermo”. Se vi volete far del male, lanciate ProcessExplorer e fermatevi a guardare

Io tento l’opzione nucleare. Dopo di questo non saprei proprio quale sia il meno peggio tra un Hackintosh, l’obsoleto Windows 7 e questa merda di OS che sembra disegnato per mettersi di traverso.

-quack

P.S. la scorsa settimana si è fulminato l’SSD del laptop della formichina. Aveva poco più di un anno e non avevo ancora preparato il piano di backup. È il secondo SanDisk Ultra II a stendere le penne in pochi mesi. Ero davvero tentato di sostituirle Windows con Chrome… sarà per la prossima volta e con un device supportato (ChromeBook).

HTTPS is coming

Qualche giorno fa sono stato contattato telefonicamente dal mio hosting provider (GoDaddy). Di solito mi chiamano per contrattare il rinnovo multiplo dei servizi di cui usufruisco e spesso gli sconti son significativi. L’ultima volta non me la son sentita di rinnovare per due anni congelando di fatto lo status quo. Stavolta però, con l’arrivo imminente di HTTPS per tutti, di contrattare un po’ di voglia ce l’avevo. Perché GoDaddy offre ai propri clienti certificati per HTTPS, ma il prezzo, per tenere in vita questo blog, sarebbe troppo alto. L’operatore tra l’altro pareva fosse anche abbastanza contento di non poter offrire certificati di terze parti e questo mi ha scocciato non poco; infatti letsencrypt mi sembrava la scelta giusta.

Si aggiunga che, quando ho deciso di scrivere la piattaforma su cui fare girare questo blog, ho fatto una scelta in retrospettiva molto sbagliata: aggiungere l’estensione ASPX a tutte le URL di questo blog. Non l’avessi fatto avrei avuto la possibilità di migrare ad un hosted WordPress per una frazione di quanto stia spendendo adesso. Quest’opzione purtroppo non è disponibile e tenere in vita le vecchie URL richiederebbe hostare WordPress per conto mio. Una pessima idea per due motivi: mi forzerebbe a tenere aggiornato WordPress a causa dei numerosi bachi che si porta appresso di release in release e costerebbe alla fine quanto hostare Blogoo finendo per giunta per perdere il contenuto del forum.

Ho cominciato ad analizzare le alternative:

• chiudere tutto (e ricominciare da zero?)
• passare ad un host meno esoso tenendo in piedi l’ambaradan corrente
• convertire Blogoo in ASP.Net Core/MySQL e usufruire di una VPS che mi permetterebbe altre robe carine
• “congelare” le pagine attuali e hostarle su un servizio gratuito (github pages) o similare. Ricominciare altrove con un nuovo dominio

La lezione che ho imparato è che le tecnologie non durano per sempre e che il tempo investito in Blogoo, sebbene mi abbia dato la possibilità di imparare parecchie cosette utili, avrei dovuto dirottarlo altrove.

E mentre scrivo e rifletto, realizzo che forse HTTPS non è quella maledizione che mi è sembrata al primo colpo e probabilmente questo potrebbe essere l’ultimo post via Blogoo. So long and thanks for all the fish.

-quack