Ein Zwei Polizei, drei vier Grenadier...

Impariamo un po' di tedesco con la cantilena-tormentone del 1994 che dalla sveglia di stamattina non si schioda più dalle orecchie:

Ma si scrive Kociak oppure Kojak?

Il tenente Kojak era il personaggio pelato con calvizie d'alopecia più famoso degli anni '70. Ma nel mercatino ancora non sanno come si scrive.

I due ingressi del negozio. Notare in entrambi la scritta Kociak:

Esatto, vende sia prodotti ittici che olive. Subito sotto il cartello delle olive compare una scritta Kojak:
 

Stoccafisso e baccalà. Anche stavolta hanno scritto Kojak:
 

Essendo una pescheria specializzata in olive, non poteva ovviamente mancare il reparto caramelle, cioccolatini e frutta secca. Stavolta pure hanno scritto Kojak:

È l'ora del bagnetto

Specifiche (cioè il contrario di "vedémo, mettémo, levàmo, checcevò?")

Mini serverino casalingo Intel NUC (in basso)
con scheda grafica esterna (in alto)
inclusa nel suo specifico case esterno con ventole
e collegata al serverino su porta Thunderbolt 3.
Non c'entra niente con l'articolo ma mi piace.

Per scrivere un software servono le specifiche, cioè la descrizione completa, precisa, senza ambiguità, coerente, verificabile, sia per il contenuto che per l'autorità ("chi" può aggiornare "cosa"), tracciabilità ("chi" ha stabilito "cosa"), priorità ("questo" è più importante di "quello"). In breve: le specifiche servono a togliere dubbi passati, presenti e futuri.

Più è delicato il software e più le specifiche devono rispettare quelle caratteristiche. Ogni ambiguità o mancanza, infatti, sostituisce l'ingegnerizzazione con la fantasia e le incertezze (e dunque la fretta e la confusione) di chi dovrà scriverlo, collaudarlo e documentarlo. Le specifiche non devono dire quanto tempo e quante risorse servono: questi sono infatti aspetti commerciali, non tecnici, e vanno concordati in altra sede.

Quando alla committenza viene dimostrato che le specifiche fanno veramente cagare, immediatamente cambia idea (il che significa che lo sapevano già e che nel frattempo hanno tentato di prenderti per il sedere). Per questo è indispensabile continuamente dichiarare a prescindere che le specifiche fanno cagare: in tal modo la committenza sfoltirà da sola, a poco a poco, gli svarioni più madornali, oppure rifilerà il pastrocchio a qualcuno più ingenuo di te.

Vediamo qui sotto alcuni esempi in cui bisogna prendere a calci nel sedere chi ti consegna specifiche non proprio perfette.

---

Esempio 1: specifica incompleta o addirittura inesistente.

"Ma come? ti ho scritto una mail di due pagine per spiegarti come devi realizzare una via di mezzo tra Facebook e Twitter orientata alla vendita di cibo per cani, e ti lamenti pure?" ... "Ma come? ti ho detto in ogni dettaglio come devi realizzare un clone del prodotto Sbirgnaus del nostro concorrente e aggiungere l'indicizzazione, e ti lamenti pure?" ... "Ma come? ti ho girato i risultati di ricerca Google su come si implementa il protocollo, e ti lamenti pure?"

No comment.

---

Esempio 2: specifica imprecisa o troppo generica.

"Ma come? ti ho detto che per sicurezza gli accessi devono essere protetti da password, e ti lamenti pure?"

Spiegazione (molto breve) di "protetti da password": database utenze con replicazione, validazione e scadenze password, canale criptografato e workaround conseguenti, separazione privilegi dentro e fuori, livelli di clearance per la manutenzione, aggiornamenti di sicurezza continui con relativi restart, nuove limitazioni alle vecchie e nuove procedure, misure anti-hacking e relativo collaudo, simulazione di intrusione e relativa mitigazione, compliance con le best practices, possibile riscrittura from scratch di procedure basate su librerie obsolete, poco manutenute, o di dubbia fama... (poi i mega-manager si chiedono come mai ragazzini craccano siti web e programmi)

In altre parole: la specifica doveva spiegare cosa si intendeva per "sicurezza" e quali passi occorrono per ottenerla. Non è che uno dice "password" e magicamente le minacce che verranno inventate in futuro vengono già sconfitte.

---

Esempio 3: specifica ambigua, tipicamente da parte di chi non sa esattamente cosa vuole.

"Ma come? nella specifica c'è scritto chiaramente che l'User Id è incrementato automaticamente e che non devono esistere due utenti con lo stesso account, cos'è che non si capisce?"

