La Juve ha sempre rubato le partite...

...per cui devi anche stare attento a dove metti i piedi!

Ciampate feline sul parabrezza

QRcode indirizzo blog in LEGO

La superficie di un QR-code con correzione minima è di 21x21 pixel per un link fino a 17 caratteri (incluso lo spreco di "http://"), con più caratteri sprecherebbe più spazio (e dunque più pezzi LEGO) per cui ho provato un po' di URL shorteners per abbreviare https://particolarmente-urgentissimo.blogspot.com ed il risultato è questo:

• https://tinyurl.com/mdo3cxl - 27 caratteri

Tinyurl esiste da quindici anni e ormai è difficile trovare una sequenza più breve di quella random suggerita di default.

• http://ow.ly/MIBR30b6cSB - 24 caratteri

Questi sono da prendere a pedate: URL cortissimo e hash chilometrico, cioè non vogliono intrusi perché serve solo per le loro apps Hoot Suite (che peraltro facevano cagare).

• https://t.co/k3hrnaz79C - 23 caratteri

Questo è il servizio di Twitter, che però in pochi anni ha creato uno sproposito di hash anche su URL ripetuti più volte poiché (mica fessi) ci fanno statistica (quando creato, da quale IP, usato da chi...).

• http://bit.ly/2oj2Aq2 - 21 caratteri

Non male, ma siamo ancora troppo larghi.

• https://is.gd/2bePLX - 20 caratteri

Anche questi sono da prendere a pedate perché prepongono una schermata di conferma della cliccata, considerando "spam" i blog della piattaforma Blogspot appartenente all'odiata Google.

• http://goo.gl/pLSxwQ - 20 caratteri

Ahimé, lo shortener di Google (cioè quello che più sicuramente durerà fino alla fine di internet) è di 20 caratteri.

• http://bit.do/alfq - 18 caratteri

Lo shortener Bit.Do permette di scegliersi sequenze cortissime, anche di 3 o 4 caratteri, e siccome "alf" era già usato da un tale Alfredo Luzon che non ha più il sito, ho dovuto aggiungere una lettera e salire così a 18 caratteri, che è ancora troppo.

• http://bit.do/xq3 - 17 caratteri!

Finalmente! Dopo qualche tentativo con le lettere più improbabili scopro che la combinazione xq3 non era stata ancora usata e quindi ho finalmente un URL sufficientemente corto

Fuori classifica ci sarebbe anche x.co, lo shortener del provider Godaddy, che permetteva sequenze di quattro lettere casuali (avrei ridotto a 16 caratteri), ma i furbacchioni hanno deciso che il servizio è utilizzabile solo da chi compra loro prodotti.


Dunque inserisco http://bit.do/xq3 in uno dei tanti siti che permettono di creare un QRcode (tipo goqr.me), lancio il LEGO Digital Designer e ricopio il disegno (c'è voluto meno a ricopiarlo a mano che a cercare una di quelle utility che ti chiedono il link e ti generano il progetto già pronto, inoltre ho tentato di sfruttare al massimo le flat tile nere che già ho a stock) e il risultato è questo:

E naturalmente ha funzionato al primo colpo, scandendolo così, dallo schermo del PC al programmino mBarcode del cellulare:

Oggi sta inquartato

Cavalleria Rustica

Foto 1, cliccare per ingrandire: "Quiz patente: indovina chi intralcia l'incrocio":

Foto 2: osservare l'ombra, il cavallo sta letteralmente volando:

The Almighty ComputerMan in the SuperMarket !!!

Giacca. Cravatta. Computer portatile poggiato sul cestone "gruppo tre calze tennis" (in modo che se ne perdi una te ne resta una di scorta). Cuffie iPhone con musica comprata su iTunes. Connessione wifi del supermercato. Zaino poggiato a terra con batteria esterna USB per il telefonino, ricaricabatterie del notebook, vari gadget USB indispensabili quando si è in giro. Aria estremamente professionale.

