Bologna, la citta dei flussi: Riqualificare e connettere tra architettura e movimento

La città di Bologna, la storia, i flussi e le connessioni. Questo progetto di gruppo nasce dalla necessità di ripensare il ruolo dell’infrastruttura nella contemporaneità e nell’atteggiamento che l’architettura può assumere di fronte alle rinnovate priorità delle città italiane che, tra espansione demografica, monumenti e centri storici da preservare, nuove reti di comunicazione e scambio delle informazioni, necessitano sempre più di una pianificazione che prenda in analisi il passato, interpreti il presente e si ponga l’obiettivo primario di dialogare con il futuro. Il capoluogo Emiliano è collocato in una posizione strategica per le comunicazioni d i trasporti, tenendo uniti gli estremi dello stivale e svolgendo un ruolo di snodo a cui oggi la penisola Italiana non può in alcun modo rinunciare. Ogni giorno una quantità spropositata di pendolari e viaggiatori è indotta nella città concentrandosi in un primo momento nell’area della stazione ferroviaria e dei piazzali antistanti, per poi distribuirsi all’interno del tessuto urbano, chi utilizzando il sistema di rete tramviaria, chi a piedi o in bicicletta. L’intento principale del masterplan proposto è quindi valutare un range di informazioni supplementari ai tradizionali studi urbani. Si è notato come le aree più degradate della città (spesso limitrofe ad infrastrutture consegnate al comune senza valutarne l’integrazione e l’impatto urbano e ambientale) manchino di una circolazione costante e di attività. Si è identificato nelle migliaia di soggetti che ogni giorno giungono a Bologna usufruendo dei servizi delle Ferrovie dello Stato la linfa vitale di un’importante parte della città. Poiché progettare per un futuro prossimo è pensare a un presente in grado di accettare i propri limiti e assimilare le aberrazioni del passato, rifacendosi ad un immaginario che non può che sconfinare i paradigmi prefissati che hanno portato ad uno status irrisolto ma non irrisolvibile.

Server-side scripting: confronto fra PHP, Python e server-side JS integrato in NodeJs

Lo scopo della tesi è quello di descrivere e mettere a confronto tre diversi linguaggi, e quindi approcci, alla programmazione server-side e di back-end, ovvero il linguaggio PHP, il linguaggio Python ed il linguaggio Javascript, utilizzato però per una programmazione “Server Side”, e quindi associato al framework NodeJS. Questo confronto si pone l’obiettivo di sottolineare le differenti caratteristiche di ogni linguaggio, gli scopi a cui esso maggiormente si addice e di fornire una sorta di guida per far in modo che si possa comprendere al meglio quale dei tre linguaggi maggiormente usati per la programmazione backend si conformi meglio all’obiettivo prepostosi.

DTN discovery and routing: from space applications to terrestrial networks.

L'argomento di questa tesi è l'architettura di rete Delay-/Disruption-Tolerant Networking (DTN), progettata per operare nelle reti “challenged”, dove la suite di protocolli TCP/IP risulta inefficace a causa di lunghi ritardi di propagazione del segnale, interruzioni e disturbi di canale, ecc. Esempi di reti “challenged” variano dalle reti interplanetarie alle Mobile Ad-Hoc Networks (MANETs). Le principali implementazioni dell'architettura DTN sono DTN2, implementazione di riferimento, e ION, sviluppata da NASA JPL per applicazioni spaziali. Una grande differenza tra reti spaziali e terrestri è che nello spazio i movimenti dei nodi sono deterministici, mentre non lo sono per i nodi mobili terrestri, i quali generalmente non conoscono la topologia della rete. Questo ha portato allo sviluppo di diversi algoritmi di routing: deterministici per le reti spaziali e opportunistici per quelle terrestri. NASA JPL ha recentemente deciso di estendere l'ambito di applicazione di ION per supportare anche scenari non deterministici. Durante la tesi, svolta presso NASA JPL, mi sono occupato di argomenti diversi, tutti finalizzati a questo obiettivo. Inizialmente ho testato la nuova implementazione dell'algoritmo IP Neighbor Discovery (IPND) di ION, corretti i bug e prodotta la documentazione ufficiale. Quindi ho contribuito ad integrare il Contact Graph Routing (CGR) di ION nel simulatore DTN “ONE” utilizzando la Java Native Interface (JNI) come ponte tra il codice Java di ONE e il codice C di ION. In particolare ho adattato tutte le librerie di ION necessarie per far funzionare CGR all'interno dell'ambiente di ONE. Infine, dopo aver analizzato un dataset di tracce reali di nodi mobili, ho contribuito a progettare e a sviluppare OCGR, estensione opportunistica del CGR, quindi ne ho curato l'integrazione in ONE. I risultati preliminari sembrano confermare la validità di OCGR che, una volta messo a punto, può diventare un valido concorrente ai più rinomati algoritmi opportunistici.

