Hibernate: Maîtrisez le débit et les performances de vos requêtes SQL

Thu, 12 Nov 2020 00:00:00 +0000

Dans ce post, j’aimerais vous parler de bonnes pratiques Hibernate. Le sujet semble éculé, tant cette technologie existe depuis longtemps. Il existe déjà par ailleurs de nombreuses ressources permettant de bien comprendre le framework.

Pourtant, en 2020, le sujet me semble encore d’actualité, car Hibernate est toujours massivement utilisé dans de nombreux projets Java. Et il est souvent mal utilisé.

Une majorité des problèmes de performances que j’ai pu rencontrer dans ma carrière étaient liés à des interactions entre l’application et la base de données, et à une méconnaissance des bonnes pratiques Hibernate et SQL.

De plus, c’est un fait, Hibernate est mal-aimé.

Les développeurs trouvent l’outil difficile à configurer et maintenir. Les DBA constatent que les bases de données SQL sont sollicitées par des requêtes pouvant être superflues ou mal optimisées. Les devops aussi pourront déplorer une utilisation mémoire très importante et des temps de réponse médiocres sur les serveurs.

Souvent, on rejette la faute à Hibernate. Il faut dire que l’outil est tellement puissant et flexible qu’il est vraiment très facile de prendre de mauvaises décisions qui vont dégrader considérablement les performances et la maintenabilité d’une application.

Pourtant, avec quelques astuces à la portée de tous, on peut aisément atténuer la majorité des écueils les plus courants.

Avec ma modeste expérience, je souhaiterais rappeler certains principes de base et démontrer que l’on peut utiliser Hibernate proprement, en contrôlant le flux et la qualité des requêtes générées, pour le plus grand bonheur de vos utilisateurs et de vos collègues.

Toujours penser SQL d’abord

Il est parfois bon de rappeler les choses évidentes. Hibernate ne fait pas de magie, il convertit du Java en SQL notamment avec la configuration effectuée dans des classes Java (les fameuses entités).

La clé pour bien utiliser Hibernate, c’est toujours se préoccuper du SQL qui sera généré à la fin.

Lorsque vous travaillez sur une fonctionnalité, essayez d’imaginer les requêtes SQL minimales pour répondre au besoin.

Si le SQL généré par Hibernate contient plus de requêtes ou d’instructions (champs, jointures, etc.) que nécessaire, alors votre configuration Hibernate n’est pas optimale. La base répondra moins rapidement, et vous polluerez votre heap JVM avec des objets inutiles.

Comment éviter cela ? Les prochaines lignes vous apporteront quelques éléments de réponse.

La configuration des entités Hibernate

La plupart des problèmes liés à Hibernate proviennent d’une mauvaise configuration des entités. Le rôle d’une entité est de représenter en Java une table SQL et la stratégie pour la requêter. Le souci, c’est que la configuration de votre entité va impacter TOUTES les requêtes qui vont référencer cette entité. On a donc une configuration d’entité commune qui sera utilisée par des requêtes supposées être sur-mesure.

Il faut donc configurer vos entités de façon la plus fermée et minimale possible, et aller chercher les infos supplémentaires au cas par cas dans vos requêtes.

Soyez paresseux !

La règle d’or à appliquer autant que possible, est de marquer explicitement toutes vos associations @OneToMany, @ManyToOne, @OneToOne comme étant LAZY. La plupart des soucis de performance Hibernate sont provoqués par des jointures non maîtrisées, ce qui va générer des requêtes inutiles ou trop lourdes. Ce paramètre vous obligera à faire vos jointures uniquement quand elles seront nécessaires.

@Entity
public class Employee {
    
    @Id
    private Long id;
    
    @OneToOne(fetch=LAZY)
    private Department department;
}

C’est le conseil le plus important de cet article, car il offre des bénéfices considérables assez facilement.

Cependant, l’appliquer sur un projet existant ne sera pas toujours simple car cela nécessitera de réécrire une partie des requêtes référençant cette entité (pour aller chercher manuellement les jointures). Si vous oubliez de le faire, le compilateur ne vous protégera pas et vous aurez des erreurs au runtime (LazyInitializationException).

Cette exception peut être évitée avec l’option enable_lazy_load_no_trans. Celle-ci permet de faire automatiquement une requête en base pour les associations LAZY qui ne sont pas encore dans la session Hibernate, au moment où elles seront appelées dans le code (ex: employee.getDepartment()).

Cependant, activer cette option reste déconseillée. Comme je l’ai dit, toute requête automatique non maitrisée sera souvent superflue et dégradera vos performances. Il est préférable que Hibernate jete une LazyInitializationException qui sera bien plus visible, et que vous pourrez gérer avec des join fetch dans vos requêtes HQL. Nous parlerons des requêtes HQL plus en détail ci-après.

Cela dit, s’il faut choisir, il reste préférable d’utiliser l’option LAZY + enable_lazy_load_no_trans plutôt que d’utiliser EAGER. Cette option peut d’ailleurs s’avérer utile en cas de migration progressive de EAGER vers LAZY car il offre un compromis acceptable.

Autres optimisations

Hibernate propose beaucoup d’options pour affiner la configuration des entités. Certaines sont plus ou moins applicables selon le contexte. En voici deux faciles à appliquer :

Marquez comme @Transient tous les champs et méthodes de l’entité qui ne doivent avoir aucune interaction avec la base de données. Il peut parfois être pratique de rajouter du comportement dans votre entité, mais cela ne doit pas impacter les requêtes vers la base.

@Entity
public class Employee {
    
    @Id
    private Long id;
    
    @OneToOne
    private Department department;
    
    @Transient
    public String getDepartmentName() {
        return department.getName()
    }

}

Si vous avez des tables ou des champs en lecture seule, il est très intéressant d’utiliser @Immutable ou insertable=false et updatable=false. Hibernate évitera d’envoyer des UPDATE indésirables pas toujours évidents à détecter, tout en amélirant la lisibilité du code.

@Entity
@Immutable
public class Employee {
    
    @Id
    private Long id;
}

@Entity
public class Employee {

    @Id
    private Long id;
    
    @Column(name = "department", insertable=false, updatable=false)
    private String department;
}

