* Universidad Tecnológica Nacional - Facultad Regional Buenos Aires (Research and Professorship of Software Design)
An startup based in NYC that provides a service to manage all your cloud storage services (Drive, Dropbox, Box) in one spot.
In this project I was the Team Leader and also participated on definitions regarding architecture and infrastructure. The whole backend was designed to use micro-services and expose an API that was accessed by the single page app (built in Angular.js), some mobile apps and also desktop apps.
Skills involved: ASP.NET, Azure, AWS (EC2, S3, SQS, Dynamo DB), node.js, Mongo DB, MS SQL Server, Android, iOS, Ionic, Angular.js, Firebase, micro-services,
* Zauber: software consultancy service
I work in different projects for clients all over the world using different web (Java with Play! Framework, Ruby on Rails) and mobile (Android) technologies.
* Striiv - fitness tracker wristband
This fitness tracker application consisted on a mobile application that paired with a wristband tracker using bluetooth, built by a company based in Palo Alto. I was in charge of maintaining the Android version, which was already in production, and work on the re-skinning of the main screen.
This app consisted of two components: a web and a mobile app for tablets. Besides, the mobile app was splitted into three other sub-components. The main goal of this app was to help children from 3 to 9 years old learning portuguese at a couple of schools in Brazil, and provide feedback to teachers and parents. Despite the fact that the end client was a school in Brazil, the product was designed and managed by a company based in Palo Alto.
The first one was a game (Motogato) built using Libgdx framework. Upon some events from the game, it collected specific data that were persisted on Sqlite database. At the same time, there was an Android Service running in background that ran a Diagnosis open source engine (created by a university) that analysed the output of the game.
The second one was a Dashboard, built as a separate section of the same application and using the Android SDK. This Dashboard was only accessible to teachers and parents and was role-based in terms of features. If the Teacher was a Coordinator he could have access to a couple of screens to create, delete and modify some specific data. When the app started it displayed a fancy login for the children, who could choose their avatars by tapping on them. At the top right corner there was a button to access the Dashboard.
The third component was the Android service mentioned previously. It was in charge of synchronizing the data from the Sqlite database with a central server (we used Parse.com as a BaaS), and was executed every X minutes.
This application was by far one of the most amusing ones I had ever built. The team was formed 4 people and in the last 6 months I was assigned the role of Team Leader.
Last but not least, I used this spec to present a use case and a framework I built for that purpose at the AnDevCon Boston 2014.
* Digitaria Tagg - Pet Tracker
Tagg was the version 2.0 of an app that was already in the market, built by a company based in California, USA. Basically, the app connected to a server, retrieve data using a Rest API and displayed it using different graphs. The data came from the pets, which were previously added in the web app, and had a tracker collar that sent data to the server periodically.
Since the legacy code was difficult to maintain, we took the decision to rebuild the app.
Among the features that were implemented:
push notifications, to know whether the dog was not inside a specific range where the collar could connect to WiFi or start using 3G
see statistics about the dog’s health and monitor its activity
see where the dog was at the moment
read news about different exercises you could do with your pet
* Steelcase Volley Adapter
This app was part of a bigger product for Steelcase Inc., a company based in Michigan, USA. The main goal was to bundle it together with an Android stick that would be plugged into Smart TVs, given the fact that the app itself was a viewer of a Session linked to a web app.
The idea behind the product can be compared to what we know today as Chromecast: cast content, but with the slight difference that the content casted to this app was private and only the users that were invited to the Session were able to access it. The content being rendered was also related to a particular Session, which consisted on a Viewer (PDFs, images and office docs) and was accessible through a specific URL. All participants were able to see every document change live in real time, even it this meant a page up/down. In addition to this, a participant could highlight a specific section of the document and everyone would be able see it. This highlight was temporal and disappeared after 6 seconds.
All these features were mirrored to the Volley Adapter. It was identified with an ID code that could be used to include the Adapter in the Session.