Analisi dei principali web framework basati su python

Lo scopo di questa tesi è dimostrare quale sia il miglior Web Framework con linguaggio Python fra i tre principali esponenti: Django, web2py e TurboGears. Inizialmente verrà effettuata un’analisi generale sui Web Framework, in particolare quelli con architettura MVC poiché sarà l’architettura utilizzata da Django, web2py e TurboGears. Successivamente, per ogni Web Framework verrà analizzata la struttura generale e i componenti core degli stessi. Tuttavia per stabilire chi sia il migliore fra di essi bisogna anche analizzare come essi gestiscono altri ambiti dello sviluppo web e quindi vengono analizzati tutti i tools messi a disposizione dai Web Framework. Alla fine verranno tratte le conclusioni in cui verrà chiarito quale sia il Web Framework migliore per uno sviluppatore e perché, andando a riassumere le caratteristiche di tutti e tre.

Valutazione del rischio sismico e idrogeologico nelle reti di distribuzione acqua e attuazione dei possibili interventi

L’obbiettivo ultimo di questo elaborato è quello di valutare il rischio per un evento sismico e un evento idrogeologico di tre reti di condotte per la distribuzione dell’acqua, per poter assegnare ai vari gradi di rischio un opportuno intervento. Le condotte delle reti sono identificate con: ID, materiale, pressione nominale, diametro nominale, portata, spessore, tipologia di giunti, rivestimento, protezione catodica, anno di posa, collocazione. Noti i dati, si possono calcolare le classi dei fattori vulnerabilità, esposizione e pericolosità, relativa ad ogni singola condotta e all’intera rete. La vulnerabilità valuta i fattori di suscettibilità e resilienza di una condotta, l’esposizione valuta i costi ad essa associati e la pericolosità valuta la possibilità degli eventi scelti in base alla collocazione fisica della condotta. Le classi sono successivamente combinate per conoscere il rischio della condotta rispetto l’intera rete. Valutato il livello di rischio abbinato al livello di vulnerabilità della condotta, si ottiene l’intervento opportuno per la condotta analizzata.

Confronto simulativo tra architetture per la mobilità: analisi simulatore MIPv6 e confronto con ABPS

Il presente elaborato tratta il lavoro di studio, analisi e sperimentazione effettuato dal sottoscritto, Giovanni Sitta, in conclusione al Corso di Laurea Magistrale in Informatica presso l'Università degli Studi di Bologna. Questo ha dapprima previsto un periodo di approfondimento di alcune architetture di supporto alla mobilità dei terminali di rete, in particolare di due protocolli allo stato dell'arte, Mobile IPv6 (MIPv6) e Locator/Identifier Separation Protocol (LISP), e di una terza architettura sperimentale denominata Always Best Packet Switching (ABPS). Sono stati in seguito esaminati tre simulatori, uno per ciascuna architettura di supporto alla mobilità considerata, realizzati come estensioni della libreria INET del framework OMNeT++, assicurandosi che fossero conformi alle specifiche del protocollo implementato (almeno entro i limiti di semplificazione rilevanti ai fini del lavoro), e correggendone eventuali problematiche, mancanze e anomalie in caso questi non le rispettassero. Sono poi stati configurati alcuni scenari simulativi utilizzando le tre librerie, in prima battuta di natura molto semplice, utilizzati per verificare il corretto funzionamento dei simulatori in condizioni ideali, e successivamente più complessi, allestendo un ambiente di esecuzione più verosimile, dotato di un maggior numero di host connessi alla rete e di ostacoli per i segnali radio usati nelle comunicazioni wireless. Tramite i risultati sperimentali ottenuti da queste simulazioni è stato infine possibili realizzare un confronto tra le prestazioni di MIPv6, LISP e ABPS.

Confronto simulativo tra architetture per la mobilità: analisi simulatore LISP e confronto con ABPS

L'utilizzo sempre crescente di dispositivi mobili, lo sviluppo di applicazioni mobile in continuo aumento, e la necessità di una sempre migliore qualità della comunicazione, ha portato grande interesse ad analizzare i protocolli di supporto alla mobilità dei terminali. Questi, tra i quali il più conosciuto è forse Mobile IP, vengono posti in esame utilizzando diverse metriche per valutarne le prestazioni. Si confrontano dunque due protocolli: LISP e ABPS; per ognuno dei quali ne viene presentata e descritta l'architettura e le principali funzionalità; entrambe queste architetture per il supporto alla mobilità, prevedono delle specifiche per fornire continuità nella comunicazione durante il roaming di un nodo multihomed. Vengono presentati poi gli strumenti con i quali verrà effettuata il l'analisi: il simulatore a eventi discreti OMNeT++ e il suo framework INET. Successivamente sono descritte le principali componenti dei simulatori per LISP e ABPS, che modellano le meccaniche dei due protocolli analizzati. Questi sono stati sottoposti a modifiche mirate a correggerne eventuali anomalie di comportamento, e ad introdurre nuove funzionalità, soprattutto per quanto riguarda ABPS, che era solo parzialmente implementato. Sono mostrati gli scenari in cui verranno effettuati i test per il confronto delle prestazioni: uno scenario semplice e uno che cerca di proporre una rete urbana verosimile; di seguito vengono elencati i parametri e le configurazioni utilizzate per ognuno dei due scenari. Infine vengono presentati i risultati mettendo a confronto due aspetti della mobilità dei terminali: durata dell'intervallo di indisponibilità e latenza dei pacchetti.

Disseminazioni in reti peer-to-peer attraverso algoritmi di gossip a due fasi

Gli algoritmi di gossip sono utilizzati per la disseminazione di messaggi in una rete peer-to-peer. La tesi tratta lo sviluppo, l'implementazione e l'analisi di quattro nuovi algoritmi di gossip "a due fasi". Gli algoritmi sono stati sviluppati e testati con il simulatore LUNES per poi essere analizzati in vari confronti con gli algoritmi classici dell'ambito, ovvero Fixed Probability e Conditional Broadcast. Le prove sono state effettuate su varie tipologie di grafi, ovvero Random, Scale-free, Small-world e K-Regular.

Determinazione e analisi del rischio sismico e idrogeologico nelle reti di distribuzione acqua

In questo elaborato si è focalizzata l’attenzione sulla determinazione del rischio simico e idrogeologico per una rete di distribuzione acqua. Partendo dalle caratteristiche di ogni singolo elemento si sono valutati la vulnerabilità, l’esposizione e la pericolosità per ogni condotta. In conclusione si è analizzato il rischio al fine di individuare quegli elementi maggiormente compromessi su cui concentrare l’attenzione per possibili interventi futuri.

Elaborazione di Big Data: un’applicazione dello Speed Layer di Lambda Architecture

