Come ottimizzare un sito in WordPress ad alto traffico senza CloudFlare (la guida definitivah!1!)

È un periodo in cui sto popolando la mia categoria Articoli che piacciono ad Aranzulla. Oggi è il turno di una guida la cui trama è tratta da una storia vera.

Visualizziamo il caso dell’edizione in lingua italiana di Wikipedia. Genera un traffico di duecentosettantamila visite all’ora. Anzi, prendiamo anche quella in lingua inglese. Vanta circa quattro milioni di visite all’ora. Non so se mi spiego. Quattro milioni. Ma non basta. Prendiamo pure tutte le duecentonovantasei dannatissime edizioni linguistiche di Wikipedia, insieme a tutte le diciotto edizioni linguistiche di Wikiversity, e non fatemi contare le edizioni linguistiche di Wikivoyage, Wikibooks, Wiktionary, Wikiquote, Wikisource, senza dimenticare Wikimedia Commons e Wikidata.

Non so se riusciamo ad immaginare sedici miliardi di accessi al giorno.

Ora immaginate che siate voi i possessori di un sito di (relativamente) insignificativa visibilità (con tutto il rispetto per il vostro tema, ma di fronte allo scenario che stiamo immaginando siamo tutti dei peti al vento). Anche se magari avete davvero la bellezza di venti visite l’ora (di cui solo 2 di nostra madre!). Immaginiamo poi che domani il vostro sito sia promosso con un banner bello GROSSO in cima ad OGNUNO di quei siti enumerati precedentemente, esponendovi alla pioggia di centinaia di migliaia di accessi simultanei.

Che fate?

Per non saper nè leggere nè scrivere avremo tutti fatto due conti. Se anche a voi risulta che sono centinaia di migliaia le possibilità di prenderselo nel culo, allora capirete i miei sudori freddi quando dirò che tutto questo è successo davvero (o meglio, sta succedendo proprio ora).

Sì, perchè il sito in questione è Wiki Loves Earth; i proprietari del dominio sono una piccola e tenera associazione culturale di miei amichetti (Informazioni.Wiki). Il motore del sito è WordPress. Il server è il mio. E sì, la Wikimedia Foundation ha ficcato un bannerone su ogni suo sito, come ad ordinare alla gente di prendere a calci nel culo tale sito.

CPU addormentata. E la macchina fa schifo. Tutto funziona.

Contrariamente ad ogni mia aspettativa siamo riusciti a gestire la situazione. Alla grande. Direi che è stata una passeggiata. Probabilmente grazie al fatto che la gente non clicca sui banneroni in alto nei siti, i numeri sono stati inferiori alle aspettative, con appena 11-15 mila accessi al giorno. Circa 500 visite ogni ora. Il che non è tantissimo ma non è nemmeno poco.

Questo grafico è tratto dalla nostra istanza Matomo (perchè nel 2019 siamo sufficientemente evoluti per fare statistiche senza inculare la privacy dei visitatori con Google Anal-ytics). Possiamo notare la linea blu che rappresenta la pace prima della tempesta, nella prima parte del grafico, con circa un centinaio di accessi al giorno. Ad un certo punto, BOOM, 11.000 accessi al giorno. Ora guardiamo la linea verde. È il generation time. In teoria, più hai visite, più metti sotto sforzo la macchina, più il generation time aumenta. Noi lo abbiamo fatto calare facendo tuning ogni giorno. È sempre sceso, arrivando ad abbattersi da circa 6 secondi ad un molto più gestibile 0.2 secondi.

Da questa storia ho imparato che:

  1. È sufficiente partire da questa guida definitiva per velocizzare WordPress!1!
  2. Ridurre al minimo le risorse in ogni pagina a qualsiasi costo ripaga moltissimo
  3. Adotta cache lato webserver con mod_cache o Varnish o chi per esso ed elimina qualsiasi strato di cache lato applicativo (dato che questi ultimi sono scritti da indiani, coi piedini)
  4. Se usate Apache, ovviamente disabilitate AllowOverride e tutte le altre merde inutili. Ora. Subito. Fate tuning di qualsiasi cosa.
  5. Testa tutto con Apache Benchmark o amici simili. A/B. Prima dopo. Flip flop. Fallo e sarai ripagato.
  6. A quanto pare la gente non clicca sui banner. Quindi se ti linkano da ogni progetto della Wikimedia Foundation non è da vedersi come terrorismo.

