Le topic de la programmation: Et envoyez des sioux!

**FB74** · 16/09/2019, 11h02

Y'a Avast qui s'affole depuis quelques jours quand je viens sur cette page.

**vectra** · 16/09/2019, 11h24

Envoyé par Teocali

1ere nouvelle... Tu as des sources la dessus ? Vrai question, parce que j'ai un passif de consultant Atlassian, et j'aime me tenir au courant.

https://confluence.atlassian.com/jir...800307235.html
Je sais pas si toute la suite est dispo, mais je me souvenais de ça au moins.

Sur le principe, c'est pas déconnant: je vois mal Arbuste ou Boing exécuter des boîtes noires sur leurs serveurs.

**Teocali** · 16/09/2019, 12h14

Envoyé par vectra

https://confluence.atlassian.com/jir...800307235.html
Je sais pas si toute la suite est dispo, mais je me souvenais de ça au moins.

Sur le principe, c'est pas déconnant: je vois mal Arbuste ou Boing exécuter des boîtes noires sur leurs serveurs.

oeuf corse : ça rentre dans la catégorie bonne raison et pognong.

Mais j'avoue, je pensais pas que c'était faisable dès que tu avais une "simple" license commerciale. Je me coucherais moins con ce soir.

**vectra** · 16/09/2019, 12h17

Perso, je t'avoue que je n'ai pas du tout besoin de ce genre d'assurance.
Mais visiblement, les gros clients d'Atlassian, oui...

**FB74** · 16/09/2019, 20h11

Pas exactement de la prog, mais des livres traitant de la certification réseau/ sécurité:
https://www.humblebundle.com/books/n...cation-2-books

**Teocali** · 16/09/2019, 22h09

Bon, les gens, question :

Je suis a l'heure actuelle en train de bosser sur une app web/rest en Java que je réecris en Kotlin, et cette même application va donc chercher ses données dans une BdD relationnelle.
Par reflexe, et pour gagner du temps, j'ai donc utilisé Hibernate, couplé a Spring Data pour effectuer mes accès base de données.

Mais bon, plus ça avance, et plus je me demandes si ça reste la meilleure solution, parce que bon, faut pas se leurrer, Hibernate, y'a des fois, en terme de génération de requêtes, il est un peu au fraises en terme de performance, sans compter que les mecs derrière ont pas l'air trop décidé de sauter sur Kotlin, au contraire des mecs de Spring. J'ai donc commencé à me pencher sur les alternatives à Hibernate : JOOQ, Exposed, Requery, etc. Pas mal de truc sexy pour mon usage (tel que la gestion des Upsert chez Requery), mais un truc me bloc : J'ai l'impression qu'aucune de ces solutions ne propose une validation du schema à l'execution. Hors, vu le contexte chez moi (pas mal de modification et de migration DB, de manière fréquente et assez extensive), c'est une fonctionalité dont je ne peux pas vraiment me passer.

Donc voila, si vous une solution Kotlin (idéalement) ou Java qui permettent de faire de l'ORM avec une validation du schema DB au démarrage, je suis interessé.
Ah oui, et dernier point, une entité ne doit pas hériter d'une classe ou implémenter une interface spécifique pour fonctionner. ça écarte KTorm, par exemple.

**gros_bidule** · 17/09/2019, 00h10

Envoyé par Teocali

Bon, les gens, question :

Je suis a l'heure actuelle en train de bosser sur une app web/rest en Java que je réecris en Kotlin, et cette même application va donc chercher ses données dans une BdD relationnelle.
Par reflexe, et pour gagner du temps, j'ai donc utilisé Hibernate, couplé a Spring Data pour effectuer mes accès base de données.

Mais bon, plus ça avance, et plus je me demandes si ça reste la meilleure solution, parce que bon, faut pas se leurrer, Hibernate, y'a des fois, en terme de génération de requêtes, il est un peu au fraises en terme de performance, sans compter que les mecs derrière ont pas l'air trop décidé de sauter sur Kotlin, au contraire des mecs de Spring. J'ai donc commencé à me pencher sur les alternatives à Hibernate : JOOQ, Exposed, Requery, etc. Pas mal de truc sexy pour mon usage (tel que la gestion des Upsert chez Requery), mais un truc me bloc : J'ai l'impression qu'aucune de ces solutions ne propose une validation du schema à l'execution. Hors, vu le contexte chez moi (pas mal de modification et de migration DB, de manière fréquente et assez extensive), c'est une fonctionalité dont je ne peux pas vraiment me passer.