Ambiguità: non si capisce se lo User Id è unico, e non si capisce nemmeno se Utente e Account esprimono lo stesso concetto. Per esempio sarebbe stato molto più chiaro così: "l'Account utente è univocamente identificato da un User Id, unsigned 32 bit che cresce monotonicamente".

"Ma come? nella specifica c'è scritto chiaramente che le API supporteranno JSON e XML. Di che ti lamenti?".

Ambiguità: supporteranno adesso oppure in futuro? Le specifiche devono parlare come se il software che descrivono esiste già. Le specifiche non sono letteratura, non servono a far bella figura, ma a farsi capire da chi deve lavorarci su. Devono dare risposte, non domande. Devono fugare dubbi, non crearne.

---

Esempio 4: specifica non autoritativa, cioè l'estensore non sa fare il suo mestiere.

"Ma come? nella specifica c'è scritto chiaramente che crediamo che siano da supportare più interfacce e che siete invitati ad aggiungere quelle che vi sembrano convincenti, e indicarle qui sotto..."

Questa non è una specifica ma solo l'opinione di uno che ha le idee poco chiare, e che invece di spiegare cosa va fatto e come va fatto chiede opinioni e iniziativa. In realtà andava scritta così: "sono da supportare solo le interfacce Sbrauz 1.x e Sbarabambagnaus, più la Sbrauz 2.0 in sola lettura per i flussi singoli".

Se si prevedono aggiornamenti, possono provenire solo dalla stessa autorità che l'ha scritta e sempre rispettando le sue caratteristiche: "aggiornamento (GD, 47/2017): il supporto della Sbrauz 2.0 deve prevedere anche la lettura di flussi multipli, come documentato negli allegati tecnici 131-GD-2017 e 133-GD-2017".

---

Esempio 5: specifiche non verificabili, cioè confusionarie.

"Ma come? non è chiaro? l'utente deve poter scorrere la lista immagini dei prodotti in modo veloce e fluido".

Il requisito funzionale ("scorrere immagini") viene vincolato a uno non funzionale, addirittura un concetto ambiguo ("scorrere veloce e fluido"). La parte funzionale è verificabile (si può facilmente stabilire se il software permette di scorrere la lista immagini o no), la seconda parte non è verificabile ("quanto" deve essere veloce? come si misura la fluidità? in quali ambienti deve risultare veloce e fluido?), e addirittura non si capisce se sia più importante la lista o la velocità. Certo che se metto una sola immagine sarà tutto veloce e fluido, no?

Magari poi ti arriva un nuovo requisito funzionale: "scorrere anche le sotto-liste di prodotti". La fluidità si deve applicare anche a queste? Quanto veloce deve essere? Ok, "entro 500 millisecondi": ma su quale piattaforma hardware? con quante immagini e di che dimensioni? Da quale momento deve cominciare il conteggio dei 500: dall'inizio del caricamento della pagina, o dal suo completamento?...

"Ma di che ti lamenti? i report vengono generati in PDF quando richiesto, e devono essere scaricati o inviati via e-mail. Più chiaro di così?"

Confusionario. I report di "cosa" e generati da "chi"? Dell'utente o del manutentore? In quali circostanze possono essere "generati" e in quali no? La confusione è dovuta all'esprimersi con verbi impersonali e senza far capire chiaramente "chi" fa "cosa".

---

Esempio 6: micromanagement, cioè specifiche che scendono troppo nei dettagli.

"Ma di che ti lamenti? l'utente deve autenticarsi attraverso Facebook cliccando sul tasto di login, e il suo username, avatar ed email andranno inseriti in database".

Le specifiche devono essere complete ma questo non significa spiegare i minimi dettagli. Non si capisce se il dire "inserire in database" implichi come requisito l'avere un database in più, oppure è solo un suggerimento di usare qualcosa di concettualmente simile ad un database. E non si capisce se l'inserimento riguarda solo quei quattro campi oppure se riguarda almeno quei quattro campi.

---

Esempio 7: specifiche incoerenti.

"Ma di che ti lamenti? il nostro obiettivo deve essere un'interfaccia user friendly ottimizzata per le prestazioni; la parte client va scritta in Java perché così sarà più veloce".

E quando la parte user friendly impedisce di ottimizzare meglio le prestazioni, quale dei due concetti va considerato? E come si fa a verificare quale dei due obiettivi (o entrambi) è stato raggiunto? E cosa garantisce che il solo "scrivere in Java", in quel preciso contesto, migliora la velocità percepita dall'utente finale?

---

Esempio 8: specifiche senza glossario, le capisce solo chi le ha scritte.