Qualche dritta su mod_cache

Come funziona mod_cache? Esso arnese salva su disco le risposte dell’applicativo e le consegna alle visite future. Questo abbatte drasticamente i tempi di generazione della pagina. I parametri di default vanno bene per la maggior parte dei casi. Non vengono messi in cache i file troppo piccoli, i file troppo grossi, i file richiesti via POST, etc. Addirittura la vostra distribuzione GNU/Linux se non fa schifo abiliterà da sola il demone apache-htcacheclean che pulirà la cache vecchia (o almeno così avviene in Debian GNU/Linux).

Infatti, mod_cache è una pezza di software abbastanza rispettabile che fa il suo sporco dovere, e bene, se l’applicativo soddisfa una serie di banalità, tipo spedire correttamente header HTTP Expires, preferire richieste stateless evitando le sessioni, usare GET solo per richieste idempotenti, etc.

Chiaramente la maggior parte dei CMS fa soltanto una di queste cose, se non nessuna.

Dovrete girare intorno a tutte le lacune dell’applicativo ed istruire voi mod_cache. Ad esempio, mod_expires viene eseguito prima di mod_cache quindi potete usarlo per sopperrire alla mancanza di Expires dell’applicativo. Potete istruire mod_cache per saltare il caching di richieste che iniziano con /admin-stacippa. Forse dovrete anche evitare che vengano messi in cache le richieste che hanno header quali Cookie e Set-Cookie, etc.

Problemi noti

Se dopo l’abilitazione di mod_cache emergono subito artefatti allucinanti, ad esempio se il visitatore vede la stessa pagina per tutti gli URL, allora vi risparmio le bestemmie: è colpa di mod_rewrite.

WordPress, infatti, usa mod_rewrite. Lo capite subito se lo usa se avete un sito con URL fighetti tipo /2019-09-05/bao invece che un meno SEO-sexy ?p=666.

Questo funziona perchè a monte avrete sicuramente una regola del genere di mod_rewrite:

RewriteRule . /index.php [L]

Questa regola pesca qualsiasi indirizzo e risponde con l’output di index.php. Il che è sensato ma per mod_cache comporterà un bel casino dato che, per ragioni su cui non ci è dato polemizzare, mod_cache avviene dopo mod_rewrite; e dato che la cache è salvata ovviamente sulla base dell’URL, questo significa che state mettendo in cache una sola pagina per tutte le richieste, perchè /welcome/ diventa /index.php e /about diventa /index.php etc.

Prima di passare a Varnish (asd) potete sfruttare questo mio workaround partorito durante una generosa seduta al bagno pensando immensamente a quanto fosse stimolante mod_cache. Fra l’altro posso asserire con una vaga certezza che sia una mia idea, anche perchè c’è solo un altro tizio sul web che fa così ma in una domanda sgrammaticata e con una risposta che manco spiega il funzionamento. asd).

Ecco la variante:

RewriteRule ^(.*)$ index.php/$1 [L]

Funziona, perché /welcome/ diventerà un innocuo /index.php/welcome.

Perchè la richiesta `/index.php/welcome` dovrebbe essere lecita se quel file non esiste? Ottima domanda! Qui ti volevo. Funziona, perchè nel tuo webserver avrai attiva di default una delle mie direttive di Apache preferite, una di quelle che non conosce nessuno, ma proprio nessuno, ma, ripeto, è attiva in tutti i webserver del pianeta. Di default. In tutti. asd.

Parliamo di AcceptPathInfo. Se conosci questa direttiva significa che sei l’anticristo in persona e puoi vantarti di visitare indirizzi senza senso ottenendo una risposta valida. Esempio:

https://www.facebook.com/index.php
https://www.facebook.com/index.php/melone-prezzemolato

Come vedete, è una direttiva talmente sfigata che manco Facebook sa di averla, altrimenti l’avrebbe disabilitata o avrebbe impostato un reindirizzamento o dichiarato un URL canonico, cosa che al momento non fa (quindi potremmo avvelenare i loro risultati di ricerca linkando termini a caso su URL esistenti con termini a caso dentro! che bello. asd).

