J'ai retrouvé dans mes archives mes notes de révision pour la certification Spring Developer, et j'ai pensé que cela pourrait vous intéresser. Je vous mets le document en pièce jointe. Certes, il s'agissait de Spring 2.5 à l'époque, mais tous les concepts sont encore valides, en particulier si vous intervenez sur un projet Spring "brut" (non-Boot).

Bonne lecture !

Neo4j is a graph database.
I never had the chance to actually use it, but it was on my watch list for a while, so this book by Jérôme Baton came as an excellent opportunity to lean more about it.

You know that I read a lot of technical docs in general, and books in particular. I have lots of them. But I'm often left frustrated because they don't cover much more than the official docs, or only explain the hows instead of the whys.

But this one came as a good surprise, and I enjoyed it.
Jérôme Baton, the main author, is obviously a very experienced Neo4j user. The book is technically dense, with lots of pragmatic tips and examples. Furthermore, I found it entertaining and easy to read, and I completed it in about a week of short studying sessions.

This said, retrospectively, the order of some chapters seemed quite illogical to me, so I'll group them by topic below, rather than book ordering. Now let's start the review.

Disclaimer : a copy of this book was sent to me for review by the authors. But if you are a seasoned follower of this blog, you know that I say what I really think !

Lorsque je dis que je travaille en indépendant, on me fait souvent remarquer que je dois mieux gagner ma vie que quand j'étais salarié.
Après tout, si on prend mon TJM, qu'on le multiplie par, mettons, 20 jours par mois, je retiens un et j'ajoute l'âge du capitaine... Je dois être millionnaire, non ?

Je me retrouve alors à expliquer les flux financiers d'une SASU (Société par Actions Simplifiée Unipersonnelle) à l'aide de schémas plus ou moins biscornus, pour en arriver à la conclusion que... ça dépend. Ca dépend du TJM, ça dépend des inter-contrats, ça dépend de la répartition entre salaire et dividendes.
Une seule chose est sûre : l'Etat se sert à tous les niveaux.

J'ai donc décidé de développer une application^[1] (compatible mobile) qui permettrait à tout un chacun de jouer avec les différentes variables, et de se faire une opinion personnelle sur la rentabilité d'une SASU.

http://sasu.mokatech.net/

J'espère également que l'application jouera un certain rôle éducatif.

• Pour ceux qui hésitent à passer indépendant, l'application permettra de calculer le TJM minimal permettant de couvrir leur train de vie - et de s'apercevoir qu'il n'est pas si élevé que ça.
• Et pour ceux qui sont en SSII, de comprendre mieux l'utilisation de leur TJM, et pourquoi il ne tombe pas intégralement dans leur poche à la fin du mois - surtout que les frais de ces sociétés sont considérablement plus importants que ceux d'une SASU (commerciaux, administratifs, marketing, locaux...)

Alors allez-y, jouez avec l'application, et dites-moi ce que vous en pensez dans les commentaires !

Voici en pièce jointe les slides de mon quickie "Twisted Java", qui a apparemment suscité beaucoup d'intérêt chez les développeurs désireux de troller leurs collègues soucieux d'améliorer la lisibilité de leur code.

Bonne lecture, et n'en abusez pas :)

Voici (en pièce jointe du billet) les slides de ma conférence "Log me tender", présentée à DevoxxFR 2017.
Gros succès du sujet (le grand amphi était plein), et beaucoup de questions après. Comme quoi, en 2017, le problème des logs n'est toujours pas résolu !

Bonne lecture !

La modélisation d'une API REST permettant de gérer une ressource naturellement arborescente pose un problème technique intéressant.

Pour l'exemple, imaginons une API permettant de lire les métadonnées (taille, date d'accès...) d'un fichier sur disque, identifié par son chemin.
Selon la logique RESTful, l'URI associée au fichier foo/bar/baz.txt doit être http://<server:port>/file/foo/bar/baz.txt, et le endpoint Spring MVC associé mappé comme ceci :

@GetMapping("/file/{path}")
public HttpEntity<FileInfo> fileInfo(@PathVariable("path") String path) {
    return filesystemDao.getFileInfo(path);
}

Problème : Spring MVC ne sait pas capturer les fragments d'URL (@PathVariable) contenant des "slash" , même encodés en %2F.

