Dans ce second article, je vous propose de découvrir les fonctionnalités de Guava relatives aux collections.
Nous nous intéresserons dans un premier temps aux Prédicats et aux Fonctions, puis nous découvrirons les nouvelles Collections proposées par Google.

Cet article fait partie d'une série :

• Guava : les classes utilitaires
• Guava : les collections
• Guava : I/O

How many times have you read the following sentence : "When you don't provide any constructor in a class, the compiler automatically inserts a default, no-args constructor for you" ?

So now you assume that every class with no apparent constructor has a hidden, default, no-arg constructor. Big mistake.

Guava est une librairie Java éditée par Google, qui fournit de nombreuses fonctionnalités qui auraient dû se trouver dans le JDK.

Cette série d'articles n'a pas pour vocation de détailler toutes les classes de la librairie, mais d'en présenter une sélection facilement utilisables sur vos projets.
Chaque classe présentée est assortie d'un exemple sous la forme d'un test unitaire mettant en évidence son fonctionnement.

Cet article fait partie d'une série :

• Guava : les classes utilitaires
• Guava : les collections
• Guava : I/O

Un "test d'acceptation" est un test rédigé par, ou en coopération avec la MOA. C'est une véritable spécification exécutable, qui est décrite dans un format humainement lisible. Le but recherché est d'extraire les algoritmes métiers du code, afin de les rendre visibles par tous les acteurs du projet - MOA, développeurs, testeurs, éventuellement les utilisateurs...

Les tests d'acceptation encouragent la "spécification par l'exemple" : la fonctionnalité développée est encadrée par des exemples décrivant les cas nominaux, les cas particuliers, les exceptions, etc. Les tests s'assurent ensuite que le comportement attendu est respecté.

Plusieurs outils existent, comme FitNesse, Cucumber (Ruby), RobotFramework (Python), JBehave (Java)... Concordion se démarque du lot par son extrême simplicité de mise en oeuvre car il s'appuie sur JUnit, et ne nécessite aucun serveur externe ni langage exotique.

I don't know if you play Minecraft - but if you don't, you should.

It is basically a sandbox construction game, where you can do whatever you like : crafting tools and materials, explore caves or dig mines to find ore and diamonds, create whole cities with your friends or wander around til the sun sets.

Then at night, things are different - this is when monsters appear. Minecraft mobs come in a variety of shapes and degree of pain-in-the-ass-ness. Some are quite inoffensive, others can ruin a whole day's effort in a second.

It struck me recently that those mobs were indeed quite representative of the varieties of software bugs. Let's see how.

Brian Goetz parle des "Virtual extension methods" (anciennement connues sous le nom de "Defender methods") lors du JVM Summit 2011.

(Lire la suite pour voir la vidéo)

Je travaille actuellement sur l'industrialisation d'un gros projet "legacy" : je mets en place le build par Maven, l'intégration continue avec Jenkins, et la qualimétrie avec notamment PMD et Checkstyle, configurés via Sonar.

Le précédent billet expliquait comment j'avais réussi à placer le projet sous intégration continue avec Maven et Jenkins ; dans celui-ci, je parlerai de qualimétrie avec Sonar, PMD et Checkstyle.

Je travaille actuellement sur l'industrialisation d'un gros projet "legacy" : je mets en place le build par Maven, l'intégration continue avec Jenkins, et la qualimétrie avec notamment PMD et Checkstyle, configurés via Sonar.
Mais l'application ne respecte évidemment aucune des conventions de Maven - "multi-module" mais pas tout à fait, arborescence des sources différente, jars exotiques non identifiés...

Comme j'ai pas mal lutté pour faire marcher tout ça ensemble, je vous livre ici mon retour d'expérience et les quelques astuces que j'ai glanées ci et là.

En entreprise, il est fréquent de travailler sur des postes sous Windows, configurés avec des profils itinérants, c'est-à-dire synchronisés avec un serveur central de manière à pouvoir être accédés depuis n'importe quel autre poste.

Par défaut, tout le répertoire utilisateur est ainsi sauvegardé (C:\Documents and Settings\<user>), et redescendu localement lors de l'ouverture d'une session. ll est donc important de limiter sa taille au strict minimum, sous peine de subir des temps de connexion importants (quoique cela donne un bon prétexte pour aller prendre un café matinal ou draguer les filles de la compta).

Problème : de nombreux outils stockent leurs données dans ce répertoire par défaut, données qui peuvent être très volumineuses - et en particulier Maven et IntelliJ.

Je vous propose donc de rassembler ici une liste des configurations à effectuer sur différents outils ou programmes, afin qu'ils placent leurs données dans d'autres répertoires. Je vous invite à m'aider à la compléter !
Dans un souci d'homogénéité, on désignera le nouveau répertoire à utiliser comme ceci : <configdir>.

Everyone knows (or should) that a non-static inner classe has a hidden reference to the instance of its containing class.

Let's exercise this sample class :

public class Outer {
 
    private final int i;
 
    public Outer(int i) {
        this.i = i;
    }
 
    public class Inner {
        public void print() {
            System.out.println(i);
        }
    }
 
}