"Ma di che ti lamenti? il TDR delle richieste va in TO a 3000, più chiaro di così!"

Solo che non c'era un glossario che ti dice "TDR = tempo di risposta espresso in millisecondi" e "TO = timeout". Il primo caso è un concetto noto ma espresso con una sigla gergale (e non necessaria), interna a certi settori dell'azienda, il secondo caso è un concetto noto ma espresso con una sigla inutile (nessuno abbrevia "timeout", tanto meno con "TO"). Le sigle come TCP/IP, FIFO, ecc., rintracciabili su wikipedia vanno bene; ma le sigle sconosciute all'esterno dell'azienda vanno spiegate tutte.

Beretta APX

Spettacolare Beretta APX: come fai a non averla?!?

Prezzi a partire da 710 euro
inclusa valigetta e accessori

Ma... ma è... è il TRENINO !!!

Video della mia ultima creazione (di oltre tremila mattoncini LEGO):

In dettaglio:

Promemoria pagine precedenti:

• novembre: inizio progetto
• dicembre: sciopero dei macchinisti
• dicembre: prima bozza pronta, seguiranno modifiche
• febbraio: anticipazione per ItLUG Lecco 2017
• marzo (oggi): entrata in servizio

L'opensource della NASA, cioè il caos

Aaah, uno splendido software della NASA per calcolare le traiettorie interplanetarie qualora uno volesse spedire aggeggi nello spazio, sfruttando le "fionde gravitazionali", rispettando "finestre di lancio" e partendo da un punto a piacere della superficie terrestre...

Il software è scritto in C++ e Python. Descrizione e sorgenti sono sul sito della NASA, mentre la versione Windows (che richiede una carretta di DLL e Visual C Runtime, più una versione speciale di Python per ambienti scientifici, più una libreria "SNOPT" scritta in Fortran, prelevabile in versione dimostrativa dietro iscrizione e bla bla bla) è scaricabile da Sourceforge.

Una delle rare volte che mi ritrovo a dover dichiarare "quasi obsoleto" un computer...

Uno dei miei migliori investimenti informatici di tutta la vita: Fujitsu-Siemens Stylistic ST-5022, comprato usato a gennaio 2007 (più di dieci anni fa!) per la modica cifra di trecento euro da un giovane surplussaro calabrese residente in Germania e utilizzato dapprima come tablet PC (non come quelle cagate Apple, ma come un vero e proprio tablet con la penna) e quindi come server casalingo.

Anno di produzione: 2004. Nasceva alquanto ben carrozzato (e nonostante ciò lo vendevano come "tablet"):
- CPU Pentium-M a 1.1 GHz
- 1 Gb RAM
- disco ATA IDE da 60 Gb a 5400 giri
- porte: ethernet gigabit, firewire IEEE 1394b, due USB 2.0, modem 56k, fast infrared
- slot PCMCIA, slot SD, uscita VGA, wifi, bluetooth, speaker, microfono, jack mic/ear 3.5mm, otto tasti
- batteria Li-Ion 10.8V da 4800mAh
- schermo 12" 1024x768 con digitizer Wacom (e penna nello slot apposito)

Ho smesso di usarlo come tablet quando la batteria cominciò a durare meno di un'ora, dopo avermi accompagnato per decine di migliaia di chilometri in totale, per lo più in treno. Ci ho perfino dormito sopra, usandolo in treno come sedile o come cuscino (in entrambi i casi involontariamente), grazie alla sorprendente robustezza del suo case, per lo più metallico: mi occorse un po' di fatica per trapanarlo e aggiungervi un connettore RP-SMA per l'antennona wifi esterna per fare wardriving.

Ha sopravvissuto poi a numerosi traslochi e riposizionamenti. Dopo diversi guasti (slot SD, PCMCIA, wifi+bt, schermo, tolti tutti; ventolina di raffreddamento) ho upgradato l'ardisco a 250 Gb IDE e fatto funzionare come server casalingo 365/24 con Ubuntu 12.04 Desktop, usando VNC e ssh per accedervi, facendo girare numerosi servizi critici e per larghi tratti anche al 100% di CPU: la CPU non si surriscaldava mai, anche senza ventolina (nella foto si vede un suo cavo troncato di proposito), perché scoperchiato. Praticamente l'unica parte in movimento era l'ardisco.