En réfléchissant plus avant, on s'aperçoit que les "slash" ne sont pas les seuls caractères pouvant poser problème : les noms des répertoire et fichiers sont autorisés à contenir des caractères incompatibles avec les URLs. Il nous faut donc encoder tout le chemin, mais, à cause du bug indiqué plus haut, un simple "urlencode" ne suffit pas.
We need a bigger boat.

In "corporate" projects, exceptions are often categorized as TechnicalExceptions and BusinessExceptions.

As technical exceptions usually have a wide application range (eg. DataAccessExceptions), their stacktraces help finding out the exact technical context in which they occurred.

However, for business exceptions, which are often more specific (eg. AuthenticationException) and whose origin in the code is well known, stacktraces are usually useless - but still expensive to generate. What would be more interesting though, is the _business context_ in which they occurred ; for example, knowing that the system failed while processing order #42's payment as part of the daily book-keeping batch is an important information.

Tout a commencé sur Twitter, lorsque Jean-Christophe Sirot (@jcsirot / Coding Stories) m'apostrophe à propos d'un étrange problème de compilation d'une lambda.

Pourquoi ce code compile-t-il...

public class Test {
    private final String s;
 
    public Test(String s) {
        this.s = s;
    }
 
    public Consumer<String> c = 
      (x) -> System.out.println(x + "/" + this.s);
}

...alors que celui-là refuse ?

public class Test {
    private final String s;
 
    public Test(String s) {
        this.s = s;
    }
 
    public Consumer<String> c = 
      (x) -> System.out.println(x + "/" + s);
}

La vidéo de la conférence "Hashons peu, mais hashons bien" , que j'ai présentée à Devoxx France 2015 avec Olivier Bourgain, est désormais visible gratuitement sur Parleys !

En 40 minutes, découvrez ce que sont les fonctions de hachage, à quoi elle servent, et comment les Maps en tirent parti dans le JDK. Avec en bonus, des histoires de parkings, de métros, et du trifouillage de bits de la manipulation d'octets en folie !

Voir la conférence Hashons peu, mais Hashons bien.

Préface

Comme indiqué dans un précédent billet, je tente l'ouverture du blog à des auteurs externes, de jeunes développeurs brillants et sélectionnés avec soin.
Ils apporteront leur expertise et un point de vue décalé sur des sujets que je ne traite pas habituellement.

Je vous présente aujourd'hui Hadrien Pierart, freelance au parcours atypique, spécialisé dans le développement front (web et Android).
Hadrien tiendra notamment une rubrique récurrente intitulée "Dernières nouvelles du Front", inspirée des célèbres Javascript Weekly et HTML5 Weekly, dont voici le premier numéro.

Bonne lecture !
Olivier

Dernières nouvelles du Front #1

Quelques mots sur moi pour cette première édition : historiquement développeur Java Android, je me suis rapidement mis au développement web et plus particulièrement JavaScript. Comme on ne peut rarement tout faire, j'ai choisi de me concentrer principalement sur le web, les webperfs et le développement fullstack avec une nette préférence pour le front et une passion pour ce langage atypique qu'est le JS.

Je suis freelance comme Olivier et je travaille actuellement pour une startup nommée Once.
Enfin je suis aussi Editor pour infoQ FR.

Pour résumer cette édition, je vais vous parler de plugins grunt, de nouveautés ou fonctionnalités cachées des DevTools de Chrome, de convention de code en CSS et un peu de JS bashing pour finir. (Ca fait toujours sourire, même pour un grand adepte comme moi)

Chers lecteurs et lectrices,

J'envisage d'accueillir sur ce blog des auteurs extérieurs, sélectionnés avec soin, afin de le dynamiser et de l'ouvrir à d'autres horizons.

Dans ce cadre, mon premier invité se proposerait de tenir une rubrique "développement front/web" bi-mensuelle, pour vous tenir au courant des dernières avancées de HTML, Javascript et des frameworks à la mode.

Mais je ne peux pas prendre cette décision importante sans vous consulter, puisque vous êtes les premiers concernés.

Pourriez-vous prendre le temps d'exprimer votre avis dans les commentaires ?

• Que pensez-vous de l'ouverture éventuelle à des auteurs invités ?
• Êtes-vous intéressés par davantage de web ?
• Des remarques ou idées ?

Merci pour vos réponses !

April's fool day... The perfect day to flood Twitter with random thoughts !

NSA about to declare Scala a threat for national security, argues it cannot decrypt it yet

