Cette magnifique photo prise par ma chère et tendre est, je trouve, une belle métaphore de cette soirée de septembre, où, au détour d'un tas de vieux fichiers éparpillés sur un (encore plus) vieux disque dur, j'ai retrouvé le projet Hygi.

Hygi, qu'est-ce que c'est ?

Hygi est ma première application personnelle. Enfin, la plus ancienne dont j'ai retrouvé trace à ce jour. C'est un peu comme pour les dinosaures : on sait dire qu'un fossile est plus âgé qu'un autre, mais on n'est jamais sûr de ne pas en trouver un plus ancien.

L'objectif ? Suivre et améliorer mon hygiène de vie !

C'est donc un petit projet JAVA, développé probablement entre 2010 et 2011. Une petite interface reposant sur Swing / AWT, un gros paquet de JButton et JLabel, ainsi qu'une base MySQL embarquée... wait what ? Oui vous avez bien lu. Alors "embarquée", pas tout à fait. Dans le projet se trouve l'exécutable de WampServer, qui est installé et lancé par un somptueux Runtime.getRuntime().exec(...) ... 🤪 Pourquoi Wamp ? Pour installer MySQL, il faut suivre :D. Et oui, mes lacunes étaient grandes. Mais j'étais jeune ! (Mais admettez que ça a un peu côté malin)

Côté fonctionnel, un écran d'inscription, un de connexion (et oui ! je gérais des sessions !), et une succession de formulaire pour saisir mes bons et mauvais points quotidiennement : alimentation, sommeil, sociabilisation... tout y est ! Enfin, un écran de résultat donnant une vue synthétique des données saisies. Je suis assez surpris de la qualité du code de l'époque (non je rigole). Mais en tous cas, ça tourne encore.

Il m'aura juste fallu retrouver comment builder et lancer, un projet en Java. 🕵🏼‍♂️ C'est loin tout ça. Un petit coup de javac, de java, le classpath et hop, voici le résultat :

Allez, bonne nuit les enfants, si vous voulez le .jar, on peut s'arranger 😅

Tchao

C'était il y a 5 ans. 5 ans ! En 2015, après avoir fêté mes 4 ans en tant qu'apprenant développeur, j'ai eu l'envie de créer enfin quelque chose de concret. Fini les animaleries, byebye les calculatrices. Je voulais pouvoir montrer le fruit de mon travail à mes proches, et recevoir autre chose que des regards dubitatifs.

Ayant à l'époque besoin de progresser en anglais, car je devais passer le TOEIC afin de pouvoir valider mon futur diplôme d'ingénieur, je me suis dit que passer des heures à travailler avec un fonctionnel dans la langue de Shakespeare serait un exercice bénéfique.

Je me mis alors à la réalisation d'une app permettant d'apprendre les verbes irréguliers anglais, éternel épouvantail des collégiens et lycéens français. Je choisis Android comme terrain de jeu, pour être mesure de toucher le plus grand nombre.

Liste de verbes, personnalisation, quiz, entrainement, etc... Nombreuses furent les fonctionnalités qui, au fil de mon développement, vinrent s'ajouter à ce nouveau projet.

Vint alors le temps du partage. Comment montrer mon application ? À qui ? Réponse : À qui veut ! À tout le monde ! Destination le Play Store. Quelques ajustements plus tard, "Verbes Irréguliers Anglais" débarquait sur le store. En quelques mois, plus de 8.000 personnes l'installèrent et les quelques retours reçus furent pour le moins constructifs et permirent d'améliorer encore l'application.

L'un des retours cependant, me lança sur la piste d'un réussite plus grande encore.

"C'est top, j'aime beaucoup! Mais pourriez-vous faire la même chose pour les verbes allemands ?

Ah l'allemand. Petit défi graphique pour faire rentrer les mots à rallonge du langage de nos voisins. Ma réponse fut positive, et quelques semaines plus tard, une nouvelle application parut sur le Play Store.

Simple clone du projet, j'ai longuement regretté de ne pas avoir tout fait sur la même base de code, chaque évolution ou correction devant être copiée collée d'un projet à l'autre. Quelle méconnaissance de Git ! (que je n'utilisais pas, posez pas la question).

Sobrement appelée "Verbes Irréguliers Allemands", celle-ci rencontra un succès plus fort encore, avec au dernier décompte un total dépassant les 29.000 téléchargements ! Je vous avoue que je ne m'attendais pas à cela. Mais la concurrence était moins forte, et l'appli bénéficiait des améliorations de sa grande sœur anglaise.

