Amo la tecnologia e l’informatica da quando misi le mani sulla tastiera di un 286, ho vissuto l’evoluzione dei pc e vivo quotidianamente questa passione nel mio lavoro. Già nel 2016 avevo colto diversi segnali e scritto un articolo sulla mia visione di un futuro ARM. Apple M1 rappresenta oggi il punto di svolta della mia visione.

Apple M1: la nuova era dei personal computer

Con il chip Apple M1 inizia una nuova era per i personal computer. Dopo ormai 40 anni di assemblaggio di pc con il pattern CPU + GPU + RAM finalmente è arrivata una nuova architettura, un nuovo modo di elaborare.

Cosa ha portato a questo cambiamento? L’evoluzione! Si sono evolute le esigenze degli utenti, si sono evoluti i software, si sono evoluti i processi produttivi. Aumentare i Ghz ed i core delle CPU non era più sufficiente, anzi efficiente. Il nuovo SoC Apple M1 (system on a chip) compie questo salto, un ecosistema con 16 miliardi di transistor che integra CPU, GPU, Neural Engine, crittografia, I/O su un unico circuito.

Non solo chip Apple M1

Apple non è l’unica ad aver sviluppato SoC di questo tipo. ARM, ora di Nvidia, ha presentato pochi giorni fa il suo Cortex-A78C che sfida direttamente Apple M1. Ci sono poi gli Snapdragon di Qualcomm sui Surface di Microsoft ed Amazon che utilizza il suo Graviton2 nei suoi server AWS.

Allora, cos’ha il chip Apple M1 che gli altri non hanno? Oltre alla possibilità economica di investire nello sviluppo, il vero x-factor è l’impronta della visione di Jobs di un sistema totalmente integrato tra hardware e software incentrato sull’esperienza dell’utente. Da sempre i Mac hanno dato molto di più con (molto) meno grazie ad un sistema operativo ottimizzato per un hardware specifico che non producevano direttamente… fino ad oggi!

Il lato oscuro dell’era Mac con ARM

Il passaggio di architettura è stato a mio avviso ben studiato da Apple così come l’esperienza utente che offrirà. Sono stati forniti diversi strumenti per consentire la migrazione, da Rosetta2 per l’esecuzione dei i software compilati per x86, alle app universal che potranno girare “facilmente” su iOS, iPadOs e macOS.

Quindi solo aspetti positivi? Speriamo, ma mi rimangono diversi dubbi su quanto il sistema operativo verrà chiuso e quali saranno le politiche per la distribuzione del software. L’utenza di iPhone ed iPad è diversa da quella dei mac ed un’eccessiva chiusura, così come l’imposizione del passaggio da App Store e dalla “tassa” del 30% sulla vendita del software, potrebbero portare alla scomparsa di diversi software da questo sistema.

Il futuro ARM dei personal computer

Sicuramente assisteremo ad un passaggio, neppure troppo graduale, verso queste architetture da parte di tutti i produttori di PC ed in buona parte degli ambiti applicativi, dall’office al gaming passando per i server. Intel dovrà darsi una mossa perché rischia di finire come Nokia nel passaggio dal cellulare allo smartphone.
Guardando ad Apple, sulla carta è tecnologicamente favorita, ma conteranno molto le politiche commerciali relative alla distribuzione del software che deciderà di adottare.

L'articolo Apple M1 (Silicon): il futuro dei personal computer secondo me. sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

Architettura REST: cos’è?

Additional constraints can then be applied to form a new architectural style that better reflects the desired properties of a modern Web architecture.

REST vede la luce dieci anni dopo la nascita del World Wide Web, piattaforma per la condivisione di documenti distribuiti su server connessi tra loro. L’acronimo REST (REpresentational State Transfer) viene introdotto nel 2000 nella tesi “Architectural Styles and the Design of Network-based Software Architectures” di Roy Fielding definendo così uno stile architetturale basato sul Web che fissa un insieme di principi per la progettazione di un sistema hypermedia distribuito.

REST è quindi un modello di progettazione e non va confuso con un protocollo (non definisce messaggi) nè con una specifica (non definisce uno standard), ma opera ad un livello di astrazione superiore.
Non è quindi del tutto corretto confrontarlo con il protocollo SOAP anche se entrambi sono oggi ampiamente usati nello sviluppo dei Web Service.