— Olivier Croisier (@OlivierCroisier) 1 Avril 2015

Si vous n'avez pas suivi le (micro-)feuilleton du moment sur Twitter, voici un résumé rapide.

Tout commence avec un tweet d'Emmanuel Lécharny :

Replacing a 5 lines method by a 140 lines one which is 15 times faster. Don't trust people who claim that less code is better.

La Javadoc officielle est très bien faite, mais la présentation des packages sous la forme d'une interminable liste alphabétique n'est pas très ergonomique. En pratique, on se sert surtout de java.lang, java.util et ses sous-packages, un peu de java.io... et rarement des autres. Alors pourquoi ne pas les mettre en avant ?

En attendant qu'Oracle se décide à intégrer des fonctions de recherche ou un système de favoris au doclet standard, j'ai fini par hacker manuellement la javadoc afin de faciliter l'accès aux packages qui m'intéressent.

Si ça marche, on n'y touche pas !

Sur les projets informatiques, la maintenance et la modernisation de l'existant sont rarement prioritaires par rapport à l'ajout de fonctionnalités. Au fil du temps, le code devient moins pertinent, moins performant, plus difficile à analyser et à maintenir.
La dette technique s'accumule progressivement et freine les nouveaux développements, allonge les délais de débogage, instille l'incertitude.

Arrive le moment où l'équipe grogne et parvient à décrocher un budget pour la réduction de la dette technique. Mais comment la mesurer ? Par quel bout commencer ? Comment optimiser le budget alloué ?

Voici une méthode simple et efficace qui devrait vous permettre de prendre conscience de l'état global du projet, et de faciliter l'identification et la priorisation des portions les plus atteintes par la dette technique.

Le saviez-vous ? Il est interdit d'utiliser un simple underscore (_) comme nom de paramètre de lambda. Cela a de quoi surprendre, étant donné que c'est un nom parfaitement valide pour un champ, un paramètre de méthode, ou une variable locale.

Tout d'abord, bonne année 2015 à tous et toutes !

Si vous êtes en manque de bonnes résolutions, permettez-moi de vous suggérer celles-ci, qui, à défaut de faire de vous un homme ou une femme meilleur(e), au cheveu brillant et au sourire #FFF, vous évitera au moins de finir découpé en rondelles par un collègue hystérique après un build rouge ou une mise en prod' ratée :

• Arrêter de mettre des serialVersionUID dans toutes les classes pour faire plaisir à Eclipse ;
• Traiter les "erreurs normales" visibles au lancement de l'application
• Régler l'IDE en UTF8 dès le début du projet, pour ne pas vous faire appeler Martine
• Arrêter de passer sournoisement les tests qui plantent en @Ignore
• ... Je vous laisse compléter la liste, je suis sûr que vous avez des idées :)

J'ai commencé la programmation très tôt. Parce que c'était amusant.

D'abord, sur l'Apple II de mon grand-père.
Il était composé (l'ordinateur, pas le grand-père) d'une unité centrale avec clavier intégré, surplombé de deux lecteurs disquettes 5"1.4, et finalement d'un écran en noir et jaune. Une disquette (recto/verso) permettait de booter l'OS et de le monter en mémoire. D'autres disquettes permettaient ensuite de charger des programmes (tableur, jeux^[1]...) et de sauvegarder les documents.

L'OS en ligne de commandes proposait quelques commandes simples, et c'est ainsi que j'ai tapé pour la première fois le traditionnel "print "hello"" et que, miracle, ça a effectivement affiché "hello". C'était magique.

L'API Stream fournit une méthode distinct() permettant d'éliminer les éléments en doublon.
Sa Javadoc indique :

Returns a stream consisting of the distinct elements (according to Object.equals(Object)) of this stream.

Cette description laisse penser qu'il suffit que nos objets implémentent equals() pour être correctement traités par distinct(), ce qui est faux (ou du moins incomplet).

Maintenant que la rage et la fureur de Devoxx sont retombées, je vous propose de résoudre un petit quiz facile sur Java 8 !

A votre avis, qu'affiche le code suivant ?

Attention, ne trichez pas : interdiction d'exécuter le code avant d'avoir trouvé ! Mais pouvez consulter la documentation de la classe IntStream.

public class Quiz {
    public static void main(String[] args) {
 
        IntStream.rangeClosed(1, 10)
                 .map(i -> i++)
                 .forEach(System.out::println);
 
    }
}