Ecole des mines de Douai – (2012/2014)

 

Ecole des mines de Douai is my very first experience far from home, and, like every good experience far from home, it becomes a new home.

The amount of achievements i meet in this place is amazing, and the achievements i am going to meet because of time here is even more amazing.

My job in this place was a fixed length contract as Ingénieur de recherche, or research engineer.

The project i was in charge is called RoboShop. It is basically a robot guide for indoor scenarios.  Our specific scenario: shopping. The main requirement then was a differential drive robot moving inside a crowded shopping, leading costumers to do their shops, looking for best paths, avoiding to collide and of course, exposing a responsive and user friendly interface.

Since the project had several money contributors, there where also other requirements, by example, there should be also as outline a framework for implementing ROS (Robot Operative System)  nodes in Pharo smalltalk, well documented, and oriented to be used to learn robotics.

And, as if that is not enough, we had to keep publishing the evolution of the work in the team blog.

There was also, like in all engineering jobs, deadlines.

There were an amazing amount of challenges in the way.  Even when i had already some  experience working controlling hardware, a whole robot was something completely new. In addition to that, knowing that almost the software i needed to integrate, and to develop on top still being state of the art, running in an organic distributed architecture based on subscriber/publisher architectural pattern, without real testing methods, working with four languages (pharo smalltalk, c++, python and java) for the robot side, developing or enhancing drivers, learning some advanced maths,  and merging all my new knowledge in a high level application framework; And with two (pharo, javascript, html5/css are not languages) others for a GUI that has real physical impact.

The result of this was:

PhaROS ( Pharo framework for robotics in ROS), and it related Jenkins site.

PhaROS Deployer ( A whole 3rd application that automatise the infrastructure work related with ROS, as generating makefiles, deploying types, generating scripts, etc), that you can checkout here and look for documentation here

MiddlewareDeployer – A Whole framework for deploying Pharo/Squeak based projects into any kind of middleware, on which is based the PhaROSDeployer tool and that you can checkout here

TaskIT  Announced here, An enterprise-ready framework for serious multiprocessing in Pharo smalltalk, with it documentation, which is part of the Pharo for enterprise book.

XSens Bus ROSCPP driver – XSens is an accelerometer  widely known. Sadly all the implementations i found did not support Bus XSens, which is a solution for composing accelerometers (to be able to measure, by example, an arm, you need at least 3 accelerometers)

Arduino sensor/actuator controllers  – Arduino has a set of sensors and actuators that come with the beginner kit. We built an driver function for each of this sensor/actuator that you can use as a library in your Arduino code and connect with ROS. For each of this Arduino based controllers, that connect to ROS trough ROSSerial package  i built a PhaROS Nodelet ( kind of reusable object interface )  that give you full and coherent control of each of  this components.

StarGazer Linux driver – StarGazer is device that provides a highly accurate way to locate something in an indoor scenario.

The RoboShop project, which source still private, so i cannot point it here.

Finally, in what is to documentation, the team is making editorial work in order to publish the deployment design as a technical report and the PhaROS by example text as a book.  Sadly, meanwhile that is not done, the content of both is confidential.

What is already published and i can show to you is the team blog, some videos related with the PhaROS / RoboShop project


 

The video and slides of FOSDEM 2014, where i presented PhaROS.

Presentation Video (Courtesy of FOSDEM organisers)
http://mirror.as35701.net/video.fosdem.org/2014/K4401/Saturday/PhaROS.webm
And finally, the slides from the  project presentation in ESUG 2013

 

Standard

Buscouniversidad.com (2011)

busco_universidad

The same way i posted one of my best (if it’s not the best) experiences in my life, i think is fair to post now my worst experience. This one was in Buscouniversidad.com.ar

This site is a directory for looking for universities that works in Argentina. Punctually in Buenos Aires.

My experience here it did not last more than 3 months and pushed me back to my previous job. Starting with a cool environment, but morphed into a really ugly place to be in terms of weeks, with bigger challenge of do not die of boringness.

Based on PHP+Zend framework for the application side and Mysql+sphinx for the indexing and storing data, for a site exposed to high stress, the project was kind of interesting,  and finally start to face the development of a whole new site with support for internationalisation (nothing funny, but somehow challenging).

And that is  what was our job: Care about performance and availability of the running site, design a whole new one based on more robust and reliable technology.

You can see the results of our work in the site since it did not change much since i left.

Also we even had the nice challenge of email analysing that i did in python. I will see if i can find that code and release it as MIT. Is not that much really, but it was simple. It was about analysing email contents from the email server, fetching each email-file and checking content based on regular expressions for knowing to what ‘campaign’ was answer each email, if the email was duplicated, if the email had insulting content, etc.