Donc voila, si vous une solution Kotlin (idéalement) ou Java qui permettent de faire de l'ORM avec une validation du schema DB au démarrage, je suis interessé.
Ah oui, et dernier point, une entité ne doit pas hériter d'une classe ou implémenter une interface spécifique pour fonctionner. ça écarte KTorm, par exemple.

Kotlin et Hibernate : de mémoire, il y a des librairies qui permettent d'améliorer le support de Kotlin dans Hibernate, ou Spring Data, je ne sais plus. L'un des deux en tous cas qui permet de travailler avec des classes par défaut immutables de Kotlin (vu qu'à la base, Hibernate n'aime pas ça), de la même manière que l'on a une lib pour le support JSON avec Jackson + Kotlin.
Fais gaffe aussi aux quelques bugs connus pour le couple Kotlin + Hibernate. Il faut en avoir conscience sous peine de péter un câble si tu fais des choses un peu tricky.

Autre chose qu'Hibernate : si c'est la magie / boite noire d'Hibernate qui t'embête, tant pour te prendre la tête avec le cache, les relations qui font des noeuds dans le cerveau, ou les requêtes générées pas fofoles, je ne saurais que te conseiller d'aller voir du côté de Spring Data JDBC. Ca reste du Spring Data avec des repositories et entityManager, (tu pourras toujours écrire des requêtes natives à la main) mais sans la grosse surcouche habituelle de Spring Data + JPA/Hibernate (cache, etc). Ca semble être un bon compromis entre SQL à la main et Hibernate, en tous cas c'est ce qu'avançait le blog de Spring lorsque la lib a été lancée. Pourras-tu garder la validation du schéma au boot : là, j'ai pas vérifié.

Migration de base : tu fais ça avec Flyway ?