Va beh, torniamo a noi.

Funziona, perchè la concatenazione di una directory ad un file esistente provoca l’accesso a quel file. L’URL di eccedenza (e.g. “melone-prezzemolato“) viene passato sotto banco allo script all’interno della variabile d’ambiente PATH_INFO.

In sostanza: fate in modo che agli occhi di mod_cache siano sempre tutte richieste differenti. Al contrario, per l’applicativo il meccanismo di caching deve rimanere del tutto trasparente. Notare che se l’applicativo non fa uso del PATH_INFO non farete danni nell’usare il mio workaround (come per WordPress); invece chi lo usa (come Joomla!-merda) allora semplicemente questo problema non se lo porrà perchè ogni URL sarà già univoco (affinchè non sembri che stia promuovendo Joomla!-merda, vorrei ricordare che ha una terribile gestione dei permalink e quindi avrete ben altri problemi tipo contenuti centuplicati su indirizzi a caso. Se non si fosse capito, non usate Joomla!-merda. Che fra l’altro è l’unico CMS famoso NON pacchettizzato per le principali distribuzioni GNU/Linux, talmente fa schifo.)

Concludendo

Cloudflare è per pigri. Anche un po’ per rincoglioniti. Voglio dire, c’è una rispettabile fetta di utenze di Cloudflare e di altri firewall e CDN, diciamo forse l’1% dei loro utenti, che effettivamente potrebbe meritare i servizi di Cloudflare, o di altri, poichè lo userebbero col senno dell’impossibilità di farselo in proprio per mancanza di risorse. Per il resto, mi rendo conto che centralizzare il web verso un unico fornitore di servizi possa sembrare una genialata.

Fatevi da soli un server di caching. Fatevelo fare. Ma fatevi qualcosa in proprio. Se ce l’ho fatta io, che all’asilo la mia referenza era di fare denial of service dei bagni intasandoli con la carta igienica (senza pensare a mod_cache, fra l’altro) ce la fa chiunque.

A disposizione per chi interessassero ulteriori dettagli, però, principalmente, per entrare nello spirito giusto, basta partire dalla guida definitiva per velocizzare WordPress.

Il mio intervento a Border Radio – Public Domain

Rubando termini dall’oroscopo: in questo periodo lavoro, famiglia e persino riposo vanno discretamente bene. Questo significa che ho dovuto limitare le mie evasioni davanti alla mia scrivania, soprattutto nei momenti a me più proficui, ovvero dalle 20 alle 3 del mattino (non che sia una fascia oraria che oggettivamente stimoli le cellule grigie ma, semplicemente, a quell’ora è più complicato essere distratti da qualcuno di sveglio ed è più naturale rilassarsi, concentrarsi, essere produttivo).

Ospite in una puntata radiofonica di Border Radio a proposito di Wikipedia, spero di essere riuscito a trasmettere tutta la mia passione su questo progetto, nascondendo piuttosto bene il mio rammarico nel vedere ridotti i miei contributi, sfociati, nello stesso periodo, nelle mie dimissioni da amministratore dell’interfaccia.

Che dire, buon ascolto!

Podcast puntata Public Domain a Border Radio

Ah, chiedo venia per le imprecisioni o castronerie sfuggitemi (per chi le notasse). Come scusa additerò l’ansia della diretta!

Come velocizzare WordPress (LA GUIDA DEFINITIVA!1!1!)

Disattiva i tuoi plugin.
Fine della guida.

OK OK…. Immagino avrai bisogno di qualche metafora per carburare questo fatto. Visualizza questo scenario: ogni plugin che hai installato compromette di almeno il 30% tutti questi punti, parallelamente:

  • sicurezza
  • performance
  • manutenibilità
  • libertà digitale