Grazie alla batteria integrata (che ormai durava una ventina scarsa di minuti, sufficienti però a coprire praticamente tutti i black out intervenuti nel frattempo) ha raggiunto uptime epici: ieri sera ho dato il poweroff dopo oltre 191 giorni di uptime (praticamente l'ultimo reboot era stato ai primi di settembre e fu dovuto ad un guasto della "ciabatta" da cui era alimentato).

Mi dispiace mandare in pensione un gioiello del genere, frutto combinato della pignoleria tedesca e della qualità giapponese, e senza parti "Made in China" (tranne la basetta ethernet+modem+infrared che è "Made in Taiwan"). Non vedo l'ora di trovare una scusa per installarlo da qualche parte.

Promemoria: circuitino a doppia goccia

Idea: costruire un tracciato in cui il trenino LEGO motorizzato PowerFunctions attraversi gran parte dei binari in entrambe le direzioni, senza dover mai agire sugli scambi o sul motore.

Gli scambi LEGO sono "tallonabili", cioè dato un ramo A e due rami B e C, il treno può percorrere AB, oppure BA oppure CA senza dover intervenire. La leva dello scambio infatti seleziona solo l'uscita del ramo A quando viene percorso in ingresso.

Questo significa che è possibile creare un tracciato a goccia per invertire la marcia, come in questa foto:

Se mettiamo insieme due tracciati a goccia uniti da un tratto di binari, otteniamo un circuito chiuso in cui tale percorso tra le due "gocce" verrà attraversato in entrambe le direzioni, senza dover agire sugli scambi o sul treno in marcia:

Ma le gocce si possono anche incrociare, come in questo fulgido esempio (non fatevi ingannare, non è una copia del carissimo - in tutti i sensi - double crossover 7996):

In questo caso i rami aggiuntivi percorribili in entrambe le direzioni sono quello connesso agli scambi a destra e quello connesso agli scambi a sinistra: i percorsi utili saranno questi, tutti validi contemporaneamente e senza toccare gli scambi poiché sfruttiamo la loro caratteristica di essere tallonabili:

* S1-D1-D2-S1
* S2-D2-D1-S2
* D1-S2-S1-D1
* D2-S1-S2-D2

In altre parole, un treno in ingresso in uno dei quattro punti attraverserà il tracciato opposto (quello connesso ai due scambi dall'altro lato) e invertendo la direzione.
I tratti S1-S2 e D1-D2 verranno percorsi in entrambe le direzioni, senza mai dover agire sugli scambi o sul motore.

Come costruirli

La goccia è abbastanza semplice ed è dedicata a tutti coloro che si lamentano di avere troppi binari curvi nel proprio stock pezzi. Tra i modi in cui si può costruire, quello della foto è fatto così:
* uno scambio
* seguito da cinque binari dritti sul suo ramo dritto
* seguito da undici binari curvi, tutti orientati all'interno
* seguito da un binario curvo orientato verso l'esterno
* seguito da un binario corto "flexi"
* seguito da un binario dritto
* seguito da un binario flexi
* seguito da un binario curvo orientato verso l'esterno e agganciato all'altro ramo dello scambio

Totale:
1x scambio
6x dritti
2x flexi
13x curvi

La doppia goccia è costituita invece da quattro elementi simmetrici formati da:
* uno scambio
* con un binario dritto seguito da un flexi, sul lato dritto dello scambio
* e con un binario curvo orientato verso l'esterno, sul lato curvo dello scambio
* quest'ultimo binario curvo va agganciato all'incrocio centrale
* mentre il binario flexi va agganciato al flexi dell'elemento opposto

Totale:
1x costoso incrocio 9V (nei PF non esiste ancora l'incrocio!)
2x scambi destri
2x scambi sinistri
4x flexi
4x dritti
4x curvi

Video dimostrativo: notare come i due rami più esterni (i curvoni) siano affrontati in entrambe le direzioni:

Nota: anche se i flexi sono stati in entrambi i casi utilissimi per aggiustare la geometria delle curve, appariranno un pochino forzati ma non "illegali" dal punto di vista del purista AFOL (penso che sia difficile costruire gocce e doppie-gocce più piccole; a farle più grandi servirebbero più binari e più spazio). I due ingressi S1/S2 sono separati da poco meno di 44 stud (sono convergenti, non paralleli).

Piccoli consigli ingegneristici per l'armamento ferroviario:
- alternare un singolo flexi a un singolo binario dritto in modo da aggiustare le geometrie in ogni punto e poter fare curvoni di raggio notevole;
- due flexi consecutivi fanno già "ballare" il treno, diversi flexi consecutivi per fare una curva diventano faticosi da attraversare;
- regola principe: mai usare un flexi in ingresso o uscita da uno scambio.

Video di esempio di utilizzo del "doppia goccia" (più abuso di scambi e incroci):

La CIA è ancor più grossa di quanto descritto dai film di Hollywood!

Comico: ecco lo schema (parziale) dei dipartimenti della CIA (Central Intelligence Agency), secondo quanto pubblicato da Wikileaks - cliccare per ingrandire.

Ha molti più "rami" e dipartimenti di quanti non ne vengano detti nei film d'azione di Hollywood! Al posto dei puntini ci sono numerose altre ramificazioni non ancora note al pubblico.

Di cosa ha veramente paura la NATO

Visto che da anni gli americani e i loro lacché cercano ogni scusa per far guerra alla Russia, vediamo alcuni dei principali motivi per cui i vertici della NATO timidamente sconsigliano azioni azzardate.

Terrore della Nato codice "SS-X-30", anche detto Satan-2 (ed è tutto un programma), anche noto come RS-28 Sarmat: missile intercontinentale pesante (170 tonnellate), capace di portare fino a dieci testate nucleari multiple indipendenti alla velocità di ottomila chilometri orari (Mach 6.7), con un tempo di preparazione al lancio di appena un minuto. Collaudato ad agosto 2016.

Terrore della Nato detto "sottomarini classe Lada", anche noti come Progetto 677. Piccolo e leggero (72 metri fuori tutto, 2700 tonnellate di stazza in immersione), maneggevole, ottimizzato per essere silenzioso anche a 21 knots (39 km/h), può lanciare fino a 18 fra siluri e missili nucleari. Da notare che i sommergibili nucleari sono a tutt'oggi meno silenziosi dei classici elettrodiesel perché reattore nucleare e pompe di raffreddamento non possono essere disattivati nemmeno a eliche ferme.

Terrore della NATO codice "SA-21 Growler", anche noto come S-400 Triumph. Missile terra-aria con 400 km di gittata, viaggia a settemila chilometri orari (Mach 6.2) e può intercettare aerei da guerra come gli F-22 e gli AWACS, gli F-117 e i bombardieri B-2, oltre ovviamente a missili da crociera e balistici. Un sistema completo può individuare e colpire fino a 80 bersagli contemporaneamente.

Terrore della NATO codice "Fullback", anche noto come Sukhoi Su-34. Collaudato cacciabombardiere d'attacco e bombardamento a medio raggio. Due turboventole con postbruciatori, max 1900 km/h in quota, equipaggiato con tutto un arsenale di bombe, missili e razzi, più un cannone di precisione da 30mm. Previsto per lunghe missioni, al punto che la cellula è pressurizzata e il pilota può anche alzarsi in piedi. Nel 2015-2016 è diventato famoso per aver massacrato l'ISIS con bombe di precisione (ben altro che quelle "intelligenti" americane che beccano puntualmente i civili).

Venditore di carciòffole alla fermata del pullman

Questo gentile negozio ambulante di carciofi arrostiti ha eletto come sede aziendale (amministrativa e operativa) la sofisticata pensilina della fermata dell'autobus (già tappezzata di manifesti abusivi), alla faccia dei pendolari e del Nucleo Anti-Sofisticazioni.

Che poesia

Fogliolina annegata all'interno di una scarpa allagata:

Ed è appena ricominciata la pioggia!

Come godo!! Piccolo upgrade hardware: serverino casalingo Kaby Lake

A confronto col Mac Mini

Caratteristiche tecniche:
- chipset Core i5 7200U di settima generazione 14nm, 2 core, 4 thread, TDP 15 watt, 2.5 GHz (Turbo 3.1 GHz)
- case in alluminio per dissipare il calore generato
- niente parti in movimento (fanless, SSD)
- stringa identificativa del fabbricante: "Default String" 😄
- dimensioni motherboard inclusi connettori saldati su piastra: 165x125mm
- dimensioni case escluse protrusioni antenne wifi: 18x22cm circa

All'interno:
- ethernet gigabit (on-board): Realtek R8169
- 2x SATA 6gbps (on-board), uno l'ho usato per un SSD Crucial
- 1x slot PCIe occupato da scheda Broadcom BCM4727 wifi + bluetooth
- 1x slot mSATA (nel mio caso ancora vuoto perché ho montato un SSD Crucial su una SATA)
- 2x slot SODIMM (nel mio caso occupati da 2x 8Gb DDR3L 1600: sudo lshw -short -class memory).

Ubuntu 16.04 installato senza alcun problema (Fedoraaaa? Tié!!)

---

Come godo!! Tremendo upgrade del serverino casalingo.

Motivazione principale per acquistarlo:

• il momento di panico di un venerdì sera quando l'altro non si accendeva.
  • Mai avere un unico computer serio: se si guasta sei nella cacca fino al collo (figurarsi se il guasto avviene quando i prezzi sono alti e/o i negozi chiusi per ferie) fino a che non compri il nuovo, ripristini i backup e configuri e metti in opera il nuovo...

Motivazione secondaria:

• era in offerta speciale ed aveva le caratteristiche tecniche che mi interessavano... e poi pure per ridondanzae backup dati.
  
  • Ridondanza: tutto ciò che ti è indispensabile deve avere un backup vivo e palpitante - uno per uso intensivo, e l'altro per uso leggero e che funga da alternativa valida quando il primo a sorpresa ti lascia a piedi.

Caratteristiche che considero essenziali:

• dovendo restare acceso 24/365 in ambiente abitato, non deve avere parti in movimento (né hard disk, né ventole) e deve avere un buon rapporto performance/consumi.

Unboxing

L'aggeggio che ho comprato ha queste caratteristiche:
- Core i5 "Kaby Lake" 7200U (chipset normalmente usato sui notebook)
- 16 Gb RAM
- 4 porte USB 2.0 + 4 porte USB 3.0
- uscite VGA e HDMI (infatti ci piloto due monitor in modalità estensione desktop)
- SSD 240 giga (che avevo già comprato un anno fa)
- ethernet, wifi, bluetooth, jack microfono e cuffia
- case in alluminio
- niente ventole, niente speaker: totalmente silenzioso

Vantaggi: bassi consumi e non scalda:
- gli basta un alimentatore 12V 5A;
- con Ubuntu in idle i consumi che ho rilevato personalmente sono sui 9-12 watt (misurati a monte dell'alimentatore, cioè sulla 220V), che scendono a 6-7 watt se le uscite video sono in power saving;
- a pieno regime di CPU e disco, i consumi non superano i 35-36 watt
- la temperatura in idle sembra essere tipicamente non superiore di 7-8 gradi rispetto alla temperatura ambiente.

Svantaggi:
- non ha uno slot per memorycard
- al posto dell'uscita VGA avrei preferito una DisplayPort (DP e HDMI infatti trasmettono anche l'audio)
- a differenza di un tablet/notebook, non ha una batteria di backup: dovrò pensare ad un gruppetto di continuità...

Test sulla potenza di calcolo: il mio classico rendering POVray in quattro threads concluso in meno di 27 minuti (circa trentaquattro volte più veloce del Pentium III 700 MHz comprato nel 2001); il processore ha girato a 3.1 GHz ("Turbo mode") non superando i 62 gradi centigradi di temperatura (l'ambiente era a circa 18 gradi; a 100 gradi il processore va automaticamente in protezione). Un minuto dopo il rendering la temperatura del processore era già tornata sotto i 35 gradi.

Per confronto, l'altro Core i5 "Broadwell" 4200U ha terminato in meno di 42 minuti girando a 2.3 GHz; grosso modo il 7200U, a parità di clock, guadagna il 10-15% (sospetto sia dovuto alle intervenute ottimizzazioni su istruzioni SIMD sfruttate da POVray, per cui sono del tutto secondarie).

Considerazioni economiche:

Rispetto ad un Core i7 6700K ha il 10% in meno di prestazioni ma consuma cinque volte di meno. È incredibile come per avere un 10-20% in più di prestazioni (che non si notano, poiché la percezione della velocità è logaritmica) oggi occorra spendere il quadruplo, consumare il sestuplo di kilowatt, e avere una catasta di ventole che girano furiosamente. Ai bei tempi, invece, spendendo il 30-40% in più si avevano processori che andavano anche cinque-dieci volte più veloce, e valeva la pena. Saranno almeno dieci anni che il rapporto "gigahertz/euro" non cresce più in modo significativo. Perfino il recentissimo Rizen AMD è grosso modo a metà strada tra il Core i5 e il Core i7.

In più ho scoperto che l'SSD Crucial 240 Gb che avevo pagato 76 euro a gennaio 2016 ora sia prezzato sui 90 euro, proprio come il modello successivo. Non c'è stato il previsto crollo del rapporto "gigabytes/euro".

Riciclo vecchi televisori CRT

Promemoria tecnico:

• oltre 700 milioni di televisori CRT (a tubo catodico) venduti in USA dal 1980
• ormai lì tutti sono passati ai nuovi modelli flat-panel
• 700 milioni di apparecchi da smaltire sparsi in giro

I tubi catodici sono catalogati come materiali pericolosi perché contengono piombo (leaded glass: anche diversi chilogrammi per televisore) e altro.

Dunque lì sono nate aziende che promettono di riciclarli:

• raccolgono decine, anzi, centinaia di migliaia di tonnellate di vecchi TV CRT
• si accorgono che riciclare costa troppo (molto più del costo del TV nuovo)
• aumm aumm sotterrano buona parte del malloppo fingendo di averlo riciclato
• e intanto stanno pure andando in bancarotta.

La parte tragicomica è che i TV CRT sono molto più facili da riciclare rispetto ai televisori più recenti...

Come PAGARE POCO i programmatori!!

Quando un'azienda ha bisogno di produrre software, deve affrontare una spesa fastidiosa e imprevista: pagare i programmatori. Che non rispettano quasi mai le scadenze di consegna decise a tavolino dai manager. Che a volte hanno bisogno di un giorno di ferie per questioni familiari, e certe volte addirittura si ammalano. Che a volte addirittura si licenziano per andare a lavorare da qualche altra parte o mettersi in proprio. Che in certi casi trovano addirittura l'appiglio per chiedere aumenti di stipendio.

Vediamo dunque i Dieci Trucchetti per Pagare Poco i Programmatori, tutti basati sul principio che per pagare il meno possibile bisogna non solo tener bassi gli stipendi, ma anche dar loro meno appigli possibili.

1) La paga deve essere un argomento tabù. Nell'azienda non si deve mai discutere di stipendi, bonus, benefit, eccetera. Non sia mai che un programmatore scopra di essere pagato meno di qualche collega nullafacente e incompetente. Non sia mai che un programmatore capace e di grande esperienza scopra di avere lo stesso stipendio della segretaria. Se nell'ambiente l'argomento è già tabù (come quasi ovunque a causa delle invidie e dei curiosoni che ti fanno i conti in tasca su ogni cosa), i nuovi arrivati si adegueranno subito, credendo magari di essere dei privilegiati ed eviteranno di far domande scomode.

2) Aumenti e benefit devono essere del tutto imprevisti. Non devono esserci regole (neppure verbali e informali) su quando e come arriverebbero, per evitare che qualcuno se ne ricordi e soprattutto per evitare che qualcuno pensi di meritarne a causa dei risultati appena raggiunti. Se chi ha il potere di decidere gli aumenti li concede in maniera imprevedibile, anche i più meritevoli resteranno lungamente in attesa di quel momento magico, anche se si sentono sottopagati.

3) Tener tutti sotto controllo. Server di posta aziendale, computer aziendale, magari anche telefonino aziendale, videocamere di sorveglianza e macchina aziendale con tracking GPS. Anche senza spiarli davvero, bisogna fare in modo che non osino contattare altre aziende o abbiano conversazioni "private ma di lavoro" durante gli orari di lavoro. La sola paura di essere scoperti a "tradire" l'azienda per qualche dollaro in più è un ottimo deterrente alle richieste di aumenti di stipendio e benefit.

4) Accordarsi coi concorrenti: io non tocco i tuoi, tu non tocchi i miei. Se qualcuno dei miei ti manda un curriculum, voglio essere il primo a saperlo, e farò altrettanto per te. Tra manager ci s'intende - questo genere di accordi funziona benissimo - e se qualche manager non si accordasse lo capirà non appena tenterai di reclutare personalmente qualcuno dei suoi migliori programmatori offrendogli un dieci-quindici per cento in più di quanto già prendeva.