In estrema sintesi:

REST detta le regole per creare una piattaforma per l’elaborazione distribuita dei dati sfruttando l’architettura Web già dotata di tutto ciò che occorre: da una parte un’infrastruttura basata su protocolli ben definiti (HTTP in primis) dall’altra le informazioni viste come risorse mappate univocamente (URI).

I principi dell’architettura REST

Iniziare con un approccio “Null Style”

Il “Null Style” è il punto di partenza: un sistema in cui non ci sono confini distinti tra i componenti (risorse) che andranno connessi. I seguenti principi dell’architettura REST rappresentano i vincoli per standardizzare l’accesso alle risorse distribuite in questo scenario.

Client-Server

L’architettura REST applica il paradigma SoC (Separation of Concerns), “separazione dei compiti“, al sistema di funzionamento Client-Server (Richiesta-Risposta). Il vincolo Client-Server favorisce un’architettura distribuita in cui lo sviluppo applicativo lato client è indipendente da quello lato server. Questo spiega anche perché REST non si preoccupa dei linguaggi e dei metodi di sviluppo.

Stateless

La comunicazione tra utente del servizio (client) ed il servizio (server) deve essere priva di stato: ogni richiesta del client deve contenere tutte le informazioni necessarie al server per comprendere la richiesta e non deve sfruttare informazioni di sessione memorizzate sul server. E’ il client a gestire la sessione e, se necessario, dovrà ricevere opportune informazioni nella risposta del server.
Il vincolo stateless ha benefici sul monitoraggio delle richieste, sull’affidabilità e sulla scalabilità: non dovendo mantenere dati in sessione sarà più facile scalare orizzontalmente il servizio creando istanze parallele poste dietro ad un load balancer.

Cache

Nell’architettura REST il vincolo di Cache impone che le risposte siano etichettate come memorizzabili nella cache o meno. L’utilizzo della cache da parte di client, server o componenti middleware consente di ridurre le interazioni con la rete a tutto vantaggio delle performance.

Uniform Interface

L’architettura REST impone un vincolo di uniformità dell’interfaccia di accesso ai dati gestiti dal servizio, svincolandolo dalla specifica implementazione sottostante. Questo deve avvenire attraverso ulteriori sotto-vincoli.

Identificazione delle risorse

In REST ogni informazione è una risorsa, vista come qualsiasi cosa possa essere nominata: un documento, un’immagine, il meteo di oggi, …
Una risorsa può essere mutabile (l’ultima revisione di un documento) o immutabile nel tempo (la specifica revisione di un documento), l’unica cosa che deve essere statica è la semantica della sua mappatura, per questo motivo viene data una grande importanza all’identificazione univoca di una risorsa (URI) e alla necessità di mantenerla nel tempo.
Tale sotto-vincolo sottolinea lo scopo organizzativo proprio dei nomi di domino Internet.

Rappresentazione delle risorse

Una risorsa può essere rappresentata in molti modi diversi (HTML, XML, JSON, SVG, JPG, …) attraverso dati, metadati descrittivi ed eventuali “control data“. I dati di controllo possono definire lo scopo di un messaggio di richiesta o risposta, il suo comportamento o stato. Ad esempio possono specificare come gestire la cache di una riposta o la necessità di creare una risorsa sulla base dei dati e delle caratteristiche presenti nella richiesta.

Collegamenti tra risorse

L’architettura REST è pensata per connettere risorse tramite collegamenti ipertestuali. Questo principio è anche noto come HATEOAS (Hypermedia As The Engine Of Application State). Un Client deve quindi apprendere dalla rappresentazione di un risorsa fornita dal server (risposta) l’eventuale relazione con ulteriori risorse.
Ad esempio, richiedendo una fattura, la risposta dovrebbe contenere anche il link alla relativa anagrafica cliente.

Layered System

Un’architettura REST prevede più livelli architettonici, indipendenti l’uno dall’altro, frapposti fra client e server.
Gli strati intermedi possono avere scopi specifici durate il transito dei dati come ad esempio la sicurezza, il caching o il balancing.
I livelli potranno essere modificati in base all’evolversi dello scenario.

Code-On-Demand

