Il Corso di Laurea in Informatica Applicata ospiterà la Scuola Estiva Crowdsourcing for the Common Good, in collaborazione con il progetto Europeo CROWD4ROADS e altri progetti partner (DECODE, HackAIR), dal 25 al 28 Settembre 2018, con interventi e sessioni su innovazione sociale, intelligenza collettiva, crowdsensing, privacy dei dati e gamification, concludendosi quindi con un “Data Jam”, una giornata intera (e una notte) di hackaton su dati aperti.

Gli studenti del Corso di Laurea sono invitati ad iscriversi gratuitamente tramite apposito modulo online.

Le sessioni ed il “Data Jam” si terranno in lingua inglese.

Nell’edizione 2017 a Valencia sono stati trattati diversi temi attuali, come la crescente proliferazione di cosiddetti MOOC (Massive Open Online Course) e delle modalità con cui vengono preparati e svolti, l’insegnamento del “coding” o del pensiero computazionale per giovani ed adulti, approcci innovativi alla didattica, robotica, realtà virtuale e tanti altri temi.

Durante la sessione iniziale, il dirompente Bryan Alexander (dirompente anche in termini di barba) ha più volte ripetuto l’importanza di lasciarsi ispirare da tecnologie attuali e future, sfruttarne le potenzialità in qualità di strumenti di comunicazione ed educativi, in modo da trasformare l’insegnamento in un processo attivo e collaborativo. Gli studenti stessi diventano parte attiva: creatori, non consumatori, del processo educativo.

“The future is not given to you. […] You are world creators.” ~ @BryanAlexander #INTED2017 pic.twitter.com/faKgTrQu0v

— Lorenz Klopfenstein (@LorenzCK) March 6, 2017

Diversi interventi si sono incentrati sulle difficoltà dei (nuovi) docenti nell’approcciarsi in maniera efficace all’insegnamento, quando il loro ruolo accademico risulta distribuito tra ricerca, insegnamento e compiti amministrativi. La formazione dei docenti come processo e priorità delle istituzioni accademiche è stato un tema ripreso da diverse punti di vista, anche nella declinazione orientata ai MOOC, dove i docenti si scontrano con nuove tecnologie e forme di insegnamento.

Alcune sessioni erano dedicate in particolare alla gestione di lezioni in streaming video, discutendo i meriti di questo strumento, le difficoltà solitamente incontrate, configurazioni e strumenti utilizzabili, incluse delle modalità di annotazione e di aggiunta di elementi interattivi (ad esempio domande a scelta multipla), per renderne più interessante la visione. Un interessante studio di Markus Westner metteva in correlazione la pubblicazione di lezioni in streaming ed i risultati ottenuti dalla classe. In particolare, la disponibilità di video-lezioni, negli esempi riportati, conduceva ad un calo di oltre il 33% nel numero di studenti presenti in classe, con un 56% di studenti in media che visualizzavano tutti i video. Tuttavia, la disponibilità di queste risorse non ha avuto un impatto statisticamente significativo sul risultato finale. D’altro canto, la frequenza delle lezioni in presenza è correlata positivamente con il voto all’esame.

Anche sul fronte della cosiddetta “digital literacy”, della diffusione delle conoscenze digitali nelle scuole primarie e secondarie, diversi interventi si sono incentrati su collaborazione internazionale e su tecniche e modalità di insegnamento innovative. Ad esempio “CaRoMtE”, un progetto europeo condotto da una partnership Belga, Italiana e Spagnola per l’introduzione dei concetti di coding e robotica basati su strategia e linguaggio comune. Oppure “Scratching the Surface”, un progetto pilota sovvenzionato da Google che ha coinvolto alcune scuole medie del South Carolina per l’insegnamento dei concetti fondanti della programmazione tramite Scratch.

Durante la conferenza sono stati inoltre presentati due lavori sviluppati nell’egida del Corso di Laurea in Informatica Applicata. Il gioco di carte “unplugged” CodyRoby è stato riadattato in un’esperienza di realtà aumentata, grazie al lavoro del laureando Andiy Fedosyeyev, che ha condotto alla realizzazione dell’applicazione mobile per Android “CodyRobyAR”. L’app trasforma un gioco con requisiti bassissimi in un’esperienza interattiva di apprendimento che si basa su strumenti quotidiani ed alla portata di tutti come uno smartphone ed alcune stampe su carta. Inoltre, sono stati presentati anche gli esperimenti basati sul collegamento di marker temporali o fisici con dei bot su piattaforme di messaggistica online, che hanno portato alla realizzazione di eventi come la caccia al tesoro guidata da bot a Urbino.

All’interno di CodeMOOC, un massive open online course (corso aperto online su larga scala) offerto dall’Università di Urbino ed incentrato sul pensiero computazionale ed il coding, si è pianificato per il 20 ottobre lo svolgimento di un quiz di coding su larga scala. Utilizzando soltanto un client Telegram ed uno scanner di codici QR, i partecipanti hanno avuto la possibilità di partecipare al gioco e di sfidare oltre 900 gruppi di varie località d’Italia.