5) Stressare i programmatori. Non devono mai sentirsi freschi o rilassati. Devono sempre avere scadenze strette, problemi da risolvere, compiti arretrati da riconsiderare, e parecchi sensi di colpa - grazie ai quali si sentiranno a disagio nel chiedere aumenti. Il progetto deve sempre sembrare in ritardo e loro devono sentirsi il più possibile responsabili di intoppi e problemi, temendo di sentirseli rinfacciare in caso di richieste di aumenti.

6) Promettere non significa mantenere. Perciò si possono promettere futuri aumenti, imminenti investimenti, ma sempre da rinviare ad un imprecisato "momento giusto" dopo le calende greche, mai da associare a eventi importanti e verificabili. Poi, al "momento giusto", invece dell'aumento si può comprare una nuova lussuosa macchinetta per l'angolo caffè, cosa che susciterà vasto plauso e costerà meno di un singolo aumento.

7) Distribuire titoli nobiliari. In certi posti con molto personale questa strategia funziona perché i gonzi provano più gusto a scrivere sul proprio Linkedin i titoloni insignificanti Technical Architect Team VicePresident Senior Lead Consultant Specialist Manager che chiedere quanto manca ancora al benedetto "momento giusto" di quell'aumento più volte promesso e mai arrivato. E quando veramente meriterebbero un aumento, invece di concederlo falli sentire importanti: fa' chiamarli da uno degli altolocati super-manager che reciti loro un bel sermone sugli ottimi risultati conseguiti, consegni un'elegante lettera di encomio, e dia perfino in omaggio il prestigioso portachiavi aziendale (o gadget altrettanto insignificante).

