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

Contact

contact

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

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 rendais 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/17 22:28 · 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 ?

* Is it thread-safe ?

* Should this function be injected within an utility class ?

* 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/03/17 22:31 · 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.

Retour sur l'Agile Tour 2014 Nantes

J'ai eu la chance d'assister à la journée Agile Tour 2014, version nantaise, à l'école des mines. Bien organisé, riche en rencontres et retours d’expériences, comme tous les ans…

Les world cafés

Une innovation intéressante cette année : les 'World cafés' entre les conférences et pendant lesquels un sujet est discuté par un groupe éphémère et dont un seul membre (le scribe) reste pour consolider les idées qui sont ensuite présentées. Concept favorisant les échanges entre les participants. A cette occasion, j'ai notamment pu échanger avec la responsable d'une grande mutuelle qui m'expliquait qu'elle avait du mal à trouver des prestations de MCO agiles alors que de notre coté, nous avions encore du mal à trouver des clients prêts à partir en (vrai) agile en mettant en front du projet un PO (Product Owner) disposant de pouvoir de décision, d'une expertise fonctionnelle et de temps pour s'investir sur son projet.

Comment impliquer vos clients dans leurs projets ?

J'ai tout simplement adoré cette conférence très concrète et profonde à la fois. Benoit Charles-Lavauzelle (CEO de Theodo) et Julien Laure (coach agile, scrum master) présentent l'histoire de leur société et comment ils sortent des projets (maintenant) réussis en scrum. La société qui développait des projets au forfait (sites B2B en PHP/Symfony) a été proche du dépôt de bilan en 2011. L'insatisfaction des clients était forte à cause de l'effet tunnel : une fois terminées, les applications ne correspondaient pas au besoin que le client pensait avoir exprimé. La société s'est alors tourné vers la méthode scrum qu'elle a appliqué by the book. L’échec a été grand et la cause peut sembler évidente a posteriori : il n'y avait pas de PO du coté du client, donc pas d'implication. Sans PO, le projet navigue à vue. La société a décidé en 2013 ne ne plus faire que des projets en scrum avec implication forte du client. Malgré de fortes réticences des clients qui ne voulaient être facturées au temps passé et non plus au forfait, la société a vu son CA passer alors de 1.2 à 5M€ cette année. Les clients sont venus pour l’expertise technique en PHP/Symfony et sont restés pour la qualité et le respect des délais (95% des clients recommandent la société).

Comment Theodo a-t-elle réussi à impliquer le client ?
  • D'abord, rassurer le client : l'inviter aux plannings de sprint, estimer avec lui (en pocker planning) pour qu'il se rende compte des difficultés techniques. Faire des sprints courts (une semaine ici).
  • Etre transparent, Theodo suit précisement chaque écart au standard (voir support P28).
  • Burdowncharts visibles par le client en live via outils Web.

Qu'est ce qu'on bon PO ?

  • Il faut choisir le PO qui porte (vraiment) le projet, possède le pouvoir de décision (attention aux erreurs de casting).
  • Il faut du feedback permanent avec le PO : système d'évaluation hebdomadaire et portant sur la vélocité et l'accompagnement.
Comment faire valider le PO ?
  • Board électronique avec les taches à valider : Trello (très simple à utiliser pour le client).
  • e-mail quotidien en mode digest avec toutes les questions en suspens, URL importantes, n+1 en copie. Envoyé après le daily.
  • Une fiche d'auto-eval agile (voir support P44) permet d’évaluer la qualité “technique” du sprint et d'arbitrer entre le court et le long terme.
Bilan
  • Le PO travaille de un à deux jours par semaine avec l'équipe, ce n'est pas de trop !
  • Un nouveau problème émerge avec les grands comptes : la distance avec le PO et la généralisation des proxy-PO représentant du PO coté prestataire. Un proxy-PO, c'est mieux que rien (mais à peine mieux).

L'Intelligence collective au service de l’innovation et de l’industrialisation

Clément Duport (Alyotech) nous fait part de sa vision de l'innovation. Il explique que le nœud gordien des politiques IT actuelles réside en ce domaine dans l'ambivalence entre la créativité, le risque, la liberté du coté de l’innovation et l'harmonisation, le contrôle, l'ordre du coté de industrialisation. Ceci conduit à une vraie schizophrénie (OK, nous avons chez Capgemini le Lab'Innovation qui résout en partie ce dilemme en proposant cet espace d'innovation à nos clients). En fait, il explique qu'il faut les deux pour avancer, il faut trouver la bon niveau entre l'ordre (pour survivre) et le désordre (pour avancer). “Créer, c'est se souvenir de ce qui n'a pas eu lieu” (Siri Hustvedt). L’innovation peut émerger d'une démarche industrielle, par recombinaison d'idées.

Faire de la conception en équipe sans architecte

Ly-Jia Goldstein nous fait part de son expérience de développeuse en équipe suivant les préceptes du software craftmanship et de l'XP. Elle explique qu'un bon processus de développement en XP et s'appuyant sur le BDD, le tout en responsabilisant au maximum les membres de l’équipe (en instaurant des decisions techniques collégiales) pouvait se passer d'architecte (logiciel). Ceci présente de nombreux avantages comme un meilleur bus factor, une plus grande réactivité projet et une meilleur fluidité du refactoring. De bons points ont été soulevés. Néanmoins, la conférence tournait de mon point de vue autour du rôle d'architecte logiciel uniquement. Il me semble qu'un cadre d'architecture général (urbanisation, architecture technique, catalogue de solutions, cadre industrialisé, PIC) soit incontournable dans les grands SI, même s'il est vrai que les équipes, constituées en grande partie d’ingénieurs, gagneraient à être plus proactives sur un plan logiciel et éviter des situations telles que celle-ci :

