mogli e modellismo

Link ad un simpatico articolo di un mio amico appassionato di modellismo storico: Dedicato alle mogli

Preti

La serie che vi fornirà le risposte. Forse non siete ancora pronti per questo... ma i vostri figli ci rideranno (citazione libera).

VPS su Digital Ocean

Digital Ocean offre soluzioni Virtual Private Servers (VPS) a prezzi veramente interessanti. Io ho optato per una soluzione di basso profilo (512MB ram, storage SSD da 20GB) a 5$ al mese.
Ho spostato lì le mie pagine personali e sviluppato alcune soluzioni solo per testare l'ambiente... mi ritengo soddisfatto.
Per iscriversi visita Digital Ocean (è un link di affiliazione, guadagnerò dei crediti se ti iscriverai attraverso questo link)

Digital Ocean offers VPS solutions for a very low monthly fee. I set up a server with them (512MB ram, 20GB storage SSD), I moved my personal pages and I experimented some solutions... and I am satisfied.
To sign up please visit Digital Ocean (this is an affiliate link, I'll earn some credits if you use this link to sign up)

Assurdità grilline

Da questo link una simpatica iniziativa, anche se non entro nel merito perché ho letto solo un paio di post.

In realtà un po' di tempo fa mi volevo cimentare in un'impresa un po' più universale, cioé raccogliere tutte le assurdità degli avvenimenti politici, ma è necessario uno sforzo importante affinché la qualità del sito rimanga alta. Ad oggi non ho energie sufficienti da dedicarvi... chissà un giorno

Funerale di Priebke

Stavo scrivendo un pensiero sulla questione surreale di Priebke, ma poi ho letto alcuni articoli che mi sono piaciuti molto, per cui ho preferisco linkarli. Essi sono due articoli complementari comunque in fase con le mie idee:
http://odifreddi.blogautore.repubblica.it/2013/10/12/priebke-come-welby/
http://www.keinpfusch.net/2013/10/la-professione-di-fede.html

Poi è uscito anche quest'altro:
http://www.keinpfusch.net/2013/10/l-italia-di-priebke.html

Buona lettura

Che vitaccia quella del decision maker pubblico

Questo post cui ho commentato mi ha ispirato un breve post. Ma premetto che sarà un post qualunquista, ancora più qualunquista per questione di sintesi, ma oggi mi va così.

Nell'ottica di riduzione della spesa, in ogni campo si è introdotto[1] il vincolo della razionalizzazione dei costi.
Purtroppo ci si sontra con due problemi non indifferenti:

• si dimentica che i costi sono in realtà investimenti, quindi sarebbero da prioritizzare;
• la parola razionalizzazione prevede eccitazione dei neuroni, e nell'impossibilità di molti decision-maker si preferisce il taglio pseudo-randomico.

Insomma, il bilancio richiede diminuzione dei costi quindi si tagliano i costi. Punto.
L'immediata conseguenza?
Il taglio dell'investimento si scontra con le necessità dei cittadini. Ma il decision maker dice: "Colpa del taglio dettato dall'alto"... e questa tiritera procede fino ai vertici dello Stato i quali rispondono sempre utilizzando uno schema pseudo-randomico opta alternativamente:

• siamo costretti perché ereditiamo il passato;
• non dovete chiederlo a me, l'ha deciso quell'altro (nonostante io sia il capo del mio ministero, ma ovviamente facciamo tutti parte della stessa squadra... o no?).

Insomma... sembrerebbe che il cittadino rimanga senza speranza.
Non proprio, perché può sperare che il decision maker utilizzi il famigerato provvedimento d'urgenza. Ed è simpaticissima l'immediato sviluppo.
Il decision maker, senza voler nulla in cambio ad esclusione del voto alle prossime elezioni o più semplicemente essere portato in trionfo, non procede rimodulando razionalmente il bilancio ma, utilizzando uno schema pseudo-randomico, opta alternativamente per:

• rimodulare alcune voci di bilancio (tanto sono numeri!!)
• non interessarsi dei vincoli di bilancio[2].

In entrambi i casi il cittadino è spesso pronto a dimenticare il periodo di disservizio, ora il servizio è di nuovo attivo, anzi è anche migliorato perché è stato esternalizzato verso il privato che utilizza strumentazione moderna.
Ovviamente qualcuno si sarà accorto che purtroppo nel breve/medio periodo si dovranno ripercorrere i medesimi passaggi perché, ricordiamolo, che nemmeno ora si è utilizzato un metodo razionale, ma rispettivamente:

• rimodulazione del bilancio per accontentare i cittadini;
• non interessarsi del bilancio, non è un problema vincolante.

Rispetto la panoramica proposta si potrebbe intuire: il decision maker ha un compito semplice, tutti possono esserlo.
Ma assolutamente no.
E' importantissimo capire quanto tempo sia necessario prima di far esplodere il problema e ricorrere al privato. Ma è anche fondamentale non aspettare troppo tempo.... la finestra temporale nella quale agire è discretamente breve.
Perché se il dirigente ci ricorre troppo presto, allora diviene chiaro che abbia voluto favorire il privato.
E se ci ricorre troppo tardi diviene chiaro per troppi che il dirigente sia inadeguato.
Insomma, la vita del dirigente è difficile, è necessario essere in fase con le necessità e non distrarsi... potrebbe essere fatale.


Note:
[1] -> mi fa sorridere che tale motto si è introdotto "ora", come se prima fosse non necessario, probabilmente finora si viveva nella bambagia, quindi era una questione marginale
[2] -> io sono solito pensare i vincoli come rette, ma le rette sono curve e le curve possono essere arrotondate un po' come vogliamo.... non è così?

MySQL: VIEW, UNION, JOIN... and IF

Nel mio lavoro utilizzo spesso MySQL. Non sono un esperto, ma ne faccio largo uso. Stavo affrontando un certo problema che si è risolveva banalmente creando tale vista[1]:

 CREATE VIEW `impiantisoggetti` AS
     SELECT
         `collegamento`.`id` AS `id_collegamento`,
         `collegamento`.`id_user` AS `id_user`,
         `utente`.`codice` AS `codice`,
         `impianto`.`id` AS `id_impianto`,
       FROM ( (`impianto`
         left join `collegamento`
           on (`impianto`.`id` = `collegamento`.`id_impianto` ) )
         left join `utente`
           on (`utente`.`id` = `collegamento`.`id_user`)
         inner join impiantisoggettilast
           on (`collegamento`.`id` = `impiantisoggettilast`.`maxID`)
     )
   UNION
     SELECT
         `collegamento`.`id` AS `id_collegamento`,
         `collegamento`.`id_manutentore` AS `id_user`,
         `manutentore`.`codice` AS `codice`,
         `impianto`.`id` AS `id_impianto`,
       FROM ( (`impianto`
         left join `collegamento`
           on (`impianto`.`id` = `collegamento`.`id_impianto` ) )
         left join `utente`
           on (`manutentore`.`id` = `collegamento`.`id_manutentore`)
         inner join impiantisoggettilast
           on (`collegamento`.`id` = `impiantisoggettilast`.`maxID`)
     )

Banalmente, una VIEW formata da una UNION di JOIN.
Non ci sarebbe molto da dire. Creata la vista, la provo e noto che le prestazioni decadono di un fattore 100.
Isolando le query della UNION, creando tali viste impiegano su dati reali una frazione attorno al mezzo secondo in un caso, un decimo nel secondo. La VIEW formata dalla UNION mostrata impiegava circa 40 secondi.
Leggendo un po' di documentazione, ho scoperto che creando le VIEW l'algoritmo utilizzato è MERGE oppure TEMPTABLE. Se non definito, nella costruzione il server cerca di utilizzare MERGE altrimenti TEMPTABLE.
Facendola breve, se si utilizza MERGE i filtri possono essere applicati direttamente, altrimenti sarà utilizzato TEMPTABLE in cui sarà necessario creare una tabella temporanea a cui successivamente si applicherà il filtro. Si intuisce facilmente la caduta prestazionale.
Ok, requisito affinché si possa utilizzare MERGE nella creazione della VIEW è che non si utilizzino funzioni o aggregazioni sulle colonne, insomma è necessario utilizzare le colonne in modalità row, così come sono. La UNION è male, nel senso non permette l'utilizzo dell'algoritmo MERGE.
Come si può risolvere. In due modi.
Il primo è modificare l'applicativo. Spesso è facile quindi non è un'opzione necessariamente da scartare.
La via preferibile è la seconda proprio perché è più semplice e più immediata... è necessario utilizzare un accorgimento lato sql con gli IF che personalmente non avevo mai utilizzato. Ecco la loro applicazione, molto intuitiva e pertanto non spiegherò ma è utile mostrare:

 CREATE VIEW `impiantisoggetti` AS
    SELECT
        `collegamento`.`id` AS `id_collegamento`,
        IF (`collegamento`.`id_user` IS NOT NULL, `collegamento`.`id_user`, `collegamento`.`id_manutentore`) AS `id_user`,
        IF (`collegamento`.`id_user` IS NOT NULL, `utente`.`codice`, `manutentore`.`codice`) AS `codice_utente`,
        `impianto`.`id` AS `id_impianto`,
    from ( (`impianto`
        left join `collegamento`
            on (`impianto`.`id` = `collegamento`.`id_impianto` ) )
        left join `utente`
            on (`collegamento`.`id_user` IS NOT NULL AND `utente`.`id` = `collegamento`.`id_user`)
        left join `manutentore`
            on (`collegamento`.`id_manutentore` IS NOT NULL AND `manutentore`.`id` = `collegamento`.`id_manutentore`)
        inner join impiantisoggettilast
            on (`collegamento`.`id` = `impiantisoggettilast`.`maxID`)
    )

Note:
[1] -> ovviamente è stato presentato una versione semplificata