I partecipanti si potevano registrare ad un canale Telegram, sul quale sono state pubblicate le istruzioni del gioco poco prima dell’evento. All’inizio del gioco è stato pubblicato il collegamento ad uno stream live su Youtube, attraverso il quale venivano diffuse ulteriori istruzioni e le domande del quiz.

Per ogni quiz assegnato durante il gioco, il bot Telegram pubblicava un collegamento speciale sul canale pubblico. Questo collegamento conduceva ad una conversazione privata tra partecipante e bot, sfruttando il cosiddetto deep linking di Telegram. Siccome ogni quiz del gioco era identificato da un particolare codice unico, il deep link, dopo aver condotto il partecipante alla conversazione privata, inviava anche un comando nascosto:

/start IY4

(Dove il codice IY4 identifica il 4° quiz dell’evento.)

I partecipanti potevano partecipare ai quiz anche scansionando direttamente un codice QR mostrato nello stream Youtube, che a sua volta conteneva il medesimo deep link.

Una volta attivato tramite il collegamento, il bot chiedeva all’utente di fornire la risposta al quiz.
Appena l’amministratore del quiz chiudeva la domanda (semplicemente scrivendo la risposta corretta al bot tramite una conversazione privata), il bot classificava tutte le risposte corrette ricevute in base al timestamp di ricezione e le rendeva pubbliche sul canale. Le prime 3 risposte corrette venivano premiate con l’assegnazione di alcune, inestimabili, medaglie emoji. ?

Gestione dei messaggi

Un totale di 974 partecipanti (intesi come singoli utenti Telegram) hanno partecipato all’evento. Siccome ogni utente poteva registrarsi per conto di un gruppo di persone (rappresentandolo come capogruppo), il conteggio sale ad un totale di 9689 persone di partecipanti. 14 domande sono state poste durante il gioco, raccogliendo un totale di 7004 risposte dai partecipanti, durante circa un’ora e mezza di gioco.

In altre parole: un sacco di messaggi sono stati scambiati con il nostro bot nell’arco di pochissimo tempo.

Telegram supporta due diverse modalità di ricezione dei messaggi: pull e push.

Modalità Pull

In modalità Pull, il bot si collega periodicamente ad un end-point HTTP dei server Telegram e scarica tutti o parte dei messaggi in coda per la consegna. Il meccanismo di consegna può essere personalizzato, ad esempio scaricando una sequenza di messaggi in un unico collegamento oppure utilizzando l’opzione di long polling per rendere bloccante la richiesta ed attendere che vi siano dati disponibili lato server.

Sulla carta questa modalità assicura maggiore efficienza: le richieste sono controllate dal server che ospita il bot, possono essere gestite con più facilità ed un gran numero di messaggi può essere trasferito all’interno della stessa comunicazione HTTP.

Tuttavia, operazioni pull sono, per natura, sincrone. Le API di Telegram non permettono più di una richiesta concorrente (visto che, ovviamente, le singole richieste pull operano sequenzialmente sulla stessa coda di messaggi). Mentre trasferire un singolo grande payload di messaggi e processarli in un unico passo di decodifica JSON è potenzialmente più efficiente, quello che accade in effetti è che in questa modalità il tempo medio di risposta aumenta. Inoltre, dopo la fase di scaricamento e di decodifica, il parallelismo è interamente compito dello sviluppatore. La gestione dei messaggi su diversi processi o thread paralleli può essere più o meno difficile in base al proprio ambiente di programmazione: in Go si può invocare una goroutine per ogni messaggio, mentre la stessa cosa può essere fatta usando dei task async su .NET.

Modalità Push

Questa modalità—che per inciso è l’unica modalità disponibile su diverse altre piattaforme di messaggistica—baratta la fase di un singolo trasferimento dati molto efficiente per una moltitudine di operationi di gestione messaggi che avvengono in parallelo.

Invece di aspettare che il bot contatti il server Telegram per ottenere nuovi messaggi, eventuali aggiornamenti sono inviati direttamente al server web del bot attraverso un end-point ad un URL definito dallo sviluppatore (Telegram richiede una connessione HTTPS, un dominio ed un certificato valido). Invece di doversi occupare dei dettagli implementativi della gestione parallela dei messaggi, questa modalità permette di sfruttare i punti di forza intrinseci di un server web: la gestione di un grande numero di connessioni in ingresso e la loro gestione efficiente.

Risultati

In base ai nostri log, ben 7,414,458 messaggi sono stati inviati al nostro bot tramite Telegram, durante circa 80 minuti di gioco.

In media il bot ha ricevuto oltre 380 messaggi per minuti, con un picco di circa 1200. Guardando attentamente il grafico è possibile intuire quando sono state poste le 14 domande del quiz.