L’ultimo vincolo di code-on-demand è facoltativo e consente ad un’implementazione REST di estendere le funzionalità del client scaricando ed eseguendo il codice sotto forma di applet o script. Ciò appare oggi abbastanza scontato e potrebbe rendere questo vincolo facoltativo quasi paradossale, ma non lo era nel 2000 quando i contenuti Web erano per lo più pagine statiche renderizzate dal browser.

Differenza tra architettura REST ed servizio RESTful

Eroneamente usati come sinonimi, REST è il nome dello “stile architetturale” mentre RESTful viene utilizzato per qualificare un Web Service che rispetta i vincoli dell’architettura REST.

Architettura REST: i contro

• L’architettura REST si può applicare solo in ambito Web a differenza del protocollo SOAP.
• A causa del vincolo stateless c’è la possibilità di un aumento dei dati di ambiente restituiti ripetutamente in una serire di richieste (overhead per interazione). Il vincolo di Cache cerca di compensare questo aspetto.
• A causa del vincolo stateless, spostando il controllo sul client si riduce il controllo da parte del server sul comportamento coerente dell’applicazione.

L'articolo Architettura REST per sviluppare Web Service sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

Di seguito i comandi da lanciare, uno dopo l’altro.

diskN deve essere sostituito con il disco che rappresenta la nostra SD. Il comando diskutil list mostrerà infatti la lista dei dispositivi montati dal osx. Conoscendo la dimensione della memory card, individueremo facilmente l’alias assegnato alla SD, ad esempio “disk2“.

diskutil list 
diskutil unmountDisk /dev/diskN 
sudo dd if=/dev/zero of=/dev/diskN bs=1024 count=1 
sudo dd bs=4m if=/Users/XXX/YYY/nome-immagine.img of=/dev/diskN

Per creare un’immagine da SD invece usare:

sudo dd if=/dev/rdiskN of=/Users/XXX/YYY/nome-immagine.img bs=1m

L'articolo Raspberry Pi: scrivere immagine su SD card con OSX sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

La periferica non è disponibile neppure verificando fra le periferiche in “informazioni su questo Mac”…

Problema: chiaramente è un problema legato al bluetooth, nella maggior parte dei casi di natura software. Ho mandato in assistenza il Mac (nel mio caso MacBook Pro R9) al quale è stata sostituita la scheda AirPort che fornisce le connettività bluetooth e wifi, ma con quest’ultima non avevo probemi e l’inconveniente si è ripresentato.

Ora, se fosse stato difettoso qualche componente della parte del bluetooth, il problema si sarebbe dovuto risolvere con il cambio di AirPort , diversamente, se fosse stato un difetto del connettore della scheda madre, allora avrebbe dovuto dare problemi anche il wifi.
Inutile dire che ho tentato anche la cancellazione dei file di configurazione dal plist e ogni altro trick trovato in rete. Nulla.

Soluzione: visto che il problema si presenta sporadicamente, ho trovato un sistema per riattivare il bluetooh: è sufficiente scollegare il mac da qualsiasi periferica e riavviarlo.
Se al riavvio si dovesse presentare ancora il problema “bluetooth non disponibile” eseguire nuovamente il riavvio  premendo il tasto D prima del bong, per entrare in modalià diagnosi. Attendere circa un minuto e mezzo per il check hardware, nel caso doveste ricevere l’errore DL001: problema all’hardware bluetooth, ripetete l’operazione.

Riavviando il mac ora il bluetooth dovrebbe funzionare nuovamente!

L'articolo Apple MacBook: errore DL001 – problema bluetooh non disponibile sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

Problema: la batteria si è deteriorata, ogni ciclo di carica ha ridotto la sua efficienza e l’indicazione di carica visualizzata sul display non corrisponde al vero.

Soluzione: ovviamente sostituire la batteria sarebbe la strada migliore da percorrere, ormai i cinesi le sostituiscono per pochi euro, ma possiamo ugualmente fare qualcosa, almeno per sopravvivere nel breve periodo.

Possiamo innanzitutto ricalibrare la batteria con pochi semplici passaggi:

• Facciamo scaricare completamente e lentamente il device, magari ascoltando musica a basso volume e con il display spento.
  Se si spegne prima di arrivare all’1%, colleghiamolo all’alimentatore per qualche minuto per poi staccarlo e continuare nella nostra operazione.
• Ricarichiamo completamente il device per tre orette, preferibilmente con l’alimentatore originale.
• Scollegate l’alimentatore e tenete premuti contemporaneamente i tasti Home + Accensione e riaccendete il device.