8) Costruire un ambiente "familiare". Eventi aziendali, torte di compleanno, panettone a Natale e colomba a Pasqua, posto auto come se fosse un prezioso ineguagliabile diritto, angolino caffè con lussuosa macchinetta a cialde e distributore automatico di merendine, magari il diritto di portare il proprio cane in ufficio, o addirittura la Giornata dei Figli in Ufficio, talvolta persino scrivanie nuove e computer ben carrozzati (meglio spendere seicento euro per un PC nuovo che dare cento euro mensili di aumento). A furia di ripetere che i soldi "non sono tutto", di fronte a tutti questi micro-benefit uno si sentirà traditore dei valori familiari-aziendali nel chiedere un aumento...

9) Concedere generosamente aiutini. Deve comprare la macchina e non sa come gestire le rate? Deve organizzarsi per qualche cartella delle tasse? Deve prenotare una visita specialistica? Deve spedire i punti della Mira Lanza e gli mancano busta e francobollo? Si faccia in modo che la segretaria sbrogli le loro pratiche (così anche lei produce qualcosa di più utile che le solite telefonate e fotocopie) e loro pensino di aver immeritatamente sfruttato risorse aziendali per i propri comodi.

10) Sii un amico. Questa è la tecnica più potente di tutte. Devi essere amico dei tuoi programmatori, perché è difficile negoziare soldi con un amico. Per cui in aggiunta a tutti quei benefit che costano poco all'azienda, aggiungi telefonate non di lavoro, la cena con le loro famiglie (magari anche a casa tua), perfino i biglietti omaggio per il cinema "non posso usarli ma so che a tua moglie piacerebbe vedere quel film". All'amico è difficile dire di no quando si tratta di rimanere in ufficio oltre l'orario di lavoro, ma guarda caso l'amico del programmatore non ha mai tempo per parlare di busta paga e di aumenti. E poi, programmatore incontentabile e viscido, dopo tutto quello che l'azienda ha fatto per te vieni pure a chiedere altri soldi?

