DEV Community: Avalon Lab

Pourquoi écrire des Documents de Choix d'Architecture ? (Architecture Decision Record)

Jean-François Le Foll — Wed, 16 Jun 2021 13:50:22 +0000

Tout d'abord qu'est-ce qu'un ADR ?

La base de notre métier est de faire des choix : choix de technologie, choix d'architecture, choix d'implémentation...
Certains sont plus impactants que d'autres.

Le but d'un ADR est de documenter et de tracer le raisonnement derrière ces choix, en gardant le contexte du niveau de connaissance et de maîtrise du sujet au moment de ce choix.
Quel était mon problème ? Quelles étaient les différentes solutions envisagées ? Quels éléments nous ont amenés vers ce choix ?

Quel formalisme pour un ADR ?

Un ADR, c'est un document texte, facile à partager au sein de l'équipe (dans un wiki ou dans un repository par exemple).

C'est un document immuable, il n'a pas vocation à être mis à jour, au mieux le statut peut changer si cette décision est remplacée par une autre.

Le titre de l'ADR doit être explicite :

choix_langage_backend
choix_base_de_données
gestion_des_dates
format_des_logs

Décrivez clairement le contexte, pourquoi cette décision se pose, quel problème / contrainte essayons nous de résoudre ?

Décrivez le raisonnement qui vous amène à votre décision, n’hésitez pas à lister les expérimentations que vous avez faites, les articles sur lesquels vous vous êtes basés, tout ce qui vous permettra de comprendre votre décision si vous relisez l'ADR dans 6 mois.

Ce sont pour moi, les trois parties les plus importantes d'un ADR : titre, contexte, raisonnement/décision

Vous pouvez également décrire les conséquences qu'aura ce choix (par exemple nouvelle contrainte ou nouvelle complexité).
Vous pouvez aussi ajouter un statut à votre ADR (accepté, rejeté, déprécié, remplacé...).

Vous pouvez trouver des modèles d'ADR beaucoup plus détaillés sur internet, mais au final c'est vous et votre équipe qui allez les écrire et les lire donc choisissez les rubriques qui sont pertinentes pour vous.

Conclusion

Dans un contexte en constante évolution, où nous apprenons de nouvelles choses régulièrement (sur les besoins des utilisateurs, sur les technos, ...), pouvoir pourquoi et comment tel ou tel choix a été fait est important pour une équipe et sa compréhension de son produit.
C'est aussi une source d'information pratique pour les nouveaux arrivants dans l'équipe.

D'un point de vue personnel, chez Avalon Lab, nous sommes des prestataires, nous accompagnons des entreprises et porteurs de projets qui n'ont pas forcément d'équipe technique.
Dans ce cas, les ADR nous permettent de documenter tous les choix technologiques et d'architectures que nous prenons, car finalement ce n'est pas nous qui allons vivre avec ces choix, mais bien les développeurs·euses qui seront recruté·e·s plus tard par le client.
Les ADR leurs permettrons de comprendre comment et pourquoi le produit est ce qu'il est.

Pour aller plus loin sur le sujet des ADR :

ADR GitHub organization

Architecture decision record (ADR)

Cover Photo by Kaleidico on Unsplash

Setting up a typescript project in 2021

Marceau "XioRcaL" Lacroix — Wed, 28 Apr 2021 07:48:50 +0000

This post will describe how to create a project in typescript from scratch. The final project include some basic code, tests, commit hooks to enforce code formating, automatic tests on push and more ! I hope you'll enjoy it :)

TL; DR

find the code here

Basics

Before you start

you should have node/npm (latest lts should do the trick)
npm init was run. So you have a package.json

Setting up typescript

Typescript itself

Pretty straight-forward : npm install typescript --save-dev

Now check if that worked ; create a file src/demo.ts and fill it with

export function greeter(person: string): string {
 return "Hello, " + person + "!";
}

console.log(greeter("World"));

And run... Wait... what should I run ? Meh that JS, a node src/demo.ts will do it !
...
Oh no... Why does it complains about some unexpected ':' ?
:-/

Configuring typescript itself

I like to use a recommended default setting for tsc (typescript compiler) : npm install --save-dev @tsconfig/recommended then create a file named tsconfig.json and fill it with :

