KrISS feed 8.7 - A simple and smart (or stupid) feed reader. By Tontof
  • Thursday 03 May 2018 - 08:46

    Cela fait un moment que je n’avais pas fait de retour l’événement annuel des développeurs en France : Devoxx France 1 2 3.

    Depuis 3 ans, cette conférence a deux facettes pour moi : en tant que conférencier et orateur.

    Mon programme

    Voici les conférences auxquelles j’ai pu assister :

    Les quickies sont souvent super intéressants mais j’avais envie de prendre le temps de manger et faire une coupure dans ces journées marathon. Alors je n’en ai suivi aucun… :-/ Vu le format, c’est assez facile à regarder sur la liste officielle des Quickies de Devoxx France 2018.

    Ma conférence

    C’est la 3e année que je postule et que j’ai la chance de présenter un sujet ! Je n’ai jamais pris le temps de partager sur cette expérience mais c’est très enrichissant sur plein de points de vue. Je pense que je pourrais écrire des pages et des pages sur le sujet mais je ne trouve pas le temps…

    Comme il y a 3 ans avec RAML, je propose un sujet sur Open API sans trop y croire… Le sujet est accepté à ma grande surprise (1re épisode) ! J’avais un autre sujet qui me tenait plus à cœur sur le traitement d’image et qui était en liste d’attente. Mais il n’est finalement pas passé.

    Pour revenir sur le sujet initial, c’est la première fois que je faisais une telle présentation en binome (hors meetup local). C’est une expérience différente avec ses avantages et inconvénients. Hormis les séances de répétition classiques, nous avons eu l’occasion de la dérouler 2 fois en public (pour le BreizhCamp et Codeurs en Seine). Ce qui apporte un confort non négligeable.

    Quelques jours avant Devoxx France, j’apprends que nous passerons dans l’amphi principal. Le sujet intéresse beaucoup de monde à ma grande surprise (2e épisode) !

    La session se déroule comme prévu et sans mauvaise surprise. Pas de question à la fin de la présentation mais une demie douzaine dans le couloir à la sortie. Un public timide ? 🙂

    Pour être franc, je trouve qu’il manque quelque chose à cette présentation mais je ne sais pas quoi… De plus, si je devais la refaire, je choisirais une autre forme : un live coding ?

    Le mot de la fin

    Comme chaque année, on rentre de Devoxx France avec plein d’idées et d’outils à tester.
    Comme chaque année, on rentre de Devoxx France avec l’envie d’y retourner l’année suivante.
    Comme chaque année, on rentre de Devoxx France avec le secret espoir de pouvoir présenter à nouveau un sujet.

    Un grand bravo aux organisateurs, à l’équipe, aux sponsors, aux hôtes, aux speakers et aux participants ! A l’année prochaine !


    © SeB for Le weblogue de SeB, 2018. | Permalink | No comment

    Add to del.icio.us

    Search blogs linking this post with Technorati

    Want more on these topics ? Browse the archive of posts filed under Développement, Java EE.

  • Thursday 14 June 2018 - 08:28

    Continuons notre série d’articles sur Git – le b.a.-ba.

    Quand vous travaillez dans un dépôt Git, vous avez parfois besoin de sauvegarder votre travail en cours sans forcément le commiter. Ceci est possible avec le remisage et la commande git stash.

    Jusqu’à présent je n’utilisais que 2 commandes pour le remisage :

    # remiser le travail en cours
    $ git stash
    
    # retourner dans la dernière version de travail
    $ git stash pop
    

    Ce sont vraiment les 2 lignes de commandes minimales à connaitre. Mais quand on multiplie les branches et surtout les interruptions (ie. les tâches en parallèle), il est nécessaire de mieux connaitre le fonctionnement du remisage et les commandes utiles.

    Sauvegarder et mettre de côté les modifications

    Nous venons de le voir, un simple git stash fera l’affaire. Après avoir exécuté cette commande, toutes vos modifications disparaissent de votre espace de travail.

    Restaurer les dernières modifications

    Si on souhaite seulement restaurer les dernières modifications, il faut alors procéder à un git stash apply. Dans ce cas, vos modifications seront de nouveau présentes dans votre espace de travail. Et elles sont également toujours sauvegardées. Vous pourrez donc les appliquer de nouveau plus tard si besoin.

    Ce qui est intéressant ici, c’est qu’il est possible d’appliquer la modification à une autre branche que la branche sur laquelle a été faite la modification à l’origine.

    De plus, par défaut, seules les modifications sont appliquées. Si vous aviez des indexations en cours lors du remisage, il est possible de les restaurer également avec l’option --index et donc de cette façon git stash apply --index.

    Lister les modifications sauvegardées

    Pas de suspens. Il faut faire un git stash list pour avoir la liste de vos modifications enregistrées.

    Nommer une modification

    En multipliant les modifications, il va être rapidement nécessaire de pouvoir les identifier rapidement. Heureusement pour nous, il est possible de nommer une modification lors du remisage avec la commande git stash save "test du nouveau framework JS à la mode".

    Restaurer une modification en particulier

    La liste des remisages retourne un identifiant de la forme stash@{N}. Il est possible de restaurer une modification en particulier à partir de cet identifiant avec la commande suivante git stash apply stash@{0}.

    Consulter une sauvegarde

    Vous souhaitez vérifier le contenu d’une sauvegarde avant de l’appliquer ? Rien de plus simple avec git stash show stash@{0} qui retournera l’équivalent d’un git diff --stat. Si vous souhaitez obtenir le contenu des modifications (comme avec git diff), il faut alors ajouter l’option -p comme ceci : git stash show -p stash@{0}.

    Supprimer une sauvegarde

    Le dernier remisage peut être supprimé avec la commande git stash drop. Si vous souhaitez supprimer une sauvegarde en particulier, il faut alors préciser son identifiant : git stash drop stash@{0}.

    Restaurer et supprimer une sauvegarde

    On retrouve ici la commande de base git stash pop qui vous permet d’appliquer votre modification précédemment sauvegardée tout en l’oubliant.

    Créer une branche à partir d’une sauvegarde

    Vous aviez mis de côté une modification et maintenant vous devez vous remettre dessus et même créer une branche spécifique ? Rien de plus simple avec git stash branch stash@{0}.

    Annuler une restauration

    Imaginons que vous avez restauré une modification sur laquelle vous réalisez d’autres modifications. Puis arrive un moment où vous souhaitez annuler seulement les modifications de la remise mais pas celles qui ont suivi. Vous suivez ? Ceci est possible en chainant 2 commandes git : git stash show -p stash@{0} | git apply -R.

    Aller plus loin

    Comme vous avez pu le constater, un “stash” se manipule comme un commit. vous pouvez donc y appliquer les mêmes opérations telles que merge, patch, checkout, etc…

    Sans pousser une utilisation aussi avancée, vous avez maintenant toutes les clés pour gérer vos différentes modifications concurrentes sans avoir à créer des branches ou faire des commits pour rien.


    © SeB for Le weblogue de SeB, 2018. | Permalink | No comment

    Add to del.icio.us

    Search blogs linking this post with Technorati

    Want more on these topics ? Browse the archive of posts filed under Développement, Non classé.