Jean-Yves

Septième Semaine

2023-12-20T00:00:00+00:00

La maison d'Aurélie Valognes - extrait de carnet

Je reprends l'écriture après plus d'un an d'abscence, et je poste ce vieux billet en cours...

Un billet court pour cette septième semaine. J'ai eu une semaine chargée, avec un aller retour vers l'est sur trois jours, une bonne dose de train. On a beaucoup parlé d'intelligence artificielle et ce n'est pas pour me rassurer. Tout le monde utilise maintenant ce système sans se poser de questions. D'ailleurs c'est une de nos caractéristiques, je pense, de ne pas (trop) se poser de questions.
Qui organise ses vacances, qui corrige les fautes d'orthographes, qui fait écrire ses textes à sa place. L'IA a tout lu, et a tout vu, donc on peut lui faire faire a peu près n'importe quoi. L'expérience que j'en ai n'est pas si belle. Est-ce la fin de l'intelligence humaine ? En effet on peut imaginer que l'on ne crée plus rien puisqu'il suffit de le demander à l'IA, et donc l'IA, ne s'enrichit plus puisqu'on ne crée plus de savoir .... Affaire à suivre.

Un an après la situation ne s'amélioeere pas, voic @ploum La fin d'un monde ?</a>

A lire</h2>
Allez un petit lien pour se remonter le moral avec une citation que j'aime bien, "Ecrire du logiciel sans types permet d'aller à toute vitesse, a toute vitesse dans le mur" : "Writing software without types</a> lets you go at full speed. Full speed towards the cliff.
A tester 1</a></h2>
`jq</code> is a lightweight and flexible command-line JSON processor akin to sed</code>,awk</code>,grep</code>, and friends for JSON data. It's written in portable C and has zero runtime dependencies, allowing you to easily slice, filter, map, and transform structured data https://github.com/jqlang/jq`
`C'est à vous</h2>Le projet Common Voice</a> a besoin de voix</li> Depuis 31 ans, R.A.P. (Résistance Agression Publicitaire) lutte contre le système publicitaire sans relâche et avec détermination. En 2023, nous avons amplifié la lutte pour l’ouvrir sur de nouveaux horizons. Grâce à votre soutien</a>, nous pourrons mieux entamer les batailles à venir contre la pub en 2024.</li> </ul> ^{1 Testé avec succés pour récupérer du json en bash </div>}`