Ci sono poi alcune ottimizzazioni basilari che possono aumentare notevolmente l’autonomia della batteria e di conseguenza la sua vita:

• Disattiviamo i servizi di localizzazione e l’aggiornamento dei dati in background per le applicazioni che non sono fondamentali!
  Per la localizzazione andiamo nel menu
  Impostazioni > Privacy > Localizzazione
  variando i “sempre” in “mentre usi l’app” o “mai”.
  Per i dati andiamo invece nel menu
  Impostazioni > Generali > Aggiornamento app in background
• Quando siamo in un’area con scarsa copertura impostiamo la modalità aereo o impostiamo manualmente il gestore disabilitando il rilevamento automatico attraverso  il menu
  Impostazioni > Gestore > Automatico (OFF)
  La ricerca della rete e lo switch continuo da un operatore all’altro consumano molta batteria.
• Attiviamo la funzione di risparmio energetico che solitamente si inserisce quando il livello scende sotto al 20% attraverso il menu
  Impostazioni > Batteria > Risparmio energetico (ON)
• Disinstallare le app inutili che consumano troppa energia verificando questo dato attraverso la lista presente accedendo in
  Impostazioni > Batteria

Non tutti sanno che: la batteria degli iPhone è progettata per garantire almeno l’80% della capacità originale per 400/500 cicli di carica. E’ possibile controllare i cicli di carica utilizzando il software iBackupBot.

L'articolo Problema batteria iPhone / iPad: calibrazione ed ottimizzazione sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.

ARM è potente… ma non potentissimo.

Il primo indizio lo abbiamo sotto gli occhi: tutti gli applicativi utilizzati in ambito home / office (e non solo) che richiedevano fino a pochi anni fa l’utilizzo di un pc, oggi girano senza problemi su smartphone/tablet dotati di processore ARM.
Anche in ambito server è possibile trovare oggi soluzioni ARM piuttosto performanti, per non parlare dell'”ecosistema Pi” (Raspberry / Orange / Banana) dagli impieghi più disparati.

ARM consuma poco.

Un secondo indizio a favore di ARM sono i bassi consumi con relativa minore dissipazione di calore, ergo impiego mobile.
Non è una magia, questa differenza è data dai due differenti tipi di architettura: di tipo RISC con un “ristretto” set di istruzioni per i SoC ARM, di tipo CISC con un set esteso di istruzioni per quelli INTEL (e AMD). L’architettura semplice consuma meno, quella complessa di più.
Negli anni ARM ha lavorato sodo, le istruzioni si sono evolute mantenendo i consumi bassi mentre INTEL… mmm… ha prevalentemente migliorato i processi produttivi.

Un futuro ARM?

Il risultato è che oggi, nell’era della virtualizzazione, ARM ha raggiunto una maturità tale da poter “fare la mossa” (cit.) e virtualizzare anche le istruzioni x86/x64 dei processori INTEL.
Perché non può farlo anche INTEL? Beh, può farlo, ma l’enorme vantaggio di ARM è che lo abbiamo tutti in tasca e costa molto meno a chi produce i dispositivi.

Scenari futuri in stile film anni ’80

La mia visione è di una supremazia ARM su tutto il segmento consumer/small-business con INTEL legata alle workstation e agli ambienti enterprise server.

Ed ecco a voi un nuovo prodotto: il phonebook! Arriviamo in ufficio, sfiliamo dalla tasca il nostro smartphone, lo appoggiamo su una piccola dock collegata al monitor, tastiera/mouse bluetooth ed ecco il nostro ufficio sempre con noi per consentirci quel dinamismo che la nostra era ci impone, giusto o sbagliato che sia.

Gli indizi a conferma della mia visione sono molti. Lunedì Fry mi segnalava un articolo di arstechnica su dei rumors che vedrebbero nel 2017 Windows su processori ARM con istruzioni X86/X64 emulate. Anche AMD, storico antagonista di INTEL, ha acquistato una licenza ARM ed iniziato a produrre CPU di questo tipo per ambito server.

Chi vivrà vedrà, questa è la mia visione …

L'articolo ARM vs INTEL: il futuro dei microprocessori secondo me. sembra essere il primo su Cesare Bordi | Innovation Manager & Back-end Developer.