Perchè? Perchè la maggior parte di essi sono stati scriti coi piedi. È come se vi foste fatti costruire la casa da un bambino a cui abbiano dato in mano un’accetta per realizzarla e il disegno di una casa a pastelli per progettarla. È come avere in mano la ricetta di un’insalata scritta da un avvocato societario utilizzando l’autocorrettore di un telefono che conosca solo formule di fogli di calcolo. È come se qualcuno avesse trascritto il litigio di una coppia all’IKEA facendo modifiche a caso finchè quel testo non diventasse un programma che compilasse senza errori. È come se qualcuno avesse dato in pasto la foto di un tabellone di Scarabeo ad un software di visione computerizzata in cui valgono triplo le parole riservate in JavaScript. È come se qualcuno avesse trascritto le previsioni meteorologiche navali nello stesso momento in cui un picchio di legno martellava sul tasto shift e in seguito indentasse il testo completamente a caso. È come se una poesia dadaista e/o surrealista fosse stata composta interamente con quei nomi utente suggeriti durante la registrazione in un sito, quando quello che volevi è stato già preso. È come se aveste in mano l’output di bot per calcolare catene di Markov istruito esclusivamente sulla base dei passaggi dei pullman di una città in cui i pullman si schiantano di continuo.

Mi correggo. Se tutto questo funziona, quegli autobus non si schiantavano: prendevano fuoco.

I plugin che hai installato sono un tentativo di scrivere un poema lirico utilizzando solo parole provenienti da quella roba che sta negli URL dopo il punto interrogativo. È come una tabella in JSON di codici di modelli di torce che devono avere “super tattica” nel nome. È come se gli sviluppatori avessero letto soltanto un articolo accademico di Turing del 1936 sulla computazione e altresì un esempio di codice JavaScript e avessero tirato ad indovinare tutto lo scibile che sta nel mezzo. È come la traduzione in linguaggio l33t di un manifesto di un culturista della sopravvivenza che per qualche ragione è ossessionato anche dall’allocazione di memoria.

Disinstalla quei fottuti plugin o fatteli riscrivere da zero. Sul serio. Sono scritti col culo e compromettono il tuo sito.

Fine della guida.

Grazie ad XKCD 1513, XKCD 1695 e ad XKCD 1883 per l’aiuto metaforico. asd

Ci stanno tracciando… staccah staccah!

Questa immagine scattata da Cristiano Paris al Lucca Comics è l’essenza stessa di una eccezionale discussione svolta su Wikipedia. asd:

Discussione su Hackerino in Wikipedia.

Immagine completa di Cristiano Paris.

Immagine scattata da Cristiano Paris e distribuita in licenza Creative Commons Attribuzione – Condividi allo stesso 4.0 internazionale.

La bellezza delle espressioni regolari (aka: correggendo bgcolor in Wikipedia)

Non so se l’avessi già detto ma amo perdere una consistente quantità di tempo su Wikipedia in lingua italiana. Appena posso lo faccio. È rilassante e stimolante. Ritaglio del tempo soprattutto per svolgere i task più inutili che mi auto-assegno con gioia per sentirmi in pace con me stesso nello sfuggire agli impegni più seri.

Oggi mi sono imbattuto ad esempio in una voce Wikipedia che aveva una semplice tabella con uno sfondo colorato. Colorata con bgcolor.

Non è che tutti dovrebbero sapere che l’HTML si è evoluto giusto un briciolo dalla sua nascita e che roba come bgcolor non si dovrebbe più usare almeno da HTML 4 ovvero almeno dal 1999. Diciamoci la verità, l’ho sempre sospettato, ma manco io avevo la certezza che fosse un attributo deprecato prima di scoprire che la voce [[HTML 4]] non aveva fonti e prima di giungere quindi alle specifiche W3C per pura serendipità. asd

In sostanza, facendo una rapida ricerca, circa un migliaio e mezzo di articoli di Wikipedia ad oggi usavano ancora bgcolor.

Ora, è chiaro che se quasi 1500 voci di Wikipedia hanno una tabella colorata con bgcolor e se ogni browser del pianeta (tranne Internet Exploder) mostra correttamente questo colore, significa che non c’è proprio nessuna fretta a correggerlo. Certo però che un giorno questa migrazione sarà da fare. Un giorno.

Ora sapete il perché ciò mi abbia allettato.

In teoria una sostituzione del genere appare piuttosto semplice. In fondo bisogna solo trovare nel testo della pagina tutto ciò che assomigli a questo:

