L’arte della copia ai tempi del web (prima parte)

Nell’era del web e dei social network si stima che fino al 30%(1) dei contenuti visibili sia costituito da copie e duplicati. Le ragioni per cui questo accade, i modi con cui si realizza e gli effetti che ne conseguono costituiscono una storia a sé, che voglio raccontare, per quanto posso, in questo articolo e nel successivo.

Web scraping

La prima e forse più nobile arte della copia su web è il cosiddetto “web scraping”: si catturano informazioni da siti web per costruire propri database di dati, da usare poi per la costruzione di altri siti, la scrittura di applicazioni, la creazione di mailing list ecc. Obiettivi preferenziali degli scrapers  sono i siti che contengono basi di dati utili a varie attività commerciali (elenchi telefonici, indirizzari, cataloghi di prodotti o servizi, registri professionali, orari e tariffari dei trasporti, repertori di varia natura ecc.)

Ovviamente questa raccolta di dati non si fa manualmente (salvo eccezioni), ma si usano programmi fatti apposta, prodotti software e servizi online; quando si parla di web scraping si sottintende di solito che si tratta di attività automatiche e periodiche, effettuate tramite automi software (bots).

Normalmente, il fruitore non va troppo per il sottile e non si preoccupa di accertare se l’operazione sia lecita oppure violi qualche regola di copyright; nella maggioranza dei casi lo scopo è quello di ottenere gratis dati che altrimenti costerebbero molto o sarebbero inaccessibili; per questo, lo “scraper” tipico sa di “fare il furbo” e di usare metodi che come minimo non rispettano lo spirito del copyright.

Non sempre, però, il web scraping è un’operazione illecita o al limite della decenza. Secondo alcuni è un modo in cui l’informazione in rete si ristruttura, si aggrega e acquisisce una maggiore intelligenza, trasformando la massa informe di dati in qualcosa di più simile ad una base dati condivisa.

Inoltre, se i dati oggetto dello scraping sono pubblicamente disponibili senza protezioni, lo scraping è effettivamente uno dei modi leciti in cui questi dati contribuiscono a creare ulteriori servizi e prodotti. Qualche esempio lo abbiamo in casa nostra: le App per iOs e Android “Farmacross” e “Comuni d’Italia” si basano su basi dati proprie costruite con una serie di operazioni di acquisizione da fonti pubbliche (tra cui la Base Date dei Farmaci AIFA, i report demografici ISTAT, e numerose altre). Per arrivare a rendere questi dati usabili per i nostri obiettivi è necessaria una serie di operazioni non banali di integrazione e bonifica dei dati, operazioni che a tutti gli effetti creano del valore aggiunto rispetto alle informazioni grezze originali.

Strumenti e metodi

Una delle cose interessanti in merito al web scraping è che ha fatto nascere un intero settore specifico dell’informatica e ha portato al fiorire di una serie di prodotti e servizi intorno a quest’area.