{
 "extends": "@tsconfig/recommended/tsconfig.json",
 "compilerOptions": {
 "outDir": "./dist",
 },
 "include": ["src/**/*"],
 "exclude": ["node_modules", "dist"]
}

in your package.json add a script for build : "build": "tsc",
you should be able to run npm run build then node dist/demo.js
Nice !

Speeding things up

well I'm the kind of person that does not like to have to type 2 commands everytime my code changes. So lets spend some time automating it a bit

first add tsc-watch to the project: npm install tsc-watch --save-dev
then add a watch script to the package:
"watch": "tsc-watch --onSuccess \"node ./dist/demo.js\"",
now you can run npm watch and every change you made will imediately be complied and run !

Enforce the "2 spaces or GTFO" law !

formatting will be done with eslint and prettier, enforcing formatting will be done with husky and its pre-commit hooks

configuring style tools

npm install --save-dev eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin eslint-config-prettier eslint-plugin-import prettier

in .eslintrc.js file :

module.exports = {
  parser: '@typescript-eslint/parser',
  parserOptions: {
    project: 'tsconfig.json',
    sourceType: 'module',
  },
  plugins: ['@typescript-eslint/eslint-plugin'],
  extends: [
    'eslint:recommended',
    'plugin:@typescript-eslint/recommended',
    'prettier',
  ],
  root: true,
  env: {
    node: true,
  }
};

in .eslintignore :

node_modules
dist

in .prettierrc.js :

module.exports = {
  trailingComma: "all",
  tabWidth: 2,
  singleQuote: true,
};

add a lint script to package.json :
"lint": "eslint src --ext .js,.jsx,.ts,.tsx"

Automate it

Once again, I'm lazy, so I need those tools to run automatically for me. That's where husky commes to play!

npm install --save-dev husky pretty-quick

add a prepare script : "prepare": "husky install"
run it : npm run prepare
you should see a .husky directory now.
create a file nammed pre-commit in this directory and fill it with :

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx --no-install pretty-quick --staged
npm run lint

now your formatting will be fixed on commit \o/

enforce the "meaningful commit or GTFO" law !

this will be done with commit-lint
npm install --save-dev @commitlint/config-conventional @commitlint/cli
then create a commit-msg file in .husky directory with :

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx --no-install commitlint --edit "$1"

and a commitlint.config.js with module.exports = {extends: ['@commitlint/config-conventional']} in it.
Now your commit messages are force to obey the law !

Prevent your friends to break the law

husky take care of that for you :)

These are not the tests you are looking for

Set-up

I use jest so we need to install it first: npm install -D jest ts-jest @types/jest
then config, jest.config.js :

module.exports = {
  preset: 'ts-jest',
  testEnvironment: 'node',
};

add a test script : "test": "jest"

Your very first test

in demo.spec.ts we are going to ensure that our greeter is really polite:

import {greeter} from './demo'

describe('greeter function', () => {
    test('a greet should start with Hello', () => {
      expect(greeter("Bob").startsWith('Hello')).toBe(true)
    });
});

try it with npm run test

Guess what...? AUTOMATION

This time no external deps nor manual tweaking ! jest took care of that for us. simply run jest --watch ! Your tests should run on source edit. Alternatively you can use an extension in your ide to do it.

Setting up your dev env

I'm using vscode so this is the one that will be covered by this section.

Extensions

I suggest enabling code coverage overlay for jest (io.orta.jest.coverage.toggle).
Using prettier as formatter directly in editor will instantanely format your code correctly rather than on commit.

Time for release ?

Ok so your greeter is now ready for its first release ! Lets take advantage of our strict commit message policy to have a nice changelog ! standard-version will help us do so
npm i --save-dev standard-version
and a release script : "release": "standard-version"
finally run npm run release -- --first-release to do your... first release !

automate it, noob !

using github actions because those are pretty neat. create a .github/workflows/ directory to setup those actions.

auto test on commit

This workflow will do a clean install of node dependencies, build the source code and run tests across different versions of node
For more information
node.js.yml :


name: Node.js CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:

    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [12.x, 14.x]
    steps:
    - uses: actions/checkout@v2
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v1
      with:
        node-version: ${{ matrix.node-version }}
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test