<td bgcolor="#ff0000"></td>

E trasformarlo in questo:

<td style="background:#ff0000"></td>

Ma i casi da tenere in considerazione sono almeno questi:

<td bgcolor="#ff0000"></td>
<td bgcolor="#f00"></td>
<td bgcolor="ff0000"></td>
<td bgcolor=ff0000></td>
<td bgcolor="f00"></td>
<td bgcolor  = "red"></td>

Senda dimenticare che una becera sostituzione potrebbe provocare attributi style doppi ove ve ne fosse già uno:

<td bgcolor="red"     colspan="2" style="color:blue;">
↓
<td style="color:red" colspan="2" style="color:blue;">

Tagliando corto dopo un’oretta buona ecco qui una casseruola di espressioni regolari che lanciate in sequenza effettuano la corretta conversione di parecchi di questi casi:

1. Una prima sostituzione di tutti i vari colori esadecimali scritti ahimè senza cancelletto davanti tipo bgcolor="ff0000" e che il bot non deve confondere con bgcolor="red" o altri nomi propri che non vogliono il cancelletto davanti:

# Ricerca:
/bgcolor *= *("?)([a-fA-F0-9]{6}|[a-fA-F0-9]{3})+\1/
 
# Sostituzione:
style="background:#$2"

Notare l’utilità dell’operatore \1 nella ricerca per riferirsi al primo apice che può esserci o meno.

2. Segue una sostituzione di tutti i vari colori esadecimali con cancelletto davanti e quelli dal nome specifico:

# Ricerca
/bgcolor *= *("?)(#[a-z0-9A-Z]{6}|#[a-zA-Z0-9]{3}|[a-zA-Z]{3,})+\1/
 
# Sostituzione
style="background:$2"

3. Per sfizio a questo punto uno potrebbe anche decidere di accorciare tutti i colori dal formato #aabbcc a #abc:

# Ricerca
/#([a-fA-F0-9])\1([a-fA-F0-9])\2([a-fA-F0-9])\3"/
 
# Sostituzione
#$1$2$3"

Notare sempre l’uso dell’operatore \1, \2, \3 per dire che un gruppo sarà ripetuto un’altra volta subito dopo.

4. A questo punto ci si potrebbe ritrovare con un tag HTML con due style come in questa situazione, e che dovranno essere uniti in qualche modo:

<td bgcolor="red"                colspan="2" style="color:blue;"></td>
↓
<td style="background-color:red" colspan="2" style="color:blue;"></td>

E quindi si lancia un’altra espressione regolare per unire tutti gli style presenti nello stesso tag (questa è tenera asd):

# Ricerca
/style="([a-zA-Z0-9-; #:%]+?);?"((?: +[a-zA-Z]+ *= *("?)[a-zA-Z0-9-; #:%]+\3)*) style="([a-zA-Z0-9-; #:%]+?);?"/
 
# Sostituzione
style="$1; $4"$2

Notare il doppio-gruppo innestato (?:()*) in mezzo ai due style. Qui il gruppo centrale è ripetuto da zero ad infinite volte e non deve avere nome (altrimenti si entra in altre dimensioni… asd) mentre il gruppo esterno colleziona queste ripetizioni interne e le salva in $2. Quindi se si ha la situazione:

style="uno" roba=asd pippo="gianni" style="due"

Questo sarà il valore della cattura in $2:

roba=asd pippo="gianni"

E quindi avverrà questo magico accorpamento dei due style, mantenendo il resto del ciarpame:

<td style="background-color:blue;" colspan="2" rowspan=1 style="color:red">
↓
<td style="background-color:blue; color:red" colspan="2" rowspan=1>

Notare che ci si è presi lo scrupolo di non far venire ;; nel concatenare le due proprietà CSS o di dimenticarsi proprio ; nella loro congiunzione.

D’altra parte se fin’ora abbiamo acchiappato e convertito i bgcolor ora questo processo dovrà essere ripetuto per color, valign, align ed altre cose, più o meno in quest’ordine. Perché in quest’ordine? Perché il color va sostituito dopo aver sostituito eventuali bgcolor, perché bgcolor può essere frainteso come color e se non avete voglia di piazzare un lookahead per decidere quando inizi il nome di un attributo HTML… insomma, bisogna considerare l’ordine.

C’è anche da dire che finché si sostituisce solo un singolo attributo come bgcolor si rischia al massimo di creare due style e questo problema è risolto con la sostituzione appena citata. Al contrario se gli attributi iniziano ad essere n occorrerà lanciare n volte l’espressione numero 4 affinché passo dopo passo tutti gli style si vadano ad inglobare passaggio dopo passaggio:

<td bgcolor=red color=red valign=left colspan="1" style="padding:1px">
↓
<td style="background:red" style="color:red" style="vertical-align:left" colspan="1" style="padding:1px">
↓
<td style="background:red; color:red; vertical-align:left" colspan="1" style="padding:1px">
↓
<td style="background:red; color:red; vertical-align:left; padding:1px" colspan="1">

(Come fai ad essere già qui? asd. Torna su a constatare i passaggi finché non ti convinci dell’efficacia della espressione regolare numero 4 e del fatto che basti lanciarla n volte per avere un corretto accorpamento dei n attributi deprecati esplosi nei vari style)

Ebbene, lanciando tutte queste espressi regolari su una pagina a caso ecco il risultato: test.

A questo punto si lancia il mio bottino personalissimo e si corregge Wikipedia:

./replace.php \
--always \
--wiki=itwiki \
--generator=search \
--gsrsearch='insource:bgcolor' \
--regex \
--summary="Bot: cose" \
REGEX1 SOSTITUZIONE1 \
REGEX2 SOSTITUZIONE2 \
...

E per oggi le nostre inutilità le abbiamo fatte.

E anche oggi siamo riusciti a non usare un parser HTML per fare ciò che bisognerebbe fare con un parser HTML. asd

P.S.
Naturalmente non solo è stupido pensare che qualcuno mi ringrazierà per aver fatto una cosa del genere (o forse a farlo sarà il World Wide Web Consortium? chissà. asd) ma sarebbe altrettanto stupido pensare che non sia scappato un errore da qualche parte in qualche corner-case allucinante in qualche voce a bassissima visibilità fuori dai controlli a campione, magari proprio mentre mi ero distratto un momento a rispondere alle domande impertinenti di quel bischero di Ferdi2005, mentre con una pupilla monitoravo il bot e con l’altra gli mandavo una gif di un Sofficino. Quindi, fra 2 anni, un utente verrà giustamente a cazziarmi e dovrò giustamente spiegargli come mai io mi sia permesso di non verificare come mai nella sua specifica circostanza un testo abbia potuto perdere la formattazione desiderata. Dannato Ferdi2005. Dannati Sofficini. asd

La vita non da gioie. Le espressioni regolari neanche. Ma almeno abbiamo dimostrato ancora una volta quanto le espressioni regolari siano bellissime. asd

Strappando la licenza di Microsoft Windows

Consiglio a tutti. È un toccasana contro lo stress.

A margine:

  • Questo è un video trash ed è perciò adatto a YouTube. Se fosse stato un video culturalmente interessante l’avrei caricato su Wikimedia Commons.
  • Se proprio devi caricare un video su YouTube almeno evita la licenza YouTube standard (che è di default).
  • Questo video è incorporato dal dominio youtube-nocookie.com

Fra pochi minuti inizia il code challenge

Siamo qui all’IIS Avogadro di Torino, fuggiti dalla nostra università, per partecipare ad un code challenge di cui tenteremo di non dire il nome e che non linkeremo per non fare loro speculazioni SEO gratuite :D

Avremo molta fame in queste 4 ore per risolvere una sfida algoritmica che ci sarà comunicata a breve.

(Sì, sembriamo dei ritardati. Ma dei ritardati con un uovo di Paqua…)

Vinca il migliore!

Team di sviluppo: glossario

(Dalla nuova serie informatici dal parrucchiere)

Glossario per la sopravvivenza all’interno di un team di sviluppo di successo.


Il Boss: Paga. Tu tratti bene lui, lui tratta bene te. Semplice.


Il Delegato: Essere apparentemente simpatico. Se evocato da Il Boss, rimane per sempre. È in grado di fissare deadline sugli esseri umani. Per sadismo personale Il Delegato deve sempre stabilire deadline all’ultimo momento, passandole come imposte dall’alto per non essere linciato dagli uomini. Il delegato conosce limitate ma efficaci frasi di circostanza per variare all’improvviso una deadline. Ad esempio «Ecco! Le specifiche sono cambiate!  Maledetti quegli stronzi ai piani alti! [n.d.r. non c’è nessuno ai piani alti]» «Ecco! Dovremmo [n.d.r. dovrete] rifare tutto da capo ed entro domani!». Il Delegato ride sotto i baffi insieme a L’Esperto quando si raggiunge lo scopo: metterlo nel culo al ragazzo.


L’Esperto: È un abile psicologo in grado di emanare un campo di serenità placebica ai piani alti. L’Esperto ha diversi punti deboli correlati: è allergico alla baracca, è allergico ad il ragazzo ed è mortalmente allergico ad ogni sua riga di codice. L’Esperto è un vero esperto quando si tratta di ingegnerizzare e fissare un briefing con i suoi colleghi esperti. [n.d.r. Che poi chi cazzo sono ‘sti colleghi esperti? Sono altrettanto esperti?]. Sogno nel cassetto: tirare su blog nella notte, come funghi porcini.


briefing: Raccoglimento spirituale effettuabile esclusivamente dalla figura di un L’Esperto per infondere positività nella risoluzione di un problema. Un modo come un altro per evadere in pausa caffè. È importante che nessuno risolva il problema prima della conclusione del briefing per non demoralizzare l’autostima de L’Esperto.


ingegnerizzare: Tipico intercalare de L’Esperto per introdurre una serie di amenità sconclusionate all’interno di un discorso il cui obiettivo è raccogliersi in un briefing per variare le specifiche. Esempio d’uso: «ragazzi bla bla bla allora bla bla bla La Piattaforma bla bla bla occorrerebbe ingegnerizzare il tutto bla bla bla bla — briefing.».


deadline: data inderogabile in cui tutta la baracca deve funzionare. Deve sempre sembrare l’ultima e per questo ha sempre l’ultima parola Il Delegato. L’algoritmo è il seguente: Si ha molto anticipo? Non si fisserà alcuna deadline. Il lavoro deve essere finito fra un mese? La deadline sarà lunedì. Siamo già a lunedì e il ragazzo ha lavorato tutta domenica notte? Si chiama L’Esperto, si scriveranno nuove specifiche, ci sarà da far rifare tutto da capo e finalmente si avrà una nuova deadline.


specifiche: quando Il Boss esprime una necessità ad Il Delegato, quest’ultimo si attiva per introdurre il problema alla figura di un L’Esperto, il quale si sentirà giustificato a calendarizzare un briefing, nel nome della razionalizzazione del problema. Al termine di questo tripudio di nullafacenza si avrà una nuova specifica da poter consegnare ad il ragazzo. Quest’ultimo, in qualità di terminale di questo telefono senza fili, starà al gioco e ringrazierà. In seguito cestinerà questo prodotto e farà una telefonata ad Il Boss per capire che cosa volesse realmente.
Una nuova specifica introduce una nuova deadline. Una specifica deve essere in contrasto con la precedente.
In pratica il ragazzo la domenica sera commenterà via il codice de la baracca scritto  per la specifica precedente, così come per la prossima specifica commenterà via il codice scritto in tal giorno, e via così.


la baracca: Il termine baracca sta ad il ragazzo come Piattaforma sta a L’Esperto. La baracca è madre, padre, figlio, cibo e compagno di letto de il ragazzo. Esempi d’uso: «Ma dove c*** ‘sta il server dove dovevamo ficcare la baracca?» esordisce il ragazzo. Si pensa che La Piattaforma sia la stessa cosa de la baracca, ma La Piattaforma è tirata su da L’Esperto a suon di specifiche grazie al cloud computing, mentre la baracca e tirata su da il ragazzo programmando la domenica notte sul suo server.


server: La figura de L’Esperto può garantire che questa tecnologia missilistica all’ultimo grido sia già pronta da ieri, ma purtroppo è sorto un problema. Su questo bolide non si può installare una sega. Partono le chiamate. «DOVE CAZZO È CHI HA INGEGNERIZZATO QUESTA BARACCA? CHE QUESTI POI SI ACCORGONO CHE MANCO SO INSTALLARE UNA DEBIAN IN MENO DI QUATTRO GIORNI DI CUI TRE LAVORATIVI!» — esordisce L’Esperto. Se il ragazzo nel frattempo si è impietosito a sufficienza,  quasi sicuramente per evitare il disastro e figure dimmerda avrà detto la minchiata del secolo: proporre di usare il suo server per tenere su la baracca.


La Piattaforma: Studi di settore concordano sul fatto che La Piattaforma abbia un valore di mercato ed una complessità assolutamente non paragonabili ad la baracca.


problema: Salta sempre fuori. Non è mai colpa de L’Esperto o delle sue specifiche. Solitamente L’Esperto non perde mai occasione di tenersi stretto per sè la responsabilità di risolvere un problema attraverso il raccoglimento in un briefing. Se il problema si protrae fino alle 18:00 o se è arrivato il week-end, il briefing deve essere considerato come un successo e perciò la responsabilità può essere trasferita immediatamente ad il ragazzo.


il ragazzo: È sempre uno. Cioè, mi sembrava fossero due, ma è uno solo. Dalla regia mi dicono che l’altro è andato in burnout a furia di sentire le amenità de Il Delegato / ai briefing de L’Esperto.


beta-tester: È un concetto da sfigati. La Piattaforma è sempre sicura e funzionante. È subito possibile scagliare su La Piattaforma le scimmie.


scimmia: TRATTASI DI PIGIATASTI PARTICOLARMENTE AMANTI DEL CAPS LOCK . NEMICI NATURALI DELLA NETIQUETTE E PERSONE TANTO FRUSTRATE QUANTO FRUSTRANTI A LORO INSAPUTA . SI CAPISCE CHE USANO WINDOWS PERCHé LE LORO “è” ACCENTATE SONO LE UNICè COSè MINUSCOLè — n.d.r. cosa che non capiterebbe con GNU/Linux — SCOPO DELLE SCIMMIE è ENTRARE A CONTATTO CON IL SUPPORTO TECNICO .


Supporto tecnico: Sono paladini della giustizia sociale che evadono qualsivoglia richiesta ricevuta dalle scimmie. Il supporto tecnico è allergico ad ogni accesso al database. Nel raro caso in cui una richiesta tecnica sia davvero una richiesta tecnica, è irrisolvibile dal supporto tecnico. Il supporto tecnico deve essere in grado di non far notare a L’Esperto che c’è bisogno di il ragazzo per risolvere il problema. A questo punto il ragazzo comunica la soluzione ad il Supporto tecnico che risponderà alla scimmia.

Informatici dal parrucchiere

Dato che in molti mi stanno facendo capire che devo dedicare più tempo al benessere personale, inizierei a condividere con l’Internet qualche vicessitudine frustrante e/o irriverente. In sostanza sparlerò di qualche collega. Naturalmente il soggetto interessato non ha nulla da temere: il suo nome sarà protetto da potenti algoritmi crittografici vulnerabili solo al metodo del tubo di gomma.

Se vi suona come qualcosa di sbagliato, cosa credete che dica di voi la vostra vicina di casa dal parrucchiere? ;) Solo che lei non usa mezzi termini.

Nel caso qualcuno se lo stesse chiedendo, no, non mi sto ispirando a Manzoni. Io sono decisamente più ignorante e mi limito ad inchinarmi alle perle già contenute in Storie dalla sala Macchine :D

Se sei giunto fin qui perchè ti fischia l’orecchio o hai la coda di paglia o altri simili problemi metaforici e ritieni di essere moralmente stuprato, in quanto il tuo egocentrismo ti fa credere di essere il diretto interessato dei miei sfoghi, ti sbagli! Sei sufficientemente intelligente per capire che in verità tu non esisti in quanto tale: io no ho mai citato nessuno.

asd ^^

Continua in: Categoria:Informatici dal parrucchiere.