Dal punto di vista tecnico, il primo approccio al web scraping è semplice: i contenuti pubblicati su Web si presentano come pagine HTML ottenute dal browser richiamando con il protocollo HTTP un web server. Dato che una chiamata HTTP può essere effettuata da qualsiasi linguaggio di programmazione moderno, il web scraping più elementare consiste nello scrivere programmi (di solito con php, python, c#, javascript, java) che effettuano le chiamate necessarie, acquisiscono il contenuto della pagina e ne estraggono le informazioni desiderate. Ci sono di mezzo una serie di “technicalities”  che rendono la cosa meno banale di quanto sembri, ma il concetto resta semplice.

Fino a una dozzina di anni fa, questo metodo elementare avrebbe funzionato con gran parte dei siti esistenti; però, il disturbo che questo creava ai legittimi proprietari dei siti (sia in termini di violazioni di copyright, sia per i disservizi dovuti al sovraccarico di accessi) ha fatto nascere e diffondere contromisure via via più complesse e, in parallelo, metodi di scraping sempre più sofisticati.

Captcha

Uno dei più diffusi e semplici sistemi di protezione dallo scraping è l’uso di captcha(2) cioè di quella specie di quiz visivo che tutti noi abbiamo incontrato su qualche sito, escogitato per verificare che la pagina sia stata raggiunta da un essere umano e non da uno “stupido” programma.

Dato che i programmi sono sempre meno “stupidi”, il tipo di quiz si evolve nel tempo; ma i maniaci dello scraping sono ingegnosi e hanno inventato una curiosa soluzione per questo problema, se si hanno i fondi per pagarla. Basta affittare un servizio di risoluzione dei captcha (“captcha solver”); si ricevono le istruzioni per collegare il programma al servizio attraverso un’interfaccia (Api): il programma invia l’immagine del captcha e ottiene dopo circa 15 secondi il testo che risponde al problema.

Ma come fa il captcha solver a interpretare l’immagine? Semplice: la passa ad un operatore umano, che ha l’unico (ingrato) compito di immettere la risposta (e deve farlo entro pochi secondi, se vuole essere pagato). Non ci vuole molto a capire che questi servizi possono nascere solo in paesi dove il costo del lavoro è molto basso; comunque, se siete interessati a guadagnare lavorando da casa (ben 0,88$ per 1000 captcha risolti) potete ad es. rivolgervi qui: https://2captcha.com/make-money-online.

Protezione basata su Javascript

Se non ci sono captcha a bloccare l’accesso, il sito si può proteggere in vari modi. Uno dei più semplici è non produrre il contenuto HTML nel primo messaggio HTTP diretto al browser ma invece comporlo dinamicamente utilizzando le funzioni del browser. Ad es. le nostre applicazioni HTML5 / CSS3 / Javascript costruite con framework come ExtJs o JQuery rientrano in questa categoria: la pagina HTML vera e propria contiene ben poco, perché i veri dati sono ottenuti da chiamate Ajax che avvengono in vari punti del codice javascript, dopo che la pagina HTML è stata ricevuta dal browser.

In questo caso, se il programma di scraping è troppo semplice non vede alcun contenuto utile nella pagina HTML e le tecniche di programmazione per superare l’ostacolo in questo caso diventano un po’ più sofisticate. Però se il sito non ha altre protezioni esplicitamente progettate, un programmatore sufficientemente esperto e volenteroso può individuare (con gli strumenti di debugging del browser) le chiamate HTTP interne alla pagina e riuscire a simularle da programma.

Bot detection tools

Per eliminare completamente (o quasi) il problema degli scrapers, i siti meglio attrezzati si dotano di strumenti anti-bot: si tratta di strumenti che tentano di riconoscere quando un accesso ad un sito è effettuato presumibilmente da un robot e lo bloccano con un messaggio informativo (vedi ad es. questa pagina).

Nella forma più semplice, un anti-bot non fa altro che controllare alcune caratteristiche del messaggio HTTP (headers), verificare che non avvengano troppe richieste per unità di tempo da uno stesso indirizzo IP ed escludere indirizzi di provenienza appartenenti a qualche blacklist. Questi controlli possono però essere abbastanza facilmente superati da un programma abbastanza sofisticato; nel tempo si sono perciò sviluppati meccanismi molto più complessi: gli anti-bot più avanzati si basano su complessi metodi di composizione delle pagine in più fasi, che includono l’esecuzione di porzioni di codice javascript criptato e variabile. Pur essendo in teoria possibile violare questi sistemi, il costo per violarli diventa talmente alto da dissuadere gli eventuali attaccanti.

Il business

Come dicevo, è interessante notare che si è sviluppato un business specifico intorno a questi temi, su entrambi i lati della barricata: ci sono società come Distil Networks  e ShieldSquare che basano il loro fatturato sugli strumenti di protezione dai bots, e altre società e comunità che lavorano per superare quelle stesse protezioni.

Ad es. Selenium è un progetto open-source che sviluppa funzioni per simulare le azioni di un operatore umano su un browser Chrome, Firefox, IE; formalmente nato per l’automazione dei test di applicazioni web-based, è più diffuso come strumento di web scraping.

Esistono poi un gran numero di servizi online che dichiarano di utilizzare tecnologie avanzate di web scraping e in alcuni casi offrono anche applicazioni gratuite da utilizzare sul proprio computer: il più noto è probabilmente Import.io, ma potete trovare una lista piuttosto esauriente in questo => blog.

Infine, caso mai non foste appagati dai 9 dollari guadagnati decifrando i vostri primi 10mila captcha, potete proporvi su uno dei tanti progetti di web scraping umano attraverso siti tipo www.freelancer.com o www.peopleperhour.com: cercate titoli come “Fill Excel spreadsheet with data” e potrete facilmente guadagnare anche 4 dollari in un’ora, copiando accuratamente a mano l’elenco degli annunci da un sito di e-commerce arabo  oppure i nomi e i recapiti di 20mila medici  da un sito pakistano.

A presto, e restate sintonizzati per la Parte Seconda…


Note e riferimenti

(1) http://searchengineland.com/googles-matt-cutts-25-30-of-the-webs-content-is-duplicate-content-thats-okay-180063
(2) https://it.wikipedia.org/wiki/CAPTCHA

Abbiamo un blog

E così, in pochissimo tempo, un’idea buttata lì quasi per caso si è realizzata. O meglio, per adesso ha solo preso il via. Poi, la scommessa sarà quella di mantenere questo blog vivo e vitale, di farlo crescere, ovviamente con la collaborazione di tutti.

La proposta di aprire questo spazio sul sito aziendale era scaturita dalla considerazione che ognuno di noi avesse informazioni, interessi, conoscenze – non solo in campi strettamente lavorativi – che rimanevano di fatto sconosciute e che sarebbe stato importante portare alla luce, riuscire a tirare fuori e condividere.

Penso che chiunque di noi, negli anni che ha dedicato a questo lavoro, abbia pensato, prima o poi, di “informatizzare” qualcosa legato ai propri interessi personali, a un hobby, a una idea qualsiasi nei campi più diversi, dall’astronomia alle ricette della nonna, dalla fotografia ai giochi sparatutto o a quelli per bambini, dalla grafica 3D a come creare un ebook – o a qualsiasi altra cosa, perché questa lista in realtà non ha fine e può contenere di tutto – e nel far questo abbia approfondito argomenti e acquisito conoscenze che poi forse non ha mai concretizzato in progetti reali.

E poi tutto quello che impariamo con il nostro lavoro, sulle nuove piattaforme, i problemi che risolviamo nei nostri progetti, informazioni sui prodotti, gli ambienti. Questo spazio potrà essere usato per condividere le nostre esperienze, così come ha iniziato a fare Giorgio con il primo articolo, scrivere veri e propri tutorial o semplici tip & tricks, riportare resoconti di corsi o di eventi esterni a cui abbiamo partecipato, o interni come i nostri AperiLogica.

Questa potrebbe essere l’occasione per mettere un po’ di ordine in quello che sappiamo, per riorganizzarlo in modo da renderlo fruibile anche ad altri. Esporre qualcosa, conoscenze  che magari abbiamo in testa in forma frammentaria, scrivendo una specie di articolo potrebbe sembrare un compito arduo, oltre le proprie possibilità – e in effetti, almeno per me,  lo è – ma in realtà bisogna solo provarci. E nessuno verrà a cercare qui dentro articoli da Premio Pulitzer. E comunque si possono anche usare altre forme di divulgazione, come  ad esempio dei video.

Credo che non ci sia limite, né alle forme né ai contenuti, di quello che potrebbe essere scritto qui, che rimane comunque interno e non visibile su internet. Però è anche vero che questa potrebbe essere l’occasione di raccogliere materiale da esporre all’esterno, per arricchire l’immagine della nostra azienda su internet. Pensate anche a questo.

 

 

Lo sviluppo di Apps in Logica Informatica

Pionieri?

Forse non tutti sanno che Logica Informatica è stata una delle prime società informatiche italiane ad interessarsi allo sviluppo di applicazioni per smartphone. Già nel 2006, assorbendo la società IS&O, acquisiva il progetto PocketLine, che prevedeva una modalità di comunicazione avanzata tra sistemi centrali “tradizionali” e smartphone dotati di un sistema operativo appena accettabile. A quel tempo il Symbian della Nokia e il Blackberry erano più o meno gli unici sistemi su cui si poteva pensare di sviluppare un’applicazione “utile”. PocketLine era però in grado di usare i sistemi primitivi di messaggistica (SMS, MMS) per rendere possibile ad un’azienda la condivisione di informazioni tra i sistemi centrali e dispositivi remoti, in modo generalizzato ed estensibile.

PocketLine rimase a livello di prototipo e non divenne mai un prodotto commerciale; in effetti fu una fortuna non aver investito ulteriori energie nel progetto, visto che già nel 2007 fu presentato al mondo il primo iPhone e  l’anno dopo divenne disponibile l’Apple Developer Program per iOs che avviò l’era dello sviluppo di App.  Ci si rese conto subito che paragonare una tecnologia pensata per il più avanzato dei Nokia con il primo iPhone era come confrontare un’Ape Piaggio con una Bugatti. L’iPhone avrebbe portato rapidamente all’estinzione dei dinosauri.

Saltiamo sul treno

Ovviamente non siamo rimasti a guardare. Le nostre prime sperimentazione mostravano che l’iPhone aveva capacità quasi da fantascienza: era  possibile realizzare praticamente qualsiasi cosa (figuriamoci adesso). Nei primi mesi di vita dell’Apple Store erano state pubblicate migliaia di App, molte delle quali potremmo definire “inguardabili”; c’era comunque l’impressione che le possibilità creative fossero illimitate. Inoltre, solo in minuscola percentuale si trattava di App provenienti da sviluppatori italiani e in proporzioni ancora più infinitesimali da Società italiane.

Logica Informatica, per rispettare la sua natura (e perché era più facile) decise di cimentarsi nella creazioni di applicazioni “utili”, in particolare di applicazioni che potremmo definire “di consultazione”. Nel Dicembre 2008 pubblicò la prima: Ipse Dixit, dizionario di citazioni, in quattro lingue, seguita nei mesi successivi dai Codici (Civile, Penale ecc.), da FarmaciaPlus (prontuario dei farmaci), Comuni d’Italia e via dicendo. A tutt’oggi abbiamo realizzato più di 30 App, sia per il mercato “consumer” diretto (cioè vendendole come Logica Informatica), sia per conto terzi (ad es, Maggioli Editore, Guardia di Finanza, ecc.), sia per utilizzo interno di  nostri clienti. Per alcune di queste App ci sarebbe molto da raccontare, ma non lo farò questa volta. Parlerò invece della evoluzione “tecnologica” che ha subìto questa area di sviluppo in Logica Informatica.

Android, Windows e gli altri

Tanto per cominciare, dopo l’iPhone, il quadro si complica: nel 2009 compaiono i primi telefoni dotati di sistema Android, e si vede qualche miglioramento degli smartphone basati su Windows; si affacciano sul mercato anche altri possibili sistemi operativi (Tizen, Firefox,…): a tutt’oggi risultano però semplici esperimenti non riusciti.

Logica Informatica decide di tentare, senza fretta, il “porting” di FarmaciaPlus, la sua App più importante, su Android e Windows. L’impresa riuscirà con fatica, su Android, solo nel 2011, mentre le limitazioni intrinseche di Windows la renderanno impossibile fino all’uscita di Windows Phone 8.1 (Windows CE non poteva gestire un database più grande di pochi megabytes). Per quanto riguarda Windows, l’attenzione dedicatagli si rivela tempo perso, visto che nel 2016 i dati di mercato cominciano ad indicare l’inarrestabile declino della quota di mercato già minima di Windows Phone; il porting di Farmacia Plus su Windows Phone non verrà quindi mai completato. Riposi in pace.

Sviluppo cross-platform

Fino al 2012, lo sviluppo delle App di Logica Informatica era avvenuto con gli strumenti nativi di ciascuna piattaforma, cioè XCode / Objective C per iPhone, Android Sdk / Java per la piattaforma Android e Visual Studio / C# per Windows Phone. Si tratta di strumenti completamente diversi uno dall’altro, come del resto i sottostanti sistemi operativi, e il costo dello sviluppo di un’applicazione complessa per tutte e tre le piattaforme risulta tanto elevato da costituire un problema. In particolare, Logica deve risolvere questo problema nel momento in cui viene ingaggiata da Clienti per la realizzazione di App che devono presentarsi identiche su iOs e Android; la competizione con gli altri possibili concorrenti costringe a trovare e adottare soluzioni tecniche che consentano il “write once, deploy many”, cioè scrivere un solo codice sorgente e poterlo poi “compilare” per le diverse piattaforme.

Il problema si presenta in effetti fin dal 2010, ma diviene essenziale proporre una soluzione solo nel 2012, per la realizzazione di un’App per le ricevitorie Sisal. A quel punto, si esplorano le varie tecnologie disponibili e si sceglie la nostra prima piattaforma per lo sviluppo cross-platform su dispositivi mobili: Titanium Appcelerator. Comincia quindi nel 2012 una strada che porterà ad altri cambi di piattaforma e che sicuramente non è ancora conclusa: ecco qualche dettaglio di questa storia.

Titanium

Titanium Appcelerator (oggi semplicemente Appcelerator) è uno strumento che permette di usare il linguaggio Javascript per realizzare applicazioni “sostanzialmente” native: in effetti, con un’architettura piuttosto ingegnosa, Appcelerator presenta gli oggetti nativi della piattaforma (cioè tutte le componenti visuali e non visuali disponibili su iOs e Android) attraverso dei “wrappers” javascript. Quindi si programma in Javascript, ma in effetti ogni view, widget, file, database, connessione ecc. è realizzata dall’oggetto “nativo” sottostante.

Il risultato è che non solo l’aspetto visuale di un’App realizzata con Appcelerator è uguale a quello di una App nativa, ma anche le prestazioni dell’App sono molto simili, anche se leggermente inferiori, a causa dell’ overhead che il passaggio attraverso Javascript produce rispetto ad una soluzione realmente nativa. Inoltre le App sviluppate con Titanium sono considerevolmente più voluminose del loro equivalente nativo, a causa dei componenti che sono presenti necessariamente in ciascuna di esse, in particolare un interprete Javascript e tutte le interfacce di tra oggetti Javascript e oggetti nativi.

L’esperienza Titanium dura 2-3 anni e interessa lo sviluppo di varie App per terze parti (in particolare, iGdF); progressivamente, la Logica Informatica si orienta però verso un abbandono della piattaforma, sia perché non supporta Windows (problema che si riteneva ancora rilevante fino a un anno fa) sia perché il sistema di licensing del prodotto e il ritmo degli aggiornamenti di release non convincono e creano qualche problema. Inoltre, emergono anche problemi squisitamente tecnici nello sviluppo: pur raggiungendo il risultato di mantenere un solo codice sorgente per tutte le piattaforme,  ottenere i risultati visuali e funzionali desiderati risulta piuttosto faticoso, proprio a causa delle modalità sofisticate con cui la piattaforma Titanium nasconde gli oggetti nativi dietro interfacce Javascript.

Sencha Touch

Intorno al 2014, si decide di cambiare approccio e di orientarsi verso lo sviluppo di App di tipo HTML 5 /JS / CSS 3: si tratta cioè di sviluppare l’App come fosse un sito Web (in effetti come una “single-page application“, usando HTML e Javascript) per poi compilarla in modo che venga eseguita all’interno di una “web view” nativa della piattaforma. Il “compilatore” è fornito dal prodotto open-source Cordova della Apache Foundation, che è utilizzato universalmente da tutte le piattaforme di sviluppo di questo tipo.

Si studia un po’ la situazione del mercato e, tra le molte scelte disponibili, si opta per Sencha Touch: il motivo è che Logica Informatica già utilizza dal 2011  Sencha ExtJs per la realizzazione dei suoi prodotti Web-based (in particolare DCSys e Lossis) e Sencha Touch è una versione dello stesso prodotto, adattata alle necessità dei dispositivi mobili. Lo sviluppo con Sencha Touch richiede l’utilizzo di Sencha Architect, prodotto che consente di comporre in maniera visuale il layout delle pagine e di manipolare componenti e proprietà in modo guidato.

Con Sencha Touch si realizzano alcune applicazioni, tra cui iMinerva, per la Scuola Superiore di Polizia Tributaria, e l’ultima versione di iGdf. Nonostante gli aspetti positivi della scelta, con il tempo si comincia a considerarla non sostenibile, più o meno per gli stessi motivi di Titanium: problemi strettamente tecnici (la piattaforma è così sofisticata che ottenere i risultati desiderati su tutti i modelli di smartphone e tablet risulta piuttosto complicato) e ragioni strategiche: il sistema di licensing e il frequente passaggio di release del prodotto rendono rapidamente obsoleto quanto realizzato; ad ogni evoluzione richiesta dai Clienti si deve affrontare il costo della migrazione delle App all’ultima versione della piattaforma.

L’obiettivo strategico rimane quello di usare un approccio basato su HTML, ma si comincia a ragionare su una forma di downgrade della piattaforma, cioè il ritorno ad un modello di sviluppo che aggiunga ai componenti fondamentali la quantità minima possibile di sovrastrutture. Questo ha anche una precisa corrispondenza nella qualità del codice HTML e Javascript utilizzato: quando si sviluppa con una piattaforma come Sencha Touch, la struttura HTML costruita dalla piattaforma è talmente complicata che risulta difficile controllarne i comportamenti (ad es. affinare dimensioni e posizioni per adattarsi a diversi formati dello schermo).

Xamarin

Mentre si comincia a sperimentare la prossima evoluzione della soluzione HTML, il cliente Poste Italiane mette in condizioni Logica Informatica di sperimentare Xamarin, piattaforma di proprietà della Microsoft, per realizzare il prototipo di una nuova App di uso interno.

Xamarin si basa sullo sviluppo con C# (in Visual Studio) per creare applicazioni cross-platform  native: il risultato cioè viene convertito effettivamente in codice compilato per Windows Phone, Android, iOs. In questo caso, il fatto che la piattaforma provenga da Microsoft, società che sta chiaramente fallendo il suo tentativo di penetrazione nel mercato degli smartphone, solleva qualche dubbio sull’opportunità della scelta fatta dal Cliente, ma comunque consente di esaminare anche questa possibile strada.

L’impressione conclusiva ricavata dall’esperienza su Xamarin è che si tratti di un sistema ancora immaturo, risultante da un collage di componenti non ancora perfettamente integrati, che presenta gli stessi problemi di ogni piattaforma “proprietaria” provata fino ad oggi: non è cioè facile riuscire a costringere lo strumento a produrre i risultati voluti, su ogni tipo di dispositivo.

L’ultimo passo?

Nel corso del 2015, Logica Informatica comincia a sperimentare la soluzione identificata, quella cioè basata su un utilizzo “a basso livello” di HTML, Javascript e CSS, associato ad Apache Cordova per la compilazione dei pacchetti finali. Il risultato finale della sperimentazione è applicato a FarmaCross (pubblicata su Apple Store nel febbraio 2016), versione riveduta e corretta di FarmaciaPlus, della quale parlerò in un altro articolo.

La scelta del metodo di sviluppo si basa su alcuni principi, ma lascia una notevole libertà nei particolari:

  • clean html: l’HTML che costituisce le varie pagine dell’App deve essere privo per quanto possibile di sovrastrutture generate da strumenti di varia natura (in FarmaCross, l’HTML è stato costruito a mano).
  • si usano jQuery e componenti aggiuntivi basati su jQuery (ne esistono in numero illimitato: jQueryUI, jEasyUI, jQuery Mobile, ecc.)
  • possono essere usati componenti di ausilio per il layout (ad es. bootstrap)

La scelta effettuata ha consentito di ottenere alcuni risultati eccezionalmente utili:

  1. lo sviluppo avviene utilizzando il browser come sistema di debug (in particolare, il debugger Chrome in modalità device)
  2. non è necessario acquisire altri skill al di fuori di quelli utili alla realizzazione di una moderna applicazione Web
  3. l’App può essere costruita per essere aggiornabile “on the fly”, cioè può ricevere aggiornamenti e correzioni senza bisogno di essere ripubblicata (da server si possono acquisire porzioni di HTML e scripts che vanno automaticamente a sostituire le parti corrispondenti del pacchetto)

In sostanza, questo tipo di metodologia di sviluppo rigetta gran parte delle nuove strumentazioni nate specificatamente per lo sviluppo cross-platform, ma utilizza fortemente tutte le innovazioni nate per il web 2.0, a partire da HTML5 e CSS3. Componente fondamentale rimane però Apache Cordova, il vero asso nella manica dello sviluppatore.

L’esperienza con FarmaCross ha consentito di trarre alcune importanti conclusioni:

  • è il sistema di sviluppo più semplice e maneggevole tra quelli utilizzati finora
  • la quantità di codice comune a tutte le piattaforme è praticamente il 100%
  • le App sono più lente delle corrispondenti App native

Quest’ultimo punto è ovviamente importante: intendiamoci,  non parliamo di giochi interattivi, né di realtà virtuale, né di applicazioni stile Whatsapp. Nel nostro caso si tratta di applicazioni  principalmente di consultazione, dotate di un database locale, di modalità di colloquio con un server e di qualche funzione di notifica; questo restringe il numero di possibili problemi di prestazioni, ma si è dovuto comunque tenerne conto nel progettare la user experience. 

Il caso più tipico è la presentazione di liste a scorrimento: in un’applicazione iPhone nativa (come ad es. la nostra Comuni d’Italia), una lista può tranquillamente contenere migliaia di righe senza che l’utente percepisca il minimo rallentamento. Una lista di migliaia di righe realizzata con HTML su uno smartphone è semplicemente una cosa da evitare, a causa del tempo necessario al browser per effettuare il rendering della pagina.

Il futuro

Mentre Logica Informatica si ingegna, il settore delle App continua ad essere in piena effervescenza, anche se le statistiche indicano che solo una minima parte delle App realizzate (in tutto il mondo più di 2 milioni) producano introiti sufficienti a mantenerle. In quest’ottica, diventa essenziale avere strumenti migliori per ridurre tempi e costi di sviluppo e ci si aspetta quindi un crescente numero di proposte in tal senso.

Già oggi esistono una serie di possibilità che non abbiamo ancora esplorato a fondo:

  • application makers: si tratta di strumenti o più spesso siti che permettono di costruire un’App in modo guidato, usando modelli e componenti predefiniti. Spesso viene proposto un canone, che prevede anche servizi di monitoraggio. Il numero di offerenti è enorme (vedi ad es. https://www.websitetooltester.com/en/blog/app-makers) ed è oggettivamente difficile capire quanto siano efficaci senza sperimentarli sul serio.
  • piattaforme di sviluppo complete: in particolare Google Firebase e altre (Syncano, Telerik, Intel), propongono ciascuna un proprio ecosistema che si “sposa” o si rigetta in toto.
  • altri framework basati su Javascript: due dei più diffusi sono Ionic e React Native; quest’ultimo presenta qualche aspetto innovativo interessante.

Secondo la mia personale opinione, la strada maestra dovrebbe comunque basarsi sulle stesse tecnologie del Web 2.0, cioè HTML, CSS e Javascript, per motivi pratici e anche di principio: si tratta in fondo solo di due canali lievemente diversi che portano agli stessi contenuti e servizi.

Con l’evolvere delle capacità degli smartphone, il fattore velocità (lentezza) diventerà meno rilevante, così come tenderanno a sparire le differenze tra i diversi “motori” di rendering e interpreti Javascript. In prospettiva, mi aspetto che gli stessi “motori” siano via via incorporati ad un livello sempre più vicino al “core” del sistema operativo e all’ hardware, portando di fatto ad una convergenza tra programmazione Javascript e programmazione nativa.

HackTheSchool – IPSEOA Tor Carbone

MindSharing.tech e BIC Lazio in collaborazione con l’IPSEOA TOR CARBONE ed il supporto di Logica Informatica organizzano un hackathon per la valorizzazione degli skills degli studenti frequentanti l’Istituto e per la promozione dell’imprenditorialità giovanile.

Un hackathon è una maratona di programmazione nella quale diversi team gareggiano risolvendo concretamente una delle sfide (challenge) proposte dagli organizzatori.

Gli studenti durante #Hacktheschool saranno invitati a pensare e lavorare su nuove soluzioni ed idee di business.
Nei due giorni si sfideranno gli alunni dell’IPSEOA TOR CARBONE, che saranno suddivisi in team da 5 alunni ciascuno.

Gli obiettivi di questa iniziativa sono:

• Consolidare in modo mirato la preparazione degli studenti nei settori tecnologici;
• Favorire la nascita di processi creativi e di autoconsapevolezza;
• Guidare gli studenti verso il problem solving e spingerli a mettersi in gioco senza aver paura ad esporre le proprie idee;
• Rafforzare l’utilizzo di tecnologie abilitanti, in particolare le tecnologie dell’informazione e della comunicazione, per promuovere la cultura dell’auto imprenditorialità;
• Fornire ai docenti i mezzi e gli spunti per attuare una didattica innovativa;

Alla fine del secondo giorno i ragazzi dovranno presentare i progetti davanti alla giuria con un pitch di tre minuti. Sono previsti 3 Premi per i migliori progetti e 2 Menzioni Speciali.

Gli obiettivi di MindSharing.tech e del programma Startupper School Academy realizzato da BIC Lazio per conto della Regione Lazio, sono stati condivisi dal professoressa Alessandra Cannelli dell’IPSEOA TOR CARBONE, che hanno ritenuto quest’evento molto utile per l’attuazione del Piano Nazionale Scuola Digitale.
L’importanza di tale attività è stata riconosciuta anche da Logica Informatica, società che opera nell’ambito IT e ICT: “Supportare questi eventi vuol dire investire nel futuro dei nostri ragazzi” sostiene il CEO Michele Perrotta.

“Valorizzare le potenzialità degli studenti, promuovere la cultura collaborativa e quella dell’imprenditorialità, portare all’interno della scuola esperienze uniche e stimolanti” questi sono gli obbiettivi del progetto MindSharing.tech secondo il suo founder Aldo Pergjergji.

MindSharing.tech è un progetto che offre pacchetti di attività interattive e stimolanti per i ragazzi delle scuole elementari, medie e superiori, che hanno come obiettivo la promozione della imprenditorialità, la conoscenza dell’importanza della programmazione (coding) e, allo stesso tempo, la creazione di una consapevolezza degli aspetti negativi legati al mondo digitale, ovvero il cyberbullismo.

PROGRAMMA

Giovedì 23/03/2017
08.30 Check-in
09.00 Presentazione / Recap BMC / Introduzione Challenge / Team Building
09.30 Inizio Lavori (preparazione BMC)
12.30 – 13.30 Break
13.30 – 14.00 Workshop PitchTraining
17.30 – Fine lavori

Venerdì 24/03/2017
09.00 Inizio lavori (preparazione Pitch)
15.30 Fine Lavori – Raccolta progetti
16.00 Inizio Pitch Battle (3 min per team + 2 min Q&A)
17.00 Premiazione
17.30 Fine Hackathon

Per maggiori informazioni info@mindsharing.tech