Dans la religion méthodologie Scrum, les spécifications du produit à développer ne sont pas rédigées dans leur intégralité au début du projet, mais au contraire fournies par le client au fur et à mesure de l'avancement du développement, afin de lui offrir une plus grande réactivité.
Le périmètre courant du projet est matérialisé par le "product backlog", c'est-à-dire un flux priorisé de fonctionnalités à développer, alimenté en permanence par le client, et consommé en flux tendu par l'équipe de développement.

Mine de rien, on est là en plein pattern producteur-consommateur. On pourrait même y voir une certaine similarité avec le fonctionnement d'un ThreadPool, les thread (les développeurs) traitant des jobs (les fonctionnalités) dans leur ordre de soumission.

Question : les bonnes pratiques associées à la gestion des thread pools (en particulier leur dimensionnement) pourraient-elles être appliquées aux équipes de développement Scrum ?

Jusqu'à Java 6 inclus, TreeMap et TreeSet avaient un comportement rigolo, pouvant fournir matière à quiz ou question d'entretien technique.

A votre avis, que fait ce bout de code ?

TreeSet set = new TreeSet();
set.add(new Object());
set.add(new Object());
System.out.println(set.size());

A l'exécution, on obtient une ClassCastException... à la ligne 3.
C'est-à-dire l'insertion du premier objet se passe bien, mais que la seconde provoque une exception.

La raison en est simple : un TreeSet (ou une TreeMap) étant implémenté sous forme d'arbre binaire, il doit comparer les objets entre eux pour les organiser. Or, nous voyons dans le code que les objets insérés n'implémentent pas Comparable, et qu'aucun Comparator n'est fourni au TreeSet.

Le premier objet étant... le premier justement, et donc le seul dans la structure, aucune comparaison n'est effectuée : il devient simplement la racine de l'arbre. A partir du second objet, une comparaison devient nécessaire, et les objets sont donc "castés" en Comparable... ce qui provoque une ClassCastException.

Funky, mais logique, quelque part.

Et bien, tout ceci est fini en Java 7 : on obtient une exception dès la première insertion.
C'est moins drôle, mais ce nouveau comportement est sans doute plus sain. On ne s'en plaindra donc pas.

Et puis, maintenant vous avez une nouvelle anecdote pour épater les convives dans les dîners mondains :)

Si je vous demande de me citer des structures de données, vous répondrez sans doute : les tableaux, les listes chaînées, les Maps, les Sets, voire les arbres binaires... Ces structures sont simples et d'un usage courant, et suffisent pour la plupart de nos besoins.

Dans certain cas toutefois, les structures basiques atteignent leurs limites, et il est nécessaire de recourir à des structures spécialisées. Aujourd'hui, je vous présente les Arbres de Fenwick.

Vous connaissez le "Behavior-Driven Development" (BDD) ?
C'est une méthode de spécification et de test, qui consiste à décrire des scénarios sous la forme de triplets "conditions initiales" / "action" / "résultat attendu" (Given... / When... / Then...).

Différents frameworks (Cucumber, EasyB, JNario...) facilitent la mise en place de ce pattern en proposant notamment une syntaxe spécifique (DSL), et offrent de nombreuses fonctionnalités fort pratiques.

Mais si seule la formalisation "Given / When / Then" vous intéresse dans vos tests unitaires, il suffit d'utiliser... les labels Java.