Trace: start


This is the Bertrand Florat's personal page. You will find here some links to articles or projects I'm involved in. All articles are dated with creation year and - when applicable - of the last modification date year.

Social medias

GithubGoogle+TwitterLinkedIn

Open Source Projects

[EN] Jajuk Project (Java Jukebox)

[EN] QDWizard project (Swing Wizard API)

Articles and conferences

[EN] (2013) How I manage my passwords

[EN] (2013) My Cloud, My Way (Article)

[FR] (2012-2014) Cours gestion de versions (Git et SVN) (Université de Nantes)

[EN] (2012) Keynux Epure S4 laptop review

[FR][EN] (2009) Conférence RMLL : "Développement Open Source : un retour des tranchées (Jajuk)" video

[FR][EN] (2009) Conférence RMLL : "Comment l'Open Source permettent de faire de meilleurs projets" video

[FR] (2008) Producing Open Source Software book translation

[FR] (2008) Conférence Solutions Linux "Augmenter la productivité JEE grâce à l’approche orientée modèles DSM"

[FR] (2001-2002) Tutorial Java

[FR] (2005) Les bugs mystiques

CV

[FR] Mon CV en ligne

Various subjects

[FR] (2014) Retours d’expérience de cyclotourisme familial

[FR] (2009) Le compostage en milieu urbain

[FR] (2007-2012) Voyager léger

Older subjects

[EN] AMI protocol open-source project (P2P protocol, no more supported)

[EN] (2005) Linux on VIA ME6000 and USB external disk real howto

[EN] (2001) Laptop Asus L8400K under Linux

[EN/FR] Technology blog

1 Post(s) for March 2015

The IT crowd, entropy killers 2015/03/02 22:23 Bertrand Florat

The IT crowd, entropy killers

http://www.channel4.com/programmes/the-it-crowd

I once asked myself “how to define our job in the most general sense of the term, we, computer scientists ?”.

Our fields are very diverse but according to me, the greatest common divisor is “entropy hunter” or “anti-chaos soldier”.

All we do have is geared toward the same goal : decrease the level of complexity of a system by modeling it and transforming a bunch of semi-subjective rule into a Turing machine program that can't execute the indecisive.

Everything we do, including documentations, workshops with the stakeholders, project aspects, and not only the programming activities should be about chasing doubt. Every word, every single line of code should kill ambiguity.

Take design activities : most of human thoughts are fuzzy. This is the reason why waterfall (traditional) project management processes where all designs are done in one go can't work : the humans need to see something to project themselves using it and go further in their understanding.

Business designs are subjective in many ways, for instance :

  • by describing missing cases (or less often, unexisting cases)
  • by words ambiguity. Here's a small anecdote : last week, I worked on a specification document written in French with the word : “soit” : “the file contains two kinds of data, soit data1 and data2”. This sentence could be understood in two opposite ways because the French word “soit” means “either/or” but also “i.e.”. Hence, this sentence could mean at the same time “the file contains data1 AND data2 kinds” or “the file contains data1 OR data2 types”. I encounter this kind of uncertainty several times a week.
  • by lacking of examples. The example are often much more demanding and objectionable. They require a better understanding of the system. Moreover, designing by the example (like in BDD) tend to be more complete because when you start to provide nominal examples, you are tempted to provide the corner case ones. (read Specifications by example by Gojko Adzic for more).

On the opposite, a program is deterministic. It is a more formal (and modeled thus reduced) version of a complex reality. The more a reality need cases and rules to be described entirely, the more the program is complex but it is still much simpler than the reality it describes.

The quality of all we do should IMO be measured in the light of the amount of complexity we put into our programs. The less complexity we used to model a system, the better a program is.

· 2015/03/02 22:23 · 2015/03/03 21:43 · Bertrand Florat · 0 Comments

Deployment scripts gain to be auto-updated

After few months of continuous deployment scripts writing for a pretty complex architecture (two JBoss instances, a mule ESB instance, one database to reset, a workflow server, each being restarted in the right order and running from different servers), I figured out a good practice in this field : scripts have to be auto-updated.

When dealing with highly distributed architectures, you need to install this kind of deployment script on every involved node and it becomes soon very cumbersome and error prone to maintain them on every server.

