Mysql on Melabit

Swift contro Python, ovvero mele contro pere

Mon, 03 Oct 2022 06:00:00 +0000

– Fonte: Martina Leuderalbert su Unsplash.

Alle elementari la maestra mi aveva insegnato a non sommare le mele con le pere, cioè a non mettere insieme (o paragonare) cose e fatti molto diversi fra loro. Non ha quindi senso sommare 3 litri di acqua con 5 chilogrammi di farina o chiedersi se 40 metri sono più o meglio di 20 secondi.

Quello che diceva la mia maestra lo dicono, sono sicuro, le maestre di tutto il mondo, ma c’è sempre qualcuno assente a queste lezioni.

Il Golia della programmazione moderna

Uno di questi è stato di sicuro Ari Joury che, nonostante il suo dottorato in fisica delle particelle, non si è fatto scrupoli a pubblicare su Medium questo Swift was poised to replace Python. Then it tanked.

Cosa dice l’articolo? Che nel mondo del machine learning i linguaggi di programmazione più usati sono Matlab, R, Julia e soprattutto Python. Quest’ultimo, nato originariamente per sviluppare dei piccoli script senza troppe pretese, è diventato oggi un vero “Golia della programmazione moderna”, tanto da essere usato estensivamente da aziende come Dropbox, Instagram e Pinterest per i loro servizi online.

Grazie alla disponibilità di librerie come TensorFlow o PyTorch (nonché, aggiungo io, di librerie di base come Pandas o NumPy), Python è diventato anche il linguaggio di elezione di chi si occupa di machine learning e di analisi dei dati.

La crescita di Python sembra bloccata da un paio di anni, ma la sua enorme diffusione lo farà rimanere comunque un attore centrale anche nel prossimo futuro.

Entra in scena Swift

Fin qui tutto vero e condivisibile. Magari si potrebbe eccepire qualcosina sull’importanza di R nell’ambito dell’analisi dei dati, ma non voglio essere puntiglioso.

Il guaio è che se uno si limita a scrivere queste cose non se lo fila nessuno, chi vorrà mai leggere l’ennesimo articolo generico sulle virtù di Python per il machine learning (e non) o su quale linguaggio è destinato a soppiantarlo?¹ Ci vuole un colpo d’ala.

Per fortuna c’è sempre Apple che, come il nero, va bene su tutto e, soprattutto, garantisce sempre un bel po’ di click. E allora perché non mettere in mezzo Swift?

Swift è un linguaggio di programmazione sviluppato da Apple con l’obiettivo specifico di sostituire Objective-C come linguaggio di elezione per lo sviluppo delle applicazioni per iOS e per macOS. Swift è facile da imparare e la sua sintassi leggibile ricalca quella di Python, è vero, così come quella di Julia e di tanti altri linguaggi di programmazione moderni.²

Swift però non ha mai preteso di essere, come sostiene il nostro Ari, il nuovo “Re della Programmazione”. Ad Apple non interessa posizionare Swift come uno strumento di programmazione general purpose, le interessa solo che venga usato per programmare le applicazioni per i suoi sistemi operativi. Del resto, il fatto che manchi di una versione per Windows taglia fuori una fetta così importante di potenziali utenti da rendere impossibile a priori una pretesa tanto assurda.

A maggior ragione Swift non ha mai preteso di essere il nuovo strumento principe per il machine learning, come il buon Ari sotto sotto ci vuole far intendere. È vero che Google ha provato a supportare Swift all’interno di TensorFlow (di cui Google è il principale sviluppatore), ma questo esperimento, come succede con tanti altri prodotti dell’azienda di Mountain View, è stato interrotto nel 2021. È ragionevole pensare, infatti, che chi sviluppa in Swift preferisce usare gli strumenti per il machine learning integrati in macOS/iOS piuttosto che prodotti di terze parti.

Io sono più popolare di te