auto publish on release

npmPublish.yml:

name: Publish package on npm

on:
  release:
    types: [created]

jobs:
  publish-npm:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-node@v1
        with:
          node-version: 12
          registry-url: https://registry.npmjs.org/
      - name: Cache node modules
        uses: actions/cache@v1
        with:
          path: ~/.npm # npm cache files are stored in `~/.npm` on Linux/macOS
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-build-${{ env.cache-name }}-
            ${{ runner.os }}-build-
            ${{ runner.os }}-
      - run: npm ci
      - run: |
          if [ ${{ github.event.release.action }} = "prereleased" ]; then
            npm publish --tag beta
          else
            npm publish
          fi
        env:
          NODE_AUTH_TOKEN: ${{secrets.npm_token}}

NPM_TOKEN is a repository secret holding an access token with publish rights from npm. get your own at https://www.npmjs.com/settings/{YOUR_USER}/tokens

fun stuff

haha you whish

CTO d'amorçage / Team as a Service, qu'est-ce que c'est ?

Jean-François Le Foll — Wed, 13 May 2020 14:57:45 +0000

Le principe du CTO d'amorçage / Team as a Service est d'intervenir, à minima en binôme, dans une structure sans compétence disponible en développement logiciel (développement, gestion de projet, etc ...) afin de démarrer un projet, d'accompagner le client sur le développement et la conception de son produit ou MVP, de poser les bases d'une architecture saine et éventuellement de l'aider dans son recrutement de développeurs.

Nous avons abordé notre action de CTO d'amorçage / Team as a Service suivant trois axes : tout d'abord d'un point de vue apprentissage fonctionnel, puis d'un point de vue méthodologique et enfin d'un point de vue technique.

Apprentissage fonctionnel

Le métier de ce client était quelque chose de nouveaux pour nous, nous avons donc fait plusieurs ateliers d'Event Storming avec l'expert métier.

Le but de ces ateliers est multiple :

Découvrir le langage métier de l'expert (et donc partager le même langage entre le code et la réalité métier)
Découvrir le fonctionnement de l'outil, le process métier, les besoins
Avoir une première idée / ébauche de la conception du logiciel

Ceci s'inscrit dans une approche Domain-Driven Design (DDD) ou Conception pilotée par le domaine (métier).

Ces ateliers sont refaits régulièrement, par exemple pour présenter un nouveau use case afin d'en explorer le fonctionnement.

Méthodologie

Chez Avalon Lab, nous sommes convaincus par les principes de développement agile.

Nous avons un fonctionnement assez proche de la méthode eXtrem Programming :

Contact étroit avec l'expert métier
Livraison fréquente
Feedback régulier
Binômage
Développement piloté par les tests (TDD)
Intégration et déploiement continue
Rythme soutenable
Conception simple

Intervenant dans un contexte "remote" dès le départ, l'expert métier n'étant pas localisé avec l'équipe de développement, nous avons mis en place plusieurs outils afin de collaborer efficacement en fonction des contraintes client :

Gitlab (gitlab.com), pour la gestion de projets (user stories, bug tracker, milestone)
Miro (miro.com), un tableau blanc collaboratif (schémas, atelier post-it)
Skype ou autre, notamment pour faire des démos, via le partage d'écran.

Technique

L'approche DDD, notamment au travers d'ateliers type Event Storming, nous permet de mieux concevoir l'application.

L'application est découpée en domaine, unités logiques correspondant à un regroupement logique de sens métier.

Pour implémenter ces domaines, nous avons suivi les principes de l'architecture hexagonale où tout le code, correspondant aux règles métier, est correctement isolé de l'extérieur (base de données, web services, interface utilisateur) et n'est pas "pollué" par du code provenant d'un quelconque framework ce qui rend les choix de solutions type framework moins définitive et impactant.

Aujourd'hui, on sait que les fonctions principales d'un logiciel concernent principalement de la présentation de données (certains parlent de 80 % lecture de données et 20 % écriture de données).