We now commit them into a VCS (Subversion in our case), it is the master location of the scripts. Then, we try :

  1. To checkout them before running when possible. For instance, we used a Jenkins job to launch our deployment process (written as a bash script). The job is parametrized to checkout the SVN repository for the script before running it from the Jenkins workspace. This is very convenient.
  2. When this is not possible, we try to make the script to auto-update (for ie, our bash script starts by checkouting itself from SVN, then runs). OK, we still run the n-1 version of the script as the OS has already loaded the script but we ensure that we'll use the up-to-date script the next time we run it. We also provide some “bootstrap” script to update the deployment scripts manually from SVN.

Retours Eclipse DemoCamp 2015 Nantes

J'ai eu le plaisir de me rendre à l'Eclipse DemoCamp Nantes jeudi dernier au Hub Creatic (il est difficile à trouver car pas encore indiqué, c'est le bâtiment jaune vif à coté de l'école Polytech Nantes. C'était la première fois que je m'y rendait et je dois dire que j'ai été impressionné, dommage qu'il ne soit pas en centre ville).

Nous avons eu un panorama extrêmement éclectique mais passionnant du monde Eclipse en 2015, de l'internet des objets (IOT) à l'usine logicielle de grands groupes en passant par l’informatique pour les enfants. Ceci montre, si besoin était, la force de traction du monde Eclipse en tant qu'IDE bien sûr mais surtout en tant que plate forme.

Gaël Blondelle de la fondation Eclipse

l'a très bien expliqué : la force d'Eclipse est avant tout sa capacité fédératrice : la version Luna a été réalisée par 400 développeurs issus de 40 sociétés différentes.

La notion de release train (livraison simultanée et annuelle de tous les projets en juin) assure une stabilité et une intégration de qualité entre les centaines de plugins.

Une notion émergente concerne également les Working groups regroupant des travaux par thème comme :

  • LocationTech orienté SIG . Un des projets les plus innovants de ce groupe est Mobile Map générant des cartes directement calculées sur le smartphone.
  • IOT fédérant les projets autour de l'internet des objets. Deux projets intéressants : Eclipse Smart Home pour la domotique et Eclipse SCADA proposant des librairies et outils SCADA (Supervisory Control and Data Acquisition) servant au monitoring de nombreux hardwares.
  • Eclipse Science pour des projets de visualisation ou de traitements scientifiques.
  • PolarSys regroupe des projets pilotés par Thales, le CEA, Airbus, Ericson… pour les projets de modélisation autour de l'embarqué (Papyrus SysML, Capella…).
Laurent Broudoux et Yann Guillerm, architectes au MMA

nous ont ensuite exposé l'historique de déploiement et leur stratégie multi-versions d'Eclipse. Leur DSI regroupe 800 personnes dont 150 utilisateurs d'Eclipse travaillant sur des projets aussi variés que du legacy (Cobol, Flex, Java historique) à des projets plus novateurs (mobile, applications Web à base de Grails…).

En résumé, la construction d'une nouvelle version de l'atelier (unique jusqu'en 2012) prenait jusqu'à 50JH en partant d'Eclipse de base et en intégrant/testant tous les plugins nécessaires. La nouvelle stratégie se décline en deux axes :

  1. Construire un atelier modulaire en trois couches : 1) une base (seed) : distribution Eclipse pré-packagée ; 2) des plugins communautaires (Confluence, Mylyn, Subclipse…) 3) des plugins maison principalement autour des outils de groupware Confuence.
  2. Différentier les ateliers suivants les besoins (6 variantes, 4 familles) :
  • une usine legacy à base de Galileo
  • une usine « High Tech » pour les « usages » (CMS, mobile) basée sur la distribution Grails GGTS (et bientôt intégrant les technologies Android ADT) ;
  • une usine « cœur de métier » basée sur Juno (je n'ai pas noté la distribution Eclipse utilisée comme seed) pour les applications JEE (fournit les briques techniques de persistance SQL et NoSql, la modélisation UML, les outils MDD (Acceleo, ATD…), M2E pour l'intégration Maven… ;
  • une usine de modélisation d'architecture pour gérer le patrimoine, les études d'impacts, la déclinaison des scénarios projets… Cette modélisation d'entreprise se base sur un Metamodèle dérivé de TOGAF. Cet atelier se base sur la seed SmartEA (d'OBEO).