Ne Jamais dire Jamais 2023-12-15T00:00:00+00:00 Des tests, vous en reprendrez bien un bocal ? Lorsque l'on teste une méthode qui appelle un service en utilisant un mock, il est facile de vérifier qu'on appelle la bonne méthode avec les bons paramètres en utilisant la méthode verify de mockito</a>. Mais qu'en est-il lorsque l'on insère une condition qui implique que l'on ne doit pas appeler la méthode. La tentation est grande d'utiliser un verify avec le mode de vérification never. Exemple avec scalatest</a> : Le code à tester def addinfo(user: User): = { user.info foreach(i => infoManager.addInfo(user.name, i)) } </code></pre> Je vérifie ci dessous que je ne vais pas appeler la méthode addInfo d'infomanager "do not add information for a new user without info" in new Fixture { val service = ServiceFactory.create() val user = UserFactory.create(service.name).copy(info = None) userManager.addInfo(user, service) verify(infoManager, never()).addInfo(user.name, user.info) } </code></pre> Je me suis toujours posé la question de la pertinence de ce test, car imaginons que je transforme le code de la façon suivante. def addinfo(user: User): = { infoManager.addInfo(user.name, "What ?") } </code></pre> Lorsqu'on lance le teste précédent, le test passe, si user.info bien sûr n'est pas égal à "What ?". Lors de l'écriture du test, et si on le réalise en TDD, il y a peu de chance de tomber dans ce piège. Mais tout au long du projet, lorsqu'on va remanier le code, il y a des chances que l'on arrive à un cas similaire. Et dans ce cas le test en question ne teste plus rien. C'est toujours périlleux de tester qu'on ne fait jamais quelque chose. Heureusement il y a verifyNoInteractions</code> qui permet de vérifier qu'on a jamais d'interaction avec l'objet. Le même test avec verifyNoInteractions</code> "do not add information for a new user without info" in new Fixture { val service = ServiceFactory.create() val user = UserFactory.create(service.name).copy(info = None) userManager.addInfo(user, service) verifyNoInteractions(infoManager) } </code></pre> On peut aussi utiliser verifyNoMoreInteractions</code> lorsque l'on a dans le code d'autres interactions avec l'objet. En conclusion pour ma part j'éviterais le never</code> qui peut être délicat lors de refactoring au profit du verifyNoInteractions</code> en n'oubliant pas l'avertissement de la documentation</a> de ne pas systématiser l'utilisation de la méthode verifyNoMoreInteractions</code>. Sixième Semaine 2023-12-13T00:00:00+00:00 De la lumière dans l'hiver Sixième billet hebdomadaire, je tiens le rythme depuis la promesse que je me suis faite le 8 Novembre 2023</a>. Ce sera donc le dixième billet publié depuis cette date, soit un peu plus d'un billet par semaine. Il est encore trop tôt je pense pour dire si ma capacité d'écriture s'est améliorée, car une séance par semaine me paraît trop peu pour que cela fasse un entraînement efficace. Il n'empêche, le premier billet faisait un peu moins de 300 mots, maintenant j'écris plutôt un peu plus de 600 mots sans trop de problème ce qui fait une progression certaine. Une fois n'est pas coutume, j'ai noté cette semaine dans mon obsidian préféré, ce qui m'a marqué et je vous en ferai part à la fin de cette article. L'écriture</h2> Je reviens un peu sur mon process d'écriture. Je fais d'abord un premier jet à la volée, sans (trop) de corrections afin de ne pas perdre le fil de mes idées, et c'est efficace, car dés que je reviens en arrière le fil est coupé et le redémarrage est vraiment difficile, même si c'est compliqué de s'astreindre à laisser passer les fautes, les mal dits. Dans cette phase lorsque je ne suis pas sur d'une information ou d'un lien je la remplace par une série de XXX sur laquelle je reviendrai ensuite. Une fois l'article terminé, je fais une première relecture, je corrige principalement les fautes les plus évidentes quelques tournures de phrases. Je commence ensuite la mise en forme, j'ajoute les liens là ou c'est pertinent. Je reprends ensuite le texte et je le copie colle dans un correcteur d'orthographe en ligne qui me donne encore d'autres améliorations possible et des fautes qui m'ont encore échappées (Ah l'orthographe !). Pour terminer l'article, je choisis une photo dans ma galerie, et je l'ajoute à l'article avec un texte alternatif et un commentaire. Le travail est fait, il ne reste plus qu'à le publier en le 'poussant' sur Gitlab, le CI faisant le reste c'est à dire la mise en ligne. A lire aussi sur le sujet le blog de Thierry Crouzet, Edition la fin des correcteurs ?</a> Projets de la semaine</h2> Pas beaucoup de Scala cette semaine, j'ai terminé mon exploration Scala vers Java, en écrivant les parties les plus compliquées. Il reste maintenant la longue traversée du désert à faire, c'est à dire la réécriture des parties métiers et transformations de données. Java étant un langage pas mal plus verbeux que Scala, cela risque d'être un chemin assez ennuyeux. Maintenant par contre j'ai une assez bonne visibilité sur le travail qu'il reste à réaliser. Une semaine de documentation aussi ou j'ai découvert pandoc</a>. Le fait de documenter l'architecture du code m'a aussi permis de me poser des questions sur les chemins que j'ai choisi et m'a donné quelques pistes de remaniement de code assez profond. C'est donc un exercice que je vous recommande et qui permet de prendre un peu de recul sur ce que l'on a écrit. Au bout d'un an d'écriture, l'architecture mise en place au départ et qui paraissait pertinente, mérite à être questionnée. Je continue aussi d'approfondir mes connaissances sur le monde de la géomatique</a> au travers d'un projet de dessin géolocalisé au dessus d'images géo-référencées et de modèles numérique de terrain. J'ai passé de bons moments de collaboration avec la société 3liz</a> éditeur entre autre de Lizmap</a>. Une semaine découverte des possibilités étonnantes de PostGis</a> de QGIS</a> et de Lizmap qui mériterait je pense un petit article tellement il est facile de publier des cartes en exploitant les données ouvertes disponibles maintenant pour le public. Bravo en tout cas pour ce travail en Open Source A noter d'ailleurs entre autre de plus en plus de données mise à disposition comme par exemple la SNCF</a>, ou le project Plan de Corps de Rue Simplifié</a> ou encore la Plateforme ouverte des données publiques françaises</a>. On ne passe pas une semaine sans crayons et sans pinceaux, je poursuite ma découverte de l'aquarelle avec Jean-Marc Jezequel, à voir ici sur mon compte Pixelfed</a>. Lectures</h2> Je poursuis la lecture, sans trop d'enthousiasme d'un roman policier, par contre de belles lectures sur le web.\ Un article de Ploum, qui date un peu sur le silence au milieu du bruit</a> qui réfléchit sur la masse d'information qui nous assaille en permanence et surtout sur l'utilité et la qualité de cette information. Est-il nécessaire d'en rajouter, et pourquoi prendre la peine de rédiger ce blog en devenir ?</li> Dévendre la croissance</a> La décroissance n’est pas plus source d’appauvrissement que la croissance est source d’enrichissement de Thimothée Parrique</li> Bye bye WhatsApp, hello ?</a> A garder sous le coude pour alimenter les discussions que vous ne manquerez pas d'avoir pendant les fêtes autour de Whatsapp, Signal, Matrix, Telegram etc de Ivan Enderlin.</li> </ul> J'ai lu en Vrac</h2> Une alliance entre quelques grands groupes</a> autour de l'intelligence artificielle qui devrait empêcher une seule entreprise à dominer cette technologie. C'est un sujet qui me préoccupe de plus en plus.</li> Lynis</a> Une suite d'outils de consolidation des systèmes d'exploitation Linux au niveau de la sécurité en GPL. C'est aussi un sujet d'actualité dans mes pratiques quotidiennes.</li> On ne vous a jamais appris à écrire des logiciels de qualités par Florian Bellman. Quelques citations ci dessous qui résonnent en moi. "deliver software without bugs in time" "We need to speak about money. As developers, we need to speak about the cost of not doing QA. This is the language of business and managers in general" "I like the term 'minimal effective dose' (MED). The smallest dose that will produce the desired outcome"\ </blockquote> </li> </ul> A retenir</h2> Framasoft mobilizons nous</a>, cherche du monde pour continuer les développements de Mobilizon</a> un outil qui permet de trouver, créer et organiser des événements. Belle semaine à tous. Doc et Pdf sont dans un bateau 2023-12-12T00:00:00+00:00 Non la documentation n'est pas un casse croûte La documentation dans un projet</h2> Dans les projets auxquels je participe, j'aime bien mettre la documentation dans un répertoire doc, sous forme de fichiers markdown. Dans le readme.md, que l'on trouve traditionnellement à la racine du projet, on y met les informations essentielles pour bootstraper le projet dans un environnement de développement. En plus, ce que je fait d'habitude, c'est de mettre un lien dans ce fichier vers la documentation qui se trouve dans le fameux répertoire doc. L'avantage est que la documentation se retrouve au même endroit que le code, donc facile à mettre à jour et à maintenir. L'inconvénient est qu'il n'est pas facile de la transmettre ou de la publier. Suite à une demande d'un de mes clients, je me suis mis à la recherche d'une solution de transformation de ces fichiers vers du pdf. Il y a principalement trois solutions : Des sites spécialisés</li> Des extensions Visual Studio Code</li> Pandoc</li> </ul> Les sites spécialisés</h2> Il y en a pléthore, je ne m'étendrai pas sur cette solution, qui sont souvent une occasion de faire de la publicité, de générer des clicks et de récupérer au passage de l'information. Les extensions Visual Studio</h2> Visual Studio Code Markdown PDF</h3> Cette extension</a> utilise chromium pour faire la conversion et est assez longue à installer. Elle fonctionne parfaitement pour un fichier, mais ne possède pas (ou je ne l'ai pas trouvé.), de mode multi-fichiers. Il y a de plus une astuce pour l'utiliser sous wsl (Ah les bonheurs du développement sous windows) je vous la donne ci-dessous. L'extension nécessite pour fonctionner en remote wsl sous visual studio code l'installation des paquets suivants (sous ubuntu) : sudo apt-get install libxcursor1 sudo apt install libxss1 sudo apt install libpangocairo-1.0-0 sudo apt install libgtk-3-0 </code></pre> Une fois ces paquets installés, la conversion est utilisable et le résultat est plus que correct, mais mono fichier. Il faut donc faire un pdf par fichier, ce qui dans mon cas, car j'ai l'habitude de séparer les fichiers n'est pas la solution idéale. Pandoc</h3> Pandoc</a> est une solution 'Universelle de conversion de documents' comme indiqué sur leur site. C'est effectivement ce qui est le plus efficace même si vous allez le voir, cela demande un peu de préparation et de recherche. Pandoc est capable de transformer non seulement du markdown, mais aussi par exemple du reStructuredText, de l'AsciiDoc, etc... Tous ces formats peuvent être transformés soit en HTML, en PDF, en EPUB en Docx en wiki markup formats (MedaiWiki, DocuWiki) et beaucoup d'autres formats. Pandoc est écrit en Haskell, et c'est un utilitaire en ligne de commande. Vous écrivez un document sans (trop) vous occuper de la mise en page, et Pandoc, avec le paramétrage qui va bien s'occupe du reste. Exemple</h4> pandoc -s *.md doc/*.md -o projectdoc.pdf --from=markdown+rebase_relative_paths \ --toc --pdf-engine=xelatex -V mainfont="Ubuntu" --number-sections --metadata-file doc/metadata.yml </code></pre> -s : Les fichiers à transformer</li> -o : Le fichier résultat</li> --from=markdown+rebase_relative_paths : important garde les chemins relatifs de liens et des images</li> --toc : génère le sommaire, en parcourant la totalité des fichiers</li> --pdf-engine=xelatex : utilise un processeur pdf qui gère un peu mieux les polices de caractères.</li> -V mainfont="Unbuntu" : change la police par défaut (je n'aime pas trop visuellement la police utilisée par défaut)</li> --number-sections : Option magique qui numérote les têtes de chapitres, pas besoin de s'en occuper dans le texte</li> --metadata-file doc/metadata.yml, permet de gérer les options qui sauvent la mise en page sans alourdir la ligne de commande.</li> </ul> Comme je vous le disais précédemment la mise en oeuvre de l'outil n'est pas directe et nécessite pas mal d'essais et pas mal de lecture de documentation et d'articles sur son utilisation, mais le résultat est vraiment pas mal. Le fichier metadata.yml</h4> C'est un fichier de configuration qui permet de paramétrer le formatage du document. Je vous livre le mien --- title: Project documentation header-includes: | \usepackage{geometry} \geometry{ a4paper, left=15mm, top=20mm, right=15mm } \usepackage{fancyhdr} \pagestyle{fancy} \fancyhead[L]{\date{\today}} \fancyhead[C]{MYProject} \fancyhead[R]{\thepage} \usepackage{fvextra} \DefineVerbatimEnvironment{Highlighting}{Verbatim}{breaklines,commandchars=\\\{\}} </code></pre> Les options sont assez faciles à comprendre, et sont des options pour le processeur LaTex, a noter tout de même les deux dernières lignes qui permettent de gérer les retours à la ligne dans les blocs de code. Si vous avez de la doc à écrire, je vous conseille vraiment de vous pencher sur cet outil. Il y a beaucoup d'autres possibilités, qui lorsque l'on écrit de gros documents sont particulièrement utiles, comme par exemple la gestion des citations de la bibliographie. L'installation</h3> Sous ubuntu, le paquet de la distribution est trop ancien, je vous conseille donc de télécharger la dernière version ici</a>. Une fois le paquet télécharger l'installer sudo dpkg -i pandoc-3.1.9-1-amd64.deb</code>.\ Puis installer les paquets suivants: sudo apt install pdflatex sudo apt install texlive-latex-base sudo apt install texlive-latex-recommended sudo apt install texlive-xetex sudo apt install texlive-fonts-recommended texlive-fonts-extra texlive-latex-extra </code></pre> Références</h2> Quelques sites qui m'ont aidés Le site officiel de Pandoc</a></li> Redaction durable avec Pandoc et Markdown</a> du site Programming Historian</a></li> </ul> Cinquième Semaine 2023-12-06T00:00:00+00:00 L'éternité des vagues ARNOLPHE "Quelle nouvelle ?" AGNÈS "Le petit chat est mort." ARNOLPHE "C’est dommage : mais quoi Nous sommes tous mortels, et chacun est pour soi. Lorsque j’étais aux champs n’a-t-il point fait de pluie ?" AGNÈS "Non." Bon voyage au paradis des chats, après ce long voyage qui l'a menée des terres froides du Canada à notre beau pays de Bretagne, venteux, quelques fois humide, mais si lumineux. Que ces quelques fleurs de printemps que j'ai semé pour l'occasion t'accompagne ainsi que les fleurs de sauge et le saule que nous avons laissé pour toi. J'expérimente en ce moment un portage d'une application utilisant play framework de Scala</a> en Java</a>. Je ne m’étendrai pas sur les raisons qui ont poussé à faire cela, bien qu'on puisse légitimement se demander ce qui pousse les développeurs à ne pas sortir du Java pour essayer le Scala. Autant les démarrages sont assez facile, car on peut faire au début du java-scala, mais au fur et à mesure que l'on progresse, le fonctionnel prends le dessus et le code écrit est souvent relativement difficile à lire pour ceux qui ne sont pas familiers avec la tournure fonctionnelle. Cela mériterait, je pense un peu plus de développement, mais ce sera pour une autre fois. Pour le portage en Java je reste sur du Play Framework</a> version Java, un petit upgrade quand même du JDK et un passage vers des acteurs typés. L'expérience est intéressante et me pousse à trouver des solutions fonctionnelles en Java, comme par exemple l'Optional<T></code>. Première étape l'authentification en cours, la connexion LDAP est opérationnelle et je tente la suite qui est la mise en place d'un acteur qui gère la connexion vers un serveur de configuration Genesys. Affaire à suivre. Cela fait bien longtemps que je n'avais pas touché à ce langage, et cela fait du bien. J'ai travaillé cette semaine sur deux aquarelles que j'ai postées sur mon compte Pixelfed</a>. Par la même occasion, j'ai craqué pour la série d'Humble bundle</a> How to Start Drawing et j'ai aimé plus particulièrement dans cette série le livre de Veronica Lawlor One Watercolor a Day</a> qui rejoint à peu près ma conception de l'aquarelle. De l'eau de l'eau de l'eau. J'ai lu cette semaine une belle bande dessinée d'Etienne Davodeau</a> le Droit du sol</a> qui m'a fait réfléchir sur le facteur temps. A voir aussi le site d'Etienne</a>. L'auteur part de la grotte de Pech Merle</a> et, à pied, trace son chemin jusqu'à Bure, là ou nous projetons d'enfouir nos déchets nucléaires. Au-delà de la problématique du nucléaire et de ses déchets, se pose la question du temps. Les dessins des grottes préhistoriques, sont à peu près tout ce qui nous reste de cette époque, soit il y a à peu près 25 000 à 35 000 ans. Comment peut-on imaginer que dans 100 000 ans, oui vous avez bien lu cent mille ans, il y aura encore des traces utilisables des procédures et des précautions que nous devons suivre pour ce stockage hautement toxique? Dans un des entretiens racontés dans le livre, il évoque la pérennité des différents supports comme par exemple le papier, de l'écriture et la communication, des langues. J'ai beaucoup aimé son trajet, l'histoire qu'il nous raconte, les rencontres ainsi que les entretiens qu'il met en scène tout au long du voyage avec des personnages bien réels, mais qui l'accompagne sur la route en imagination. Merci pour ce livre. Ca donne envie de partir à pied. Que les prochains jours vous soient propices et à la semaine prochaine. Quatrième Semaine 2023-11-29T00:00:00+00:00 Zénitude des plantes Quatrième semaine, au moins je n'ai pas trop à réfléchir (pour l'instant) à trouver un titre. Je pourrais aussi appeler ce billet rétrospective de la semaine, car c'est un peu ce que je fais en général. Peu d'écriture cette semaine, une paire d'exercice seulement d'écriture à la volée pendant 15 mn avec un rythme de 500 mots par quart d'heure. J'ai aussi noté vous avez dû le remarquer, les heures sur ces billets hebdomadaires, cela me permet d'avoir une vision du temps que prends la rédaction d'un article pour le blog. En résumé, 15 minutes pour l'écriture des mots et environ trois quart d'heure pour le reste : édition, correction, choisir une photo, et remanier un peu (mais pas trop le texte). Oui j'aime bien les photos en entêtes de billets, et j'ai modifié le thème du site en conséquence, pour que la photo d'entête s'affiche dans la liste des billets et correctement aussi lors de la lecture, que ce soit sur grand écran ou sur un mobile. C'est d'ailleurs sur un mobile que je consulte les sites la plupart du temps. J'ai aussi modifié le thème pour que lorsque l'on cite un article du blog la photo aussi apparaisse, en modifiant les balises qui vont bien (og:image par exemple). Peu de dessin aussi, un croquis rapide lors de ma visite aux Bocaux d'Anna que j'ai posté sur mon compte Pixelfed</a>. J'ai continué mon projet en Scala</a> utilisant Play Framework</a>, et à noter cette semaine un séance de TDD en "presque" pair programming avec un de mes collègues à distance. Je dis "presque" pair programming car en réalité, c'est moi qui tenais le clavier, même si la partie a été assez interactive. Nous avons réussi à respecter le cycle rouge vert rouge vert, écrire le test, écrire le code, faire passer le test, remanier le code, en écrivant une nouvelle méthode d'un controlleur. Tout y est passé y compris le traitement d'erreur, ce que nous avions laissé un peu tomber jusque là. Le TDD est vraiment un bon moyen de réfléchir sur le code, de simplifier et aussi de généraliser. Il n'es pas facile par contre de n'écrire que le minimum, aussi bien au niveau du test qu'au niveau du code. Je me suis aussi un peu remis à Docker</a> à travers le projet Lizmap</a> que je fais actuellement car, j'ai dû déployer une image "custom" pour le "POC" de traçage que nous sommes en train de faire. Dieu que j'aime le PHP ! Dans mes lectures, un article sur les estimations et la maintenance m'a interpellé et m'a fait pas mal réflèchir. Je n'ai malheureusement pas noté la référence. En essence, l'article mentionne que l'on oublie souvent lors des estimations de travail autour d'un projet de parler de la maintenance. Or, cette maintenance est obligatoire. L'auteur inclu aussi dans cette maintenance, la mise à jour des plate-formes utilisées, aussi bien les plate-formes de déploiement que les plate-formes de développement. Il estime à environ 10% le cout de celle-ci (en général moi, je donne plutôt 15%). En corollaire, si l'on oublie cette partie, il faut ensuite se battre pour faire rentrer ce temps dans les itérations, se battre avec le PO, pour que les Sprints / Kanban incluent cette maintenance. Je me suis amusé à faire un petit calcul sur un coin de table. Considérant qu'une personne travaille sur un projet pendant un an, donc 200 jours, l'année suivante, il aura à sa disposition 180 jours : 200 - 10%, l'année suivante 162 jours ... etc. Cela ne vous rappelle rien ? Avez-vous l'expérience de projets qui ralentissent ? C'est pour cela qu'il est important de travailler sur l'aspect maintenance, et comme j'ai coutume de le dire, "Une ligne de code en production est égale à un euro" Je m'arrête là. Moi qui pensais ce matin que je n'aurai pas le courage d'écrire un article long, je me suis laissé aller. L'écriture appelle l'écriture Je vous souhaite une très bonne semaine et un mercredi encore meilleur. 21 mn de rédaction, 30 mn d'édition Troisième Semaine 2023-11-22T00:00:00+00:00 Le meilleur véhicule du monde 7h44 C'est parti, je garde mon rendez-vous hebdomadaire, et qui plus est un mercredi (c'était bien mercredi je crois la semaine dernière</a> non ?). Cette fois ci je ne suis pas dans le train à 300 km/h mais assis à mon bureau à 1670 km/h, si on prends en compte la vitesse de la rotation de la terre :) Je continue le défi d'écrire au moins une fois par semaine, et donc je vais devoir certainement écrire deux fois car l'idée était de publier au moins un article technique par semaine, celui-ci restant un article plutôt général, presque le "en vrac" de Tristant Nitot</a> que j'aime beaucoup. Cela fait un moment que je ne l'ai pas lu d'ailleurs. Une semaine un peu chargée, qui tourne toujours autour des trois activités que j'aie en ce moment, le dessin avec les Aberscketchers</a>, les système d'information géographiques</a> (GIS) et le development d'une application en scala utilisant Play Framework</a> pour piloter un centre de contact Genesys</a> ainsi que l'écriture d'un post sur la revue de code</a>. Gis</h2> Après avoir passé pas mal de temps à écrire un rôle Ansible</a> pour déployer la stack Lizmap</a> avec docker-compose sur une machine de chez Hetzner</a>, je me suis lancé dans l'étude du code de l'affichage de cartes afin de pouvoir réaliser une intégration sans passer par Qgis</a> desktop pour créer le projet. La génération des fichiers projets Qgis et Lizmap a été assez facile (merci Arnaud), par contre pouvoir lancer l'affichage web sans configuration préalable nécessite de descendre dans le code du client web de Lizmap. Pour l'instant, malgré la piste sérieuse que j'avais de créer des repositories à la volée, ce n'est pas concluant. Travail en cours donc. A noter sur le front de la géographie Openlayers</a> bibliothèque d'affichage et d'intégration de cartes et le futur site gouvernemental des cartes et données du territoire</a>. Dev</h2> Sur le développement en Scala</a> et Play, j'avais omis au départ de tester les contrôleurs, en effet cela est souvent très consommateur de temps car on doit monter la stack web complète avant de lancer les tests, j'ai trouvé un compromis en les testant unitairement et en écrivant des helpers de tests qui simplifient grandement l'écriture des tests, malgré l'utilisation d'acteurs Akka qui permettent l'interconnexion avec d'autres serveurs. J'avais mis en place une architecture à base de contrôleurs / backcontrollers, ou l'essentiel du travail est fait dans le backcontroller qui lui est complètement testable car hors de la stack web. Grace à cette opération, je démarre désormais les développement des nouvelles routes en TDD ! La nouvelle version de Play m'a permis aussi de remettre en place le rapport de couverture de tests, malheureusement que 70%. Dessin</h2> Une petite séance de dessin avec les Aberscketchers</a> salle Nuit de Noce dimanche dernier. J'ai aussi pris part à un premier atelier avec Jean-Marc Jezequel</a> à Guisseny ou j'ai commencé à peaufiner mon usage de l'aquarelle. J'ai lu cette semaine "Nemesis" d'Isaac Asimov</a>, que je n'avais pas encore lu, moi qui pensait avoir tout lu de lui. Je suis toujours fan de ses personnages, des dialogues et de cette histoire de l'humanité. Ici on est au prémisse de l'essaimage des hommes dans la galaxie, avec dans les personnages principaux une jeune fille qui m'a fait penser à la petite fille de la maire de Terminus dans la série "Fondation". Pas de robots par contre dans ce roman. Toujours un plaisir à lire. A noter aussi le visionnage d'une video</a> d'Adrian Cockcroft de sur laquelle je reviendrai et l'écoute d'un podcast d'IFThenDev</a>. Ce sera tout pour cette semaine, il va me falloir du temps je pense pour améliorer mon écriture, car c'est encore un peu laborieux. Portez vous bien et à la semaine prochaine j'espère. 08h03-08h36 La revue de code 2023-11-21T00:00:00+00:00 Le Bel Espoir et le Rara Avis au mouillage à l'Aberwrac'h Tout le monde a lu ou lit aujourd'hui des articles sur la revue de code (code review en anglais), c'est une pratique qui devient largement répandue. Peut-être la pratiquez vous vous même. Mais se demande t'on si cela est une pratique efficace et surtout à quoi ca sert ? Qu'est ce que cette pratique peux nous apporter et surtout quel problème peut-elle nous aider à résoudre. Les objectifs</h2> Quels sont les objectifs de la revue de code ? L'apprentissage</h3> On ne le répétera jamais assez une équipe qui va vite est une équipe qui apprend et qui est capable d'apprendre. C'est un des facteurs les plus importants de la performance à long terme. Un des objectifs numéro un de la revue de code est donc l'apprentissage, cela peut se traduire de trois façons différentes : La base de code</li> Le language utilisée</li> L'architecture du code</li> </ul> La base de code</h3> C'est un moment d'échange entre les participants qui permet, lorsque le volume de code devient relativement important, de suggérer d'autre façon d'implémenter la fonctionnalité en utilisant du code existant. Les développeurs ayant la connaissance la plus approfondie peuvent donner à celui qui est l'auteur du code des pistes de remaniement de code en utilisant des méthodes ou fonctions du code déjà existant. Le language</h3> Certains languages ont de subtilités qui méritent à être connues. Je pense par exemple à l'utilisation de modes fonctionnel plutôt que de l'objet en scala, ou encore utiliser les multiples possibilités des bibliothèques de collections. En PHP en peut aussi penser à utiliser un typage fort par exemple. L'architecture du code</h3> Je connais peu de projets ou l'architecture du code est correctement documentée, bien qu'à ma grande surprise c'est un sujet qui revient souvent dans les rétrospectives. Le code évoluant fréquemment c'est l'occasion ici de partager sur les modèles (pattern) utilisés. Le nommage</h2> Le nommage est aussi une phase importante de l'écriture d'un logiciel, une fois un nom choisi il devient de plus en plus difficile à changer avec le temps. Même si avec les outils actuels (qui ne sont pas toujours utilisés par les développeurs) on peut facilement renommer des variables ou des méthodes / fonctions. Il n'en reste pas moins, qu'une fois les noms choisis, ils passent aussi dans le vocabulaire courant et la cela devient de plus en plus difficile de renommer ce qui est dans le cerveau d'un être humain. On peut se poser légitimement la question, la revue de code est-ce le bon moment pour discuter du nommage, et n'est-il pas déjà trop tard. Ne vaut-il pas mieux en discuter lors de séances de conception, de pair programming, de spécifications, de définition de user stories ? En tout cas, la revue de code est le dernier moment ou peut éviter de laisser partir un nommage pas très heureux. L'adéquation aux spécifications</h2> C'est le deuxième oeil sur ce qui a été développé et au delà du passage des tests unitaires et des tests fonctionnels (ce qui doit aussi être obligatoire), c'est l'occasion d'apporter un deuxième angle sur ce qui a été réalisé et vérifier que cela correspond bien a ce qui a été demandé. En résumé</h2> La revue de code, permet certe d'améliorer la qualité du code produit en partageant les bonnes pratiques et en les propageant vers tout les membres de l'équipe. C'est aussi un moment ou l'on pourra vérifier la pertinence de l'implémentation et aussi l'exhaustivité de la réalisation. Mais attention de ne pas tomber dans l’excès. Un développeur sachant que son code et son implémentation vont être revus peut être tenté de ne pas porter toute l'attention qu'il aurait du avoir si son code partait directement en production. Références</h2> The Standard of Code Review</a></li> What to look for in a code review</a></li> Apprendre à apprendre avec le Lean, un passage obligé</a></li> </ul> Deuxième semaine le retour 2023-11-15T00:00:00+00:00 L'ile vierge vue de Stagadon Commencé à 17h12 Chose promise, chose due, je reviens pour la deuxième semaine. Comme je l'ai dit dans ce précédent article</a>, voici le deuxième post de la série un article par semaine. J'ai donc craqué et acheté le livre de Johanna Rothman</a> pour libérer l'écrivain qui est en moi</a> et me voila parti. Le livre</h2> Quelques mots sur son livre que je viens de terminer. Ecrire ecrire ecrire</li> </ul> Le secret de l'écriture vous n'en douterez pas c'est d'écrire, plus on écrit plus on sait écrire. C'est peut être enfoncer un porte ouverte, mais c'est un conseil que l'on peut appliquer à beaucoup de domaines, l'écriture, le dessin, le développement, le TDD etc.... Ecrire pour ses lecteurs</li> </ul> Il s'agit de se mettre à la place de son lectorat. Ca ne vous rappelle rien ? Se mettre à la place de l'utilisateur, je raconterai certainement l’anecdote une autre fois. Terminer ce que l'on commence</li> </ul> Terminer c'est finir l'écriture et surtout publier. Pour paraphraser quelqu'un que je connais bien, ce qui n'est pas en production n'existe pas ..... Ecrire à la volée</li> </ul> C'est à dire ne pas revenir en arrière pour corriger le text ou le reformuler. On démarre par une session de 15 minutes, un peu long pour moi je trouve, et à la fin de chaque session on cycle, c'est à dire on reviens sur ce qu'on a écrit et surtout on n'édite pas. La j'avoue que j'ai un peu de mal à comprendre ce que veux dire ce cycle, j'y reviendrai sûrement après y avoir réfléchi. La structure</li> </ul> On commence par une phrase d'accroche: quel est le problème que l'on essaie d'adresser. Ensuite on développe et en conclusion on reviens sur la définition du problème. (j'écris un test j'écris un code et je remanie le code Refactor) Il y a encore beaucoup d'autre choses dans ce livre qui mérite d'être digéré et relu, j'en reparlerai sûrement. Pendant la semaine</h2> J'ai tout de même réussi pendant la semaine qui vient de s'écouler à publier deux articles, un sur la construction de ce blog</a> et un autre sur les abersketchers</a> un groupe de dessin que j'ai créé, une de mes passions avec le développement, et auquel je participe ici à Landéda. J'ai aussi passé pas mal de temps sur la structure technique de ce blog, pas vraiment satisfait par la mise en page du thème abridge</a>, j'en ai essayé un autre deepthought</a>. Mais intégrer un autre thème m'a envoyé un peu trop loin alors je me suis mis à modifier le thème abridge en réécrivant une partie des templates et des feuilles de style. J'ai aussi mis en pratique les conseils de Johanna Rothman</a> en faisant l'exercice d'écrire pendant un temps déterminé, 10 mn en l’occurrence. Par contre je ne suis pas allé plus loin pour l'instant, il me reste à réviser l'article et à le publier. J'oubliais j'ai aussi fait le tour de mes autre blogs démarrés et abandonnés et je me suis apercu que j'avais déjà écrit pas mal de choses !!! J'ai commencé à semer mes pierres des champs fieldstones(voir Weinberg’s _Weinberg on Writing</a>) et à créer une banque d'idée que je met à jour avec Obsidian</a> (tiens le thème d'un ou deux prochains articles) Comme vous voyez, les idées ne manquent pas il ne me reste plus qu'à revoir un peu la structure de ce post y ajouter quelques liens, une belle image et le publier. A bientôt. Terminé à 17h27 - 18h06 Tout sur les Aberscketchers 2023-11-12T00:00:00+00:00 Histoire</h2> Le groupe Aberscketchers en référence aux Urbanscketchers</a> s'est réunis pour la première fois au Bzztcafé</a> à Plouguerneau le 12 Juin 2022. Depuis nous nous rencontrons de loin en loin souvent le dimanche matin de 10h30 à 12h30 environ, et nous prolongeons la rencontre, si le temps le permet d'un pique nique partagé. Les sorties sont pour l'essentiel autour de Landéda, Plouguerneau et Lannilis Depuis cette date, nous nous sommes réunis une bonne quinzaine de fois. Organisation</h2> Les réunions se passent de préférence à l’extérieur nous sommes néanmoins obligés de temps en temps de nous retrouver à l'intérieur surtout l'hiver. Il n'y a pas réellement d'organisation, chacun peut convoquer une réunion à son gré, il suffit d'avoir envie de dessiner quelque part et de partager son rendez vous sur la liste de diffusion du groupe. Pour être au courant des informations du groupe, on s'inscrit à la liste de diffusion du groupe Aberscketchers</a> liste hébergée par framagroupes</a>. En général, quelqu'un m'envoie un mail et j'ajoute la personne à la liste de diffusion. Les rencontres</h2> Les séances de dessin sont collectives, sans animateur, chacun amène son matériel et dessine ce qui lui fait le plus envie sur le moment. Il n'y a pas d'obligation d'utiliser tel ou tel medium, et toutes les techniques sont les bienvenues, y compris les techniques numériques. A la fin du rendez-vous nous partageons nos dessins et publions les photos ici dans un répertoire partagé</a> Vers un événement l'année prochaine</h2> Nous prévoyons un week-end d'échange autour du dessin le week-end du 25 et 26 mai que nous organiserions conjointement avec l'atelier d'aquarelle (à confirmer) Quelques idées pour le week-end</h3> Exposition des participants</li> Journée parcours de croquis avec points de rendez-vous, pique nique partagé le midi et retrouvailles en salle pour mise en commun des oeuvres et apéro puis repas commun le soir pour les inscrits</li> Invitation des groupes proches (Morlaix, Brest, Quimper, Lorient)</li> Ateliers de démarrage pour ceux qui veulent ce lancer</li> Autres ateliers pour ceux qui veulent échanger leurs savoirs.</li> Et beaucoup d'autres idées .... j'espère.</li> </ul> Fonctionnement avec Echanges et Savoir.</h2> Nous sommes en discussion avec l'association échanges et savoir</a> de Landéda, avec qui nous aurions des intérêts communs le mouvement des urbansketchers étant aussi dans une dynamique de partage. Les quelques idées que nous avons évoquées ensemble lors de notre dernière réunion : Nous sommes à la recherche de salle surtout l'hiver, environ 2 fois par mois. Nous pouvons convenir à l'avance de dates et de créneaux horaires pour cette période.</li> </ul> </li> Il est bien entendu que pour profiter des séances en salle lors des rencontres dans le cadre d'échange et savoir, les participants devront être à jour de la cotisation.</li> Par contre en dehors des séances en salle échanges et savoirs l'accès aux rencontres reste libre et sans obligation de cotisation.</li> Le nom du groupe reste Aberscketchers</li> On continue à utiliser la liste de diffusion pour organiser nos rendez vous.</li> </ul> Quelques références.</h2> Le mouvement Urbansketchers : https://urbansketchers.org/fr/</a> Le mouvement Français : https://france.urbansketchers.org/</a> Vision et valeurs : Le manifeste des Urbansketchers</h3> Nous dessinons sur place, à l'intérieur ou à l'extérieur, en capturant ce que nous voyons par observation directe.</li> Nos dessins racontent l'histoire de notre environnement, de nos voyages et des lieux où nous vivons.</li> Nos dessins sont des enregistrements du temps et du lieu.</li> Nous sommes fidèles aux scènes dont nous sommes témoins.</li> Nous utilisons tout type de support et valorisons nos styles individuels.</li> Nous nous soutenons mutuellement et dessinons ensemble.</li> Nous partageons nos dessins en ligne.</li> Nous montrons au monde, un dessin à la fois.</li> </ul> Mise à jour du thème Abridge 2023-11-09T00:00:00+00:00 Je viens de mettre à jour non sans difficultées le thème abridge</a> que j'utilise sur ce blog avec getzola</a>. Reste à bidouiller un peu le css pour la taille des fonts, et gérer correctement le multilangue. Voici mes notes (en anglais): Remove content (except posts)</li> Remove template</li> Save config.toml</li> </ul> git submodule update --remote </code></pre> Follow doc touch templates/.gitkeep rsync themes/abridge/config.toml config.toml rsync themes/abridge/content/_index.md content/ rsync themes/abridge/COPY-TO-ROOT-SASS/* sass/ rsync themes/abridge/netlify.toml netlify.toml rsync themes/abridge/package_abridge.js package_abridge.js rsync themes/abridge/package.json package.json rsync -r themes/abridge/content . </code></pre> Update config.toml and saas/abridge.css (social icons) Un article par semaine 2023-11-08T00:00:00+00:00 08h16 C'est parti aujourd'hui je prends une décision. Après avoir tourné longtemps autour du pot et lu quelques articles ici ou la sur la pratique régulière de l'écriture, je me lance.... Un article par semaine. Il est difficile de ne pas se laisser distraire, je saute donc sur mon éditeur de code préféré</a>, je refrène un peu mon envie de trouver comment mettre en place un correcteur orthographique en français (vous voyez les fotes ?) et en avant. Mon dernier article date d'y il y a un mois, sur le defi inktober</a> que j'ai réussi à suivre, un dessin par jour, j'en ai posté quelque uns sur pixelfed</a> par contre je ne les ai pas tous postés. Un livre à lire</h2> Vais je acheter le livre de Johanna Rothman</a> sur leanpub Free Your Inner Nonfiction Writer</a> ? Cela me permetterait peut-être de lancer cette fois un blog technique et de m'y tenir. J'ai pas mal de sujets en ce moment autour d'Ansible</a>, de Lizmap</a> que je suis en train d'explorer et d'un projet en Scala</a> utilisant Play Framework</a> mais ca ce sera pour le prochain article. En tout ca je continue ma prise de notes avec Obsidian</a> qui sera j'espère une source d'inspiration Allez le combat continue ... bon écriture à tous et à la semaine prochaine. Ps: C'est bon je rajoute quelques liens, une p'tite photo en haut de l'article et je publie (git commit, push et gitlab</a> va faire le reste) 08h33 Inktobreizh 2023 2023-10-12T00:00:00+00:00 Cette année je retente le challenge dessin du mois d'octobre Le defi inktober</a> 2023 et sa version bretonne</a> J'ai choisi la version bretonne avec sa liste de mots 11 jours de dessins à l'encre, un exercice à tenter, pas facile de dessiner à l'encre directement et de simuler les couleurs. Je suis un peu seul sur le tag breizhtober2023</a> sur pixelfed</a> par contre pas mal de monde qui s'essayent à inktober2023</a> Allez le combat continue ... bon dessins à tous. Pixelfed, nous voilà !!! 2023-05-22T00:00:00+00:00 Allez aujourd'hui je démarre sur PixelFed</a> Après un choix rapide du serveur sur https://pixelfed.org/servers</a>, pas très compliqué je prends l'instance française pixelfed.fr</a> et hop me voila parti !!! Un premier post sur notre dernière rencontre d'Urbansketcher, à la chapelle de Tromenec</a> de Landéda avec les Aberscketchers. De belles contributions des participants Adieu Instagram Un role Ansible qui coince 2022-11-03T00:00:00+00:00 Je me suis retrouvé coincé aujourd'hui avec un role ansible qui effectue un déploiement avec git, le repo était bien copié sur le serveur mais ansible ne rendait pas la main après avoir terminé le clone du repo git.

A retenir</h2> Framasoft mobilizons nous</a>, cherche du monde pour continuer les développements de Mobilizon</a> un outil qui permet de trouver, créer et organiser des événements.</p>
Belle semaine à tous.</p>

Les sites spécialisés</h2>
Il y en a pléthore, je ne m'étendrai pas sur cette solution, qui sont souvent une occasion de faire de la publicité, de générer des clicks et de récupérer au passage de l'information.</p>

Les extensions Visual Studio</h2>

Références</h2>
Quelques sites qui m'ont aidés</p>

Le site officiel de Pandoc</a></li>
Redaction durable avec Pandoc et Markdown</a> du site Programming Historian</a></li> </ul>

Références</h2>

The Standard of Code Review</a></li>
What to look for in a code review</a></li>
Apprendre à apprendre avec le Lean, un passage obligé</a></li> </ul>

Quelques références.</h2>
Le mouvement Urbansketchers : https://urbansketchers.org/fr/</a></p>
Le mouvement Français : https://france.urbansketchers.org/</a></p>

Jean-Yves

Septième Semaine

Ne Jamais dire Jamais

Sixième Semaine

Doc et Pdf sont dans un bateau

Cinquième Semaine

Quatrième Semaine

Troisième Semaine

La revue de code

Deuxième semaine le retour

Tout sur les Aberscketchers

Mise à jour du thème Abridge

Un article par semaine

Inktobreizh 2023

Pixelfed, nous voilà !!!

Un role Ansible qui coince

Jean-Yves

Septième Semaine

Ne Jamais dire Jamais

Sixième Semaine

Doc et Pdf sont dans un bateau

Les sites spécialisés</h2> Il y en a pléthore, je ne m'étendrai pas sur cette solution, qui sont souvent une occasion de faire de la publicité, de générer des clicks et de récupérer au passage de l'information.</p>

Les extensions Visual Studio</h2>

Le fichier metadata.yml</h4> C'est un fichier de configuration qui permet de paramétrer le formatage du document. Je vous livre le mien</p>

Références</h2> Quelques sites qui m'ont aidés</p>

Cinquième Semaine

Quatrième Semaine

Troisième Semaine

La revue de code

Références</h2> The Standard of Code Review</a></li> What to look for in a code review</a></li> Apprendre à apprendre avec le Lean, un passage obligé</a></li> </ul>

Deuxième semaine le retour

Tout sur les Aberscketchers

Mise à jour du thème Abridge

Un article par semaine

Inktobreizh 2023

Pixelfed, nous voilà !!!

Un role Ansible qui coince

Les sites spécialisés</h2>
Il y en a pléthore, je ne m'étendrai pas sur cette solution, qui sont souvent une occasion de faire de la publicité, de générer des clicks et de récupérer au passage de l'information.</p>

Références</h2>
Quelques sites qui m'ont aidés</p>

Le site officiel de Pandoc</a></li>
Redaction durable avec Pandoc et Markdown</a> du site Programming Historian</a></li> </ul>

Références</h2>

The Standard of Code Review</a></li>
What to look for in a code review</a></li>
Apprendre à apprendre avec le Lean, un passage obligé</a></li> </ul>