Inizialmente il nostro bot era stato configurato per operare in modalità pull, con una gestione sincrona dei messaggi in ingresso, visto che questa modalità permette di sviluppare e fare debug in maniera molto comoda. Tuttavia, appena l’evento ha avuto inizio, abbiamo subito scoperto che la coda dei messaggi in ingresso stava crescendo a dismisura e il nostro bot semplicemente non riusciva a tenere il passo dei giocatori.
Siamo riusciti a passare rapidamente alla modalità push. Dopo un paio di minuti il bot è riuscito a mettersi in paro con i messaggi, dopodiché non si sono verificati altri problemi di responsività nella comunicazione con i partecipanti.

Il bot era installato su una macchina quad-core a 2.6 GHz, con 2 GB di RAM.

Concludendo, la modalità pull è perfettamente adatta per lo sviluppo dei bot, visto che permette agli sviluppatori di controllare il flusso di messaggi in ingresso e di effettuare un attento debugging del codice. Tuttavia, probabilmente non vale la pena implementare un metodo efficiente (e corretto) di gestione dei messaggi tramite modalità pull. Come già suggerito da altri, è molto più sensato affidarsi ad un server web per la gestione efficiente di richieste parallele invece di provare a reinventare la ruota.

Più generalmente—e questo è molto importante nel contesto della recente attenzione ai bot come rimpiazzo delle applicazioni mobili—l’utilizzo di un bot al posto di un sito web o altro ci ha dato un fondamentale vantaggio. La piattaforma di messagistica, Telegram in questo caso, funge da “load balancer” estremamente scalabile tra gli utenti ed il proprio servizio. La piattaforma gestisce la coda dei messaggi, l’invio, la consegna e la notifica degli utenti—in sostanza Telegram offre una incredibile infrastruttura molto sofisticata ad un costo nullo. Questo permette agli sviluppatori di bot di concentrarsi sullo sviluppo del servizio invece di doversi occupare dei fondamenti.

Questo evento dello Europe Code Week è stato un’ottima opportunità per valutare gli effetti di un carico di lavoro inusuale su un bot (per quanto ci riguarda). Altri eventi di questa natura verranno organizzati in futuro e ci aspettiamo di poter valutare altri aspetti legati alle prestazioni ed alla scalabilità in maggiore dettaglio.

Il codice utilizzato durante l’evento è disponibile su Github.

In the context of CodeMOOC, a massive open online course offered by the University of Urbino about computational thinking and coding, a large-scale coding quiz was planned for 20 October. Using only a Telegram client and a QR Code scanner, the participants were able to take part in the game and compete with over 900 groups in Italy.

Participants did register to a Telegram channel where they would receive instructions before the start of the game. At the start of the game, we handed out the link to a live Youtube stream, where further instructions and quiz questions were given out.

For each coding quiz, the Telegram bot coordinating the event wrote a special link to the channel conversation, that would redirect users to the voting conversation using Telegram’s deep link feature. Since each quiz had a unique identifier, the deep link would not only transfer the user to the bot, but also send out a hidden command.

/start IY4

(Where IY4 is the hidden code for the 4th quiz question.)

Participants could also access the voting process by scanning a QR Code, containing the same deep link.

Once invoked, the bot did ask for an answer from the user.
As soon as the question was closed from our side (by simply providing the correct answer to the bot), the bot did rank all correct answers by timestamp and signal the results on the channel. The first 3 correct answers were publicly acknowledged with various, priceless, emoji medals. ?

Message processing

A total of 974 participants (in terms of Telegram users) took part in the event. Since each person could register for a group of people (acting like a team leader), a total number of 9689 people were involved with the game.
14 questions were asked, collecting a total of 7004 responses by participants, over approximately one hour and a half.

In other words: a lot of messages were sent to our bot over a short amount of time.

Telegram supports two different modes of fetching incoming messages: pull and push.

Pull mode

In pull mode, your bot server periodically connects to a Telegram end-point and downloads part of the messages queued up for delivery. The delivery mechanism can be customized, for instance downloading a batch of messages in a single call and using long-polling to stall the request until some data can be returned.

In theory, the pull method ensures higher efficiency: requests are sent out by your server, they can be controlled easily, and large batches of messages can be returned in a single HTTP data transfer.

However, pull operations are synchronized by nature. The Telegram API disallows multiple parallel requests (since, of course, the pull request operates sequentially on the delivery queue).
While transferring one single large payload and performing one single JSON decode step may be more efficient, in pull mode you are indeed increasing the average response time of each message.
Moreover, after the download phase, data parallelism is entirely up to the developer. Handing off message handling to different threads can be more or less easy, depending on your development framework: in Go a goroutine can be dispatched for each message, while the same can be done for async tasks on any .NET language.

Push mode

This mode—which incidentally is the only mode of operation of many other messaging platforms—trades off the single, efficient data transfer step for multiple parallel message handling operations.

Instead of waiting for your server to fetch messages, updates are pushed to your bot’s web server to an URL of your choice (Telegram requires HTTPS, a domain name, and a certificate). Instead of having to deal with parallelism, this mode exploits the inherent strong points of a web server: dealing with multiple incoming connections and handling them off efficiently to your code.