La stack technologique des usines s’appuie notamment sur Mylyn (gestion des taches), Confluence (wiki d'entrerise), Maven, Chef pour le Configuration Management, SVN comme VCS.

Stéphane Bégaudeau d'OBEO

nous a ensuite présenté les outils de développement et d'intégration de l'écosystème NodeJS. Le scaffolding par archétypes se fait via l'outil Yeoman . Le package manager des librairies JS est npm. On dispose également des librairies/frameworks angular.js, ember.js et backbone.js. Bower est un gestionnaire de packet pour librairies JS. Le build se fait soit avec Grunt (modèle configuration over code) ou (préféré), le plus récent Gulp (code over configuration) plus simple. Min.js assure des fonctions de minification du code. Pour les tests, on dispose de Jasmine (BDD), Mocha, Qunit. PhantomJS et CasperJS permettent des tests headless. Istanbul assure l'analyse de la couverture de code. JSHint effectue les tests de style. Karma teste l'ubiquité des pages (responsive design). Pour finir, Stéphane nous présente Eclipse Orion, l'IDE Eclipse Web basé sur NodeJS. Cet IDE assure entre autres la complétion du code, la coloration syntaxique, vient avec un très bon support de Git et peut être étendu par plugins.

Hugo Brunelière d'Atlanmod

nous a fait découvrir le programme de recherche ARTIST proposant des outils d'ingénierie des modèles et des méthodologies pour migrer une application traditionnelle en application cloud-friendly. Le programme de 10M€ est développé principalement par l'INRIA et ATOS (Spain). Le programme propose :

  • De la méthodologie via un handbook, un modèle de certification.
  • Des outils d'analyse de faisabilité métier et technique, de la rétro-ingénierie, des outils d'optimisation.

La modélisation est faite en UML stéréotypé sous Enterprise Architect principalement. Des DSL textuels à base de XText sont également utilisés ainsi que des DSL graphiques à base de SIRIUS. L'analyse M2T est faite via Modisco et la transformation de modèle M2M en ATL. Le reporting se base sur BIRT. La méthodologie est outillée par EPF (Eclipse Process Framework). Un modèle de maturité cloud-friendly a été développé : le modèle MAT (Maturity Assessment Tool).

Stévan Le Meur de Codenevy

nous a fait une démonstration de Eclipse CHE , une plate-forme SaaS pour les développeurs basée sur Orion et Docker. Un poste de développement peut être très facilement provisionné puis “déployé” en Web pur (c'est la notion de « Factory Codenevy »). Il est possible de sélectionner puis d’exécuter des containers Docker faisant tourner des SA Tomcat, Jboss ou autre en local ou à distance. Une nouvelle fonctionnalité d'intégration GitHub en avant première (clone puis pull request en quelques clics sans rien installer) a fini de nous bluffer.

Maxime Porhel d'OBEO

nous a présenté un environnement de programmation graphique pour les cartes Arduino et à destination des enfants. Ce DSL graphique très simple a bien sûr été développé en SIRIUS (la version Open Source d'OBEO Designer). Une démonstration très rigolote a prouvé le concept sur une carte Arduino AVR inclus dans un kit DFRobots. Ce sont mes enfants qui vont être contents :-)

Enfin,

Fred Rivard, fondateur de IS2T

nous a expliqué les enjeux économiques et technologiques du Java embarqué. 100Md de micro-contrôleurs de 1 à 15$ sont actuellement déployées au niveau mondial. 25 % tournent en environnements « balisés » : iOS, Android et Linux. Le reste est est extrêmement éclaté en centaines de technologies sur lesquelles on programme encore en assembleur. Le ticket de départ d'un projet se chiffre à 1M€ minimum et il faut sortir le produit en moins de six mois pour être rentable vis à vis de la concurrence. Le Big Data ne pourra se développer harmonieusement que si le Little data (les devices, l'IOT) qui l'alimente devient plus économique. IS2T vise à développer des JVM embarquées extrêmement rapides et légères en mémoire (rentable en terme de mémoire à partir de 100K de mémoire flash vis à vis de code classique). Toutes ces technologies sont regroupées autour de la plate-forme MicroEJ). IS2T développe également un « store » d'applications embarquées pour ce type de hardware. Fred nous a présenté de façon ludique de nombreux exemples d'utilisation comme cette montre connectée qui s'allume en 48ms alors qu'il faut 500ms pour soulever son bras pour lire l'heure : la montre peut donc être arrêtée le plus clair de son temps, son autonomie est en décuplée.

A noter quelques apartés en séance

sur Oomph, un nouvel installer pour les plugins Eclipse permettant également de centraliser le paramétrage des développeurs.

· 2015/02/09 21:55 · 2015/03/02 21:11 · Bertrand Florat · 0 Comments

Programming is craftsmanship and requires skills

Many managers think that programming is easy, it's just a bunch of for, if, else and switch clauses after all, isn't it ?

But coding is difficult because it is mainly about TAKING DECISIONS ALL THE TIME.

Driving is easy because you don't have to take decisions about the way to turn the steering wheel; walking is easy, you don't even have to think about it; Drilling a 10 mm hole into a wall is easy because the goal is clear and because you don't have many options to achieve it…

Software is difficult and is craftsmanship because there are always many ways to achieve the same task. Take the simplest example I can think about : an addition function : we want to add a and b to get c=a+b.

* Should I code this the object-oriented way ( a.add(b) ) or the procedural way ( add(a,b) ) ?

* How should I name this ? add() ? sum() ? How should I name the arguments ?

* How should I document the function ? is there some project conventions about it ?

* Should I return the sum or store it into the object itself ?

* Should I code this test first (TDD) ? write an UT afterwards or write no test at all ?

* Does my code scale well ? does it use a lot of memory ?

* Which visibility for this function ? private, public, package ?

* Should I handle exceptions (a is null for instance) or from the caller ?

* Should the arguments be immutable ?

* If I'm coding in object oriented, is it SOLID compliant ? what about inheritance ? …

* … tens of others questions any good coder should ask to himself

If all of this decisions could be taken by a machine, coders would not be required at all because we would just generate code (and we sometimes do it using MDD technologies, mainly for code skeletons with low added value).

We -coders- would then all be searching for a new job. But, AFAIK, this is not the case, we are still needed, still relevant. All companies still need costly software craftsmen !

Q.E.D. ;-)

I can't agree more with the manifesto for software craftsmanship.

· 2015/01/02 12:11 · 2015/01/02 12:11 · Bertrand Florat · 0 Comments

Undocumented PreparedStatement optimization

We just get a 20% response time gain on a 600+ lines query under Oracle. Our DBA noticed that queries were faster when launched from SQLDeveloper than from our JEE application using the JDBC Oracler 11g driver. We looked at the queries as they actually arrived to the Oracle engine and they where under the form : SELECT… WHERE col1 like ':myvar1' OR col2 LIKE ':myvar2' AND col3 IN (:item1,:myvar2,…) and not 'SELECT… WHERE col1 LIKE ':1' OR col2 LIKE ':2' AND col3 IN (:3,:4,…) like usual when using PreparedStatement the regular way.

Indeed, every PreparedStatement documentation I'm aware of, beginning with the one from Sun states that we have to use '?' to represent bind variables in queries. These '?' are replaced by ':1', ':2', '3' … by the JDBC driver. So the database has no way to now in our case that :2 and :4 have the same value. This information is lost.

We discovered that we can use PrepareStatement by providing queries with named bind variables instead of '?'. Of course, we still have to set the right value using the setXXX(int position,value) setters for every bind variable occurrence in the query. Then, queries arrive to Oracle like when using SQLDeveloper, with named bind variables.

OK but what's the deal with all this ?

I'm not sure but I think that this optimization may allow Oracle optimizer to be cleverer, especially for queries with redundant parts. It is especially good for queries with duplicated sub SELECT with IN condition containing all the same list of items. Maybe Oracle create on-the fly WITH clauses or similar optimizations in this case ?

Note that this optimization may only work with Oracle and is probably only useful for very large or redundant queries. I don't recommend it in most cases. AFAIK, neither Hibernate nor Spring-JDBC implements this optimization.

start.txt · Last modified: 2015/02/12 21:36 by bflorat