Et par curiosité, comment fais-tu la transcription Java -> Kotlin ? As-tu essayé la trad auto via IntelliJ ? Ca donne un résultat sympa ? (je ne l'ai essayé que sur du java desktop, avec grand succès, mais pas encore du Spring).
Le site de la conf Mix-It est en Spring + Kotlin, j'essaie de regarder le code pour repérer de bonnes pratiques (https://github.com/mixitconf/mixit).

**deathdigger** · 17/09/2019, 06h47

Imaginons que j'ai une appli en v1. Je fais plein de modifs, et pour garder une trace de la v1 (en cas de rollback), c'est quoi la bonne méthode avec Github ? Une branche v1.1 que je fous dans le master aussi ?
Les branches servent aussi à gérer les versions ?

**Max_well** · 17/09/2019, 10h35

Envoyé par deathdigger

Imaginons que j'ai une appli en v1. Je fais plein de modifs, et pour garder une trace de la v1 (en cas de rollback), c'est quoi la bonne méthode avec Github ? Une branche v1.1 que je fous dans le master aussi ?
Les branches servent aussi à gérer les versions ?

Un tag sur ta V1. Tu peux créer une branche à partir du tag à tout moment si besoin.

**vectra** · 17/09/2019, 12h48

Envoyé par war-p

Le nombre de places est limité

Je vais probablement m'inscrire; faut que je checke ma dispo avant.
Y'a encore 25 places, ça devrait aller...

**deathdigger** · 17/09/2019, 18h57

Envoyé par Max_well

Un tag sur ta V1. Tu peux créer une branche à partir du tag à tout moment si besoin.

Faut que je regarde ça, merci.

**gros_bidule** · 17/09/2019, 18h58

Envoyé par Max_well

Un tag sur ta V1. Tu peux créer une branche à partir du tag à tout moment si besoin.

Voilà.

Il faut aussi savoir qu'un tag sous Git, c'est une techniquement branche mais avec une symbolique différente.
Tu fais sois un tag v1 (mais ça sous-entend que tu ne feras plus de dev sur la v1, ce sera finalement une release), soit des branches. Et là, c'est l'occasion de choisir un modèle de gestion des branches : tu peux t'inspirer de gitflow (pour ne citer que celui-là), etc : ces méthodes ont le mérite d'avoir été pas mal challengées, et répondent plus ou moins bien à diverses problématiques et méthodes de travail.

**GrandFather** · 18/09/2019, 06h49

Envoyé par gros_bidule

Il faut aussi savoir qu'un tag sous Git, c'est une techniquement branche mais avec une symbolique différente.

Histoire de pinailler, je dirais l’inverse : une branche dans Git est techniquement un tag.

Pour une petite équipe qui débute sous Git, Gitflow est un excellent choix de modèle de branching. Le rôle de chaque branche est assez intuitif, et la discipline pour s’y tenir pas trop rigoureuse.

**war-p** · 18/09/2019, 07h58

Envoyé par gros_bidule

Voilà.

Il faut aussi savoir qu'un tag sous Git, c'est une techniquement branche mais avec une symbolique différente.
Tu fais sois un tag v1 (mais ça sous-entend que tu ne feras plus de dev sur la v1, ce sera finalement une release), soit des branches. Et là, c'est l'occasion de choisir un modèle de gestion des branches : tu peux t'inspirer de gitflow (pour ne citer que celui-là), etc : ces méthodes ont le mérite d'avoir été pas mal challengées, et répondent plus ou moins bien à diverses problématiques et méthodes de travail.

Tu connais d'autres méthodes ?

**GrandFather** · 19/09/2019, 07h31

Envoyé par war-p

Tu connais d'autres méthodes ?

Tu fais tout dans Master. Plein de gens font ça.

**Tramb** · 19/09/2019, 09h45

Envoyé par GrandFather

Tu fais tout dans Master. Plein de gens font ça.

OpenBSD fait bien du CVS avec une qualité bien supérieure à peu près tout ce qu'un canard aura jamais écrit, donc c'est sans doute pas un gros problème.

**Nattefrost** · 19/09/2019, 16h24

En parlant de VCS (et de *BSD), FreeBSD travaille sur un passage de SVN vers git https://www.developpez.com/actu/2757...ec-Subversion/

Ouais, je sais, developpez.com... J'ai pas retrouvé l'article en anglais ou j'avais vu l'info à l'origine

.

edit : ha ben oui voilà, merci Tramb

**Tramb** · 19/09/2019, 16h29

https://www.freebsd.org/news/status/...eBSD-Core-Team

The core team voted to appoint a working group to explore transitioning our source code 'source of truth' from Subversion to Git. Core asked Ed Maste to chair the group as Ed has been researching this topic for some time. For example, Ed gave a MeetBSD 2018 talk on the topic.
There is a variety of viewpoints within core regarding where and how to host a Git repository, however core feels that Git is the prudent path forward.

**gros_bidule** · 19/09/2019, 18h56

Et surtout avec Git (je ne sais pas si ça se fait aussi sous hg/svn/cvs/etc) : squashez vos merdes !

Nan, parce que quand on débute en informatique ou avec les VCS, on a tous un historique qui ressemble à ça :

Code:

fix jenknikns
fix jenkins 2
fix jenkins
fix test
test
test
test
+ doc
doc
fix 4 bon
revert fix 4
fix 4
fix 3
fix 2
fix save canards
feature jira-12345-coincoin

Alors qu'on pourrait regrouper tout ça dans un seul commit. Pour s'y retrouver quand tu voudras rechercher un commit, et pour travailler en équipe sereinement.
Le jour où on m'a appris à squasher, j'ai du faire "haaaa mais purée oui, oui oui oui !". Et travaillez sur vos branches, car squasher implique de réécrire l'historique, donc on évite sur les branches partagées type develop.

C'est aussi une bonne façon de se rappeler que Git (et n'importe quel autre VCS) n'est pas une solution de sauvegarde. Tu ne fais pas des commits réguliers juste pour sauver ton boulot, car en faisant ça tes commits n'auront plus aucun sens. Cela ne m'empêche pas de voir plein d'équipes avec comme guideline : "pensez à commiter souvent pour sauvegarder votre travail". C'est sans doute ce qui arrive quand le patron tarde à embaucher des dev expérimentés, et se dit que se reposer uniquement sur des ~~prostituées~~ jeunes diplômés, c'est aussi bien et moins cher. Bah nan, car le dev expérimenté il finit par arriver et il va jouer le pompier.