Étudiant à l'époque, j'avais fait le choix de mettre un peu de publicité dans l'application, et de faire une version pro à 1€20 (demandez pas pourquoi .20, je ne sais pas). Un choix qu'aujourd'hui je ne referais probablement pas, mais qui me permis à l'époque de me payer le Coca nécessaire à ma productivité sur ces projets.

À ce jour, ces deux applications ne sont plus disponibles sur le Store, du fait des mises à jour exigées par Google que je n'ai pas eu le temps de faire. Mais elles reviendront, j'y travaille ! :)

En attendant, vous pouvez télécharger les APK (promis, la pub ne s'affiche plus) :
- Verbes Irréguliers Anglais
- Verbes Irréguliers Allemands

Allez, au boulot, interro surprise dans 1 heure :)

Corentin

Cas pratique que l'on retrouve un peu (trop) partout, la "TODO list" n'en est pas moins un parfait sujet pour étayer ses compétences front-end et back-end, à condition d'aller un peu plus loin qu'une simple liste statiques interrogeant une base de données mono-table-mono-colonne, on est d'accord.

Back

Cette fois, je n'ai pas opté pour la facilité : pas de Sails.js, pas de gros framework tout fait qui fait tout. Je me lance sur une stack Node.js basée sur express, une petite architecture maison 3-tiers (data / logic / api), et pour bien lier tous les ingrédients, j'utilise la méconnue librairie d'injection de dépendances Piquouze (article à venir).

Couche "Data"

Côté base de données, j'ai opté pour un duo MySQL / MongoDB, couplés respectivement avec Sequelize et Mongoose. Le choix d'avoir les deux technologies n'était clairement pas indispensable, et s'apparente plus à une expérimentation technique qu'à un choix stratégique. :)

Couche "Logic"

Toutes les règles métiers sont implémentées dans cette couche applicative, et celle-ci ne communique qu'avec la couche data. Techniquement, rien de très spécial ici : j'utilise quelques librairies qui sont pour moi des classiques : ramda, request-promise, bluebird, etc.

API

Comme bien souvent dans mes projets personnels, j'utilise une surcouche maison d'express.js, facilitant son utilisation avec mon système d'injection de dépendances. Cette surcouche simplifie grandement la gestion de l'authentification des appels entrants. Elle est encore à l'état expérimental, mais j'aimerais, à terme, la rendre open source.

Je n'ai pour le moment implémenté que l'authentification oauth basique (login/password/access token) et la connexion depuis un service tiers, ici Google.

Front

Parfois, une démo est plus parlante qu'un grand discours :

Côté front-end, je me suis basé sur la dernière version en date de React.js, pour profiter de toutes les nouveautés de la libraire, notamment les hooks.

J'ai utilisé react-beautiful-dnd pour le drag and drop des éléments, et si la mise en place a pris un peu de temps, le résultat est vraiment bluffant, aussi bien sur PC que sur mobile.

Démo

Assez parlé, voici le lien pour découvrir et vous faire une idée par vous-même : https://bfront.lab.corentindesfarges.fr/

Évolutions

Si pour le moment je n'ai pas une grande bande passante pour travailler sur ce projet, j'ai toutefois identifié les prochaines évolutions à venir :

• Gestion de listes (bah oui c'est une TODO list), un peu à la manière d'un tableau Kanban
• Ajout des deadlines et rappels automatiques
• Refonte de l'écran "Rapport quotidien"

Allez, c'est tout pour aujourd'hui !

À très bientôt

Corentin

Installer GitLab sur son propre serveur est une idée alléchante, mais qui s'avère être un parcours du combattant pour peu que vous ne soyez pas un habitué et que vous vouliez personnaliser un peu votre installation : mailing, HTTPS, et sous-domaine...

Pour ma part, après avoir pas mal tâtonner sur mon ancien VPS, j'ai fini par tout reprendre de zéro, et ai profité d'un serveur bien mieux dimensionner pour faire tourner convenablement mon instance GitLab, qui, il faut le dire, n'est pas si légère que ça.

Ici, je vous propose d'installer GitLab via l'image Docker officielle, et de l'exposer sur un de vos sous-domaines, le tout accessible en HTTPS, grâce à nginx et certbot (Let's Encrypt).

Docker

Commençons par le fichier docker-compose.yml

version: '3'

services:
    gitlab:
      container_name: gitlab
      image: gitlab/gitlab-ce:latest
      restart: always
      hostname: gitlab.corentindesfarges.fr
      environment:
        GITLAB_OMNIBUS_CONFIG: |
          external_url 'https://gitlab.corentindesfarges.fr'
          nginx['listen_https'] = false
      ports:
        - '30443:443'
        - '3080:80'
      volumes:
        - $GITLAB_HOME/config:/etc/gitlab
        - $GITLAB_HOME/logs:/var/log/gitlab
        - $GITLAB_HOME/data:/var/opt/gitlab