· 2014/12/15 21:14 · 2014/12/15 22:47 · Bertrand Florat · 0 Comments

How to get bind variables values from Oracle

If you already used JDBC prepared statement, you know what are bind variables : the '?' in the query, like in : SELECT col1,col2 from t_table where col1 in (?,?,?) AND col2 = ? For the record, all compiled queries with the same number of '?' are cached by Oracle, hence (most of the time) faster to execute. But how to debug passed values ? This is often valuable like yesterday where one of our services tried to insert value too large for a column (a 4 digits integer into a NUMBER(5,2)).

There is several ways to achieve it, one is using a 'wrapper' JDBC driver (like log4jdbc) that audit and log the values but it's a bit intrusive.

A very simple non-intrusive way for a specific need is to query the v$sql table, the Oracle internal log. A sample query is given bellow (source Stack Overflow) :

select s.sql_id, 
       bc.position, 
       bc.value_string, 
       s.last_load_time, 
       bc.last_captured
from v$sql s
  left join v$sql_bind_capture bc 
         on bc.sql_id = s.sql_id 
        and bc.child_number = s.child_number
where s.sql_text like 'delete from tableA where fk%' -- or any other method to identify the SQL statement
order by s.sql_id, bc.position;

It works like a charm !

Move to Github done smoothly

The Jajuk issue tracker and the Git repository are now moved to GitHub (see previous article for the context).

Repository move

Obviously and by nature, the Git repository move has been very simple. I just had to drop my previous origin (pointing to the gitorious project url), to add the new Github origin and to push all my branches. The push of the master branch toke around 30 mins and the others branches (develop, hotfix) almost no time at all. Note that the -u option used in the push command recreates the upstream tracking references.

git remote del origin
git remote add origin git@github.com:jajukteam/jajuk.git
git push -u origin master

The only problem occurred when dropping our Gitorious repository (error 500 → timeout?)

Issue tracker move

I tried several Trac to Github migration tools, most of them didn't work and finaly settled down with trac2github. It is written in PHP, reads the database (supports mysql, postgres and sqlite) and call the GitHub REST API V3 to create the tickets. It creates the milestones, labels, tickets and comments with good defaults. It had some bugs when working with a postgres database and I has to patch it (two of my push request has been integrated). I also pushed a patch to obfuscate emails from comments.

I also figured out another problem (not linked with the migration tool) : we used the DeleteTicket Trac plugin to drop spam tickets but GitHub issues ids have to be continuous. Origin and destination issues ids are hence now shifted, this is a problem when the code comments have references to a ticket number but we had no solutions for this problem AFAIK.

Have a look at the brand new issue tracker ! : https://github.com/jajuk-team/jajuk/issues

· 2014/12/09 23:21 · 2014/12/10 14:30 · Bertrand Florat · 0 Comments

BitBucket vs Github issue tracker choice for Jajuk

We are currently moving our Jajuk Trac issue tracker to a better place, mainly for spam reasons. A developer suggested BitBucket, others (me included) GitHub which I already use. I cloned our secondary project QDWizard on a private BitBucket repository to make an opinion. I have to say BitBucker is really good too.

According to me, both systems deliver the most important features :

  • Simple to import from Trac.
  • Export facilities to make change possible in the future.
  • Clean and simple GUI.
  • Clean roadmap/version support.
  • Assignation facilities.

But:

  • Github has much more users (around 4M compared to 1M for BitBucket). More developers already have accounts and are used to it.
  • GitHub GUI is a bit faster.
  • GitHub is more “open source” minded, I feel BitBucket more enterprise oriented (private repositories).
  • BitBucket is free only until 5 developers.

Specifically about issues management : the issue manager in Bitbucket is not actually Jira but a lightweight tracker. It doesn't come (hopefully) with the full workflow support. Like most tracker, each ticket has a type (a “kind” : bug, enhancement, proposal, task) , a priority (trivial,…, blocker) and a status (“workflow” : “on hold”, “resolved”, “duplicate”, “invalid”, “wontfix” and “closed”). Note that these states can't be changed nor augmented (many users asked for adding “tested” but it has never been added). It's like Trac without the possibility to customize new types and new status. Some Jajuk Trac types are not supported : “known issue”, “Limitation”, “patch”, “support request”, “to_be_reproduced” (and we map our “discussion” to BitBucket “Proposal”). Some status are missing too : “worksforme”, “not_enough_information”. I suppose a migration would have force us to map several status and several types to the same Bitbucket kind/workflow.

From its side, Github comes with (according to me) a very elegant solution : there are no tickets priorities, types or states but only “labels” like : “important”, “bug”, “wont fix” , <whatever>… OK, it may be more laxist but on the other side :

  1. it allows to add any labels to qualify a ticket against any aspect you may think about ;
  2. it doesn't force to use potentially useless fields like priority.

I suppose the migration scripts will be able to simply create any new labels to reflect our existing status and status (yet to be proven). We still have to run the migration script, I'll test this probably this week end.

start.txt · Last modified: 2015/03/24 11:21 by bflorat