Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 85 sur 185 PremièrePremière ... 3575777879808182838485868788899091929395135 ... DernièreDernière
Affichage des résultats 2 521 à 2 550 sur 5543
  1. #2521
    Y'a Avast qui s'affole depuis quelques jours quand je viens sur cette page.
    "Déconstruire", c'est "détruire" en insérant des "cons".
    Battle.net (Diablo 3) : Fbzn#2658 ----- / ----- / ----- Steam ID

  2. #2522
    Citation Envoyé par Teocali Voir le message
    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.

  3. #2523
    Citation Envoyé par vectra Voir le message
    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.
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  4. #2524
    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...

  5. #2525
    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
    "Déconstruire", c'est "détruire" en insérant des "cons".
    Battle.net (Diablo 3) : Fbzn#2658 ----- / ----- / ----- Steam ID

  6. #2526
    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.
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  7. #2527
    Citation Envoyé par Teocali Voir le message
    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).
    Dernière modification par gros_bidule ; 17/09/2019 à 00h31.

  8. #2528
    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 ?

  9. #2529
    Citation Envoyé par deathdigger Voir le message
    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.
    Attention, un Max_well peut en cacher un autre
    Equipe Highlander La Rache

  10. #2530
    Citation Envoyé par war-p Voir le message
    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...

  11. #2531
    Citation Envoyé par Max_well Voir le message
    Un tag sur ta V1. Tu peux créer une branche à partir du tag à tout moment si besoin.
    Faut que je regarde ça, merci.

  12. #2532
    Citation Envoyé par Max_well Voir le message
    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.

  13. #2533
    Citation Envoyé par gros_bidule Voir le message
    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.

  14. #2534
    Citation Envoyé par gros_bidule Voir le message
    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 ?

  15. #2535
    Citation Envoyé par war-p Voir le message
    Tu connais d'autres méthodes ?
    Tu fais tout dans Master. Plein de gens font ça.

  16. #2536
    Citation Envoyé par GrandFather Voir le message
    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.
    Sleeping all day, sitting up all night
    Poncing fags that's all right
    We're on the dole and we're proud of it
    We're ready for 5 More Years

  17. #2537
    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

  18. #2538
    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.
    Sleeping all day, sitting up all night
    Poncing fags that's all right
    We're on the dole and we're proud of it
    We're ready for 5 More Years

  19. #2539
    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.
    Dernière modification par gros_bidule ; 19/09/2019 à 19h07.

  20. #2540
    Citation Envoyé par gros_bidule Voir le message
    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... )
    La programmation est une course entre le développeur, qui s’efforce de produire des applications à l’épreuve des imbéciles, et l’univers qui s’efforce de produire de meilleurs imbéciles... L’univers a une bonne longueur d’avance !!!

  21. #2541
    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

  22. #2542
    Citation Envoyé par gros_bidule Voir le message
    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"
    La programmation est une course entre le développeur, qui s’efforce de produire des applications à l’épreuve des imbéciles, et l’univers qui s’efforce de produire de meilleurs imbéciles... L’univers a une bonne longueur d’avance !!!

  23. #2543
    git commit --fixup c'est bien aussi

  24. #2544
    Citation Envoyé par vectra Voir le message
    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 ?

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

  26. #2546
    Citation Envoyé par gros_bidule Voir le message
    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 ?
    Dernière modification par Teocali ; 23/09/2019 à 09h30.
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  27. #2547
    Je vois pas trop ce qui te choque en fait
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  28. #2548
    Citation Envoyé par TwinBis Voir le message
    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é.
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  29. #2549
    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)

  30. #2550
    Citation Envoyé par Teocali Voir le message
    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.

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •