(Ci vuole un Fiore)

It takes a Flower

Tomorrowdata's Blog

Lavora con noi

TomorrowData è una startup appena costituita e incubata dall’Università di Torino, che nasce dopo tre anni di lavoro di un team specializzato nello sviluppo di soluzioni Internet of Things (IoT) in ambito industriale. In particolare progetti che permettano alle aziende di controllare e gestire i loro prodotti via internet.
Abbiamo sviluppato la piattaforma Iottly, per semplificare e accelerare la realizzazione di progetti IoT. La piattaforma è stata presentata e premiata a PyCon Sette ad Aprile 2016. Il progetto è open source, su github: https://github.com/iottly
Il progetto per proporre Iottly sul mercato come servizio cloud è stato selezionato da TIM per l’edizione 2016 di TIM #WCap e a fine Settembre abbiamo iniziato il programma di accelerazione.

Ci attendono mesi entusiasmanti per il completamento di alcune funzioni della piattaforma e il suo lancio online, ed è arrivato il momento di avere nuovi compagni di viaggio in questa nostra avventura.

Chi cerchiamo?
Una persona con disponibilità immediata, appassionata, aperta e collaborativa, amante del codice ben scritto e del software open-source.
Il ruolo da ricoprire è di Backend Developer in Python.
L’ambiente di sviluppo è Linux / Docker / Git. Lo stack di produzione è Nginx / Docker / AWS.

Nice to have:
Laurea in area tecnico/scientifica.
Esperienza di sviluppo di RESTful APIs su MongoDB e di asynchronous web development (Tornado).
Una buona padronanza della lingua inglese, parlata e scritta.
Nota: Se non sei laureato o hai esperienza in altri linguaggi / tecnologie non esitare a contattarci: per noi la capacità e disponibilità ad imparare (in fretta …) sono importanti quanto le competenze acquisite.
L’esperienza in progetti (anche amatoriali) con Arduino / Raspberry Pi / etc etc è un punto a favore!

Inviaci il tuo CV e qualunque cosa (scritto/audio/video) possa servire a presentarti e farci immaginare chi sei a: jobs AT tomorrowdata.io

Hiring process:
1. Screening CV
2. Primo contatto e code test su skype
3. Intervista attitudinale e tecnica (in inglese) on-site
4. Sessione di lavoro retribuito di due giorni presso la nostra sede, in cui ti verrà assegnato un task ridotto ma vero, fornendo strumenti e supporto per eseguirlo.
5. Feedback e esito finale.

Sede di lavoro: Torino, in coworking e ambiente internazionale
Possibilità fino ad Aprile 2017 di operare a Bologna (presso il TIM #WCap Accelerator)
Possibilità, previo primo periodo di conoscenza, di eseguire parte del lavoro da remoto

Cosa offriamo?
Contratto di Apprendistato 24 mesi, CCLN Metalmeccanici
RAL (di ingresso): 20K-25K€/anno in funzione del profilo e del know how dimostrato
Almeno il 15% dell’orario destinato alla formazione o sperimentare nuove tecnologie
Possibilità di orari di lavoro flessibili
Prospettiva di accedere ad un piano di stock options / bonus % sulle revenue dell’azienda
Budget per la partecipazione a conferenze/eventi per sviluppatori
Assicurazione sanitaria aziendale

Sei interessato ma lavori come Freelance? Entriamo in contatto.

Open multiple terminals at predefined positions, with different histories, from a Gnome icon

I was working on a project where I needed to open every time the same four terminals at different paths and I wanted to have command histories saved separately for each bash.
I ended up with this solution some times ago on Ubuntu 14.04. Now, before moving to 16.04, I’d like to have the procedure saved for later reference. So here you are! As the title suggest, this post is about:

  • Opening multiple terminals at predefined monitor positions
  • with different bash histories
  • from a Gnome desktop icon

The procedure relies on gnome-terminal. I use it on Ubuntu with Gnome. As far as I know Unity uses gnome-terminal as well, so the same should apply.

Setup

Each bash will have a different working directory.
We are going to use working dirs as ‘unique identifiers’ of each bash. (This could be improved using some env var with a uuid to identify each bash).
Throughout the post:

  • project directory: MyProject
  • workdir of bash X: MyProject/dirX, with X from 1 to 4

Of course each dir name can be customized.

Now, prepare the directories (the example assumes MyProject in the home dir, but it can be anywhere):

cd ~ && mkdir MyProject && mkdir MyProject/dir1 && mkdir MyProject/dir2 && mkdir MyProject/dir3 && mkdir MyProject/dir4  && cd MyProject/

Opening multiple terminals at predefined monitor positions

For this task We use the gnome-terminal option to save terminal configurations:

  • open 4 terminals (be sure you don’t have any other terminal opened)
  • in each of them
    cd MyProject/dirX
  • drag and resize each terminal at your preferred position/size
  • in one of the terminal save the configuration for ALL of them (this include workdir, position and size):
    gnome-terminal --save-config=../myproject-term-conf

multiple-bashes-with-different-histories

To open the saved configuration:

  • close all the terminals
  • open a new terminal and create a shell script:
    nano MyProject/open-terms.sh
  • paste this command into the script and save/exit:
    cd $HOME/MyProject
    gnome-terminal --load-config=myproject-term-conf
    
  • give execute permission:
    chmod +x MyProject/open-terms.sh
  • test it:
    MyProject/open-terms.sh

    – you should see the four terminals opening at correct positions with the desired working dirs.

Different bash histories

For this task we are going to add a snippet at the end of .bashrc:

  • edit .bashrc:
    cd ~ && nano .bashrc
  • add this snippet at the end of the file:
    TERMLIST="MyProject.dir1 MyProject.dir2 MyProject.dir3 MyProject.dir4"
    
    CURTERM=$(basename ${PWD%$(basename $PWD)}).$(basename $PWD)
    
    if [[ $TERMLIST =~ $CURTERM ]]
    then
        [[ -d ~/.history ]] || mkdir --mode=0700 ~/.history
        [[ -d ~/.history ]] && chmod 0700 ~/.history
        HISTFILE=~/.history/history.$CURTERM
        # set HISTFILESIZE to a large value
        HISTFILESIZE=4096
        HISTSIZE=4096
        ls -la
    fi
    

What the snippet does:

  • $TERMLIST contains the list of “terminals” for which you want to separately save histories
  • $CURTERM identify the currently opened terminal. Each terminal is identified as listed in $TERMLIST – slashes are substituted with dots because $CURTERM is used as the file name for the current history. Note that $PWD corresponds with the WORKDIR configured in myproject-term-conf
  • a .history directory is created in your home if it doesn’t exist
  • the bash env variable HISTFILE is set with the customized value for the current terminal
  • I also like to have a large history and WORKDIR content listed when the terminal opens

Test what we have done up to now:

  • Close any terminal
  • Open a new one and
    MyProject/open-terms.sh
  • The four terminals should open in correct positions
  • Now type a different command in each terminal, for example:
    echo X

    with X from 1 to 4

  • Now close all the terminals and open a new one, typing:
    ls .history/
  • You should see four history files, one for each terminal (keep in mind the first time you won’t see the history files until you have closed the terminals)
  • Now again
    MyProject/open-terms.sh
  • Try searching the previous echo commands in different histories!

Setup the Gnome desktop icon

  • Create Gnome desktop launcher:
    nano ~/.local/share/applications/open-terms.desktop
  • Paste the following (changing what needed)
    [Desktop Entry]
    Type=Application
    Terminal=false
    Exec=[full path to MyProject dir; don't use ~ or $HOME]/MyProject/open-terms.sh
    Name=Multi Terminals
    Comment=Multi Terminals Opener
    Icon=[your favorite icon here]
    
  • From now when searching Gnome for the Application “Multi Terminal”, a launcher should appear with your new icon
  • Right click on it and “add to Favorites” to add it to Gnome side bar.

SD and micro-SD management with linux dd

If you play with IoT, sooner or later, you’ll need to flash, backup and restore SD or micro-SD.

Linux offers the dd command to deal with binary dumps of devices:
https://en.wikipedia.org/wiki/Dd_(Unix)
http://manpages.ubuntu.com/manpages/lucid/man1/dd.1.html

The full backup process results in:

  • insert the SD (of course …)
  • find the mount point with dmesg, let’s say it is /dev/sdX
  • unmount the SD mount points:
    umount /dev/sdX1
    umount /dev/sdX2
    umount /dev/sdX...
  • dump the SD content to file:
    sudo dd bs=4M if=/dev/sdX of=[dump file name].img
    pay attention to of parameter: if you wrongly set it to some /dev/sd[your hard drive] you’ll wipe the content of your disk!
    bs is the size of blocks to be read and written one at a time, in bytes

The full flash (or restore) process goes like:

  • insert the SD (of course …)
  • find the mount point with dmesg, let’s say it is /dev/sdX
  • unmount the SD mount points:
    umount /dev/sdX1
    umount /dev/sdX2
    umount /dev/sdX...
  • dump the SD content to file:
    sudo dd bs=4M if=[image file name].img of=/dev/sdX
    pay attention to of parameter: if you wrongly set it to some /dev/sd[your hard drive] you’ll wipe the content of your disk!
    bs is the size of blocks to be read and written one at a time, in bytes

Now, consider the following case:

  • SD size = 16GB
  • image size = 8GB
  • you can flash the 8GB image onto the 16GB SD, of course all the previous data will be wiped out (not the ones in the second half of SD, but chances are that you won’t be able to access them anyway)
  • When you backup the 16GB SD with the previous process … your backup image is 16GB, as the SD physical size, not as the image you flashed on it.
  • if you want the image back to 8GB (maybe you want to flash it onto another 8GB SD) you can use the count parameter of dd command:
    count is expressed in number of blocks as they are defined in the bs parameter
    so you would say, if bs=4M, count = 8*1024*1024*1024/(4*1024*1024) = 2048 … NO!!
    because 8GB is not 8*1024*1024*1024, in fact 8G (without B) == 8*1024*1024*1024,
    while 8GB == 7948206080 bytes
    and so the correct count setting is count = 7948206080/(4*1024*1024) = 1895

Hope you can find it helpful!

Un progetto a supporto della IoT Openness

Internet in pochi anni ha cambiato radicalmente il modo di vivere e di lavorare delle persone e delle aziende, mettendo inizialmente in collegamento tra loro i computer, e successivamente permettendo l’incontro globale tra e con le persone (accessibilità delle informazioni, social networks, servizi on line, etc).
Ora è il turno della connessione tra e con le infinite “cose” o per meglio dire “oggetti” che ci circondano e con cui interagiamo nella vita quotidiana. Questo cambiamento, chiamato IoT acronimo di “Internet of Things” (o “Internet delle Cose”), secondo l’opinione di molti esperti, si preannuncia ancora più dirompente.
Possiamo affermare che “IoT” è permettere alle persone e alle aziende di comunicare, controllare, gestire, utilizzare oggetti in remoto quando questo sia veramente utile e profittevole, creativo o semplicemente divertente.
La realizzazione di progetti IoT avviene utilizzando apposite piattaforme, di cui stiamo assistendo al fiorire di una grande quantità di proposte, alcune delle quali promosse dai grandi player di Internet come Google, Facebook, Oracle e Cisco: sistemi chiusi o proprietari, sistemi parziali o industriali. Tutti sistemi interamente gestiti da terzi o per i quali occorrono competenze iperspecialistiche per essere utilizzati.

In questo contesto, se l’Internet delle Cose permetterà al nostro frigo di essere connesso, a nostro avviso questo dovrà servire a poterlo aggiornare via internet per migliorarne l’efficienza energetica o per ripararlo rapidamente, prima che per avvertirci della mancanza del latte con una notifica sponsorizzata da un supermercato.
Dato il carattere dirompente di questa tecnologia, è indispensabile lavorare fin da subito per renderla accessibile alla più vasta platea di persone possibili, con strumenti caratterizzati da interoperabilità, fruibilità, etica e ecologia.

Questo impegno collettivo noi lo definiamo “IoT Openness”.

Il progetto IOTTLY è nato con l’intento di contribuire alla realizzazione della IoT Openness, con due passi significativi:
* Creando una piattaforma strutturata come una distribuzione software Open Source (Distro) che supporti la creazione e lo sviluppo di progetti IoT, rendendo più semplice connettere, gestire e programmare via Internet schede elettroniche come Arduino, Raspberry Pi, Udoo.
* Promuovendo e sostenendo una comunità che collabori sia all’ulteriore sviluppo della distro, sia con la condivisione di progetti IoT di prototipazione industriale o di creatività digitale.

Il carattere completamente Open Source di IOTTLY consentirà di affrontare le principali problematiche che stanno emergendo nello scenario IoT: l’interoperabilità, la sicurezza e la privacy. Infatti, per raggiungere una reale interoperabilità è necessario che ogni mattone di questa costruzione possa essere condiviso da produttori e programmatori, per poterli applicare alle soluzioni, piattaforme o dispositivi più differenti. A sua volta, una diffusione così ampia del codice sorgente aumenterà la sicurezza, rendendo possibile un processo di test incrociati, effettuati da soggetti indipendenti, in contesti applicativi potenzialmente molto diversi. Inoltre, rispetto alla domanda di privacy, la pubblicazione del codice che gestisce i dati potrà costituire una risposta più incisiva, che non limitarsi a chiedere all’utente di accettare un regolamento formale.

IOTTLY vuole permettere a professionisti, educatori e maker di realizzare progetti di Internet of Things nello stesso modo in cui le distribuzioni come Ubuntu hanno reso più semplice l’utilizzo di Linux per milioni di persone. Utilizzando una distribuzione, sia gli esperti, sia gli utenti non tecnici potranno concentrarsi sul cuore funzionale o creativo dei loro progetti IoT, affidando a IOTTLY gli aspetti di integrazione e ottimizzazione degli strumenti open esistenti e dei nuovi pacchetti specifici.

Arrivare a realizzare progetti IoT complessi con pochi click è un percorso che richiede una ricca esperienza delle esigenze dell’utente e competenze specifiche sui delicati aspetti della comunicazione tra gli oggetti. Insieme è anche indispensabile una vasta comunità di tecnici e Maker che sostenga e verifichi il progetto dal lato dello sviluppo, e ne promuova le sue applicazioni nel mondo creativo del fai da te tecnologico. Il moltiplicarsi di realizzazioni concretamente utilizzabili nella vita quotidiana potrà essere il fattore determinante nel diffondere la percezione di questa tecnologia nel grande pubblico.

L’idea del progetto IOTTLY è maturata nell’ambito del lavoro che il team sta portando avanti in TomorrowData (www.tomorrowdata.io), una nascente start-up che realizza soluzioni verticali di infrastrutture IoT e applicazioni predittive di Machine Learning alla portata delle PMI.

La presentazione del progetto è avvenuta con il lancio di una campagna su Kickstarter (http://kck.st/1Pze4IG) che si concluderà il 4 Ottobre, ma che è intenzione dei promotori portare avanti indipendentemente dall’esito della raccolta.
Maggiori informazioni tecniche su questo progetto si possono trovare nella pagina della campagna e sul sito www.iottly.org.

Stefano Terna, Daniele Grieco

A project to support IoT Openness

As we all know, the Internet changed everything by connecting computers at first, and then by connecting people, thus affecting the way we live and how we do business. Now the time has come to connect with the infinite number of “things” that make up our daily lives. And this change is going to impact our world in a much more dramatic way.
We can say, “IoT” is all about enabling individuals and businesses companies to control, manage, and communicate with remote objects in a creative and productive way, whether it be for profit or just for fun.
Right now “IoT Platform” is a label associated with all kinds of systems, some of which have been sponsored by big Internet players such as Google, Facebook, Oracle, and Cisco: from closed or proprietary systems, industrial systems, systems entirely operated by third parties, or systems that require a set of highly specialized technical skills.
If the Internet of Things is going to allow our fridge to be connected, then it should involve ways to remotely upgrade it, enhance its energy efficiency, and repair it. It should generate much more than a simple alert telling you when the milk is expired, accompanied by supermarket ads.

Because of the disruptive nature of this technology, it is essential that we work towards making it accessible to the largest possible number of people, with the help of tools that share the following qualities: interoperability, usability, ethical transparency and environmental safety.

We define this community commitment the “IoT Openness”.

The IOTTLY project is being developed with the aim of contributing to the IoT Openness, with two significant steps:
By creating an IoT platform designed as an Open Source Software Distribution (Distro) that supports the creation and development of Internet of Things projects, making it easy to connect, manage and program boards like Arduino, Raspberry Pi, Udoo via Internet.
By supporting a community that is going to collaborate to further develop this Distro, and share IOT projects which can be for professional prototyping or for DIY.

IOTTLY will be fully Open Source, enabling itself to address the main issues arising in the IoT scenario: interoperability, security and privacy. A true interoperability can be achieved only if the building blocks can be shared by producers and developers among the different solutions, platforms and devices. In turn, such a wide spreading of the same code base will increase security, by enabling cross testing processes, performed by multiple independent parties in different application contexts. Moreover publishing the code that handles the data will result in a much stronger answer to the privacy demand than just asking the user to accept formal policies.

IOTTLY will enable professionals, educators and makers to implement IoT projects in the same way that distributions like Ubuntu have made it easy for millions of people to use Linux. With the value provided by a distribution approach, it will be easier for both technical experts and average users to focus on the core functional or creative aspects of their IoT projects, while entrusting IOTTLY with the integration and optimization aspects of existing open tools and new packages.

The realization of complex IoT projects through just a few clicks requires both a deep understanding of the user’s needs and also the kind of technical competence that enables objects to communicate efficiently with each other and with the end user. Therefore, a wide base of technicians and makers must have the opportunity to collaborate, support and test the project during the development phase. The same community will then be able to promote new applications following the established practices of the world of digital creations. The future of this technology will depend on a growing number of custom real-life applications, shared among do-it-yourselfers and the public in general.

The founders aim is to establish a seamless educational and professional community around IOTTLY that would grow according to the functional challenges posed by IoT technologies.

More details about this fascinating project, as well as additional technical information, can be found on the Kickstarter campaign’s page http://kck.st/1Pze4IG.

IoT and TimeZones

Suppose you have to deal with “legacy” things in the IOT (say ioLt …).
Most of the time these legacy things don’t have any kind of timezone management: they just store time in some timezone agnostic form, like [year, month, day, hour, minutes, seconds].
Moreover they don’t even have any kind of time sync with external sources (say NPT or whatever).

So:
1. you are required to syncronize time from your server to your things
2. you are required to manage timezones on behalf of your legacy things

Syncronize time from server to things
You decide the server has the right time and just want to send it to the things.
But … what timezone you choose to send?
And … what is the timezone of your server?
Are the all the things in the same timezone of the server?

Manage timezones on behalf of your legacy things
We can manage timezones in two different ways:
1. keep the timezone things-side and send to them the “localized” time
2. keep the timezone server-side and send to the things the UTC time
Which of the two depends mainly on the following: should your things show the time on some local display or not? If yes the thing should know the “localized” time, since it will have to make sense to the user who is expecting it in her timezone.

Hence, if the user contraints apply you have to follow method 1, otherwise method 2.

Of course in the absence of any other constraint, it turns out that method 2 is preferable, since time management will follow standard patterns of keeping centralized times in UTC.

Python and .Net API to generate localized datetime with respect to a given timezone
Ok, you have decided to follow method 1, and now you have to prepare server “current date”, localize it to the thing timezone and send it.

Here how to do it, supposing your timezone is ‘it’ or CET or ‘Europe/Rome’

 

Python

datetime.datetime.now(pytz.country_timezones['it'][0])

.Net

TimeZoneInfo.ConvertTimeFromUtc (DateTime.UtcNow, TimeZoneInfo.FindSystemTimeZoneById ("Europe/Rome"))

The main difference is that Pyhton datetime object is timezone agnostic by default, while .Net object cannot exist without a timezone. Hence with .Net we must start with the UTC time.

(credits:
https://flic.kr/p/4GSMuN
http://freestock.ca/skies_clouds_g61-angel_cloud__hdr_p2162.html)