IFTTT , maddeche’?

Ho iniziato a vedere recensioni incompetenti su questa applicazione, che viene dipinta come “internet of things” (peccato che i sensori siano tutti sul cellulare, quindi mancano le “things” ) o addirittura un “enabler”, mostrando l’evidente incompetenza di chi non sa di preciso cosa sia un enabler nel mondo telco. Cosi’ scrivo una recensione di questa “app”, che ho scaricato e provato.

Definire questa applicazione come “una badilata di merda sul muro bianco dell’ IT” e’ una cosa gentile e sostanzialmente “polite”. Piacera’ sicuramente a chiunque ama qualsiasi cosa esca da una startup (=unemployment  made cool!) , ma onestamente non accetterei un design del genere da uno studente.

Per prima cosa: Android esiste. Ed offre un bus per le notifiche, ovvero qualcosa grazie al quale ogni applicazione puo’ avvisare l’utente di un evento asincrono. Avete presente quando nella barretta in alto vedete una piccola icona che vi avvisa di qualcosa?

Ecco, sta succedendo che un’applicazione che girava in background ha deciso di avvisarvi, e ha un metodo standard, uguale per tutti, che permette di mandarvi un messaggio. Esiste quindi un modo per leggere i messaggi e le notifiche inviate da ogni singola applicazione, usando semplicemente quello che c’e’ sul cellulare.

IFTTT no. Per sapere se il mio cellulare ha ricevuto un SMS, cosa della quale OGNI cellulare di questo mondo e’ edotto, ha bisogno di un backend dall’altra parte del mondo, sul quale registra il mio numero di telefono, e poi (attraverso un accordo con alcuni operatori) cerca di capire se ho un SMS . Stiamo scherzando?

Peccato che non ci sia NESSUN bisogno di fare questo, perche’ i messaggi SMS sono parte dello stack GSM, e se sono in rete ricevero’ gli SMS. Il cellulare SA benissimo di averne ricevuto uno.

NON C’E’ NESSUN BISOGNO DI UN BACKEND. USARE UN BACKEND PER SAPERE QUALCOSA CHE IL TERMINALE SA BENISSIMO SIGNIFICA NON AVERE IDEA DI COME FUNZIONI IL TERMINALE. PER ESEMPIO, DI NON AVER CAPITO CHE I MESSAGGI SMS NON SONO COME L’ EMAIL CHE STA SU UN SERVER IMAP, MA ARRIVANO PROPRIO AL CELLULARE.

Stessa cosa per il servizio che mi permette di usare come “if” il mio sensore satellitare di posizione. Esso , sia Glonass o GPS, si trova sul cellulare stesso. Il mio cellulare sicuramente deve cercare un servizio di mappa se vuole trasformare le coordinate in un posto, ma NON HA BISOGNO di alcun backend per scrivere “se io sono qui dove mi trovo ora” , perche’ SA , momento per momento, dove si trova.

A che diavolo serve un backend che mi abilita “il canale”?

Tutti i “canali” di IFTTT che sono legati a SENSORI posti SUL CELLULARE STESSO, che non hanno bisogno di un backend, tuttavia richiedono che io “registri il canale”  su un inutile backend, con il bellissimo risultato che per eseguire un “if … then” sui sensori del mio cellulare, ho bisogno di macchine che stanno dall’altra parte del mondo. E cosa ci guadagno rispetto alla semplice lettura dei sensori in loco? Ecco qui:

quindi, primo punto, voto per i network skill:  “badilata di merda sul muro bianco dell’ IT”.

Andiamo al secondo punto: le applicazioni event-based che non dispongono di sensori.

Come ho gia’ scritto sopra, tutte le app di android basate su eventi asincroni possono inviare notifiche al sistema. Significa che qualsiasi applicazione puo’ usare – e quelle consentite da  IFTTT lo fanno –   un canale apposito per inviare notifiche.

Capite bene che , rimanendo in ascolto sullo stesso canale, sia perfettamente possibile venire a conoscenza di queste notifiche. Se per dire volete scatenare un evento quando c’e’ un nuovo file sul vostro cloud preferito, non avete bisogno di autorizzare un backend ad accedere allo stato del vostro cloud: l’applicazione, che avete installato onde fruire del cloud dal cellulare, puo’ gia’ inviare una notifica, e quindi basta ascoltare quella sul telefono stesso.

Invece, l’architettura proposta e’: tu utente  abiliti un canale sul backend , che poi fa questo e quello coi dati  (i tuoi dati) e l’applicazione funziona cosi’ perche’ si. Oltre ai tre difetti di cui sopra, quel che non convince e’ molto semplicemente questo: ma perche’ io ho bisogno di un intermediario tra me ed il mio cellulare?