La responsabilité des entités Hibernate

Ce point est également essentiel, et n’est même pas spécifique a Hibernate : Limitez au maximum les responsabilités et le couplage des entités Hibernate avec vos autres composants. Une entité a pour rôle de représenter votre table, et rien d’autre. De plus, pour fonctionner, votre entité se doit de respecter certains prérequis (getters/setters, classe mutable…) qui ne sont pas souhaitables dans le reste de votre code.

Pour cela il est primordial de ne pas réutiliser vos entités Hibernate au-delà de la couche de persistance. Convertissez-les le plus vite possible dans une classe dédiée. Sinon, il y aura un couplage fort entre la persistance, le métier ou encore la vue (API REST, templates HTML, etc.). Ne référencez jamais vos entités dans les couches de plus haut niveau !

Même si cela peut être tentant pour éviter de la duplication, chaque fois que vous réutiliserez une entité pour des problématiques différentes (techniques ou métiers), vous risquez d’ajouter des données ou comportements spécifiques qui amèneront des risques de bugs sur vos autres fonctionnalités.

Pour chaque use case, essayez autant que possible de créer des classes dédiées :

public EmployeeAgeDTO findEmployeeAge(Long employeeId) {
    Employee employee = employeeRepository.findById(employeeId);
    
    return new EmployeeAgeDTO(
        employee.getName(), 
        employee.getBirthDate(), 
        employee.getAge()
    );
}

public EmployeeDepartmentDTO findEmployeeWithDepartment(Long employeeId) {
    Employee employee = employeeRepository.findById(employeeId);
    
    return new EmployeeDepartmentDTO(
        employee.getName(), 
        employee.getDepartment().getName()
    );
}

Votre entité Hibernate sera aussitôt consommée et convertie dans une structure minimale et donc optimale.

Cela va amener un peu de duplication et vous devrez gérer la conversion entre vos classes, mais cela vous protègera de tout effet de bord non voulu (SQL ou Java). La partie conversion est souvent considérée comme laborieuse, mais reste peu complexe et donc peu coûteuse à maintenir.

En revanche, si vous décidez d’utiliser des classes mutualisées, vous couplerez vos use cases ce qui fragilisera à terme la maintenabilité de votre code.

Les requêtes HQL

La dernière chose nécessaire pour avoir des résultats performants et sans effet de bord, est d’essayer, pour chaque nouveau besoin, de faire des requêtes sur-mesure. En effet, entre plusieurs fonctionnalités, les résultats et leur format seront forcément différents.

De plus, la plupart du temps, vous n’aurez pas besoin de tous les champs de la table, ni de toutes ses associations.

Faire des projections sera souvent la meilleure solution. De cette façon, chaque requête exprimera et cherchera uniquement ce dont elle a besoin. Les associations LAZY permettront d’éviter les jointures automatiques indésirables. Vous ne ferez des jointures seulement en cas de besoin.

Le résultat de la projection sera donc une aggregation de plusieurs tables dans un format différent de celui de vos entités. Utiliser une classe dédiée sera donc nécessaire pour représenter ce résultat.

Un exemple possible, qui instancie un DTO directement à partir de la requête :

  public List<EmployeeDto> findEmployeesByDepartment(String departmentName) {
    Query<EmployeeDto> query = sessionFactory.getCurrentSession()
      .createQuery("select " +
          "new com.mycompany.dto.EmployeeDto(employee.id, employee.name, department.name) " +
          "from Employee employee " +
          "join Department department on employee.departmentId = department.id " +
          "where department.name = :departmentName " +
          "order by employee.name"
        , EmployeeDto.class);
    query.setParameter("departmentName", departmentName);

    return query.getResultList();
  }

Pour résumer, cet exemple regroupe une bonne partie des recommandations citées plus haut :

Une requête SQL totalement maîtrisée et avec des performances optimales.
On découple l’entité des résultats de la requête avec une classe dédiée (ici EmployeeDto). En instanciant la classe directement dans la requête vous n’aurez même pas besoin de faire la conversion en Java !
L’entité n’est pas exposée dans les couches métier / présentation de votre application qui ne pourront pas exploiter des champs ou des données inutiles.

En cas de doute, affichez et vérifiez régulièrement les requêtes SQL générées

Pour mesurer et optimiser les requêtes SQL, il ne faut pas hésiter à les logger pendant vos phases de développement, en activant les options fournies (show_sql, etc.) et en utilisant votre outil de log favori.

Exemple avec logback :

  <logger name="org.hibernate.SQL" level="DEBUG" />
  <logger name="org.hibernate.type" level="TRACE" />

Cela vous permettra notamment de savoir si le souci provient de Hibernate ou de la base. Dans le 2e cas de figure, rapprochez-vous de votre DBA pour faire de l’optimisation (index, vues, etc.)

Pensez à consulter le blog de Vlad Mihalcea

Vlad Mihalcea est une personne incontournable dans l’écosystème Hibernate. Il écrit énormément sur Hibernate notamment au travers de son blog très complet. Il est régulièrement mis à jour et honnêtement, j’ai toujours trouvé la réponse à mes questions.

C’est simple, dès que j’ai un problème sur Hibernate, j’utilise mon moteur de recherche préféré et je suffixe toutes mes recherches par Vlad :

one to many hibernate vlad
projection hibernate vlad
etc.

Vous serez alors redirigé vers son blog qui vous proposera forcément une réponse adaptée.

Un outil difficile d’accès mais qui reste très pratique

Soyons honnêtes, Hibernate requiert une certaine période d’apprentissage et certains de ses comportements par défaut peuvent faciliter une mauvaise utilisation. Son manque de cadre et sa flexibilité peuvent amener de la confusion et du découragement, surtout au début.

Malgré tout, je pense que sa mauvaise réputation est un peu injuste car c’est un bon outil, puissant et customisable. Il permet de s’abstraire de la complexité liée a la couche JDBC et d’avoir moins de boilerplate dans la couche de persistance de son code, tout en faisant du SQL propre.