Partant de ce constant, nous avons adopté le pattern CQRS (Command Query Responsibility Segregation) qui sépare les tâches d'écriture (command), des tâches de lecture (query) et ayant des modèles de donnés séparés.
[Ce pattern peut être étendu avec le principe d'Event Sourcing lorsque le métier requiert un traçage / audit des différentes actions.]

Toutes les décisions d'architectures / de choix techniques sont tracés dans des documents de décision d'architecture (Architecture decision record - ADR).

Architecture SI

L'architecture physique du SI évolue en fonction des besoins métier, tout en se basant sur les principes généraux des 12 factors

Nous avons d'un côté un frontal web (SPA) et de l'autre un backend métier.

Pour le backend métier, notre principe de base est de démarrer avec un monolithe, comme nous adoptons une démarche DDD, ce monolithe embarque nos domaines qui eux sont indépendants et correctement séparés.

L'avantage est de simplifier la phase de construction de l'application ainsi que sont déploiement et son monitoring tout en gardant la flexibilité de pouvoir sortir un domaine afin de répondre à un nouveau besoin ou à des contraintes de charges spécifiques.

De plus, cette architecture est déclinée en deux versions :

Test/intégration => construite directement depuis les sources, à chaque modification (Continuous Deployement), permet aux développeurs et à l'expert métier de tester sur un environnement déployé.
Production => construite et déployée à la demande, ouverte aux clients.

Technologie

Dans l'optique d'aider le client à recruter des développeurs et un CTO, nous sommes partis sur des technologies fiables, connues et pour lesquelles il est facile de recruter tout en respectant nos critères de qualités.

VueJS / Web Component (lit-element)
Java 11
Gitlab : gestion de code et ci/cd
Datadog : collecte et analyse des logs applicatives / monitoring [peut être remplacé par Elastic Stack]
Clever Cloud : gestion de l'infrastructure
Izanami : Configuration partagée, features flipping
Warp10 : Base de données de séries temporelles
Cellar / AWS S3 : stockage de fichiers
SonarCloud : Analyse qualité du code

Cet article vous a intéressé, vous avez envie d'en savoir plus ou par rapport à vos besoins ?

N'hésitez pas à nous envoyer un mail à contact@avalon-lab.coop

Server-Sent Events démystifiés, avec un cas concret.

Jean-François Le Foll — Wed, 11 Mar 2020 16:18:28 +0000

Préface

Avant d'aller plus loin, expliquons d'abord ce que sont les Server-sent Events (SSE pour les intimes).

Il s'agit d'un canal unidirectionnel permettant au serveur d'envoyer des messages à un navigateur.

C'est une techno ancienne, qui date de 2009-2010 et est disponible au grand public depuis les versions 6 de Chrome et Firefox, mais qui a été un peu mise de coté à l'arrivée des WebSockets.

Objectif ?

Le but de cette démo est de construire un cas concret d'utilisation de SSE.
Beaucoup d'articles ou de démos que j'ai pu trouver ne montrent guère autre chose qu'un event pré-construit envoyé à intervalle régulier, pas grand-chose à voir avec la réalité.

Dans cette démo, nous allons construire une API Rest, qui poussera un message dans un RabbitMQ en mode Fan-out.
De l'autre coté, nous aurons un serveur nodejs qui écoutera les messages et poussera un SSE au bon client de la webapp servi par le nodejs.

Dans l'objet poussé sur l'endpoint, nous avons un client ID, ce qui permet d'avoir plusieurs onglets ouverts sur la web app et ainsi voir que les SSE arrivent seulement au bon client.

Le code :

L'API Rest

Je ne vais pas entrer ici dans les détails de l'API Rest, c'est une API Java (Jooby 2) qui sert de producer RabbitMQ.

La Web App

Il s'agit d'une simple page html avec un Web Component (les dépendances sont chargées directement avec Pika, cela peut prendre quelques secondes).

Pour se connecter à un endpoint SSE, rien de plus simple, il suffit de définir un EventSource qui prend en paramètre l'url de la source.

const sseSource = new EventSource("/event-stream/" + this.clientId);

Dans notre cas, nous ajoutons dans l'url le clientId du client connecté.

Sur cet objet EventSource nous allons venir définir un event listener, le but est de ne réagir qu'aux messages de type notif :

    sseSource.addEventListener("notif", e => {
      this.count = this.count + 1;
      this.notifications = [...this.notifications, e.data];
    });

Ce code nous permet d'incrémenter un compteur et d’alimenter un tableau avec le message de l’événement.
C'est tout pour la partie front.

La partie serveur NodeJs

1) Le point d'entrée SSE