Il est important ici de déclarer les volumes à utiliser, afin de persister vos données et configurations.

J'ai choisi d'exposer GitLab sur les port 30443 (pour le HTTPS - 443) et 3080 (HTTP - 80) afin d'éviter tout conflit, mais vous êtes libre de choisir vos propres ports. Il faudra toutefois penser à les utiliser lorsque vous ferez le paramétrage du reverse proxy.

N'oubliez pas de définir votre hostname, en spécifiant le sous-domaine. Idem pour la variable d'environnement GITLAB_OMNIBUS_CONFIG, où il faut définir external_url. N'oubliez pas ici le protocol cible, à savoir https://.

Enfin, notez que nous allons configurer nginx nous-même afin de forcer l'accès en HTTPS, d'où le nginx['listen_https'] = false.

Définissez la variable d'environnement GITLAB_HOME sur votre serveur, comme suit :

export GITLAB_HOME=/srv/gitlab

Enfin, lancez la commande suivante pour démarrer votre instance :

docker-compose up

nginx

Il faut maintenant configurer votre reverse proxy, afin de rediriger correctement les appels vers votre instance sur votre sous-domaine.

Si ce n'est déjà fait, commencez par installer nginx :

sudo apt update
sudo apt install nginx

Créez ensuite le fichier /etc/nginx/conf.d/gitlab.conf, en remplaçant server_name par votre adresse (avec sous-domaine), et vérifiez que le port du proxy_pass correspond bien à ce que vous avez défini dans le docker-compose.yml.

# bloc de rediction http => https
server {
  listen 80;
  server_name gitlab.corentindesfarges.fr;
  return 301 https://$server_name$request_uri;
}

server {
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  server_name gitlab.corentindesfarges.fr;

  location / {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header HOST $http_host;
    proxy_set_header X-NginX-Proxy true;
    proxy_pass http://127.0.0.1:30443;
    proxy_redirect off;
  }
}

Enregistrez et relancez nginx :

sudo systemctl restart nginx

certbot

Comme d'habitude, on l'installe si on ne l'a pas déjà :

sudo apt update
sudo apt install certbot

Et puis on le lance, rien de plus simple ici :

sudo certbot --nginx

L'outil va automatiquement scanner vos configuration nginx, et vous proposera de choisir les domaines pour lesquels vous souhaitez obtenir un certificat SSL. Si vous avez plusieurs sous-domaines, pour éviter de gérer trop de certificat, n'hésitez pas à les resélectionner à chaque fois que vous lancerez la commande et choisissez (E)xpand lorsque ce choix vous sera suggéré.

Certbot vous proposera par la suite de rediriger vos appels HTTP vers HTTPS. N'acceptez pas, vous l'avez déjà fait dans votre gitlab.conf !

La suite ? Rendez-vous dans votre navigateur !

Développeur Android autodidacte à mes débuts, j'ai toujours eu une affinité pour la création d'application pour cette plateforme ; pouvoir me balader avec mes réalisations dans ma poche et les montrer à qui veut (et parfois qui ne veut pas :p) a un côté très satisfaisant, et ma courbe d'apprentissage fut plutôt rapide.

En 2016, j'ai eu la chance de découvrir React Native dans le cadre de mon travail, et de mener un projet from scratch avec une petite équipe et une expression du besoin particulièrement bien cadrée. Cela m'a permis de faire mes armes sur cette technologie qui aujourd'hui encore, est un de mes terrains de jeu préféré pour mes POC.

L'idée de WoloLan est très simple : pouvoir allumer (ou au moins sortir de veille) mon PC, qui me sert également de serveur multimédia, depuis mon canapé. Pourquoi ? Parce que bien souvent, ce dernier (le PC, pas le canapé) se met en veille entre deux épisodes de série, et m'oblige à traverser tout l'appartement pour le relancer. Alors oui, c'est vrai, ça permet d'éviter de m'enfoncer de manière permanente dans mon canap. Mais ce n'est pas une raison. Je pourrais également réglé mon PC pour éviter ces mise en veille intempestive, mais le challenge est moins intéressant.

L'interface est extrêmement simple, et permet de saisir l'adresse MAC de la machine à lancer. On peut également saisir l'adresse IP, mais cela ne fonctionnera que si le PC est allumé. L'intérêt ? Dans ce cas de figure, l'adresse MAC sera récupérée et l'utilisateur pourra la réutiliser ultérieurement. Il est également possible de sauvegarder une configuration (MAC + IP) afin de gagner un peu de temps.