De plus, contrairement à ce que j’ai pu lire et entendre, Hibernate n’est pas incompatible avec des concepts comme DDD si on arrive à isoler correctement la partie Hibernate du reste du code métier. Il existe un bon nombre de stratégies et patterns pour y arriver : Utilisation des interfaces et de l’encapsulation, architecture hexagonale, isolation à partir de modules de votre outil de build (Maven/Gradle…).

J’ajouterais même qu’il peut être complémentaire avec d’autres outils comme jOOQ.

Avec ce billet, j’espère vous avoir convaincu que l’on peut réussir à maîtriser un minimum ce framework avec quelques ajustements basiques, sans pour autant être un expert.

Bonne hibernation !

Devenir parent en étant indépendant : Retour d'expérience et optimisations fiscales

Tue, 25 Aug 2020 00:00:00 +0000

Dans cet article, je souhaiterais vous partager mon expérience d’indépendant et de jeune père de famille. Dans les deux situations, nous sommes confrontés quotidiennement à des situations inédites et apprenons énormément de nouvelles choses, souvent sur le tas. Cela a été évidemment le cas pour moi aussi.

Si notre vécu de parent est souvent assez singulier, ce n’est pas le cas en ce qui concerne notre quotidien de travailleur indépendant, où nous sommes soumis aux mêmes règles, et vivons beaucoup de choses similaires. On peut donc légitimement se demander si ce choix de vie professionnelle est compatible avec cette nouvelle situation familiale ? Existe-t-il, à l’instar des salariés, des dispositifs ou des aides spécifiques à ce statut ?

Il existe effectivement quelques aides et optimisations spécifiques à la famille et à la parentalité, qui nous permettent d’économiser de l’argent assez facilement. Aucun des cabinets comptable avec qui j’ai pu travailler ne m’avait parlé de ces spécificités. Je les ai donc connues soit par curiosité, soit par hasard.

Après quelques discussions avec des confrères, je me suis rendu compte que mon cas n’était pas isolé, et que cela pouvait être intéressant de partager ces informations.

Congé parental

Peut-être que comme moi, vous avez choisi cette vie d’indépendant pour avoir plus de flexibilité dans votre travail et trouver un meilleur équilibre entre votre vie professionnelle et personnelle.

J’ai eu le bonheur d’avoir un enfant en 2017, et en concertation avec la maman, j’ai décidé de poser un congé parental pour une durée indéterminée (qui a finalement duré 2 mois). Le but pour moi était de profiter de ces instants uniques dans une vie, mais aussi d’accompagner mon épouse dans cette découverte de la parentalité qui est non seulement difficile, mais qui, à mon sens, doit se partager a deux. La présence du papa est réellement importante tant pour le soutien moral, que pour les tâches quotidiennes qui deviennent de plus en plus nombreuses avec des enfants.

C’est à ce moment-là que mon statut de freelance a pris tout son sens. Dans un pays encore en retard sur les législations liées au congé paternité pour les salariés, il permet une réelle souplesse dans la gestion de notre temps, malgré la contrepartie financière non négligeable liée aux absences sans solde.

Même si on est en droit de se dire que l’aspect pécuniaire passe au second plan, il est tout de même judicieux d’anticiper cette pause pour atténuer la perte de revenus qui se répercutera forcément sur votre foyer et votre quotidien.

Combien de temps consacrer pour ce congé ? Quel chiffre d’affaires viser pour garder un certain confort financier ? Est-il nécessaire de chercher une nouvelle mission en avance ? Ce sera à vous de le déterminer, en élaborant un emploi du temps sur-mesure. Le reste ne sera qu’une formalité, car il est généralement assez aisé de suspendre son activité, même pour une durée prolongée, en s’arrangeant avec ses clients.

Toute cette flexibilité fait la force de notre statut, malgré ce côté à double tranchant qui nécessite un peu d’anticipation de notre part. En outre, Il existe quelques aides et optimisations intéressantes relativement méconnues que je vais détailler ci-dessous.

Prime de paternité

Cet article étant uniquement basé sur mon vécu, et ne voulant pas parler de choses que je ne connais pas, je ne vais malheureusement pas parler des droits concernant la maternité. Je vais me focaliser uniquement sur ce que j’ai pu expérimenter personnellement : La prime de paternité.

Avec un statut d’indépendant, le RSI (désormais intégré au régime général de la sécurité sociale) propose une indemnité forfaitaire pour tout père voulant s’absenter dans le cadre de la naissance d’un enfant (en 2020, 56,35 € par jour sur un maximum de 11 jours, donc au mieux 620 €). Cette indemnité compensera sans doute assez peu la perte financière liée a ce congé sans solde, mais cela reste toujours bon à prendre. Il suffit juste de faire valoir ce droit dans les 4 mois qui suivent la naissance de l’enfant en envoyant un formulaire et des pièces justificatives à votre caisse d’assurance maladie.

Sources officielles:

Chèques CESU

Comme la plupart des parents, vous aurez besoin de faire garder votre enfant. Lorsque vous devrez choisir une assistante maternelle agréée ou une crèche, vous aurez la possibilité, si celle-ci accepte, de payer en chèque CESU préfinancé.

L’avantage pour un indépendant, c’est que ces chèques pourront être achetés par la société. Jusqu’à un certain seuil (1830 € par personne et par an en 2020), cela peut s’avérer très intéressant.

Pour la société :

Le montant des chèques n’est pas soumis aux cotisations sociales (contrairement à de la rémunération)
L’achat des chèques est deductible du résultat (que ce soit en BNC ou en société)
Et surtout, cela donne droit a un credit d’impôt de 25 % : Le credit d’impôt famille

En revanche, le vendeur vous facturera des frais (autour de 100 € HT)

Pour vous :

Le montant des chèques compte comme un avantage en nature et non une rémunération. Ils ne seront pas soumis à l’impôt sur le revenu.

Cependant, ce montant ne sera pas inclus dans le calcul du crédit d’impôt garde d’enfant. Mais cela vaut quand même largement le coup.

Par rapport à de la rémunération, l’économie totale en taxes que vous allez réaliser sur ces 1830 € va dépendre de plusieurs facteurs (taux de cotisations, taux marginal d’imposition, etc.) mais pourra facilement dépasser 1000€, ce qui est très intéressant.