Ici on utilise ExpressJS car il n'y rien de particulier à faire pour mettre en place la ressource SSE :

app.get("/event-stream/:clientId", (req, res) => {
  let clientId = req.params.clientId;

  res.writeHead(200, {
    "Content-Type": "text/event-stream",
    "Cache-Control": "no-cache",
    Connection: "keep-alive"
  });
  res.write("\n");

  connections[clientId] = res;

  console.log("Connection open for client : " + clientId);

  req.on("close", () => {
    delete connections[clientId];
  });
});

Ici nous définissons notre ressource GET "/event-stream/:clientId" avec un paramètre clientId qui nous permet de stocker l'objet response sur lequel envoyer les messages :

    connections[clientId] = res;

Mais avant de stocker cette réponse, il faut la "configurer" pour le SSE :

  res.writeHead(200, {
    "Content-Type": "text/event-stream",
    "Cache-Control": "no-cache",
    Connection: "keep-alive"
  });

Pour résumer cette partie, à chaque fois qu'un client fait un GET sur notre ressource SSE, nous stockons dans un objet sont clientId et l'objet response afin de lui pousser des messages ultérieurement.

2) Le consumer RabbitMQ

Afin de pouvoir se connecter sur le RabbitMQ, nous allons avoir besoin de la dépendance vers la librairie amqplib

   const amqp = require("amqplib/callback_api"); // => fonctionne avec des callback
// ou
   const amqp = require("amqplib");  // => fonctionne avec des promesses

Au démarrage du serveur nodejs, on ouvre une connexion vers RabbitMQ

amqp.connect("amqp://localhost", (error0, connection) => {})

Dans cette connexion, on va créer un channel sur notre Exchange et une Queue (Cf dépôt Github pour le code de cette partie).

Ce qui nous intéresse ici, c'est de voir comment on consomme les messages.

      channel.consume(
        q.queue,
        msg => {
          if (msg.content) {
            let data = JSON.parse(msg.content.toString());

            console.log("New message for client : " + data.clientId);
            let clientRes = connections[data.clientId];

            if (clientRes) {
              clientRes.write(`event: notif\n`);
              clientRes.write(`data: ${data.content}\n\n`);
            }
          }
        },
        {
          noAck: true
        }
      );

On va parser le message pour en récupérer le contenu, grâce au clientId du message, on récupère notre objet response qui correspond.
Si elle existe, on vient écrire une première ligne avec le type d'événement clientRes.write('event: notif\n'); (pour rappel notre front n'écoute que les messages notif).
Puis une seconde ligne avec le contenu du message clientRes.write('data: ${data.content}\n\n');

Et voilà, nous avons poussé notre message dans notre stream d'événements.
Le front réagi, incrémente le compteur et affiche le message !

J'espère que maintenant l'utilisation des SSE est un peu plus claire et concrète pour vous aussi :)

Le code de la démo complète est disponible sur GitHub :

Avalon-Lab / realtime-webapp-sse-rabbitmq

Demo WebApp temps réel avec SSE et RabbitMQ

Utiliser les Futures avec Vavr

Mathieu Marchadour — Wed, 13 Nov 2019 15:20:44 +0000

Introduction

Dans le cadre d’un projet chez l’un de nos clients, on nous a chargé de réaliser une API. Celle-ci avait la responsabilité d’agréger différentes données venant de plusieurs API.

À des fins de performance, nous avons choisi de paralléliser les appels et d’utiliser les Futures.

Présentation

La librairie Vavr est utilisable à partir de la version 8 de Java.

Cette librairie a pour but d’améliorer le coté programmation fonctionnelle de Java 8 en ajoutant notamment des types de données immuables et des structures de contrôles orientés fonctionnelles.

C'est parmi ces types de données immuables que nous trouvons notre Future, objet de cet article.

Une Future va permettre de réaliser une action dont le résultat sera disponible dans le futur.