Perche una startup, che nella mitologia delle startup (1) ha pochi soldi, investe un fottio di tempo, calcolatori, banda passante, al solo scopo di fare in maniera dispendiosa qualcosa che potevano fare senza tutte quelle spese?

Che io sappia le startup aprono nei garage perche’ gli Dei dei GgiovÄni richiedono un periodo di eremitaggio  nell’autorimessa per forgiare lo spirito. DEVS LO VULT! Se non hai soldi, perche’ usi un’architettura che ti costera’ in costo opex perl’ housing, o addirittura un costo capex in un cloud (piu’ il costo opex per tenere il backend sotto monitoring , e avere un gruppo di persone pronte ad intervenire 24/7)  , quando i sensori e gli eventi che vuoi usare nella app sono tutti leggibili dal cellulare stesso?

Risposta: design di merda.

Voto per il solution design: “barcone di bagasce albanesi sullo stretto di Otranto”.

Andiamo al marketing. Non ho ancora letto una recensione ove non si parli di “internet of things”. Segno che questa etichetta fa parte di una precisa strategia. Peccato che non ci siano le “things”. Non stiamo parlando di una cosa che gira anche sui computer, su raspberry,  non viene venduto con sistemi di domotica com questi: https://sen.se , per cui stiamo davvero parlando di “things”.

Quando si dice “internet of things” si intende con precisione un fenomeno per il quale il costo dei sensori e delle board per la connessione in rete (GSM/IP)  si e’ abbassato tanto da permettere di piazzarli su ogni oggetto. Peccato che questa app abiliti solo smartphones, o quasi. Dove sono le “things”? Da nessuna parte, perche’ quando si dice “internet of things” si parla di molti SENSORI connessi tra loro e di eventuali ATTUATORI. (il reciproco di un sensore)

Qui gli eventi non sono eventi reali: si parla di “fai la tal cosa se sono taggato su Instagram”. Ah, ok. Qual’e’ il sensore? Uhm. No, mi spiace, niente internet of things.

Secondo, leggo a zonzo che questo servizio dice di essere un “enabler”. Avete idea di cosa sia un “enabler?”. Un enabler e’  , nel linguaggio specifico delle telco, un blocco dell’architettura che rende possibile per un terminale l’uso on demand  di una funzionalita’ (desiderabile dall’utente, of course) offerta da terze parti attraverso l’infrastruttura stessa, detta appunto enabler.

Anche uscendo dal mondo telco, l’ “enabler” (almeno secondo il Webster) sarebbe qualcosa che vi permette di fare qualcosa che senza non potreste fare. Esempio: il volo aereo ti permette di coprire grandi distanze in poche ore.

In questo caso non c’e’ nessun enabler. OGNI programma che gira sul cellulare sa che cosa gli stia succedendo. Non esiste alcun enabler, e nemmeno il backend di IFTTT lo fa, dal momento che non c’e’ bisogno di questa infrastruttura per avere quel servizio.

Il cellulare non viene abilitato a fare cose che non potrebbe fare senza il backend di IFTTT: in generale ogni programma capace di leggere i sensori e di leggere le notifiche di android puo’ fare lo stesso, anche a cellulare sconnesso dalla telco (il GPS funziona ugualmente, per dire): non si capisce a cosa si debba il termine “enabler”. Sicuramente si potrebbe usare “enpower” al posto di “enable” ma non basta questo per parlare di enabler.

Ma come se non bastasse, non avreste nemmeno bisogno di un programma per fare quelle cose: il che significa che questo software “automatizza”, cose che facevate gia’, e quindi non si puo’ parlare di “enabler” in NESSUN senso.

Il termine corretto sarebbe “assistant”, o “automa”  dal momento che il software fa qualcosa che magari non volete fare di persona, ma che potete fare (e spesso fate) anche senza.

Voto alla competenza del marketing: ” tua madre era sulla Concordia e lo sappiamo tutti che cosa ha urtato “.

Adesso andiamo al mio giudizio personale: IFTTT e’ una startup il cui scopo e’ di essere venduta. Siccome una app che  fa le stesse cose (senza un unitile backend)  puo’ farla una scimmia tandoori per due euro e una ciotola di merda, allora ci mettiamo un inutile backend che raccoglie dati, cookies e credenziali degli utenti, e poi vendiamo il backend – coi dati dentro –  per un fracco di soldi.

In definitiva: il prodotto siete voi.

Non siete utenti. Siete solo polli che daranno i loro dati a qualcuno, senza alcun bisogno reale di farlo, al solo scopo di farglieli vendere, e renderlo ricco.

(1) My grandfather was unemployed too, much before it was cool.