Results

Based on our logs, 7.414.458 messages where sent to the bot through Telegram, in little over 80 minutes of operation.

An average of over 380 messages per minute were handled, with a peak of around 1200. If you watch closely, you can get a hint of when the 14 questions were asked.

Initially, our bot was configured to operate via pull and synchronous message handling, since this mode allows for far easier debugging and development. However, as soon as the event did start, we quickly discovered that the queue of messages was growing uncontrollably and the bot simply could not keep up.
We quickly switched over to push mode. Over the course of a couple of minutes the bot was able to catch up and performed very responsively for the rest of the event.

The bot was running on a quad-core machine clocked at 2.6 GHz, with 2 GBs of RAM.

In conclusion, pull mode is perfectly suited for bot development, since it allows developers to control the flow of messages and to carefully debug the code. Implementing an efficient message handling method via pull mode, however, probably isn’t worth the development effort. As suggested by others, it is far easier to entrust the web server with handling parallel requests on your behalf.

More generally—and this is very important in the context of the recent focus on bots as a replacement of apps—using a bot instead of a web site (for instance) gave us a very important advantage. The messaging platform, Telegram in this case, acts as an extremely scalable load balancer in front of your service. It handles message queuing, retrying, delivery, and push notifications—essentially Telegram offers an incredible amount of complex infrastructure for free. This allows you to focus on actual service development instead of having to worry about the plumbing.

This Europe Code Week event has been a good opportunity to appreciate the effects of an unusual load (for our scale of development) on our bot. Further similar events will be planned and we look forward to evaluate performance and scaling issues in deeper detail.

The code used during the event is available on Github.

The game had been developed during the week just before the event and the whole team behind the treasure hunt spent the last minutes before the start feverishly fixing the last bugs. (Well, most of them.)

The summer school, aimed at school teachers of all grades, had the main focus of bringing coding to the classroom, in a way that could be engaging for both teachers and young students. Thus, it made more than sense that the treasure hunt itself, “Urbino Code Hunting” as it was called, would be based on coding puzzles as well.

What made the treasure hunt interesting is that the whole registration process, the actual hunting, puzzling, and other game mechanics were directly handled by a Telegram bot. Anyone with a Telegram account could very easily register during the 4 days before the game just by entering a conversation with it.

Registrations to the game were handled by a run of the mill conversation with the bot.

The bot asked registrants to solve a “preliminary” puzzle (to prepare players for what would have come later and to work as some kind of captcha), how many other participants would have taken part to the game together with the team leader, and the team’s name.

Usually a treasure hunt game requires players to find hidden objects or reach secret locations based on some—more or less vague—clues. In our case, the actual puzzling was centered around coding questions delivered by the bot, not around recognizing locations from clues, both because coding was the theme of the game and because many participants weren’t familiar with the city. Therefore, locations to reach were given out explicitly by the bot.

The actual gameplay was structured as follows:

• 1) Each group gets a random location to reach (sent as a precise geographical location and rendered as a point on a map).
• 2) On reaching its assigned location, the group snaps a selfie and sends it to the bot.
• 3) The bot picks one of the coding puzzles and waits for the group’s answer. The bot forces a minimum delay of 1 minute between attempts.
• 4) If the solution is correct, the bot gives out a new clue for the final puzzle.
• 5) Go to 1.

We identified 30 well-distributed locations around the town, which we marked with a description, a precise GPS location, a numeric ID, and a secret code (16 random alphanumeric characters).

Each location had its own secret 16-character code.

How did the bot ensure that a group has reached its destination? Easy. We printed 30 paper signs (on A4 sheets), one for each location, with a special QR Code linking to an URL following this scheme:

https://telegram.me/treasurehuntbot?start=0123456789ABCDEF

This link makes use of the deep linking feature of Telegram: after opening the URL through a QR Code scanner, the user’s phone automatically starts the Telegram client and sends the “/start 0123456789ABCDEF” string to our bot, without actually displaying it inside the conversation screen. Since each QR Code contained the location’s secret 16-character code inside the URL, the bot would know with certainty which code the group had scanned and thus which location was reached.

The bot tracked each group making its way through a sequence of 12 locations. To ensure that groups of players do not follow each other and that they don’t cluster in the same area, the sequence of locations to reach for each group was chosen at random.

In order to ensure fairness, sequences of locations were generated beforehand with a bounded maximum (and minimum) length.

Puzzles—which were given out as soon as a group reached a location and sent a confirmation selfie of the group—were based on the CodyRoby quizzes . These simple logical puzzles make use of shared conventions, like the colored pseudo-code blocks from Blockly used in Code.org and the CodyRoby coding cards .

Sample question.

All puzzles required at most a couple of minutes to be solved and the answer could be provided as a simple text message, usually with a single character or a single number. Answers would be accepted quite liberally, with whitespace, in upper or lower case, and with any formatting. Wrong answers caused a forced delay of 60 seconds before the next attempt.