Lorsque l'action de la Future est terminée, trois états de celle-ci sont possibles :

completed: lorsque la Future s'est terminée
success: lorsque la Future s'est terminée avec succès
failure: lorsque la Future s'est terminée en erreur

Il est possible d'ajouter des callbacks afin d'intercepter ces trois états.

Chez notre client, cela permettait de lancer X actions (Futures) permettant de récupérer des données, attendre le résultat de chacune et agréger toutes les données. Pour mettre en place ceci, nous avons créé une liste de Futures, les avons packagées dans une séquence. Nous devons attendre le résultat de toutes les Futures et avons donc bloqué les différents Thread grâce à la méthode .await(). Ensuite, la méthode .get() nous permet d’obtenir le résultat de la Future.

Illustration : la course d'animaux

Afin de lancer la course et de vous présenter les Futures, nous allons réaliser un test unitaire.

Création de la classe Java Animal avec son nom, sa famille, son type et vitesse moyenne. L'annotation @Data vient du projet Lombok : une librairie de génération de code. Ce projet fera l'objet d'un autre article.

Ici, nous initialisons 5 animaux qui sont de famille et de vitesse différentes.

Le test unitaire:

Résultat du test unitaire :

Conclusion

Grâce à ce test unitaire, nous avons utilisé la librairie Vavr, disponible à partir de Java 8, afin de paralléliser des traitements. Cette librairie ne permet pas uniquement l’utilisation de Future mais elle implémente aussi des Collections, List, Map, Option, Try …

La documentation de Vavr est disponible ci-dessous afin d’approfondir cette librairie.

Documentation

Site officiel Vavr

Introduction to Future in Vavr | Baeldung

Premiers pas avec AutoHotkey

Marceau "XioRcaL" Lacroix — Wed, 06 Nov 2019 14:58:13 +0000

Trop long / Pas lu

le code est là

Problématique de base

Suite à changement d'environnement de boulot (poste de dev linux -> windows) j'ai besoin de retrouver certaines habitudes et notamment

Oui je fais partie de ces gens qui ont besoin d'un terminal à portée d'une touche de clavier. Sauf qu’apparemment sous Windows ce fonctionnement n'existe pas. Depuis j'ai appris que c'était plus ou moins possible, voir la section alternative en bas de l'article.

C'est quoi AutoHotkey ?

D'après leur site web c'est The ultimate automation scripting language for Windows. Ça a l'air plutôt cool présenté comme ça ! Et effectivement ahk permet aussi bien de simuler un clic souris que d'utiliser des dll windows. Sur le papier ça devrait permettre de résoudre le problème.

Le script

Cibler la touche de déclenchement

En temps normal c'est assez facile avec akh, il suffit d'écrire Matouche:: pour déclencher une action

j::
MsgBox, "vous avez appuyé sur 'j'"
return

Sauf que moi j'ai envie d'utiliser ma touche ². Naïvement j'ai essayé

²::
MsgBox, "vous avez appuyé sur '²'"
return

qui produit un joli

Il faut donc trouver un moyen d'identifier le code correspondant à la touche; la doc ahk sur le sujet est assez claire; il suffit d'ajouter #InstallKeybdHook dans mon script et de regarder les logs.

Le code de la touche ² est donc SC029; essayons ça :

SC029::
MsgBox, "vous avez appuyé sur '²'"
return

et ça marche! (il faut utiliser un encodage utf8 avec BOM pour avoir les caractères spéciaux affichés correctement)

La base : basculer sur une fenêtre existante

Maintenant il faut identifier la fenêtre cible et la rendre active. Pour ça le mode 'Window Spy' est très pratique, il permet d'afficher le titre, la classe, l'executable et le pid de la fenêtre active.

L'algo qu'on cherche à implémenter en pseudo code donnerait quelque chose comme

Si fenêtre active = terminal
  minimiser
  réactiver ancienne fenêtre
sinon
  sauvegarder ancienne fenêtre
  activer la fenêtre terminal

Pour ça on va se servir des fonctions ahk suivantes:

previous_active := ""