Secondo me sta controllando se i calzini in offerta a 3,99€ si trovano su Amazon a 3,49€, in modo da risparmiare comprandoli on-line.

Come godo!! Huzzah power in my hands!

Ho comprato questi Adafruit Huzzah, microcontroller con wifi (sia client WPA2 che accesspoint, basato su ESP8266) a 80 MHz, con alimentazione da batteria 3.7V (e da USB con ricarica) e nove pin GPIO (alcuni dei quali rimappabili in una SPI e una I²C).

A bordo c'è già installato il firmware NodeMCU basato su una versione semplificatissima del linguaggio scripting Lua (per cui non ho neppure bisogno di usarlo in modalità Arduino) con tanto di prompt comandi sulla seriale USB.

L'applicazione-tipo è questa:

• sempre connesso alla wifi di casa
• ogni tot secondi legge il valore dei pin
• invia il risultato su socket del server (in pratica: serve per accedere a quei pin via wifi anziché i soliti bluetooth o porta seriale).

Oltre ai soliti moduli per i sensori più diffusi (lux, umidità, ecc.) le librerie supportano anche features simpatiche (HTTPS client, crittografia SHA256, client MQTT, data/ora da SNTP, client Websocket, stati deep sleep, ecc.; alcune richiedono la ricompilazione del nodemcu) fermo restando il limite di una ventina di kilobytes di RAM; del resto, se deve solo inviare valori ad un server locale o a un broker Mosquitto, gli basta la connessione wifi e il client HTTP, non ha bisogno neppure di conoscere data/ora.

Come tutti i prodotti originali Adafruit è ottimo ma costa un sacco di soldi (attualmente 3600 euro al chilo).

Il buongiorno si vede dal mattino:

• impostare il terminale seriale a 9600 8N1 sulla porta /dev/serial/by-id/usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_0136E32E-if00-port0
• premere il tastino di reset, compare la scritta: NodeMCU 0.9.5 build 20150318  powered by Lua 5.1.4
• se non è ancora impostato un autoexec (init.lua) comparirà anche la scritta lua: cannot open init.lua
• al prompt dare i comandi per connettersi e verificare l'indirizzo IP assegnato:
    wifi.setmode(wifi.STATION)
    wifi.sta.config("SSID_del_mio_wifi", "mia_password")
    print(wifi.sta.getip())
• a questo punto può trasferire dati via internet:
    c = net.createConnection(net.TCP, 0)
    c:on("receive", function(s, c) print(c) end )
    c:connect(80, "www.adafruit.com")
    c:send("GET /testwifi/index.html HTTP/1.1\r\nHost: www.adafruit.com\r\nConnection: keep-alive\r\nAccept: */*\r\n\r\n")