Correct answers not only let the group move forward, but they also rewarded the group with an important clue that would then be used to solve the last riddle: as soon as a group reached the last location (which we made sure was the same for all groups), they were given a map (like, a real, tangible, honest to goodness map made out of paper) that could be used to find out the exact place where the coveted prize was hidden.

The first group that reached it would get to keep the prize and receive another wonderful QR Code. Who doesn’t love QR Codes anyway? This last code signaled that the game was over for everyone.

A Telegram channel was used to broadcast information, to share selfies, and to make the game more engaging.

The Urbino Code Hunting Telegram channel was created on the day of the game and all participants were invited to subscribe to it. Major advancements of the groups were broadcast on the channel, along with all selfies taken by the groups as soon as they were sent in from the various locations. The channel gave the participants and us a way to monitor the state of the game, thus making it more engaging as the groups got closer to their final destination.

Part of all the selfies collected by the bot.

The bot was powered by a PHP program and a MySQL database, patched together in less than a week. The source code has been published on Github under the MIT license if you want to take a look. At the moment, deploying the bot for your own backyard treasure hunt might not be the easiest of tasks, but we are already planning to make it reusable at will.
(And we have other significant—and scary?—plans for the future…)

Come descritto precedentemente, per l’occasione dell’evento ConvComp2016 del 24 giugno, abbiamo realizzato un semplice Bot che permettesse di raccogliere pensieri, emozioni e stati d’animo geolocalizzati, in modo da dare un’idea del sentimento generale in un’area. Il Bot è online su Telegram come @wordcloud_bot ed è possibile utilizzarlo da subito per vederlo in azione.

Strumenti semplici ed aperti per realizzare il proprio Bot.

La semplicità e la rapidità con cui si sono diffusi le svariate piattaforme di messaggistica ed i loro Bot sono, in buona parte, il frutto di anni di software e livelli di astrazione che rendono, oggigiorno, la programmazione di un’applicazione o di un sistema di comunicazione sorprendentemente facile. Alla stessa maniera, l’esistenza di immani “spalle di giganti” su cui basarsi fa sì che—almeno per quanto riguarda l’implementazione di un semplice Bot—ci siano già tutti i pezzi LEGO di cui abbiamo bisogno e che combinarli per raggiungere il nostro risultato spesso possa anche essere divertente.

In questo esempio faremo uso del software che viene utilizzato come supporto didattico nel corso di “Piattaforme Digitali per la Gestione del Territorio” del Corso di Laurea in Informatica Applicata dell’Università di Urbino, che viene offerto anche come MOOC online sulla piattaforma EMMA. Il software in questione è disponibile liberamente anche su Github.

Foto di The.Comedian, via Flickr.

Quattro semplici pezzi LEGO per comporre un Bot.

La piattaforma di base per il nostro Bot è Telegram, che mette a disposizione un’interfaccia molto ricca per l’implementazione degli stessi. Una volta collegato con Telegram, la logica interna del Bot è implementata con uno script PHP, che sfrutta un database MySQL per memorizzare le informazioni fornite dagli utenti, la loro posizione geografica ed altri dati accessori.

Se finora le tecnologie utilizzate non mostrano particolare creatività—del resto sono le medesime su cui si basa la maggior parte dei siti web o blog degli ultimi anni—è nel rendere la conversazione del nostro Bot più credibile che possiamo sfruttare un ulteriore blocco “pronto all’uso”: Program O, un interprete basato sulle specifiche di ALICE e che permette di sviluppare velocemente dei Bot che conversano in maniera (più o meno) naturale sulla base di codice dichiarativo (una variante di XML).

La libreria d’esempio su Github mette a disposizione diverse funzioni già implementate per l’interazione con Telegram, MySQL e Program O.

Le potenzialità del remix: piattaforme, dati aperti, software libero…

Non finisce di certo qui. Riprendiamo il motto di “Everything is a Remix” per asserire che qualsiasi idea—piccola o grande che sia—e qualsiasi pezzo di software, che è possibile realizzare anche senza conoscenze di programmazione, può essere visto come il culmine di anni di astrazioni—i blocchetti del LEGO—a noi liberamente disponibili. Il prodotto dei tre fondamentali passi delineati qui sotto.

Piattaforme, dati aperti, software libero e tanti altri blocchi a portata di mano possono essere ricombinati a piacimento per creare innovazione, opportunità e conoscenza. Le interfacce conversazionali rappresentate dai Bot sono una di queste piattaforme.

Il codice di @wordcloud_bot è disponibile liberamente su Github sotto licenza MIT. Se vi viene in mente qualche brillante idea per un Bot—magari ispirato ai principi dell’intelligenza collettiva—siamo curiosi di sentirla!

L’interesse per i Bot e le interfacce conversazionali sfruttati all’interno delle applicazioni di messaggistica testimoniano in qualche modo la naturale tendenza a non re-inventare la ruota: in presenza di un sistema esistente e con un grande valore dato dalla presenza di utenti e servizi—come può esserlo una piattaforma di messaggistica—vale sempre la pena sfruttarla per costruirci qualcosa sopra.