WoloLan, est donc une appli Android basée sur React Native. Le réveil des PC distants se fait via l'envoi de "Magic Packet". React Native n'étant pas en mesure d'envoyer ses paquets lui-même, j'ai également développé un module en Kotlin (première fois!), appelé par React pour faire le travail.

J'ai ressortie mes notes de cours de réseau de DUT pour utiliser Wireshark - qui soit dit en passant est bien moins compliqué que dans mes souvenirs - et scruter le réseau à la recherche de mes Magic Packets.

Et voilà ! C'est tout ! Vous pouvez récupérer depuis le Store https://play.google.com/store/apps/details?id=fr.corentindesfarges.wololan :)

Pour que ça fonctionne, veillez bien à ce que le réveil par ce protocole réseau soit activé dans votre BIOS. ;)

Des années après la première version de mon application de gestion de la compta destinée à ma très chère maman, j'ai décidé de faire quelque chose d'un tout petit peu mieux.

Un grand coup de refresh dans un projet débuté en 2012 en JAVA, réécrit en 2013 en C# puis en C++/Qt fin 2014. Je me suis pas mal cherché, au fil de mes découvertes et de mes amours technologiques. Côté stockage des données, je suis également parti de loin, en passant par le tristement célèbre fichier plat (j'étais jeune!), SQLite, MySQL ou encore MongoDB.

2019, la React-ion

Il est parfois difficile de se dire : allez hop, on refait tout. Certains développeurs adorent ça, d'autres fuient ces situations.

Mais quand votre client (votre maman de surcroît) vous explique qu'elle n'utilise plus votre app parce qu'elle met 6 minutes 30 à démarrer (quand elle ne crash pas), difficile de lui expliquer que c'est normal, que c'est parce qu'elle a été compilée en mode debug sous Windows XP, que SQLite 3 n'est pas forcément hyper opti, et que les images sont en bitmap et pèsent 50 Mo. Il n'était pas non plus temps d'essayer de lui vendre un nouveau PC, au risque de m'entendre dire que ses cahiers de compte faits main ne coûtaient rien, eux.

J'ai donc préféré ne pas faire de diagnostic plus poussé, et en ai profité pour me lancer sur une techno que je connaissais bien, mais avec laquelle je manquais un peu d'occasion de pratiquer : React.js

Quelques grammes de redux, un bon filet de material-ui, et une pincée de react-select plus tard, et ComptAct version 2019 sortait de terre.

Côté serveur, j'ai opté pour un petit projet basé sur Sails.js, en implémentant une authentification oauth2 basique.

Démo

L'app est utilisée à ce jour par ma cliente préférée, mais pour plus de simplicité, le back et le front tournent sur un petit Raspberry Pi sur son réseau local.

J'ai également publié une version de démo ici : https://demo.corentindesfarges.fr

Je préfère vous prévenir tout de suite : tout n'est pas parfait, et j'ai été contraint de mettre temporairement de côté le développement de ce projet, l'essentiel étant qu'il soit suffisamment fonctionnel et agréable à utiliser.

Pas de responsive design, un code un peu vieillissant par rapport aux dernières features de React, et pour la version de démo : la base de données est réinitialisée toutes les 5 minutes, car l'application ne tourne pas sur un très gros serveur.

Voili voilou, j'espère que vous le trouverez quand même pas trop mal.

Corentin

En installant ce blog, et en voulant uploader un thème (un zip de 1.5 Mo), je me suis retrouvé confronté à cette erreur :

The file you uploaded was larger than the maximum file size your server allows.

Rassurant d'un point de vue sécurité, mais pas très pratique en l'occurrence.

Pour y remédier, rien de bien complexe : c'est du côté de nginx que ça se passe. J'ai choisi de ne faire la configuration que pour mon blog, on verra à l'avenir si d'autres applicatifs en ont besoin.

Le fix ? Une ligne, à rajouter dans le bloc server ou location du site en question :

server {
  ...
  client_max_body_size 2m;
}

On redémarre nginx et c'est parti !

sudo systemctl restart nginx

Vous préférez tout simplement désactiver la limite ? Remplacez la valeur de la directive par 0 (zéro, sans unité). C'est tout.

Le lien vers la doc pour les plus curieux : https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size

Post mortem

En configurant un nouveau site récemment, j'ai rencontré le problème suivant : la directive client_max_body_size n'était pas prise en compte, alors que je n'avais fait qu'un simple copié / collé de la ligne depuis cet article.