• (cioè: crea una connessione attraverso il wifi, associa un evento in caso di "receive", invia una GET.... e qualche attimo dopo, in caso di "receive" andata a buon fine, arriva la stringa di Adafruit "if you can read this, it's working :)"
• ovviamente non è necessario accedere al web, si può usare anche un IP fisso su una rete locale wifi.

Propulsione a elica per ciclisti sfaticati

La parte seria del video comincia a 0:46.

Valigia trolley che segue il proprietario

Ah, questo sì che è un brevetto: una valigia motorizzata wireless con sensore nella scarpa e apps sul cellulare, che ti segue senza farsi trascinare. Se ne sentiva proprio il bisogno. E poi dicono che l'ufficio brevetti sta senza far niente da mattina a sera...

Ennesima figuraccia degli americani

Costo di un missile BGM-109 "Tomahawk": 1,87 milioni di dollari.

Il costo è giustificato dal fatto che portano 450 kg di esplosivo a 1300 km di distanza a una velocità di 900 km/h, con un sistema di guida super sofisticato (GPS, accelerometri/inerziale, telecamere che analizzano i contorni del terreno sottostante, database di immagini digitalizzate con analisi in tempo reale, radar interno di ricerca finale del bersaglio). Praticamente infallibili.

Ultime notizie: gli americani per distruggere un aeroporto siriano lanciano ben 59 Tomahawk, di cui solo 23 hanno colpito il bersaglio.

In termini economici, più del 60% ha fallito il bersaglio.

In termini pratici: hanno speso 110,33 milioni di dollari (grosso modo il costo di trecento-quattrocento appartamenti per trent'anni di mutuo ciascuno) per rendere inagibile per mezza giornata un semplice aeroporto (in serata l'aviazione siriana riprendeva i voli).

Domanda: ma come mai il Pentagono non intenta causa contro la casa produttrice Raytheon?

 

Raytheon "Tomahawk":
peggio dei discount "Made in China"

 (e io che da piccolo sognavo di lavorare nel settore militare, dove i progetti e le realizzazioni sono "a norme militari", cioè perfezione, precisione, affidabilità)

Le ultime parole famose: (dal Washington Post)

“Vediamo queste belle immagini notturne dal ponte di queste due navi della Marina [americana] nel Mediterraneo orientale” ha detto Williams, “Sono tentato di citare il grande Leonard Cohen: ‘Sono guidato dalla bellezza delle nostre armi.’”

“Ecco le splendide immagini delle nostre terribili armi mentre si lanciano in quello che per loro è il breve volo sopra quell'aeroporto,” ha aggiunto, e quindi ha chiesto al suo ospite: “Allora, cosa hanno colpito?”

Figurin figurin figurin...

figuremmèrd!!

The moment is cathartic!!

Inaudito: la lancetta del serbatoio è a fondo scala ma nella parte opposta!

Dopo dieci anni di incessante spionaggio della spia della riserva, è la prima volta che la lancetta della benzina emette il più virile grido di guerra: «se aumenta l'accise, ho fregato lo Stato!»

Movfuscator

L'idea geniale di movfuscator è questa:

compilare un intero programma usando solo istruzioni MOV, poiché la MOV è nientemeno che Turing-complete.

L'intero programma compilato avrà un lunghissimo listato assembler di questo tipo:

start: MOV ...
       MOV ...
       MOV ...
       ...
       MOV ...
       MOV ...
       JMP start

Infatti tutto si può ridurre alla MOV, inclusi if/switch/loop e chiamate di funzioni.

Sarà più lento da eseguire e richiederà più memoria ma praticamente tentare di disassemblarlo sarà impossibile, perché le funzioni e i calcoli non si distingueranno più - è solo una fastidiosissima e lunghissima sequenza di MOV (vedi per esempio un banale programmino in C di quindici righe che calcola numeri primi può essere "compilato" ad un listato di 5744 istruzioni MOV).

Vediamo come si fa.

Esempio 1: selezionare un valore da un array (cioè le singole variabili del programma possono essere indicate non con l'indirizzo di memoria ma con un numero, anche piccolo):

MOV R, 1            ; scegli la variabile 1...
MOV R, [array + R]  ; ...indicizzando

Esempio 2: con l'esempio precedente il confronto tra X e Y (CMP x,y) si può ridurre a:

MOV [X], 0  ; scrivi all'indirizzo X un byte 0
MOV [Y], 1  ; scrivi all'indirizzo Y un byte 1
MOV R, [X]  ; leggi in R un byte dall'indirizzo Y

Se X e Y sono lo stesso numero, allora la seconda MOV sovrascrive quello zero con un 1, e quindi alla fine R=1; altrimenti la terza istruzione leggerà il valore zero scritto dalla prima.

Più variabili (vere o temporanee) servono, e più si può allargare l'array.

Esempio 3: il costrutto IF x==y THEN z=100 si può ridurre a:

• una "CMP" come da esempio 2 (che restituirà 0 oppure 1 a seconda di x==y)
• usare il risultato 0/1 come da esempio 1, cioè come locazione in cui scrivere il valore 100
• ignorare la locazione 0 (scritta solo se "x==y" non risulta verificato)
• usare la locazione 1 (scritta solo se "x==y" risulta verificato) per scrivervi 100

Con lo stesso metodo applicato più volte si possono usare più di due "rami", cioè costruire tutte le varianti if/else/switch.

Esempio 4: i costrutti while/loop si possono ridurre a un calcolo che viene eseguito solo se la condizione era verificata:

• una IF condizioneloop==1 THEN z=100 ELSE ignoraz=100;

Questo significa che il codice del loop viene sempre eseguito, nel ramo da usare o nel ramo da ignorare (quest'ultimo scrive in una locazione che non verrà usata).

Esempio 5: le chiamate di funzioni e l'allocazione dinamica della memoria si possono fare usando qualche array come "stack", e i costrutti indicati negli esempi 1,2,3.

In tal modo può funzionare perfino la ricorsione.

Esempio 6: le operazioni matematiche si possono eseguire usando tabelle (array) già calcolate. Per esempio, quando un programma vorrebbe eseguire X = Y * 2, basterà avere:

array Raddoppio = [ 0, 2, 4, 6, 8 ...]

MOV X, [ Raddoppio + Y ]   ; se Y=3, troverà 6, ecc.

Il codice compilato si riempirà di tabelle precalcolate, ma non saranno troppe visto che ogni volta che hai bisogno di moltiplicare per due puoi sfruttare la stessa tabella.

Anche le operazioni logiche AND OR NOT si possono ridurre a tabelle (array) da cui estrarre risultati usando MOV.

Le operazioni in virgola mobile possono essere emulate a suon di MOV grazie a una libreria soft-float scritta in C che una volta compilata diventa di appena mezzo milione di istruzioni MOV.

Infine: anche l'istruzione assembler XOR è Turing-completa. Quindi si può fare uno Xorfuscator. Anche la ADD è Turing-completa. Anche SBB, anche CMPXCHG/XCHG, eccetera. Caos!! ☺

Nella directory poc/crackme c'è un piccolo esempio: un programmino crackme che chiede una password prima di scrivere OK. Ai bei tempi bastava usare PCTOOLS per trovare il singolo byte del JUMP da modificare per far accettare qualsiasi password. Ora invece bisogna scovare tutte le MOV interessate all'emulazione di quel JUMP, all'interno di un file eseguibile che contiene centinaia di migliaia di MOV....

Internet of Things, cioè bidonata

Riassunto:

- tizio compra serratura garage comandabile da iPhone: Garadget!

- ma l'apps iPhone va spesso in crash

- tizio dunque lascia pessima recensione su Amazon e lascia sul forum di supporto Garadget una breve lamentela dell'apps

- produttore della serratura Garadget per vendicarsi della recensione e delle parole "piece of shit" blocca l'accesso ai server all'apps di tizio, cosicché la serratura non si apre più perché l'apps non può più connettersi.

Morale:

- mai comprare oggetti che hanno bisogno di un'apps: le apps si collegano ai server del produttore (quale produttore non lo farebbe?), non solo dandogli la possibilità di avere il completo controllo, ma anche di disattivare a distanza il proprio prodotto (come ha fatto il produttore vendicativo);

- ad eccezione del computer, mai comprare oggetti che hanno "bisogno" di collegarsi a internet: come le Smart-TV della Samsung e della LG hackerabili da remoto, la Smart-Disinfettatrice della Miele hackerabile da remoto, lo Smart-Frigorifero della Samsung, perfino lo Smart-Mouse (una merda di mouse che senza collegamento a internet non ti faceva muovere la freccetta! vergogna!!!), senza contare tutta la selva di stampanti, telecamere di sorveglianza, ecc., hackerate a distanza (vedi anche Shodan).

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