L’interesse per i Bot è testimone della convergenza su interfacce di livello sempre più alto.

L’intelligenza collettiva è il principio per cui una massa di persone può acquisire una consapevolezza o una conoscenza emergente, grazie alle interazioni dei propri membri, che la massa nella sua interezza percepisce, ma che non è possibile avere individualmente.
Wikipedia ne è l’esempio più classico, ma la presenza massiccia di utenti e la loro libera interazione grazie alla rete rende tutte le piattaforme online particolarmente indicate per esempi di intelligenza collettiva.

Intelligenza collettiva è la consapevolezza emergente dalle interazioni di una massa di persone, che non dipende e non è ottenibile dai singoli individui.

Foto di mbeo, via Flickr.

Applicando gli stessi principi alla manutenzione dell’infrastruttura stradale, mentre i singoli automobilisti sono consci della qualità della strada sulla quale stanno guidando, se ci fosse un modo per registrare la qualità delle strade in maniera oggettiva, trasmetterla, metterla insieme e tenerla aggiornata senza oneri, allora conosceremmo lo stato di tutte le strade—sulla base di un fenomeno osservabile dai singoli individui, ma non generalizzabile in automatico.

Questa applicazione esiste e si chiama SmartRoadSense. È stata sviluppata presso l’Università di Urbino e permette di tener traccia della qualità delle strade in maniera automatica, per comporre una mappa nazionale (e in futuro, globale) della qualità delle infrastrutture.
SmartRoadSense è, per ragioni tecniche, un’applicazione, ma nulla toglie che anche i Bot possano giocare una parte in un sistema di intelligenza collettiva.

Usare Bot per raccogliere informazioni, piuttosto che diffonderle.

Raccogliere dati, creare informazioni, fare domande e semplificare l’interazione con gli utenti sono tutte abilità per le quali i Bot sono nati. Invece che funzionare solo da assistenti o (per il momento) innaturali sorgenti di informazione, i Bot possono raccogliere dati e quindi creare informazioni aggregate che non esisterebbero senza la partecipazione degli utenti.

Un esempio: raccogliere dei pensieri geolocalizzati.

Per l’evento ConvComp2016 del 24 giugno, abbiamo realizzato un semplice bot che permettesse di raccogliere pensieri, emozioni e stati d’animo geolocalizzati, in modo da dare un’idea del sentimento generale in un’area. Il Bot è online su Telegram come @wordcloud_bot ed è possibile utilizzarlo da subito. (Questa frase tradisce chiaramente la troppa fiducia nelle nostre capacità di programmazione.)

È un’idea semplice, realizzata in poco più di una mattinata, ma che esemplifica ciò che già da ora è possibile realizzare con strumenti molto semplici: Bot che raccolgono informazioni, integrano dati, interagiscono con utenti, legando le informazioni raccolte col territorio. Gli utenti, invece, da fruitori passivi diventano fornitori di informazioni, parti di un’intelligenza che viene raccolta, ricombinata e resa di nuovo fruibile, in maniera potenziata.

Negli altri articoli dedicati al ConvComp2016 si parla di Bot come piattaforma e della loro implementazione.

Nell’ultimo periodo le interfacce conversazionali, in particolare quelle usate da Bot ed agenti automatici che sfruttano canali di conversazione prevalentemente testuali nell’interagire con utenti umani, stanno suscitando sempre più interesse e sono sempre più al centro di sviluppo ed innovazione.

Tuttavia, i Bot rappresentano in realtà un tuffo nel passato: rispetto alle interfacce più comuni che troviamo oggi per interagire con i servizi, siti web, interfacce touchscreen, e applicazioni mobili, dialogare in maniera testuale con un computer che simula una personalità umana ricorda il futuro ipotetico che ci si prefigurava nei film degli ultimi anni ’80.

Foto di Matthew Hurst, via Flickr.

L’evoluzione che ci porta ai Bot conversazionali odierni ha moltissimi paralleli con l’evoluzione di tutte le maggior piattaforme, incluso Internet. Alla base della madre di tutte le reti si trovano infatti vari protocolli di comunicazione elettronica, stratificati. Ognuno di essi con un proprio scopo e delle peculiarità, che formano una piattaforma che può essere sfruttata da protocolli superiori ed applicazioni. L’applicazione, basata su questi protocolli alla base di Internet, che esplode in termini di popolarità è proprio il web.

Il World Wide Web: la piattaforma globale, dinamica e flessibile.

L’accesso al web tramite browser ed i succitati protocolli diventa fondamentale e guadagna di diffusione: presto il web diventa esso stesso la piattaforma per altre applicazioni. Applicazioni che facevano già parte di Internet, ma non del web, e che sfruttavano un protocollo di “pari” dignità—come ad esempio l’e-mail con l’avvento delle webmail—migrano e diventano sempre più popolari attraverso il web stesso.