Ma la cosa più sconcertante è pretendere di confrontare la popolarità (o meno) dei linguaggi di programmazione utilizzando una metrica fasulla come la percentuale di domande poste ogni mese su StackOverflow relativamente ad uno o ad un altro linguaggio. In base a questa percentuale, la popolarità di Python è cresciuta costantemente fino alla fine del 2020, per poi stabilizzarsi al 16% del totale delle domande su StackOverflow, mentre quella di Swift dopo aver raggiunto un massimo del 3% è in declino e ora si aggira nei dintorni dell'1.5%.

Perché è una metrica fasulla? Perché finché siamo sui grandi numeri e confrontiamo la popolarità di Python con quella di JavaScript può anche avere senso basarsi sul numero di domande poste su StackOverflow per valutarne la diffusione.

Ma se buttiamo nel calderone anche la terna HTML, CSS e PHP, che sono ancora oggi tre strumenti fondamentali per chi fa sviluppo web, troviamo che questi ultimi sono in costante declino, senza però che la decadenza (su StackOverflow) di PHP venga compensata da un incremento corrispondente nell’interesse verso JavaScript.

Anche Wordpress, che piaccia o non piaccia sta dietro il 40% dei siti web, secondo la metrica di StackOverflow sarebbe in calo. Idem per MySQL.

E allora la spiegazione può essere un’altra: più che la diffusione, le domande su StackOverflow ci fanno vedere la complessità del linguaggio e la qualità della sua documentazione: HTML, CSS e PHP (o Wordpress e MySQL) sono prodotti ben assestati, per loro esistono ottime guide sul web che ne spiegano diffusamente i segreti. Di conseguenza non è necessario cercare risposte più o meno occasionali su StackOverflow, e comunque quelle che ci sono già bastano ed avanzano.

Python e JavaScript, al contrario, hanno una sintassi di base piuttosto semplice ma per essere usati al meglio hanno bisogno di un gran numero di librerie aggiuntive, che sono spesso più complesse del linguaggio base e che vengono aggiornate ed espanse di continuo. La documentazione relativa non tiene sempre il passo dello sviluppo, per cui il modo migliore per imparare ad usare al meglio le centinaia e centinaia di API disponibili è quello di rivolgersi a qualche esperto su StackOverflow, spingendo così in alto la popolarità dei due linguaggi.³

Secondo la logica basata sul numero di domande su StackOverflow anche C e C++, i linguaggi usati per la programmazione di sistema (e non) su Linux e Windows, sarebbero in declino, e lo stesso succede a concetti di base come algoritmo, architettura, classe o database. Ma sono in declino perché c’è davvero poco interesse o solo perché anche per loro c’è abbondanza di documentazione di ottimo livello, senza doversi ridurre a porre sempre delle nuove domande su StackOverflow?