SC029::
  if WinActive("ahk_exe WindowsTerminal.exe") {
      WinMinimize, ahk_exe WindowsTerminal.exe
      if (previous_active) {
          WinActivate, ahk_id %previous_active%
      }
  } else {
      previous_active := WinExist("A")
      WinActivate, ahk_exe WindowsTerminal.exe
  }
return

Et si mon terminal est fermé ?

Là encore c'est assez simple, run, C:\PATH_TO_MY_APP\app.exe devrait faire le job. Mais comme mon terminal vient du windows store, je n'ai pas de lien direct pour l’exécutable. J'ai trouvé une astuce qui consiste à créer un raccourci pour l'appli en question et référencer le raccourci dans le script.

Win + R shell:appsFolder
clic droit créer un raccourci
run, path\to\raccourci

previous_active := ""

SC029::
if WinExist("ahk_exe WindowsTerminal.exe") {
    if WinActive("ahk_exe WindowsTerminal.exe") {
        WinMinimize, ahk_exe WindowsTerminal.exe
        if (previous_active) {
            WinActivate, ahk_id %previous_active%
        }
    } else {
        previous_active := WinExist("A")
        WinActivate, ahk_exe WindowsTerminal.exe
    }
} else{
    previous_active := WinExist("A")
    run, C:\PATH_TO\terminal_shortcut
}
return

Pratique, mais si j'ai besoin de taper un ² ?

Ajoutons un deuxième raccourci : Maj + ²

+SC029::
Send ²
return

La liste des modificateurs est ici

Bonus

une icône plus jolie :

I_Icon = C:\PATH_TO\icon.ico
IfExist, %I_Icon%
  Menu, Tray, Icon, %I_Icon%

Alernatives

En épinglant une appli à la barre des taches il est possible de reproduire l'ouverture/basculement. Il suffit d'appuyer sur Win + 1..9 correspondant au "numéro" de l'app dans la barre des taches

Retour sur SoCraTesDay à Rennes

Jean-François Le Foll — Wed, 06 Nov 2019 14:56:36 +0000

Vendredi 14 juin, j'ai eu la chance de participer à la première SoCraTesDay à Rennes.

Un forum ouvert d'une journée, autour du développement logiciel, des tests, de la qualité du code et du software craftsmanship.

Un forum ouvert ? Qu'est-ce que c'est ?

Un forum ouvert est une façon de structurer une conférence, sans speakers, où les participants construisent eux-mêmes leurs programmes en fonction de leurs connaissances et de ce qu'ils ont envie d'apprendre / échanger.

Une conférence dont vous êtes le héros !

Chacun affiche le(s) sujet(s), dont il a envie de parler sur un tableau (appelé Marketplace), aux intersections entre des créneaux horaires et des espaces nommés.

Marketplace du SoCraTes Rennes :

Liquid error: internal

Cet "agenda" continu de se construire au fil de la journée. En fonction des discussions, de nouveaux post-it vont être ajoutés pour approfondir certains sujets par exemple ou parce qu'une session a fait émerger une nouvelle idée à sur laquelle un groupe a envie de discuter.

Les règles de ce genre d'événement sont assez simples. En plus du respect et de la bienveillance, on retrouve également :

Quand c'est fini, c'est fini : il est important, à la fin de son créneau horaire, de s'arrêter pour laisser la place au groupe suivant. Ça ne veut pas dire pour autant qu'il faille arrêter la discussion, au contraire, il suffit simplement de trouver un espace libre pour continuer
La loi des deux pieds : à tous moments, vous êtes libre de suivre vos deux pieds pour quitter une session afin de rejoindre une autre session ou autre.

SoCraTesDay, on y parle de quoi ?

Et bien c'est ça qui est vraiment intéressant c'est qu'on y parle de tout ce dont les participants ont envie.

Personnellement, j'ai tendance à découper les sujets en trois catégories.

La technique, les outils

Lors de ce SoCraTest, il y a eu des sessions d'introductions à ELM et Rust, des katas de refacto de code legacy, des discussions autour des backends js, du code source de spring boot, de la gestion des logs avec ELK.

La conception, l'architecture, les méthodes