Il web è la piattaforma dominante: l’interfaccia più flessibile, dove tutta l’utenza è già presente.

La piattaforma più di basso livello offerta è quella del computer in quanto macchina, la piattaforma hardware, sulla quale si costruisce la piattaforma software, il sistema operativo, che fa da piattaforma alle applicazioni. Applicazioni tra le quali il web browser è sicuramente dominante. L’importanza del web browser era già visibile nel successo dell’iPhone del 2007, dove le capacità della piattaforma non erano date dalla possibilità di installare applicazioni—ancora assenti—ma da quella di disporre di un browser moderno, compatibile con tutto il web.

“Instant messaging”: la piattaforma cross-platform.

Nel campo dello smartphone si è vista un’evoluzione simile: da un sistema in cui l’esperienza d’uso degli utenti era dominata dal sistema operativo stesso, con l’apertura ad applicazioni di terze parti, sono le applicazioni stesse a determinare il modo in cui gli utenti sfruttano il dispositivo. Applicazioni mobili che sono disponibili su diverse piattaforme offrono spesso un’esperienza d’uso cross-platform, che diventa propria e distinta da quella offerta dal sistema. Offrendo dei servizi per sviluppatori, l’app diventa a sua volta una piattaforma.

Le app di messaggistica offrono l’esperienza d’uso alla quale gli utenti sono già abituati.

Le app di messaggistica offrono un’esperienza d’uso, dei servizi e—soprattutto—una ricchezza di utenti già attivi. Come il web ed il browser hanno vinto contro le applicazioni native, semplicemente offrendo un mondo più comodo, senza barriere all’ingresso, così le piattaforme di messaggistica possono avere successo. I Bot e gli altri servizi messi a disposizione da questi servizi si appropriano semplicemente dell’esperienza d’uso che gli utenti hanno già scelto da tempo.

Foto di Jan Persiel, via Flickr.

Negli altri articoli dedicati al ConvComp2016 si parla di Bot, intelligenza collettiva, e della loro implementazione.

The conference was held in the imposing conference center Lingotto in Turin, nicely bathed in sun and nice weather, with more than 700 participants from over 21 different countries.

Saverio and Lorenz after getting their badges. As you can see, badges = bliss.

Last year’s event was marked by an unmanageable epidemy of Google Glass-wearing speakers. The 2015 edition fortunately marked a switch from Google’s glasses to more discreet Android Wear based watches. A nice advantage, from a stylistic perspective at the least.

Because of that, many sessions were actually focused on Android Wear and Android Auto, the brand new platforms where our favorite green droid is expanding into. Many other talks during the two intense days of DroidCon where instead focused on the intersection between Android and the Internet of Things: for instance interesting stuff about iBeacons and (a bit discouraging) experiments on proximity monitoring by Matteo Gazzurelli.

Apart from software development, one of the most discussed topics was actually user experience (or “UX”): Lydia Selimalhigazi and Roberto Orgiu gave a nice overview on why developers and designers need to stick together and help each other in order to obtain results without (too much) conflict. The same topic was taken on, from a branding perspective, during the stimulating talk by Marie Schweiz on how the specific features of a brand influence the user experience (not only the logo, that is).

Another totally different point of view on “user experience”: Kentaro Takiguchi gave a very nice talk “Improving UX through Performance” with an in-depth overview of those little optimizations that can be applied, both on the app and on the server side, in order to improve an app’s fluidity, reliability and responsiveness. An interesting bag of tricks for scenarios where even shaving off 4 KBs from a remote request can have a great impact.

Benjamin Augustin made clear that in fact software development can, at times, be a hellish affair. However, in order to free developers from pain, a growing number of libraries and tools are being worked on. One of those libraries is in fact RxJava, the Java port of the Reactive extensions originally created for .NET: those extensions offer a nice way to “invert” how your code work, by adopting a “reactive” coding paradigm which is very well suited to manage the interactions between user interface and an unreliable backend (like network access, for instance).

Likewise, Maciej Górski presented several ways, especially using Gradle plug-ins, to reduce the amount of “boilerplate” code developers need to write (for instance getter and setter methods for Java classes). Also very interesting: the “Holy Sync!” session by Eugenio Marletti, about cross-platform synchronization methods, using CouchBase.

“Test, test and test!” was the mantra of several other talks, in particular the one given by the always funny Ali Derbane e Wiebe Elsinga (don’t even try pronouncing his name, you’ll fail) who during their talk “The hitchhiker’s guide to functional testing” gave an overview of most functional testing suites available for Android. Stephan Linzner instead showed the glorious new tools developed at the Google mothership for its mobile developers.

Finally, at 12 o’clock of the first day, pushed by hunger more than anything else, our Lorenz gave his talk “The love child of Android and .NET: using Xamarin for app development” about all our recent experiences using the Xamarin platform for Android development during the last year. Slides can be downloaded as PPTX as well.

Gave us the necessary energy between sessions: the Cola from Turin!