Nel mio piccolo lo faccio anch'io: quando programmo in R uso pochissimo StackOverflow, perché posso usare l'ottimo help in linea di RStudio e perché la documentazione che accompagna le librerie aggiuntive di R è centralizzata sul [CRAN](https://cran.r-project.org/) (_The Comprehensive R Archive Network_) ed è di altissima qualità. E quando tutto questo non basta, posso trovare decine di siti e di blog che spiegano benissimo gli aspetti più ostici del linguaggio. Quando passo a Python (un linguaggio che, sia chiaro, mi piace parecchio), StackOverflow diventa quasi una necessità, perché la frammentazione e la mancanza di sistema di gestione centralizzata delle librerie di Python rendono molto più complicato trovare documentazione aggiornata di qualità.

Decaduto o semplice?

Swift è un linguaggio semplice con una ottima documentazione ufficiale, un eccellente strumento di apprendimento del linguaggio (e non solo) come Swift Playgrounds e un numero relativemente ridotto di librerie aggiuntive, c’è davvero bisogno di passare un sacco di tempo su StackOverflow per usarlo al meglio?

Guardando il grafico relativo al numero di domande relative a Swift ci si accorge che i picchi di interesse corrispondono alle date di presentazione della versione 1.0 (giugno 2014) e al rilascio delle versioni 2.0 (settembre 2015), 3.0 (settembre 2016) e 5.0 (marzo 2019) e, come è naturale, dopo ogni presentazione l’interesse tende a decadere, proprio perché per usare il linguaggio c’è davvero poco da chiedere su StackOverflow.

A supporto di questa tesi c’è il risultato di questa semplice query SQL, con la quale ho provato a calcolare il numero di domande poste su StackOverflow ogni anno. Di SQL ne so pochissimo per cui dovete prendere i risultati con le pinze, ma sembra che il numero di domande su StackOverflow sia in progressiva diminuzione, da un massimo di 2.2 milioni di domande nel 2016 a 1.6 milioni nel 2021.

Una volta raggiunta una base di conoscenza sufficientemente ampia non ha molto senso porre sempre delle nuove domande (che su StackOverflow sono fortemente scoraggiate) ma ci si può limitare ad utilizzare il materiale già esistente. Questo almeno per le tecnologie più stabili, come possono essere HTML, CCS, PHP, Wordpress, MySQL… oppure Swift. Quando invece abbiamo a che fare con strumenti in rapidissima evoluzione, come Python o JavaScript, StackOverflow diventa davvero il modo migliore per imparare.

Conclusioni

C’è bisogno di dilungarsi ancora? Non credo, dico solo che basarsi su ipotesi fantasiose o metriche poco affidabili per ipotizzare scenari catastrofici per Swift (o, al contrario, scenari entusiasmanti per Julia⁴) mi pare francamente insensato.

– Fonte: Dilbert di Scott Adams.

Capo: Non si possono confrontare mele e arance.

Dilbert: È chiaramente sbagliato, perché li hai appena confrontati e dichiarati diversi.

Wally: Mele e arance sono entrambi alimenti che crescono sugli alberi. Sarebbe assolutamente valido confrontarli dal punto di vista nutrizionale.

Dilbert: Ho notato che molte delle cose che escono dalla tua bocca non hanno senso.

Capo: Parli come mia moglie.

Wally: Non puoi paragonare tua moglie al tuo subordinato. Sono mele e arance.

Capo: Cosa sta succedendo qui?

Wally: Non lo so, ma non lo paragonerei a lavoro.

Ari sembra avere le idee un po’ confuse sul futuro di Python, dato che su Medium ha anche pubblicato Why Python is not the programming language of the future, oppure Bye-bye Python. Hello Julia! e perfino Why TensorFlow for Python is dying a slow death. ↩︎
E non è un caso, perché alla base di tutti questi linguaggi c’è sempre il buon vecchio BASIC, il primo linguaggio di programmazione davvero per tutti, che è stato il linguaggio di base dei computer personali degli anni ‘80 su cui si sono fatti le ossa tutti i grandi nomi dell’informatica di quegli anni. ↩︎
Le sole domande sulla libreria pandas di Python (una libreria fondamentale per chi usa Python per l’analisi dei dati) assommano al 3% del totale, le principali librerie per il machine learning (TensorFlow, Keras, PyTorch, scikit-learn, OpenCV, NLTK) fanno un altro 2%, mentre quelle su Django e Flask (le principali librerie Python per lo sviluppo di applicazioni per il web) sono quasi al 2.5% del totale generale. Chiaramente queste domande vengono anche conteggiate come domande relative a Python. ↩︎
Perché sì, l’interesse per Julia sembra essere in aumento su StackOverflow, ma parliamo di non più dello 0.16% (1/10 dei valori di Swift) e anche in questo caso i picchi corrispondono al rilascio delle varie versioni del linguaggio. ↩︎

Cronaca di un disastro: come sopravvivere alla pagina bianca di WordPress

Wed, 22 Jan 2020 06:00:00 +0000

Questo non è un post adatto per chi si spaventa facilmente. Se siete ansiosi o deboli di cuore fatevi un favore e non continuate a leggere.

Premessa

Quando si verifica un disastro in ambito informatico (e non solo) la cosa più importante è non perdere mai la calma. E poi non bisogna avere fretta di rimettere le cose a posto, meglio riflettere prima di agire. Naturalmente avere un backup aggiornato a disposizione aiuta sempre moltissimo.

Tutte le volte che ho dovuto affrontare un disastro di tipo informatico – e fra casi personali, amici e conoscenti succede relativamente spesso – queste linee guida sono sempre state utilissime per risolvere il problema. L’ultima volta, però, una installazione di WordPress andata completamente in tilt ha messo a durissima prova la mia pazienza, oltre che le mie conoscenze tecniche. Ecco il racconto di quello che è successo.

Una giornata particolare

Oltre a questo blog, amministro da anni Il nostro CNR, un sito finalizzato alla discussione di tematiche relative al mondo del CNR e della ricerca in generale. Come melabit, anche Il nostro CNR è basato su WordPress. Il sito è piuttosto popolare, ha un discreto numero di visualizzazioni giornaliere, purtroppo sono sempre troppo pochi quelli che hanno la voglia e la pazienza di intervenire sul forum. Ma questo è un male tipico degli italiani, bravissimi a discutere animatamente al bar (verba volant…), ma molto meno propensi a mettere per iscritto quello che pensano, magari per paura di ritorsioni (…scripta manent ).

Poco prima di Natale Corrado Zunino, un giornalista di Repubblica sempre molto attento ai problemi della ricerca, pubblica un articolo in cui rivela che la procedura di elezione del rappresentante del personale nel CdA del CNR, conclusa un mese prima, potrebbe essere stata viziata da brogli. Il rappresentante eletto alla tornata precedente era stato una vera e propria spina nel fianco per la dirigenza del CNR e, non pago di quattro anni di fatiche e sacrifici anche personali, aveva deciso di ripresentarsi per un secondo mandato, con ottime possibilità di successo. Toglierlo di mezzo e sostituirlo con qualcuno meno rigido e competente era quasi una necessità.

Subito dopo aver letto l’articolo su Repubblica decido di diffonderlo tramite Il nostro CNR. Del resto, dopo la trasmissione di Report del marzo 2017 che ha rivelato la lunga serie di ruberie avvenute in un istituto del CNR (di certo non l’unico) e ancora di più dopo l’arresto dell’ex-direttore del CNR e dei suoi sodali, nel nostro ente l’interesse per queste vicende ripugnanti è altissimo.

– Fonte: Il Mattino, 20 novembre 2019.

Aggiornamenti inattesi

Entro quindi in quello che è un po’ il retrobottega del sito, la cosiddetta dashboard, l’interfaccia di gestione dei contenuti e delle funzionalità di WordPress, per scrivere un post sulla notizia di Repubblica e come al solito trovo alcuni plugin da aggiornare (i plugin sono dei pezzetti di codice che estendono le funzioni del sito). Succede praticamente ogni volta che accedo alla dashboard, e senza pensarci più di tanto clicco sul pulsante di aggiornamento. È una procedura assolutamente sicura e comunque, anche se uno dei plugin non dovesse più funzionare bloccando il resto del sistema, mi basterebbe modificare i nomi di qualche file per disattivarlo e recuperare la piena operatività del sito.

Questa volta invece, per qualche motivo incomprensibile, insieme all’aggiornamento dei plugin parte anche l’aggiornamento dell’intero codice di WordPress dalla versione 4.x all’ultima versione disponibile, la 5.qualcosa. Aggiornamento che per tanti motivi non volevo ancora fare, e soprattutto che non avrei mai fatto senza prima eseguire un backup affidabile di tutto il sito.

Non riesco ancora a capacitarmi di cosa possa essere successo, ma sono sicuro al 100% di non averlo fatto io stesso per errore. I pulsanti per aggiornare i plugin o il codice di WordPress sono ben distinti e non possono essere premuti contemporaneamente (lo vedete qui sotto), e poi ricordo benissimo di aver letto i messaggi che elencavano i plugin in corso di aggiornamento. Ma, quando alla fine del processo ho cliccato per tornare alla pagina principale, ho visto partire anche l’aggiornamento del codice di WordPress, e a quel punto non potevo più far niente per interromperlo.

È possibile che l’aggiornamento del codice sia partito da solo per qualche baco di Wordpress o di un plugin, del resto i bachi del software sono inevitabili. Una cosa seccante, ma ancora niente di preoccupante.

Un backup è per sempre?

Una volta concluso l’aggiornamento non voluto di WordPress, apro una nuova scheda del browser per controllare cos’è successo al sito. Compare solo una pagina completamente bianca. Il sito in effetti funziona ancora, ma non carica correttamente le pagine, e anche la dashboard appare completamente vuota. Per fortuna i file che costituiscono il sito ci sono ancora tutti, e anche il database usato da WordPress per memorizzare i dati variabili del sito è ancora al suo posto.

Un sito web dinamico come WordPress è costituito in genere da due componenti ben distinte: la prima comprende tutti file che costituiscono il sito web vero e proprio e che vengono modificati di rado, in particolare il codice WordPress e le personalizzazioni dell'utente, i plugin, i temi grafici, le immagini e tutti i documenti collegati alle pagine del sito (questa componente sarà denominata da ora in poi "file del sito" o semplicemente "sito"). La seconda componente è costituita da un database nel quale vengono memorizzati i dati variabili del sito, fra cui i testi degli articoli e degli interventi sul forum, le informazioni relative agli utenti registrati, i dati di accesso e moltissimo altro.

Quando succedono queste cose nel 99% dei casi la colpa è di qualche plugin che funziona male o non funziona affatto. Non c’era del resto da stupirsi, uno dei motivi per decidere di non aggiornare alla versione più recente di WordPress era legato proprio al fatto che almeno due plugin piuttosto importanti non erano ancora stati aggiornati per funzionare con le nuove versioni di WordPress e di PHP, il linguaggio di programmazione per il web con il quale è sviluppato WordPress.

Per correggere il problema della pagina bianca ci sono sostanzialmente due metodi: il primo richiede di disattivare i plugin uno ad uno, fino a scoprire quello che non funziona. Richiede ore ed ore di lavoro certosino e non avrebbe comunque risolto il problema dell’aggiornamento indesiderato del sito. Nonostante tutto, ho provato a disattivare i due, tre plugin più critici ma non cambiava niente.

Il secondo metodo prevede di ripristinare il sito da un backup recente e, in questo caso specifico, ha l’enorme vantaggio di poter tornare alla versione precedente di WordPress. E dato che il provider scelto per ospitare il sito fa un backup ogni ora, mi sembrava più che naturale scegliere la seconda soluzione.

Ed è qui che sono cominciati i guai.

Apro un ticket, cioè una richiesta di supporto tecnico, presso il provider e chiedo come ripristinare il sito da un backup eseguito intorno alle 9 del mattino, ora alla quale ero sicuro di non aver fatto ancora niente. Purtroppo non posso fare da solo, l’assistenza tecnica mi avvisa che la procedura di ripristino del database di WordPress deve essere effettuata dal provider, altrimenti dà errore.

Ovviamente li lascio fare, indicando il backup da ripristinare, il #687 eseguito alle 8:53, e ribadendo che volevo un ripristino totale, pulito, sia del sito che del database su cui si appoggia (la conversazione qui sotto, così come tutte le conversazioni successive, vanno lette dal basso verso l’alto).

Non funziona, anzi è peggio, i file del sito sembrano a posto, ma il database viene ripristinato solo in parte e quindi in pratica non serve a niente.

Intanto mi sono fatto dare l’intero backup del sito e del database delle ore 8:53 in formato standard e in questo backup il database sembra completo. Però ogni volta che l’assistenza tecnica prova a ripristinarlo la procedura fallisce. Secondo loro perché il database è corrotto, secondo me perché la loro procedura di ripristino non funziona bene.

Provo allora a chiedere il ripristino da un backup di un paio di giorni prima, ma non cambia niente. È già passato un giorno, il sito è ancora giù e io faccio una pessima figura con i colleghi che lo frequentano.

Andare sul cloud

A questo punto decido di lasciar perdere l’assistenza tecnica e di fare da solo, usando il backup del sito e del database che mi sono fatto dare per ricostruire il sito da zero. Potrei usare come al solito una macchina virtuale, dove installare una versione server di Linux con tutto quello che serve per far funzionare WordPress, ma questa volta preferisco di andare sul cloud in modo da poter lavorare, se serve (e servirà molto spesso!), anche da casa.

Scelgo AWS Cloud9 di Amazon, funziona bene, costa poco e mi sembra più affidabile di altri servizi che ho usato in passato, come Codeanywhere, Koding o Pilvia, che cambiano continuamente modello di business. Accedo al mio account e creo una nuova istanza di AWS Cloud9, dove installo la versione 18.04/Bionic LTS di Ubuntu Linux.¹

Potrei scegliere anche Amazon Linux, una versione di Linux specifica per Amazon AWS e basata su RedHat e CentOS, ma preferisco andare sul sicuro, in fondo Ubuntu deriva sempre da Debian, e nel mondo Linux non c’è niente di meglio di Debian.

Tralascio i dettagli dell’installazione di tutto quanto serve per far funzionare WordPress su Linux (ma se richiesto potrebbe essere argomento di un prossimo articolo). Il server web Apache, il linguaggio di programmazione PHP e il sistema di database relazionale MariaDB,² sono già installati di default in Ubuntu LTS, si tratta solo di configurare opportunamente tutto per girare su AWS Cloud9 e di creare il database per WordPress. Già che ci sono, installo anche phpMyAdmin, un programma comodissimo che permette di gestire un database MySQL (e quindi anche MariaDB) tramite una interfaccia web.

A questo punto basta scaricare il codice di WordPress ed effettuare la famosa installazione in 5 minuti per essere a posto.

Beh, magari fosse così semplice! Tutto quello che ho in questo momento è un sito funzionante ma vuoto, invece a me serve ripristinare tutto il contenuto de Il nostro CNR.

Per farlo, sostituisco i file del sito e il database di WordPress con quelli contenuti nel backup fornito dal provider. Sembra difficile, ma avendo pieno accesso al terminale di Linux ed essendo l’amministratore onnipotente del sistema su cui gira WordPress diventa un gioco da ragazzi. Riavvio MariaDB ed Apache per fargli rileggere i nuovi dati su cui operare, ma non funziona.

Naturale, il database contiene l’indirizzo web (URL) del sito originale, https://ilnostrcnr.it, ma ora sono su Amazon AWS e l’URL del sito che ho creato è completamente diverso, è qualcosa tipo https://b0ef0914612e145f8fad9237c0dabd8a.vfs.cloud9.us-east-2.amazonaws.com. Non ho intenzione di combattere con i DNS o il file hosts, per cui entro nel database con phpMyAdmin, seleziono la tabella wp_options e sostituisco l’URL originale contenuto nei record siteurl e home con quelli forniti da Amazon AWS.

Riavvio di nuovo MariaDB ed Apache e finalmente il sito torna a vivere. Con phpMyAdmin controllo se il database ha degli errori, e in effetti ci sono, ma niente di così grave che possa impedirne il ripristino (e del resto a me funziona tutto perfettamente).

A questo punto è quasi routine, ed è anche l’occasione per dare una bella rinfrescata alle funzionalità del sito. Entro nella dashboard e rimuovo il plugin All-in-One WP Migration, che usavo per fare i backup personali del sito ma che che non è compatibile con le ultime versioni di PHP 7.x, e cancello dal terminale la directory relativa. Rimuovo anche il plugin Count per Day, ottimo per analizzare le statistiche di accesso al sito ma che non è aggiornato da un anno e non è stato testato con le versioni più recenti di WordPress. E dato che ha violato le linee guida di WordPress è stato pure rimosso dall’archivio (repository) ufficiale dei plugin di WordPress.

Controllo di nuovo il database usando sia una funzione seminascosta di WordPress³ che il solito phpMyAdmin ed ora è tutto a posto, dopo la rimozione dei due plugin problematici anche gli errori del database sono scomparsi.

Ritorno al provider

A questo punto mi rimane solo da fare un backup del sito e del database, che il provider potrà usare (o meglio “dovrà usare”, visto che finora non ha fatto niente di significativo) per ripristinare il sito originale.

Ma la cosa si rivela più difficile del previsto e l’interazione fra il supporto tecnico e me sembra un dialogo fra sordi,

che sfocia rapidamente nella incomunicabilità totale. Il sito è giù da ben 11 giorni ma al servizio tecnico importa pochissimo. Inutile provare ancora a ricevere un supporto degno di questo nome.

Prima di tagliare i ponti con il servizio tecnico ho preparato un Piano B. Ore di ricerche sul web mi hanno fatto trovare Duplicator, un plugin che sembra perfetto per le mie esigenze. In apparenza è uno dei soliti plugin di backup/ripristino di una installazione di WordPress, che alla fine richiedono sempre l’acquisto della versione Pro per essere davvero utili. Duplicator invece è diverso, la versione Pro aggiunge delle funzioni molto interessanti per chi gestisce dei siti web per professione, ma la versione base gratuita fa tutto quello che mi serve, è solo leggermente più complicata da utilizzare.

In previsione del piano B ho già provato a fondo Duplicator, usandolo per fare un backup completo del sito e per ripristinarlo in una nuova istanza di AWS Cloud9, e funziona in modo spettacolare. Mi piace soprattutto il fatto che lavori a bassissimo livello, sembra quasi di usare il terminale, che è poi quello che farei io stesso se il provider mi concedesse un accesso pieno e senza limitazioni via ssh al mio sito e soprattutto al database associato.

Entro quindi nel pannello di controllo del mio sito web e di tutti i tool collegati, il notissimo cPanel, cancello tutti i file del sito e anche il database che ha creato tanti problemi, e già che ci sono aggiorno PHP alla versione 7.2, la stessa versione disponibile in AWS Cloud9. Mi tremano un po’ i polsi, da ora in poi se sbaglio non posso più tornare indietro, ma ho delle alternative migliori?

A differenza degli altri plugin di backup/ripristino che conosco, Duplicator non ha bisogno di una installazione preesistente di WordPress per funzionare, ma insieme al backup del sito genera un programma in PHP che effettua da solo il processo di ripristino del sito e del database associato. Anche l’URL che ho modificato a mano diretatmente nel database vengono aggiornati correttamente. Bastano pochi minuti e il sito torna a vivere.

È il 2 gennaio, sono passati ben 14 giorni dal disastro.

Conclusioni

Quando dicevo all’inizio che la lettura di questo articolo non è adatta a chi si spaventa facilmente o è ansioso, stavo scherzando, ma non troppo. Questa esperienza ha davvero messo a dura prova le mie capacità tecniche, nonché la mia pazienza nell’interagire con chi dovrebbe fornire un supporto tecnico decente.

Ma dopo un paio di giorni era diventata una sfida personale, una specie di esame fuori tempo massimo, sei capace di risolvere questo problema difficile? E poi, naturalmente, c’era la necessità di non fare brutta figura con tanti colleghi…

Ovvio che alla scadenza del contratto bisognerà cambiare provider, tutto sommato questo finora non è stato male, ma finché va tutto bene sono buoni tutti, le differenze si vedono solo quando il gioco si fa duro. Avevo già pensato di farlo per altri motivi, ma il dover traslocare il sito su un’altro spazio web mi preoccupava un po’. Ora, con l’esperienza che mi sono fatta, sarà uno scherzetto.

A differenza delle versioni normali di Ubuntu Linux, che vengono rilasciate ogni sei mesi, le versioni LTS, Long Term Support, vengono rilasciate solo nella primavera degli anni pari e sono particolarmente indicate per un sistema server. ↩︎
MariaDB è un derivato (fork) del notissimo database MySQL, prodotto dagli sviluppatori originali di MySQL e compatibile praticamente al 100% con la versione corrispondente di MySQL. L’origine del fork sta nell’introduzione da parte di Oracle, che nel 2010 ha acquisito la ormai decaduta Sun Microsystems con tutto il suo parco software fra cui Java e proprio MySQL, di estensioni proprietarie disponibili solo per la versione a pagamento di MySQL. ↩︎
Bisogna aggiungere nel file wp-config.php la riga define('WP_ALLOW_REPAIR', true);, andare all’URL di amministrazione YOURSITE.com/wp-admin/maint/repair.php (dove YOURSITE.com deve essere sostituito con l’indirizzo web del sito) e seguire le istruzioni. ↩︎