Statistica di fondamentale importanza

E che facciamo, bau bau micio micio? Ecco i nomi più gettonati per i gatti in Giappone, secondo la statistica condotta dal sito web Iris Pet:

ｍｉｃｅｔｔｉ　ｍａｓｃｈｉ：

1 (pari merito). Reo ("leone", imitando lo spagnolo "Leon", cioè "leone")
1 (pari merito). Tora ("tigre")
1 (pari merito). Kuro ("nero")
4. Kotaro (nome proprio di persona)
5 (pari merito). Maron (imitando il francese "Marron", cioè "castagna")
5 (pari merito). Kotetsu ("piccolo ferro")
7. Maru ("rotondo")
8 (pari merito). Momo ("pesca")
8 (pari merito). Fuku ("fortunato")
8 (pari merito). Hachi ("ciotola")
8 (pari merito). Tama ("palla")
8 (pari merito). Sora ("cielo")
8 (pari merito). Koko ("qui")

ｍｉｃｅｔｔｅ　ｆｅｍｍｉｎｅ：

1. Nana ("7")
2. Hana ("fiore")
3. Koko ("qui")
4. Hime ("principessa")
5. Mike ("tartarugata", nel senso dei colori)
6 (pari merito). Momo ("pesca")
6 (pari merito). Chibi ("piccoletta")
8. Sakura ("ciliegia")
9. Kuro ("nera")
10 (pari merito). Mei ("nipote")
10 (pari merito). Mugi ("orzo")
10 (pari merito). Mii (solo onomatopeico)
10 (pari merito). Fuku (fortunata)
10 (pari merito). Chacha (solo onomatopeico)


Top ten assoluta (per diffusione totale), necessaria perché alcuni nomi sono sia maschili che femminili:

1. Koko ("qui")
2 (pari merito). Nana ("sette")
2 (pari merito). Kuro ("nero")
4 (pari merito). Momo (pesca)
4 (pari merito). Hana ("fiore")
4 (pari merito). Chibi ("piccoletto")
7. Mike ("tartarugata")
8. Hime ("principessa")
9. Fuku ("fortunato/a")
10 (pari merito). Reo ("Leone")
10 (pari merito). Rin ("fosforo")
10 (pari merito). Mii (solo onomatopeico)
10 (pari merito). Tora ("tigre")
10 (pari merito). Tama ("palla")