Sadly, or maybe not (since the challenges were not challenge), the relation with our bosses became bad. They wanted us to make office hours, from 9 to 18 exactly, and we had moved from one office to other one, having 30 minutes more of travel in my case to arrive to the place.

It sounds incredible that 30′ can make a social relation ashes… unless you think about how many marriages had being ended bad because of things like the toilet lid.

And it is exactly what it happened. Things became really human, hysterical and unprofessional, until the point of having a discussion where my partner/boss and me where accused of wanting to stole one of the magnificent ideas of our magnificent boss.

After that experience we just decided to quit the job, and look for something else.

I think the best thing of this job was the pizza that we used to buy in the closest store, even when it used to arrive  not-that-hot.

 

Buscouniversidad was my second time using Zend Framework. I have a really deep issue with frameworks in PHP,  (that is why i started my own full stack framework, looking to adopt more simple and sophisticated ways of  define the business domain object that i already learned in other technologies for that time, and adapt them to PHP ), and my first relation with sphinx search.

The rest of the architecture picture was Debian linux, apache server one for each static and dynamic content, and MySql for the dynamic content.

If you see the site it looks a site without much work. And it has not much work for the user side: a contact form

Contact form

related with each of the careers you can find with the search form

search

A regular directory.

But this directory needs to be maintained by human beings (i have no screenshot about the admin site, but it has a quite responsive design based on Javascript with JQuery and JQueryUI) and it is also accessed by literally thousands of users daily. What means also other kind of work i cannot show, what is performance, accomplished by generation of static content with already done queries, (that is also related with a SEO strategy).

 

 

 

 

Standard

Fanwards (2011/2012)

cropped-fanwardsn

Fanwards is one of my favourite experiences not just because of the people (that is always the most important part of any job), but because of the amount of things i leaned in several aspects.

Fanwards is an startup. Like in any startup, there is a lot of work to do, and not much people to do it. Even when there is time for nice TDD, and we ruled all the development by the most rigours KanBan strategy,  there was not CI, or CD, just because we did not had even the time for installing and maintaining the required software. (Jenkins server, Puppet server, etc).

The basic idea in Fanwards is to gamify and bring to social networks the loyal plans. You do something for a brand, you earn points, you exchange your points by benefits.

The basic requirements were, great user experience, game rule system applied to social network analysis, social network analysis it self,

At that time (2011), after 9 years working in software, i had already my own way to do the things, and i was not happy, but not really frustrated. I already lead some projects to good ports, i had confidence. I was of the school of ‘generated html/javascript’ for what is to web applications. Used to use scaffolders, sometimes writing them by my self (back in the 2007) to be able to eliminate all that repeated code. Moving to groovy/grails when the technology allowed us to move (you know, stability and reliability). Writing java, php and python code for backend, depending on the projects, using languages like smalltalk and haskell just when during the night, as kind of two lives person, but, sadly, just shamed about the one at day light.

In Fanwards i started to work with a known of mine that became a great friend of mine during that time. The first and only person that made me work closer to my full capability. A real smart person (one of that, that a lot of people think they are, but they are not).

 

Thanks what ever you want to believe in, some of our requirements were:

  1. The application cannot reload at all
  2. The data source endpoints should be reusable by the mobile applications

And since we were all people that believe in good designs (even when we had done awful things in the name of the deadlines), we end up having the need of a ‘heavy client’ application. Something that i was used to do in flex, but, somehow, i never even thought in reproduce in javascript.

A whole reactive model that represents the web client world in the browser side (Then the mobile applications should have other kind of model, related with the needs). Reactive means with real events, and model means objects, for real.

That is how, after some months reinventing the wheel, (just because we, or maybe just me, thought that was something different, without solutions available), we decide to take away my ajax wires (based on an adhoc functional library i did by my self) for backbone, and later, we changed also our event management system by the backbone.js one. And for what is functional approach, we also take away my implementation going for Underscore.js

I need to say a lot of good things about backbone, mainly because it gave me back something javascript and html had stole me long time ago: faith in the client development.

In between this and a great graphic designer i had the best experience in my life about.

During this time, as well, we had time also in backend development. And for me was full of new things, first, the cloud. Google app engine,big table, objectify. A lot of frameworks and technologies that i was not yet used to. Using java without hibernate, a strange mix of spring mvc and the plain and old pal spring, for injections.

But, since that was not enough to make me fear, we choose to develop (after one year of existing java code), all the new things in Scala.