De plus, vous pourrez bénéficier de cet avantage pour chaque nouvelle année civile. Par exemple, pendant 3 ans pour un enfant (jusqu’à l’entrée en maternelle). Vous pouvez également acheter des CESU dès lors que vous avez besoin de prestations de services à la personne

Un dernier conseil : Pour maximiser les chances de convaincre votre assistante maternelle d’accepter ce mode de paiement, il vaut mieux acheter des CESU dématérialisés. Cela lui évitera de payer des frais supplémentaires ou de devoir encaisser elle-même les chèques physiques.

Sources officielles:

Chèques CESU préfinancés

Mutuelle

Cela ne se sait pas toujours, mais un travailleur indépendant a le droit de souscrire a une mutuelle et d’en faire bénéficier son conjoint et ses enfants. Les avantages sont les suivants :

Mutualisation des coûts (un contrat unique coute souvent moins cher que la somme des autres contrats)
La part de cotisations du gérant (mais pas toujours celle de ses ayant-droits, cela dépend) est déductible des bénéfices (cf. la loi Madelin)
Faire payer la société est toujours plus intéressant que de payer en tant que particulier : En effet, les sommes dépensées ne comptent pas comme de la rémunération et ne sont pas soumis a l’impôt sur le revenu (pour vous) ni aux cotisations sociales (pour la société). En effet, il faut toujours garder en tête que chaque virement de rémunération ou dividendes vers votre compte personnel sera soumis à ces fameuses taxes (qui oscillent entre 45 a 70 % selon votre situation). Vous économiserez donc potentiellement plusieurs centaines d'euros de taxes par an.

C’est surtout intéressant si votre conjoint n’a pas de mutuelle ou si les garanties/cotisations de sa mutuelle employeur sont moins intéressants que la vôtre. Il/elle sera alors en droit de refuser la mutuelle de son employeur et vous pourrez l’inclure dans votre contrat.

Sources:

Mutuelle Madelin

Le mot de la fin

Se mettre à son compte, tout comme être parent est un apprentissage permanent où nous faisons de nombreuses erreurs que nous essayons de ne pas reproduire. Si j’ai pu connaître au bon moment et bénéficier pleinement de la prime de paternité, cela n’a pas été le cas avec les chèques CESU et la mutuelle collective. Avec cet article, j’espère pouvoir aider des confrères à ne pas reproduire les mêmes erreurs que moi, et indirectement profiter d’autant plus de leur vie familiale !

Code Freelance, le livre qui démystifie le freelancing

Fri, 13 Sep 2019 00:00:00 +0000

Il y a quelques semaines de cela, Emilien Pecoul (@Ouarzy), un développeur Lyonnais assez actif dans la communauté, a publié un livre consacré au freelancing :

Tu es #Dev #Freelance ou tu voudrais le devenir ? Je viens de publier un livre qui pourrait t'interesser! #CodeFreelance https://t.co/EVexVUW23r pic.twitter.com/3Yu5Anh2w5
— Emilien Pecoul (@Ouarzy) August 28, 2019

Étant moi-même indépendant depuis plus de 5 ans, ce livre a attisé ma curiosité. En effet, le sujet me passionne depuis longtemps et j’ai beaucoup étudié / expérimenté un certain nombre de ses aspects (Comptabilité, Fiscalité, Juridique…). Comme j’ai tenu ma comptabilité pendant 3 ans, j’avais justement fait un retour d’expérience lors d’un meetup HackYourJob.

En achetant ce livre, je souhaitais non seulement soutenir la démarche que je trouve excellente pour aider à démystifier ce choix de vie encore trop méconnu, mais aussi pour comparer mon expérience avec celles d’un freelance chevronné et du collectif HackYourJob.

Avec cet article, je souhaite vous présenter brièvement les thèmes abordés dans cet ouvrage, et vous dire ce que j’en ai pensé. Et pourquoi pas aider certains indécis à décider de l’acheter ou non ?

De quoi parle ce livre exactement ?

Apres une introduction très pertinente expliquant pourquoi le freelancing progresse vite au travers d’un état des lieux du travail et du salariat aà l’heure actuelle, le livre passe dans le vif du sujet en traitant principalement des sujets suivants :

Pourquoi le statut de freelance est particulièrement adapté aux développeurs et aux métiers de l’IT

En décrivant le marché du développement logiciel et ses limites actuelles, Emilien nous explique pourquoi les freelances y ont toute leur place et en quoi cette alternative est gagnant-gagnant, autant pour les développeurs que pour les entreprises clientes.

Quels sont les avantages et motivations qui pourraient nous pousser à passer à notre compte, et quelles sont les différences par rapport au salariat

Cette partie balaye un certain nombre d’idées reçues sur les freelances, et compare ce statut avec celui d’un salarié, notamment sur le plan pécuniaire.

Comment opérer sereinement la transition

Ce chapitre distille de précieux conseils pour se lancer et se donner les moyens de réussir dans toutes les étapes de cette nouvelle aventure : démission, personal branding, négociation, etc.

Les bases juridiques et administratives pour gérer son entreprise

Cette partie plus technique que les autres est indispensable, car elle fournit quelques bases juridiques pour les entrepreneurs en herbe. Mais surtout, elle permet de réaliser que les connaissances nécessaires pour se lancer ne sont pas si compliquées et nombreuses que cela.

Comment s’épanouir dans son métier

Equilibre professionnel / personnel, qualité de vie, organisation personnelle, veille technologique, réseautage, communautés et télétravail y sont ici abordés. Cette partie est sans doute la moins spécifique aux indépendants et peut concerner n’importe quel travailleur dans l’informatique. L’auteur nous partage ses conseils concernant notre recherche d’accomplissement personnel au travers de notre profession, mais pas seulement. En effet, la grande majorité des thèmes abordés sont des étapes selon moi indispensables pour être un bon professionnel.

C’est probablement la partie la plus importante du livre. Car le freelancing est justement une des solutions possibles (mais pas la seule) permettant d’atteindre ce but.

Une réflexion sur le métier de développeur