Il y a des sessions sur le BDD (pas les bases de données, mais le Behaviour Driven Development), sur le DDD en mode introduction sur les concepts stratégiques puis comment démarrer concrètement après, sur le TDD (voilà on fait le tour des xDD ;) ), sur les archis hexagonales, les archis micro-frontend, sur les tests e2e, sur la stabilité des logiciels, sur l'agilité (notamment sur les Scrum Masters qui ne font pas de dev).

La pratique, le métier, l'éthique

Enfin, il y a eu des discussions autour de la veille, du bonheur au travail, de qu'est-ce qu'un bon développeur, sur le mentoring, alternative au salariat ? (indépendant, monter sa boite), sur l'impact écologique des logiciels et le low tech et un retour d'expérience sur une organisation horizontale.

À quoi a ressemblé ton SoCraTesDay ?

Le temps de discuter un peu, de regarder la construction du market place, je suis arrivé sur la fin de la discussion concernant le principe de micro-frontend.

J'ai enchaîné ensuite sur la session DDD que j'avais proposé, car c'est mon intérêt du moment, remettre le métier du client au cœur de notre pratique et de notre code, parler le même langage que l'expert métier, sont des choses que je trouve importantes et presque toute ma veille du moment tourne autour de ce sujet.

Cette session était plutôt basée sur les concepts stratégiques : comment exprimer les domaines, contextes métiers, notamment via des Event Storming. Elle a suscité une deuxième session, plus "tactique" où on a parlé d'User Stories Mapping, de slicing horizontal, d'architecture à Uses Cases.

J'ai terminé la matinée par les sessions sur les Object Calisthenics et comment construire une roadmap dans une approche MVP.

L'après-midi, j'ai participé à la session sur les alternatives au salariat. Le groupe était assez hétérogène avec des salariés de boites classiques, de boites "un peu plus ouvertes", des indépendants (ou ex-indé) et moi en SCOP.

On a eu beaucoup d'échanges très constructifs, des retours d'expériences enrichissants car on n'avait pas tous le même vécu, rencontré les mêmes problématiques.

Au-delà du market place, il y a aussi toutes les discussions impromptues dans l'espace commun, l'occasion de faire plein de rencontres intéressantes.

En conclusion ?

Il s'agissait de ma seconde journée de forum ouvert après NewCrafts Bordeaux de l'année dernière et je dois dire que j'apprécie vraiment beaucoup ce format de conférence qui est vraiment basé sur les discussions, les échanges contrairement à une conférence traditionnelle où on écoute un speaker pendant 45 minutes.

Rendez-vous à NewCrafts Bordeaux en octobre maintenant ;)

Article publié originellement sur Medium

Qui sommes-nous ?

Jean-François Le Foll — Wed, 06 Nov 2019 14:32:23 +0000

Nous sommes un studio de développement logiciel.

Nous sommes trois développeurs passionnés qui travaillent ensemble depuis déjà plusieurs années et qui ont décidé de monter leur structure afin de mettre en pratique leur conception du métier de développeur et de la façon de construire des logiciels.

Nous considérons qu'apprendre est notre métier, apprendre de nouvelles technologies mais également une ouverture d'esprit et une curiosité pour comprendre le métier de nos interlocuteurs et échanger avec eux. Au fil des années nous avons travaillé dans des domaines très variés et fait de nombreuses rencontres humaines : pour nous, c'est aussi ce qui rend notre travail intéressant.

Que fait-on ?

Nous réalisons vos projets logiciels avec vous, en mettant en place une co-construction itérative et agile, basée sur les principes d'eXtrem Programming et du Software Craftsmanship.

Nous vous accompagnons également vos équipes sur la mise en place de bonnes pratiques agiles et techniques issues d'XP (développement itératif, livraison constante de valeur, TDD, pair programming, ...).

Pour nous, la meilleure façon de construire un logiciel passe par une bonne communication entre les différents acteurs ainsi que par la mise en place d'équipes de développeurs auto-organisés, responsables, ayant le contrôle/pouvoir sur leur travail de tous les jours.

En nous basant sur ce principe qui nous est cher, nous nous sommes constitués sous forme de Société COopérative et Participative (SCOP), afin de laisser à chacun la possibilité de prendre part aux décisions de l'entreprise, dans la transparence la plus totale.

Jean-François, Mathieu, Jérémy.

Article publié originellement sur Medium