--

D'ailleurs, vous squashez comment vous ? En ligne de commande ou via un outil / IDE ?
J'aime bien le faire avec Smartgit (attention, payant si pro) : il a l'avantage de le faire très simplement (tu sélectionnes tes commit, Ctrl+J, et voilà), là où IntelliJ ne le propose que dans le cadre d'un rebase interactif.

**Mr Slurp** · 19/09/2019, 19h10

Envoyé par gros_bidule

D'ailleurs, vous squashez comment vous ? En ligne de commande ou via un outil / IDE ?
J'aime bien le faire avec Smartgit (attention, payant si pro) : il a l'avantage de le faire très simplement (tu sélectionnes tes commit, Ctrl+J, et voilà), là où IntelliJ ne le propose que dans le cadre d'un rebase interactif.

On utilise Bitbucket dans le cadre d'un partage de code avec une autre compagnie, et il peut faire les squash merge tout seul a partir d'une pull request. (à l'interne on est sur Perforce...

)

**gros_bidule** · 19/09/2019, 19h12

Haaa mais c'est pas mal ça !

On est aussi sous Bitbucket à mon taff, les jeunes n'aurons pas d'excuse pour ne pas squasher alors.
[edit] mais je suis bête, ils ne font pas de merge request

**Mr Slurp** · 19/09/2019, 19h38

Envoyé par gros_bidule

Haaa mais c'est pas mal ça !

On est aussi sous Bitbucket à mon taff, les jeunes n'aurons pas d'excuse pour ne pas squasher alors.
[edit] mais je suis bête, ils ne font pas de merge request