Pour finir, Emilien nous donne sa vision du métier de développeur à l’heure actuelle, et de ses limites. Manque de considération, préjugés, pression sociale, organisations pyramidales sont parmi les symptômes qui ankylosent notre secteur d’activité. Il nous explique pourquoi le fait d’être à son compte permet de changer la donne et contribue à faire évoluer les mentalités.

Mon avis

Ne tournons pas autour du pot : J’ai beaucoup aimé.

Cela dit, pour être honnête, il est probable que j’ai lu ce livre avec un biais de confirmation.

Sans le savoir, je me suis rendu compte au fur et à mesure de ma lecture, que Émilien et moi partagions beaucoup de valeurs sur le freelancing et le métier de développeur. Lire ce livre m’a conforté dans mes choix et donné de l’énergie pour essayer de faire encore mieux mon métier. La preuve, je relance ce blog qui n’avait pas bougé depuis 2 ans.

Les chapitres se lisent bien, le style d’écriture est agréable. On sent que l’auteur a fait un travail énorme de vulgarisation et de synthèse. Le livre est donc complet et accessible, tout en restant assez court. Je l’ai fini après quelques heures de lecture, donc cela ne demande pas un gros investissement de temps. On se rend aussi compte qu’un gros effort a été fourni pour donner de la consistance aux arguments développés sur chaque thème abordé, ce qui rend le tout d’autant plus pertinent.

Cependant, il faut savoir que le livre reste assez peu technique, notamment sur la partie entreprise.

Les personnes qui cherchent à obtenir plus d’informations sur le statut à choisir pour leur activité (Le sempiternel débat EURL vs. SASU vs. les autres statuts) avec leurs avantages et inconvénients n’en trouveront pas pendant leur lecture. De même, le livre ne contient pas d’astuces et avantages spécifiques aux indépendants, notamment sur la fiscalité et les régimes comme le RSI.

Je pense que c’est un parti pris de l’auteur, qui ne voulait pas aller trop loin sur une partie extrêmement complexe, qui n’est pas son principal domaine d’expertise.

Avec du recul, je me dis que ce n’était non plus l’objectif du livre, qui est de parler du freelancing dans sa globalité en tant que mode de vie tout en restant le plus accessible possible. Les statuts et autres spécificités ne sont que des détails d’implémentation, dont le choix n’a finalement pas tant d’importance que cela. Surtout qu’il existe des professionnels probablement plus compétents pour ce genre de conseils très techniques.

Sur la partie entreprise également, un paragraphe est consacré au choix du nom de la structure. J’aurais trouvé intéressant d’aborder brièvement l’INPI, en tant que solution facultative, mais intéressante, pour protéger sa marque et s’assurer qu’il n’y a pas de collision avec une marque existante.

Enfin, dans la partie qui parle de rémunération pour un TNS en EURL, la part des cotisations sociales est estimée à 30% environ. Je pense qu’il est intéressant de dire que ces cotisations sont généralement plus proches des 40% (les cotisations retraite de la CIPAV montent très vite), afin d’éviter de faire des estimations trop optimistes.

Ces remarques n’engagent que moi, et ne concernent que quelques pages du livre. Ces petits détails n’altèrent en rien sa qualité intrinsèque.

Faut-il acheter ce livre ?

En conclusion, je pense que toute personne qui veut en savoir plus sur le freelancing peut acheter cet ouvrage les yeux fermés. Il contient toutes les informations nécessaires pour aider et surtout rassurer ceux qui envisagent de sauter le pas.

Je pense également que ce livre est totalement adapté pour n’importe quel travailleur dans l’informatique. Les conseils et valeurs promulgués dans la plupart des chapitres sont tout à fait pertinents pour tout professionnel cherchant à s’améliorer et mieux vivre de son métier.

Cela permet aussi de mieux comprendre les personnes qui ont décidé de se lancer, les motivations qui les animent, et que ce n’est pas toujours une question d’argent.

Pour ceux qui sont déjà indépendants, cette lecture vous sera réconfortante, et vous aidera à déculpabiliser le cas échéant, quand certaines personnes vous perçoivent comme un mercenaire.

Un grand merci à Emilien pour ce travail qui contribuera sans doute à l’évolution des mentalités, petit à petit !

Programmation Fonctionnelle et Monads en Java

Fri, 01 Sep 2017 00:00:00 +0000