The Scala experience, from the point of view of a java programer, maybe overrated, after all, you can do almost the things in the same structured wat. But, for a repressed functional programmer as me, that looks for fun in the monadic implementation of the collections, Scala was, and is, a window open to a whole brave new world. A world where academics meet industry, a world where i can talk about curryfing and partial application without being watched as a freak. And, as a Smalltalk programmer, a place where i can be free to have more real polymorphism.

I need to say that what i did in Scala for social network analysis hardly can be done at the same time in java. And, even when i cannot be proud of the name i gave (you know, i changed metaphor meanings several times, and in the end there was not name refactor), i am proud about the general design, based in something similar to map and reduce, in a functional way.

 

Our outline in this work was really nice.  You just need to go to one of the pages (embedded in Facebook – here -) or go to the institutional page – here – to see what i talked about the design. Not just the beauty of the system but also how everything there is almost alive, how every action implies something in the visual dynamic.

 

Is sad that i do not have any legible code example to show how easy is the wiring of events and CRUD with backbone.js, the only thing i can suggest you if you want to know is to read the minimised and merged version of our javascript files.

Similar for the Scala server part, i have not permissions nor backups anymore, since i quit because of moving to France.

 

All this amazing experiences, mixed with a great scrum based organisation and with the fact of sharing my work time with one of the smartest persons i know, made

logo-color

one of my most exciting and nice experiences i ever had in my current 11 years of experience in the industry.

The outline of our work, even today keep being outstanding  (Even when the business did not work, as you can infer from the lack of movement).

As any other gamified application, Fanwards has implemented game mechanics and rules.

Game mechanics

That means, to rewards somehow the player (user) because what he does. To make his achievements something epic, and make him be part of something bigger than him self, and, most important, that that thing bigger than him, needs him.

All of we have an hero inside our selves, trying to do what is good, in exchange of the glory.  We all want our selves to be somehow immortals.

That first screenshot it has involved not just a beautiful, responsive and single-page design. It has much more things. It has a software design. Behind that fancy curtains models, objects: the badges, the brand (melee island in this case) our friends with their own punctuation. All of that are objects with the proper relations. And the most important thing is that they have the representation needed by a graphical user interface, obtained and maintained  by the RESTFul based endpoints,  transformed to JSON encoded objects by Scala functional based transformations running at Google App Engine accessing to BigTable structure through Objectify framework.

Missions based on social behaviour

As well, like this previous image shows, we have Missions (in spanish Misiones ). Each of the pills there have a social activity meaning:

Me gusta – I like it. Like a publication of Melee island and you will get points and passion!

Yo opino que… – I think that.. – Write a comment in Melee Island publication, and you will get points and passion!

Miren! – Look!! – Share with your friends a Melee Island publication in order to get, again, points and passion.

Is easy to understand that this have a big impact in the design and architecture of our application. We are talking about monitoring what the people does in relation with a brand’s Facebook page.  That mean social network analysis. And yes, we had processes running each 5 minutes crawling through the social activity of our users. The idea was to not be invasive with the users, but make them adopt a behaviour.

And this is really the last face of the missions, or the actions related with points. We had other iterations that involved analysing the timeline of each user in Facebook and Twitter, every 5 minutes, trying to understand if the comments were positive or negative about the brand. All this things were taken out because the brands were not cool with the idea that any user can make a lot of points quite fast, even with our action-cool-down strategy. So, we decided to keep just the things that add value to the broadcasting channels of the brands.

In order to achieve all this social network analysis we used different technologies, from backend to front end based, all what is needed to do not annoy the user with too much ask for permissions. That lead us to use Facebook Javascript SDK, Twitter4J, and RestFB.

If you know about GAE architecture, you will know that is strictly web, and that there is no ‘process’ that is not a request, and that there is not request that do not gives a timeout after 60 seconds.

I just can say that i am proud of my work in the social network analysis and that it was the hell hard to make it fast enough, and to deal with that kind of problems.

 

Rewards

The brands didn’t wanted to let users to have too much points because points used to mean rewards. And that is why we had two kind of points for the user: points it self and passion.

The points are a currency inside Fanwards world. You cannot change them by money, but yes by brand offered prices.  Each price here is an object! Is an object that is inside a collection of prices of the brand!

All this great projection of a domain driven design is possible thanks to the frameworks we had rely on: Backbone.js, Underscore.js, Mustache for templating, JQuery to glue the things needed be glued, and our own set of functional-approach functions that where not provided by underscore.js (such as real curryfication).

All this is what i worked on Fanwards, but is not all what Fanwards was. Fanwards have also mobile applications: Android, iOS and Blackberry applications.

And of course a lot of Startup hard work

Standard