Tu peux interdire tout push dans develop/master (si ce n'est pas déjà fait), ils feront leur multiples push dans leur branch de dev, et la merge request étant rendu indispensable pour pousser dans develop, le squash sera fait "tout seul" (si ils oublient pas de cocher la case qui va bien, mais peut être que tu peux le définir comme obligatoire)

[edit]
ça ressemble à ca pour les persmissions

Et dans "Merge strategies" tu mets la valeur par défaut à "squash"

**Cwningen** · 19/09/2019, 19h45

git commit --fixup c'est bien aussi

**Nilsou** · 20/09/2019, 19h38

Envoyé par vectra

C'est gratuit, mais est-ce open-source?

Atlassian fournit ses sources si je me souviens bien (condition sine qua non pour se faire exécuter chez certains grands comptes).

Je ne sais pas si c'est open source mais pour le coups est-ce que ça a une utilité quelconque ?

**vectra** · 20/09/2019, 21h04

Dans les labos, y'a des fans du libre...
Du gratuit en tous cas

**Teocali** · 23/09/2019, 09h15

Envoyé par gros_bidule

Kotlin et Hibernate : de mémoire, il y a des librairies qui permettent d'améliorer le support de Kotlin dans Hibernate, ou Spring Data, je ne sais plus. L'un des deux en tous cas qui permet de travailler avec des classes par défaut immutables de Kotlin (vu qu'à la base, Hibernate n'aime pas ça), de la même manière que l'on a une lib pour le support JSON avec Jackson + Kotlin.

c'est un plugin a la compilation, qui rend la totalité des entités open (ie. non final) et leur rajoute un constructeur sans arguments. Je ne despère pas de voir une refonte d'Hibernate permettant de gérer les entités via les constructeurs, mais en attendant, ça marche bien.

Fais gaffe aussi aux quelques bugs connus pour le couple Kotlin + Hibernate. Il faut en avoir conscience sous peine de péter un câble si tu fais des choses un peu tricky.

Rien de tricky pour le moment, et ça va rester comme ça. Le tricky, ça devient nécessaire quand t'as pas le controle sur ton schema de BdD, et c'est pas le cas ici (merci Flyway pour le coup)

Autre chose qu'Hibernate : si c'est la magie / boite noire d'Hibernate qui t'embête, tant pour te prendre la tête avec le cache, les relations qui font des noeuds dans le cerveau, ou les requêtes générées pas fofoles, je ne saurais que te conseiller d'aller voir du côté de Spring Data JDBC. Ca reste du Spring Data avec des repositories et entityManager, (tu pourras toujours écrire des requêtes natives à la main) mais sans la grosse surcouche habituelle de Spring Data + JPA/Hibernate (cache, etc). Ca semble être un bon compromis entre SQL à la main et Hibernate, en tous cas c'est ce qu'avançait le blog de Spring lorsque la lib a été lancée. Pourras-tu garder la validation du schéma au boot : là, j'ai pas vérifié.

C'était une solution que j'avais en tête, mais pas de validation de schema, j'ai l'impression. Pour le moment, je reste donc avec Hibernate

Migration de base : tu fais ça avec Flyway ?

Yep. A mon sens, Liquibase n'a de réel interet que lorsque tu dois supporter plusieurs DB différente. Ce n'est pas le cas pour nous, donc Flyway.

Et par curiosité, comment fais-tu la transcription Java -> Kotlin ? As-tu essayé la trad auto via IntelliJ ? Ca donne un résultat sympa ? (je ne l'ai essayé que sur du java desktop, avec grand succès, mais pas encore du Spring).

A la mimine, comme un grand. Plus sérieusement, la totalité du code Java que j'ai récupéré doit être foutu a la benne a(le developpeur originel était resté bloqué en 1998. La première version des JSP est sorti en 1999 pour info...), donc quitte a le réécrire, autant le faire en Kotlin.
J'ai quand même du faire quelques transcription (genre copié-collé) et serieusement, ça marche bien.

Le site de la conf Mix-It est en Spring + Kotlin, j'essaie de regarder le code pour repérer de bonnes pratiques (https://github.com/mixitconf/mixit).

Je vais jeter un oeil. Deja, je vois qu'ils utilisent gulp, et je n'ai aucune idée de ce que c'est. quelque chose comme Jrebel ?

**Teocali** · 23/09/2019, 19h51

Je vois pas trop ce qui te choque en fait

**Teocali** · 23/09/2019, 22h57

Envoyé par TwinBis

C'est du Java écrit en Kotlin (comprendre: ce n'est pas du Kotlin idiomatique).

Ok. Je vois toujours pas en quoi c'est un problème.

En idiomatique ce serait ça:

L'avantage de cette syntaxe, c'est que le "it" dans ta lambda est automatiquement de type Language et pas [FONT=courier new]Language[B]

Non. le compilateur voit que tu as fait un null check et fait automatiquement la conversion dans le corps du if.
Avec ta solution, tu perds en lisibilité (ie. tu t'éloignes du langage humain) et tu n'as même pas l'avantage de la concision (même nombre de ligne) donc ici, la solution idiomatique n'a aucun avantages, et que des désavantages.
Sans compter la difficulté a débugguer le truc si tu n'as pas une bonne suite d'outils

Perso, je suis fan des idiomes de kotlin, mais faut les utiliser a bon escient. Si tu a deux manière de faire une chose, la solution idiomatique n'est pas forcément celle que tu dois choisir en premier. A plus forte raison si ça te faire perdre en lisibilité.

**TwinBis** · 24/09/2019, 09h04

Exact, mes excuses pour les conneries écrites sur le smart cast (qui se fait également avec un if classique en effet).

Après je préfère utiliser une seule manière de faire les choses dans une même base de code (en l'occurrence un null-check suivi de l'utilisation de la variable vérifiée), ça facilite la lecture et évite de se poser des questions une fois qu'on y est habitué.

Mais c'est tout à fait discutable comme point de vue.

- - - Updated - - -

Et le forum supprime les posts que j'ai tenté d'éditer. 0_o
(Je vais arrêter de poster depuis mon mobile je pense)

**gros_bidule** · 29/09/2019, 12h48

Envoyé par Teocali

Je vais jeter un oeil. Deja, je vois qu'ils utilisent gulp, et je n'ai aucune idée de ce que c'est. quelque chose comme Jrebel ?

Sur ce projet, ils gèrent à la fois le backend Java et le frontend JS, la communication entre les deux se faisant via api. Gulp c'est juste pour le frontend. Le build Gradle pilote les deux.

Discussion: Le topic de la programmation: Et envoyez des sioux!

Outils de la discussion

Règles de messages