La programmation fonctionnelle (FP) a longtemps occupé une place relativement marginale dans le monde de l’entreprise, dominé par les langages impératifs (C, Java, C#, PHP…). Cependant depuis quelques années, ce paradigme de programmation se démocratise et gagne en popularité. Les projets en Scala se multiplient, et de nombreux langages impératifs traditionnels tels que Java ou Javascript s’enrichissent d’APIs se basant sur un certain nombre de concepts issus de la programmation fonctionnelle. Dans l’écosystème Java, la sortie du JDK 8 en 2014 et l’implémentation des lambdas a grandement contribué à populariser une composante majeure de la FP.

L’ajout progressif de concepts de la FP dans nos bonnes vieilles applications d’entreprise est une très bonne chose, et se combine plutôt bien avec les langages orientés Objet (OOP). Manipuler des fonctions pures, favoriser la récursivité dans nos algorithmes, retarder l’évaluation des instructions ou encore manipuler des objects immutables favorise l’écriture de programmes plus propres et mieux optimisés tout en limitant les effets de bord.

Encourager la programmation fonctionnelle grâce à des structures dédiées

Lorsque l’on s’intéresse un peu a la FP et l’OOP, on finit par entendre parler des Monads et de ses dérivées Functors ou Applicatives. Les Monads sont des structures de données répondant à un certain nombre de lois mathématiques (identité, associativité).

Pour donner la définition la plus large possible d’une Monad, on peut dire que ce sont des structures de données, avec un contexte et des comportements qui seront applicables sur les valeurs qu’elles encapsulent. Elles vont également permettre l’application et la composition de fonctions pures dans nos bons vieux langages impératifs orientés objets comme Java.

Elles apportent un cadre qui va permettre d’encourager le développeur à bénéficier des forces de la FP, et ainsi de limiter au maximum les effets de bords classiques amenés notamment par des changements d’états ou des scopes de variables non judicieux.

Par exemple, avec Optional de Java 8 (Spoiler : Optional est une représentation de la Monad Maybe) :

Optional<String> name = Optional.of(getName());

Ici, notre instance d’Optional contient non seulement la valeur de ma String, mais propose un certain nombre de comportements supplémentaires. Selon le contexte, getName() pourra contenir ou non une valeur.

Les Monads permettent donc d’ajouter du contexte a des valeurs ou des objets, tout en permettant un certain nombre d’opérations fonctionnelles telles que map, flatMap, orElse…

Dans cet article, je ne vais pas m’épancher plus sur les règles et avantages de la programmation fonctionnelle, ou encore sur la définition et règles d’une Monad, car de nombreux excellents articles existent déja sur le sujet. Je vous invite d’ailleurs à consulter les articles dans la section Bibliographie pour plus de détails.

Du coup, quel est le but de cet article ?

Une fois que l’on a plus ou moins compris la théorie, il peut être difficile de comprendre réellement comment et pourquoi les appliquer, notamment dans un langage comme Java. En effet, les Monads restent un concept, et ont un niveau d’abstraction assez élevé.

Je vais donc tenter d’expliquer ce que peuvent apporter la FP et les Monads avec un cas pratique simple en Java, et pourquoi utiliser plus souvent ces pratiques dans nos développements au quotidien peut être intéressant.

Cet exemple basique, partira d’une implémentation classique, puis nous y ajouterons progressivement des Functors, des Applicatives et enfin des Monads pour y exposer leurs bénéfices et leurs limites.

Cas d’utilisation

L’exemple tournera autour d’une classe POJO Item, qui représente un article d’un site ecommerce, avec son prix.

Ce POJO sera implémenté avec des champs privés et des getters/setters pour tous les champs. Cette implémentation est pour moi un code smell dans la plupart des cas (hors frameworks type Hibernate ou Jackson qui en ont besoin), mais elle est malheureusement la plus courante.

public class Item {
    private String name;
    private Price price;
    public Item(String name, Price price) {
        this.name = name;
        this.price = price;
    }
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
    public Price getPrice() {
        return price;
    }
    public void setPrice(Price price) {
        this.price = price;
    }

    static class Price {
        private String currency;
        private Integer amount;
        public Price(String currency, Integer amount) {
            this.currency = currency;
            this.amount = amount;
        }
        public String getCurrency() {
            return currency;
        }
        public void setCurrency(String currency) {
            this.currency = currency;
        }
        public Integer getAmount() {
            return amount;
        }
        public void setAmount(Integer amount) {
            this.amount = amount;
        }
    }
}

Notre cas d’utilisation sera le suivant :

En tant que vendeur, je veux appliquer un prix promotionnel temporaire avec une reduction de 5$ et l’afficher sur ma page web.

Exemple d’implémentation classique

Une implémentation classique pourrait être la suivante:

@Test
public void reduce_and_display_price_imperative_style() {
    Item item = new Item("book", new Item.Price("$", 50));

    item.getPrice().setAmount(item.getPrice().getAmount() - 5);
    String result = "price: " + item.getPrice().getAmount();

    assertThat(item.getPrice().getAmount()).isEqualTo(45); //mutated Price instance
    assertThat(result).isEqualTo("price: 45");
}

Le style du code utilisé dans cet exemple est volontairement grossier, mais malheureusement assez courant. Il y a bien d’autres facons d’implementer plus proprement ce cas d’utilisation.

On y voit des code smells, tels que des instances qui ont muté alors que ce n’est pas necessaire, ou encore de la répétition (item.getPrice().getAmount()). En plus d’être améliorable, ce code est plus exposé aux bugs et divers effets de bords.

Dans l’exemple suivant, je vais amener la notion de Functor. Ce Functor va amener un contexte supplémentaire sur notre montant, et encourager l’utilisation de fonctions sur notre Item.

Un Functor, c’est essentiellement une méthode fmap (ou simplement map), qui va nous permettre d’appliquer des fonctions au sein de notre structure de données.

Pour garder cet article le plus simple possible, nous allons utiliser un Functor volontairement minimaliste qui ne sait faire que des fmap : MyFunctor

Functors

Un Functor en Java est une implémentation de cette interface :

@FunctionalInterface
public interface Functor<A, F extends Functor> {
    <B> Functor<B, F> fmap(Function<? super A, ? extends B> fn);
}

Notre MyFunctor ressemble donc à ça…

public class MyFunctor<T> implements Functor<T, MyFunctor> {
    private final T value;
    private MyFunctor(T value) {
        this.value = Objects.requireNonNull(value);
    }
    public static <T> MyFunctor<T> of(T value) {
        return new MyFunctor<>(value);
    }
    public T get() {
        return value;
    }
    @Override
    public <B> MyFunctor<B> fmap(Function<? super T, ? extends B> fn) {
        B apply = fn.apply(value);
        return MyFunctor.of(apply);
    }
}

… Et va nous permettre de faire des traitements comme ceci :

@Test
public void reduce_and_display_price_functional_style() {
    Item item = new Item("book", new Item.Price("$", 50));

    MyFunctor<Item> functor = MyFunctor.of(item);

    String result = functor
        .fmap(Item::getPrice)
        .fmap(Item.Price::getAmount)
        .fmap(amount -> amount - 5)
        .fmap(p -> "price: " + p)
        .get();

    assertThat(item.getPrice().getAmount()).isEqualTo(50); // we prevent Price mutation
    assertThat(result).isEqualTo("price: 45");
}

Nous avons donc exactement le même résultat qu’avant, sauf que ce dernier a été calculé avec un enchaînement de fonctions pures.

Nous bénéficions donc de la puissance de la FP (immutabilite, limitation des effets de bord, parallélisation, composition…) pour un code plus propre et moins exposé aux erreurs.

Il est malgré tout important de préciser que de faire de la FP n’est pas une balle d’argent. Il est parfaitement possible de ne pas l’utiliser convenablement, et d’avoir des alternatives impératives bien meilleures. Mais je le répète, cela apporte un cadre qui encourage plus volontiers à adopter une approche plus propre et robuste.

C’est exactement comme la classe Optional de Java 8. Très controversée, elle est pourtant intéressante lorsqu’elle est utilisée judicieusement. Au contraire, une mauvaise utilisation peut faire bien pire que mieux.

Cependant, les Functors montrent leurs limites, lorsque l’on souhaite mapper avec une fonction qui est elle-même boxée dans un Functor :

@Test
public void functors_cannot_fmap_on_functors() {
    Item item = new Item("book", new Item.Price("$", 50));

    MyFunctor<Item> functor = MyFunctor.of(item);
    // we want our discount function to be wrapped into a functor 
    MyFunctor<Function<Integer, Integer>> discount = MyFunctor.of(amount -> amount - 5);

    /*   String result = functor
                .fmap(Item::getPrice)
                .fmap(Item.Price::getAmount)
                .fmap(discount) // does not compile
                .fmap(p -> "price: " + p)
                .get();*/

    // Could not map MyFunctor(50) with MyFunctor(amount -> amount - 5), only accepts simple Functions, but not boxed Functions
    }

Cela ne compile pas. fmap n’acceptant que les Function simples, les Functors ne savent pas comment mapper appliquer une fonction boxée dans un Functor. C’est dommage, car Function est un type Java comme les autres, et peut parfaitement être wrappé dans notre Functor pour profiter de son contexte.

Applicatives

C’est à ce moment que les Applicatives entrent en jeu. Grâce à leur méthode apply, Les Applicatives vont permettre d’appliquer des fonctions qui sont elles memes boxées dans un Applicative. Tout en gardant la puissance apportées par le fmap des Functors, car un Applicative est un Functor.

 public interface Applicative<A, App extends Applicative> extends Functor<A, App> {
     <B> Applicative<B, App> apply(Applicative<Function<? super A, ? extends B>, App> appFn);
 }
 

public class MyApplicative<T> implements Applicative<T, MyApplicative> {
     // In an Applicative, T could be a Function
     private final T value;
     private MyApplicative(T value) {
         this.value = Objects.requireNonNull(value);
     }
     public static <T> MyApplicative<T> of(T value) {
         return new MyApplicative<>(value);
     }
     public T get() {
         return value;
     }
     //applicative apply : A<T> -> A(T -> U) -> A<U>
     @Override
     public <B> MyApplicative<B> apply(Applicative<Function<? super T, ? extends B>, MyApplicative> appFn) {
         //appFn is an Applicative which contains a function
         Function<? super T, ? extends B> applicativeFunction = ((MyApplicative<Function<? super T, ? extends B>>) appFn).value;
         return MyApplicative.of(applicativeFunction.apply(this.value));
     }
     //functor fmap : F<T> -> (T -> U) -> F<U>
     // fmap is a subset of apply
     @Override
     public <B> MyApplicative<B> fmap(Function<? super T, ? extends B> fn) {
         return apply(MyApplicative.of(fn));
     }
 }

Grâce aux Applicatives, nous allons pouvoir faire passer le test qui nous bloquait précédemment :

    @Test
    public void applicative_can_apply_boxed_functions() {
        Item item = new Item("book", new Item.Price("$", 50));

        MyApplicative<Item> applicative = MyApplicative.of(item);
        MyApplicative<Function<? super Integer, ? extends Integer>> discountApplicative = MyApplicative.of(amount -> amount - 5);

        // can also fmap because Applicative is a functor - fmap is a subset of apply.
        String result = applicative
                .fmap(Item::getPrice)
                .fmap(Item.Price::getAmount)
                .apply(discountApplicative)
                .fmap(p -> "price: " + p)
                .get();

        assertThat(result).isEqualTo("price: 45");
    }

apply acceptant en paramètre un Applicative, nous pouvons désormais y wrapper à loisir des valeurs et des fonctions, et les combiner. Cela commence à devenir intéressant ! Malheureusement, apply possède aussi sa limitation :

    @Test
    public void applicative_cannot_apply_on_functions_which_return_applicatives() {
        Item item = new Item("book", new Item.Price("$", 50));

        MyApplicative<Item> applicative = MyApplicative.of(item);
        MyApplicative<Function<? super Integer, ? extends Applicative>> discountApplicative = MyApplicative.of(amount -> MyApplicative.of(amount - 5));

        // can also fmap because Applicative is a functor - fmap is a subset of apply.
        String result = applicative
                .fmap(Item::getPrice)
                .fmap(Item.Price::getAmount)
                .apply(discountApplicative)
                .fmap(p -> "price: " + p)
                .get();

        assertThat(result).isNotEqualTo("price: 45"); // result is like price: com.spe.applicative.MyApplicative@2a33fae
    }   

Aie ! Dans notre test ci-dessus, on tente d’utiliser apply sur un Applicative qui contient une fonction qui retourne un autre Applicative. Cela compile, mais cela interrompt l’enchainement des fonctions, puisque les prochains fmap ou apply seront appliqués sur un Applicative<Integer> plutôt qu’un Integer. Dans notre exemple, on pourrait s’en sortir avec un discountApplicative.get() mais la présence d’une méthode qui retourne la valeur brute contenue dans l’Applicative n’est pas toujours garanti et pertinent.

Monads

Les Monads sont la solution à tous nos problèmes :

public interface Monad<T> {

    // monads have 3 fundamental operations :
    // return : T1 -> M<T1>
    // unbox : M<T> -> T
    // bind : M<T> -> (T -> M<U>) -> M<U>

    // Monad unbox : M<T> -> T
    public T get();
    // monad bind : M<T> -> (T -> M<U>) -> M<U>
    <U> Monad<U> bind(Function<? super T, Monad<U>> mapping);
    // a monad is a functor so it can also fmap
    <U> Monad<U> fmap(Function<? super T, ? extends U> fn);
}  

La méthode bind prend la valeur boxée et retourne une nouvelle Monad avec une nouvelle valeur boxée. A présent, nous allons pouvoir à loisir chaîner toutes les fonctions que l’on souhaite, même si celles-ci renvoient une Monad du même type ou bien des Monads covariantes.

Nous allons illustrer ce comportement avec un Optional simplifié, avec 2 Monads : MyPresentMonad et MyEmptyMonad :

public interface MyOptionalMonad<T> extends Monad<T> {

}

public class MyPresentMonad<T> implements MyOptionalMonad<T> {

    private final T value;

    private MyPresentMonad(T value) {
        this.value = Objects.requireNonNull(value);
    }
    // Monad return : T1 -> M<T1>
    public static <T> MyPresentMonad<T> of(T value) {
        return new MyPresentMonad<>(value);
    }
    // Monad unbox : M<T> -> T
    public T get() {
        return value;
    }
    // monad bind : M<T> -> (T -> M<U>) -> M<U>
    @Override
    public <U> Monad<U> bind(Function<? super T, Monad<U>> mapping) {
        return mapping.apply(value);
    }
    // fmap is a subset of bind
    @Override
    public <U> Monad<U> fmap(Function<? super T, ? extends U> fn) {
        return bind(fn.andThen(x -> MyPresentMonad.of(x)));
    }
}

public class MyEmptyMonad implements MyOptionalMonad {

    public static final MyEmptyMonad INSTANCE = new MyEmptyMonad();

    private MyEmptyMonad() {
    }

    @Override
    public MyEmptyMonad bind(Function fn) {
        return INSTANCE;
    }
    @Override
    public MyEmptyMonad fmap(Function fn) {
        return INSTANCE;
    }
    @Override
    public MyEmptyMonad get() {
        return INSTANCE;
    }
}

Désormais, sky is the limit. Notre test qui bloquait précédemment répond à notre besoin :

    @Test
    public void monad_can_bind_on_other_monads_of_same_type() {
        Item item = new Item("book", new Item.Price("$", 50));

        MyPresentMonad<Item> monad = MyPresentMonad.of(item);
        Function<Integer, Monad<Integer>> discountFunction = amount -> MyPresentMonad.of(amount - 5);

        // can also fmap because Monad is a functor - fmap is a subset of bind.
        Monad result = monad
                .fmap(Item::getPrice)
                .fmap(Item.Price::getAmount)
                .bind(discountFunction)
                .fmap(p -> "price: " + p);

        assertThat(result.get()).isEqualTo("price: 45");
    }

Nous pouvons désormais appliquer des fonctions sur :

des Functions simples
des Functions boxées dans des Monads
des Monads qui contiennent des Functions retournant une Monad du même type, et même des Monads covariantes !

Ce dernier exemple, qui va renvoyer un MyEmptyMonad, l’illustre très bien :

@Test
public void monad_can_bind_even_on_covariant_monads() {
    Item item = new Item("book", new Item.Price("$", 50));

    MyPresentMonad<Item> monad = MyPresentMonad.of(item);

    Function<Integer, Monad<Integer>> emptyFunction = amount -> MyEmptyMonad.INSTANCE;

    Monad emptyResult = monad
            .fmap(Item::getPrice)
            .fmap(Item.Price::getAmount)
            .bind(emptyFunction)
            .fmap(p -> "price: " + p);

    assertThat(emptyResult.get()).isEqualTo(MyEmptyMonad.INSTANCE);
}

Peu importe le type de fonction ou le type de Monad renvoyée, il est désormais possible d’appliquer les fonctions de notre choix, indépendamment du type de la Monad renvoyée.

Faites plus de programmation fonctionnelle !

La programmation fonctionnelle prend de plus en plus de place, notamment en Java, et on comprend pourquoi.

Au delà des lambdas, le JDK 8 propose son lot de Monads comme Optional ou Stream. Elles possèdent leur contexte propre (présence ou non de valeur, gestion des collections avec évaluation paresseuse), et permettent d’y appliquer des fonctions indépendamment de leur type ou du résultat de la précédente opération. Notamment grâce aux méthodes map (fmap des Functors) et flatMap (bind des Monads), accompagnées d’opérations spécifiques à leur contexte propre (ifPresent ou orElse pour les Optional)

Grâce à leur puissance et leur concision, ces 2 classes sont devenus incontournables pour les développeurs Java 8. Cela nous permet de réaliser à quel point il est intéressant de faire plus de programmation fonctionnelle et d’implémenter plus de Monads en Java.

Sachant cela, et même si Java n’est pas le langage le plus adapté pour profiter au maximum du potentiel des Monads, il y a largement de quoi faire pour rendre notre code plus propre encore, et cela vous inspirera peut-être pour créer vos propres Functors/Applicatives/Monads pour les besoins de vos projets et ainsi faire profiter vos applications métier de leur puissance indéniable !

Bibliographie

Voici des articles que je recommande pour bien comprendre le sujet:

Hibernate: Maîtrisez le débit et les performances de vos requêtes SQL

Toujours penser SQL d’abord

La configuration des entités Hibernate

Soyez paresseux !

Autres optimisations

La responsabilité des entités Hibernate

Les requêtes HQL

En cas de doute, affichez et vérifiez régulièrement les requêtes SQL générées

Pensez à consulter le blog de Vlad Mihalcea

Un outil difficile d’accès mais qui reste très pratique

Devenir parent en étant indépendant : Retour d'expérience et optimisations fiscales

Congé parental

Prime de paternité

Sources officielles:

Chèques CESU

Sources officielles:

Mutuelle

Sources:

Le mot de la fin

Code Freelance, le livre qui démystifie le freelancing

De quoi parle ce livre exactement ?

Pourquoi le statut de freelance est particulièrement adapté aux développeurs et aux métiers de l’IT

Quels sont les avantages et motivations qui pourraient nous pousser à passer à notre compte, et quelles sont les différences par rapport au salariat

Comment opérer sereinement la transition

Les bases juridiques et administratives pour gérer son entreprise

Comment s’épanouir dans son métier

Une réflexion sur le métier de développeur

Mon avis

Faut-il acheter ce livre ?

Programmation Fonctionnelle et Monads en Java

Encourager la programmation fonctionnelle grâce à des structures dédiées

Du coup, quel est le but de cet article ?

Cas d’utilisation

Exemple d’implémentation classique

Functors

Applicatives

Monads

Faites plus de programmation fonctionnelle !

Bibliographie

Les Functors/Applicatives/Monads expliqués en images

Mieux comprendre les Applicatives

Mieux comprendre les Monads

Implémenter des Monads en Java

Les limites de Java