After two very intense days we left Turin exhausted, but encouraged and inspired by many new things to check out, technologies to use in our projects and details to keep in mind while developing on Android (and not only)! Looking forward for next year!

Quest’anno l’evento si è svolto nell’imponente centro conferenze Lingotto a Torino, illuminato da un piacevole clima sereno e solare a differenza dell’anno scorso.

Saverio e Lorenz dopo il ritiro dei badge. Come vedete, badge = felicità.

Il DroidCon dell’anno scorso si era presentato subito con un’epidemia incontrollata di vari modelli di Google Glass, indossati da una buona percentuale degli speaker, l’edizione 2015 si è rivelata ugualmente modaiola con lo spostamento abbastanza massiccio dagli imbarazzanti occhiali ai più discreti orologi basati su Android Wear. Un chiaro passo in avanti sul fronte della classe.

In virtù di questo, ugualmente marcata era la presenza di Android Wear e Android Auto, le due nuove frontiere del robottino verde, come tema principale di diversi talk tenuti durante le due intense giornate di conferenza. Interessanti pure i temi legati all’intersezione tra Android ed Internet of Things, con interessanti presentazioni come quella sullo sfruttamento di iBeacon e (sconfortanti) esperimenti sulle tecniche di monitoraggio della prossimità di Matteo Gazzurelli.

Oltre allo sviluppo software, uno dei maggiori temi trattati era la cura per l’esperienza utente (la cosiddetta “UX”): Lydia Selimalhigazi e Roberto Orgiu hanno presentato come designer e sviluppatori devono necessariamente collaborare per ottenere un risultato di successo. Il tema, dal punto di vista del branding, è stato trattato poi anche in una stimolante presentazione di Marie Schweiz proprio sull’influenza di elementi caratterizzanti di un marchio sull’esperienza d’uso e la percezione di un app da parte degli utilizzatori.

Sempre sul fronte “user experience”, ma da un punto di vista totalmente diverso: Kentaro Takiguchi nella sua presentazione “Improving UX through Performance” ha dato un’idea molto approfondita e viva di tutte le piccole ottimizzazioni che si possono introdurre, sia sul lato app che sul lato server, per rendere l’utilizzo di un’applicazione più fluido, affidabile e responsivo, dovendo fare i conti con risorse limitate e connettività lenta o spesso assente. Molti trucchi interessanti, per uno scenario in cui anche tagliare 4 KB di trasferimento dati può avere conseguenze drastiche.

Come ci ha ricordati puntualmente Benjamin Augustin nel suo talk “RxFy All The Things!”, sviluppare codice può essere spesso una sofferenza infernale. Ma proprio per alleviare le pene dello sviluppatore ci sono sempre più librerie e strumenti che vale la pena sperimentare e conoscere: uno di questi è appunto RxJava, la versione Java delle Reactive extensions concepite su .NET, un modo molto interessante per “invertire” l’approccio delle applicazioni, che adottano quindi un paradigma “reattivo” che molto bene si adatta per l’interazione tra interfaccia grafica e un backend lento o inaffidabile (come ad esempio delle richieste remote).

Alla stessa maniera Maciej Górski ha presentato una varietà di sistemi interessanti per ridurre, soprattutto grazie all’utilizzo di plug-in per Gradle (il nuovo sistema di build utilizzato da Android Studio), la necessità di scrivere molto codice “boilerplate”, ossia ripetitivo senza alcun effettivo valore (come ad esempio metodi getter e setter per le proprie classi Java). Molto interessante anche la sessione “Holy Sync!” di Eugenio Marletti, sui metodi di sincronizzazione cross-platform dei dati, in questo caso utilizzando CouchBase.

“Test, test, test!” questo è stato uno dei mantra più ripetuti in quasi tutte le sessioni di questa edizione e, in particorale, sono stati i due sempre spumeggianti Ali Derbane e Wiebe Elsinga (non provate neanche a pronunciare il suo nome, fallireste) che con il talk “The hitchhiker’s guide to functional testing” hanno fatto una panoramica sui principali strumenti per il testing funzionale delle nostre app. Mentre Stephan Linzner ha mostrato le meraviglie dei nuovi strumenti cucinati con amore da mamma Google per i suoi sviluppatori mobile.

Inoltre, a mezzogiorno del primo giorno, sospinto più dal desiderio di raggiungere il buffet che altro, Lorenz ha presentato “The love child of Android and .NET: using Xamarin for app development” facendo riferimento alle nostre esperienze di sviluppo Android utilizzando la piattaforma Xamarin durante lo scorso anno, con tutti i vantaggi e problemi del caso. Le slide presentate possono essere scaricate in formato PPTX.

Ci ha energizzati durante le sessioni: la bevanda preferita di Amedeo Avogadro!

Dopo due giornate intense siamo ripartiti da Torino esausti per l’incessante successione di presentazioni, ma stimolati da tante nuove cose da sperimentare, tecnologie da esplorare e dettagli da tenere a mente durante lo sviluppo per Android (e non solo)!