Après de longues minutes d'incompréhension la plus totale, après m'être entendu dire à maintes reprises "essaie encore une fois de redémarrer nginx, on sait jamais", j'ai remarqué que la ligne précédant ma directive ne finissait pas par un point-virgule... Pas d'erreur lors de redémarrage de nginx, tout semblait pourtant bien fonctionner. Mais non. J'ai donc terminé cette ligne comme il se doit, et tout est rentré dans l'ordre (après un redémarrage de nginx, oui!).

Morale de l'histoire : Bien souvent, l'erreur n'est pas là où vous la cherchez, mais elle n'est généralement pas très loin.

Cela fait maintenant quelques mois que j'avais envie d'essayer d'installer un petit Elastic sur mon serveur, pour jouer avec sans me soucier de casser des données.

Fin 2018 je m'étais pris au jeu de faire une installation "classique" sur mon VPS, et s'il n'a pas pris feu, c'est parce que ce n'est techniquement pas possible. Cette année, avec un modèle un peu mieux dimensionné, je me suis lancé, et au lieu de plomber ce nouveau venu à grand coup d'apt-get, j'ai choisi de passer par Docker.

docker-compose

Pour débuter, j'ai choisi d'utiliser docker-compose, plus pratique que la cli pour des lignes de 14km de long.

version: '2'
services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.8.1
    container_name: elasticsearch
    environment:
      - xpack.security.enabled=true
      - discovery.type=single-node
    volumes:
      - ./elasticsearch/data:/usr/share/elasticsearch/data
    networks:
      - elk-net
    ports:
      - "9200:9200"
      - "9300:9300"
  kibana:
    image: docker.elastic.co/kibana/kibana:7.8.1
    container_name: kibana
    environment:
      - xpack.security.enabled=true
      - ELASTICSEARCH_USERNAME=kibana
      - ELASTICSEARCH_PASSWORD=ahah
    networks:
      - elk-net
    ports:
      - "5601:5601"
    depends_on:
      - elasticsearch

networks:
  elk-net:
    driver: bridge

Service elasticsearch

Les données d'Elastic sont partagées les data avec mon répertoire ./elasticsearch/data (relatif au chemin depuis lequel je lance ma commande).

L'authentification est activée (il faudra donc configurer Kibana en conséquence).

Le porte 9200 est ouvert, ce qui me permettra d'accéder à mon instance (via le port 9200 également).

Le service utilise le network elk-net, ce qui lui permettra d'être appelé par Kibana.

Service kibana

Le service est configuré de manière à attendre que Elastic soit lancé (propriété depends_on) et partage le même réseau, elk-net, qui est défini plus bas.

Vous l'aurez deviné, le présent mot de passe ne fonctionnera pas, et vous ne pouvez pas le définir par vous-même automagiquement. Pour ce faire, une fois le fichier ci-dessus complété (vous pouvez laisser le mauvais mot de passe, ou retirer la ligne), lancez la commande suivantes :

mkdir -p $PWD/elasticsearch/data
chmod 777 -R $PWD/elasticsearch/data

docker-compose up --detach elasticsearch
docker logs -t -f elasticsearch

Assurez-vous de voir apparaître dans la console la ligne "Active license is now [BASIC]; Security is enabled", puis quittez le log (CTRL+C).

docker exec elasticsearch bin/elasticsearch-setup-passwords auto -b

Notez précieusement les mots de passe affichés à l'écran. Le premier qui va nous être utile sera PASSWORD kibana. Mettez de côté le PASSWORD elastic pour la suite. Il vous servira à vous connecter à l'interface web Kibana.

Modifiez votre docker-compose comme suit :

  kibana:
    ...
    environment:
      ...
      - ELASTICSEARCH_PASSWORD=VOTRE_PASSWORD_KIBANA

Vous pouvez désormais lancer le service Kibana :

docker-compose up --detach kibana

Au bout de quelques minutes, vous aurez accès à votre interface Kibana (si vous avez configuré correctement votre reverse proxy (sinon c'est par là [TODO]).

Pour vous connecter, utilisez le username elastic et le mot de passe PASSWORD elastic.

Et voila !

Sources

Configure security in Kibana | Kibana Guide [7.8] | Elastic

Elastic

Encrypting communications in an Elasticsearch Docker Container | Elasticsearch Reference [7.8] | Elastic

Elastic

How to set passwords for built-in users with docker-compose setup

Hey there, I am running an Elasticsearch 7.3.0 cluster with three nodes (on three different machines) via a docker-compose setup. Here is my elasticsearch and kibana service defined in docker-compose.yml: services: es-mdi: container_name: lxelk01-es-mdi image: elasticsearch:7.3.0 por…

Discuss the Elastic Stackapt-get_install_skil