I Big Data hanno forgiato nuove tecnologie che migliorano la qualità della vita utilizzando la combinazione di rappresentazioni eterogenee di dati in varie discipline. Occorre, quindi, un sistema realtime in grado di computare i dati in tempo reale. Tale sistema viene denominato speed layer, come si evince dal nome si è pensato a garantire che i nuovi dati siano restituiti dalle query funcions con la rapidità in cui essi arrivano. Il lavoro di tesi verte sulla realizzazione di un’architettura che si rifaccia allo Speed Layer della Lambda Architecture e che sia in grado di ricevere dati metereologici pubblicati su una coda MQTT, elaborarli in tempo reale e memorizzarli in un database per renderli disponibili ai Data Scientist. L’ambiente di programmazione utilizzato è JAVA, il progetto è stato installato sulla piattaforma Hortonworks che si basa sul framework Hadoop e sul sistema di computazione Storm, che permette di lavorare con flussi di dati illimitati, effettuando l’elaborazione in tempo reale. A differenza dei tradizionali approcci di stream-processing con reti di code e workers, Storm è fault-tolerance e scalabile. Gli sforzi dedicati al suo sviluppo da parte della Apache Software Foundation, il crescente utilizzo in ambito di produzione di importanti aziende, il supporto da parte delle compagnie di cloud hosting sono segnali che questa tecnologia prenderà sempre più piede come soluzione per la gestione di computazioni distribuite orientate agli eventi. Per poter memorizzare e analizzare queste moli di dati, che da sempre hanno costituito una problematica non superabile con i database tradizionali, è stato utilizzato un database non relazionale: HBase.

Implementazione e analisi di un’applicazione Android per il Dynamic Adaptive Streaming cooperativo tramite Http e WiFi-Direct

Questo lavoro ha lo scopo di presentare l’implementazione e la valutazione di un’applicazione Android che permetta la riproduzione di uno streaming auto-adattante conforme allo standard DASH sfruttando le funzionalità offerte dal player ”ExoPLayer” a cui viene aggiunta la funzionalità di caching e condivisione dei relativi segmenti tramite WiFi-Direct. Questo al fine di raggiungere diversi obiettivi come la riduzione dell’utilizzo di reti mobili, l’aumento della qualità e/o una riproduzione più fluida. Si è inoltre sviluppato un simulatore in C++ che permette di valutare il comportamento dell’applicazione, l’algoritmo usato per la scelta dei segmenti, e i vantaggi correlati.

Pi release from myosin: a simulation analysis of possible pathways

The release of phosphate (Pi) is an important element in actomyosin function and has been shown to be accelerated by the binding of myosin to actin. To provide information about the structural elements important for Pi release, possible escape pathways from various isolated myosin II structures have been determined by molecular dynamics simulations designed for studying such slow processes. The residues forming the pathways were identified and their role was evaluated by mutant simulations. Pi release is slow in the pre-powerstroke structure, an important element in preventing the powerstroke prior to actin binding, and is much more rapid for Pi modeled into the post-rigor and rigor-like structures. The previously proposed backdoor route is dominant in the pre-powerstroke and post-rigor states, whereas a different path is most important in the rigor-like state. This finding suggests a mechanism for the actin-activated acceleration of Pi release.

Outcomes of patients on dual-boosted PI regimens: experience of the Swiss HIV cohort study

Dual-boosted protease inhibitors (DBPI) are an option for salvage therapy for HIV-1 resistant patients. Patients receiving a DBPI in the Swiss HIV Cohort Study between January1996 and March 2007 were studied. Outcomes of interest were viral suppression at 24 weeks. 295 patients (72.5%) were on DBPI for over 6 months. The median duration was 2.2 years. Of 287 patients who had HIV-RNA >400?copies/ml at the start of the regimen, 184 (64.1%) were ever suppressed while on DBPI and 156 (54.4%) were suppressed within 24 weeks. The median time to suppression was 101 days (95% confidence interval 90-125 days). The median number of past regimens was 6 (IQR, 3-8). The main reasons for discontinuing the regimen were patient's wish (48.3%), treatment failure (22.5%), and toxicity (15.8%). Acquisition of HIV through intravenous drug use and the use of lopinavir in combination with saquinavir or atazanavir were associated with an increased likelihood of suppression within 6 months. Patients on DBPI are heavily treatment experienced. Viral suppression within 6 months was achieved in more than half of the patients. There may be a place for DBPI regimens in settings where more expensive alternates are not available.