Linkedin

Instagram

Blog Perso

Github

Contact


Je cherche les problèmes mais dans un seul et même objectif : les résoudre de la manière la plus cohérente possible. 

Cohérente car il existe généralement plusieurs solutions à un problème, encore faut-il bien appréhender les différentes contraintes, qu’elles soient techniques, métier ou même législatives, pour déterminer la plus à même de répondre au besoin. 

Depuis plus de dix ans j’interviens dans différents contextes, pour du développement (principalement JS et Go), de la conception (produit, architecture) ainsi que la gestion de projets techniques. 

Aujourd’hui j’interviens comme Freelance pour accompagner dans le cadrage et l’exécution, aussi bien avec les équipes produit que techniques. 

Vous avez un projet ou besoin de renforcer vos équipes ? Je vous invite à prendre contact soit via LinkedIn, soit Malt. 

À propos

Home

/images/pages/photographies/kualala/DSC_4304-4.jpg

J’espère pouvoir me souvenir toute ma vie de mes deux premiers voyages en Malaisie, ils ont été incroyablement impactant sur ma manière de concevoir le voyage et la perception du monde en général.

Pour faire court, la première fois que nous y sommes allés avec Farah c’était une nouvelle étape dans notre parcours de Digital Nomades (aujourd’hui en pause loooooongue), la première fois que nous partions aussi loin, aussi longtemps. Ce n’est pas loin de 6 mois que nous avons passés dans la région et très sincèrement, nous nous sommes vraiment régalés dans cette aventure. Nous avons tenté de profiter au maximum de l’environnement.

En rentrant nous avions bien des choses à raconter, à partager.

Un exemple tout bête est la vision d’unité et de "vivre ensemble" qui se dégage, cependant, l’année suivante, quand nous sommes repartis en Malaisie, cette vision de "vivre ensemble" a vraiment volé en éclat.

Ce qui a changé entre les deux voyages ?

Nous, notre perception du voyage, notre manière de "consommer" le voyage.

La première fois nous étions restés en surface.

Nous nous étions limités à vivre des expériences qui finalement étaient tournées vers nous-même. Que les choses soient très claires, nous n'avons pas le moindre regret concernant la première expérience, c'était génial. Par contre la deuxième fois nous nous sommes tournés vers le pays et ce qui s'y passe réellement. De cette manière, les fantasmes que nous avions pu nourrir la première fois se sont dissipés.

Est-ce que ça a fait disparaître notre amour du pays ? En aucun cas, au contraire, en le connaissant un peu mieux nous y sommes encore plus attachés, c'est aussi pour ça que la Malaisie nous manque tellement.


Kuala Lumpur

images/pages/posts/choisir-son-side-project/illustration.jpeg

Le dev c'est en grande partie le plaisir de résoudre des problèmes, alors quand il n'y a pas de problème, ou pas assez, nous avons une étrange tendance à en créer de nouveaux.
Pour dédramatiser la situation et surtout pour justifier le temps passé, nous les appelons "Side Project".
On ne va pas se mentir, en règle générale, nos Side Projects n'aboutissent jamais vraiment. Il y a plusieurs raisons à ça :
Aucun objectif précis.
Manque de temps et/ou de motivation une fois les premières heures passées sur le sujet.
Blocage technique

Pour ce qui est du manque d'objectifs précis, c'est un véritable problème, parce que sans savoir où nous allons, nous ne pouvons pas savoir quand mettre un terme au projet.
Nous avons tendance à toujours vouloir en ajouter un peu plus, toujours plus, de sorte que ce Side Project finit par devenir un chewing-gum collé à nos chaussures.
Il est donc nécessaire de tenter de fixer des objectifs assez rapidement dans le processus de mise en place du side project.

En ce qui concerne le manque de motivation, c'est assez fréquemment pour la même raison : le projet est souvent bien excitant que l'image que nous nous en faisions. Il y a souvent un écart assez important entre l'idée que nous nous faisions initialement de l'outil, avec une pelletée de fonctionnalités toutes aussi géniales les unes que les autres, et la réalité de l'exécution qui prend du temps, nous laisse confrontés à des blocages techniques ou même tout simplement une absence d’inspiration. A qui ça n'est pas arrivé de perdre un temps précieux par manque d'idée pour simplement nommer une fonction ?
Ajoutez à ça la nouvelle saison de Peaky Blinders et là c'est le drame.

## Choisir son Side Project

Pour résoudre en partie les problèmes présentés plus haut, nous pouvons nous baser sur une sorte d'arbre de décision pour bien choisir un Side Project.
En premier lieu, quel est l'objectif principal ?
Découvrir une nouvelle techno / technique / méthodo ?
Réalisation d'un outil exploitable ?
Se faire plaisir à coder ?
Évidemment, nous ne nous attarderons uniquement sur les deux premiers point, pour le dernier c'est comme le téléphone à table, chacun gère ça comme il veut.

### Side Project de découverte 

C'est très clairement le plus simple à cadrer.
L'objectif ici est d'obtenir une nouvelle compétence. Qu'il s’agisse d'une techno ou d'une technique, il suffit de fixer une destination et si tenir.

Par exemple, j'ai envie de mieux maîtriser Elastic Search. Aimant le rap et cherchant à voir les occurrences de certains mots pour voir comment ils s'imposent dans les titres, je vais me définir l'objectif suivant : 

Avoir une application me permettant d’indexer des paroles de rap avec les attributs suivants : <longue liste d’attributs...>.

* Cette application doit me permettre de faire une recherche pour un terme donné et me retourner les titres utilisant le terme.

* L'application doit également me retourner la fréquence d'utilisation de terme recherché par année, par mois et par département de l'artiste (ça peut être sympa d'observer comme un terme se répand).

À partir de cette description, je sais exactement où je veux aller. Je ne sais absolument pas comment m'y rendre au début, mais je sais ce que je veux faire et donc quand m'arrêter.

Autre exemple, je cherchais récemment à utiliser les fonctions d'agréation et de manipulation d'objet proposées par Postgresql. Pour atteindre cet objectif, je me suis listé le rapport que je souhaitais générer et à partir de là, j'ai travaillé dessus pour atteindre cet objectif. Une fois terminé, je suis simplement passé à autre chose.

## Side project All Inclusive

Là c'est le même problème que pour le Side Project de découverte sauf que pour celui-ci, en plus la nécessité de définir des objectifs, il faut embarquer des utilisateurs.

Concrètement, l'idée n'est pas de simplement se faire un outil pour le kif, mais de le faire pour quelqu'un, voir plusieurs personnes.

Nous avons tous dans l’entourage des gens qui ont des problèmes pas trop compliqués auxquelles nous pourrions apporter une solution passant par un projet web.

Je vais prendre un exemple tout simple et après j'arrête de raconter ma vie. Avec la nounou de mon fils, nous ne sommes pas à temps plein. Il y a donc un planning qui change chaque semaine. À côté de ça, nous sommes suivis pour le sommeil d'Ismaël et nous avons besoin d'alimenter un journal de sommeil avec les heures où il est couché, les heures d'endormissement et les heures de réveil.

Un Side Project All Inclusive pourrait être de faire une simple interface, idéalement orienté mobile, pour que notre nounou nous partage le planning et les informations relatives à la journée qui vient de se passer (dodo, repas, selles, ...).

De cette manière, nous aurions tout un tas d'avantages à résoudre ce problème :

1. De vrais utilisateurs font un retour sur l'application 
Des fonctionnalités peuvent émergées de la demande des utilisateurs 
2. Le fait que des vrais utilisateurs ajoute un peu de pression pour livrer quelque chose d'un minimum fonctionnel
3. Il va falloir livrer de nouvelles features, donc avoir la main sur la chaîne de déploiement de l'application

Alors là, tu vas me dire que c'est super tendu de vouloir faire ça, c'est un coup à passer pour une truffe si le projet est complètement buggé ou inachevé. Ce à quoi je te réponds que non, ça n'est clairement pas le cas pour les raisons suivantes :

* __Tu vas d'abord faire un MVP__, c’est-à-dire une version ultra-minimale du projet qui se contente de proposer la fonction la plus élémentaire de l'app (dans notre cas, soit le planning, soit les notes sur la journée), ensuite tu pourras itérer
* __Tu vas expliquer que c'est un prototype__ à la (ou "les") première personne qui va utiliser ton application et c'est impressionnant comment les gens peuvent faire preuve d'une véritable bienveillance

En plus, si ce projet fonctionne bien, qui sait, il y aura peut-être même moyen de le faire grossir et de le monétiser !


Comment bien choisir son side project ?

images/pages/posts/du-mvp-a-lapplication-stable/preview.jpeg


Souvent nous considérons des choses comme évidentes, tellement évidentes qu'il ne nous semble pas nécessaire de se poser la question de comment ça fonctionne.

Le problème, c'est que pafois, il est nécessaire de rentrer dans le détails et là, tu te sent un peu con.

C'est le cas par exemple des redirections HTTP, nosu asavons parfaitement ce qu'est une redirection 30x mais comment fonctionne-t-elles ? 





Ton CV du dois pouvoir le défendre


Si la réalisation d'un MVP ( Minimum viable product ) est l'étape la plus importante pour lancer un concept, le passage à une version réellement stable est certainement la plus critique.
La réalisation d'un MVP se doit d'être rapide, chaque jour ou semaine de perdu est un risque supplémentaire de perdre son marché, de se faire dépasser.
De ce fait, il faut agir vite, et pour agir vite il faut souvent bricoler, faire appel au premier développeur chaud pour pas de salaire en échange d'un poste de CTO, prendre des cours en ligne pour tenter de se débrouiller soi-même, ... agir vite n'est que très rarement synonyme de qualité et de performance.

*Après, il faut être clair, un MVP a un objectif:* tester un marché. Rien de plus. Alors il serait dans bien des cas contre productif de vouloir appliquer toutes les best practices dès le départ, au commencement d'un projet qui risque de ne pas se développer, qui risque de faire un flop.

## Mais si il n'y avait pas de flop ?
Si le projet se développe ? Est-ce que le bricolage initial va tenir la route ? 

Dans la majorité des cas la startup va se retrouver dans la situation suivante :
Le premier développeur de la boite ( qui est aussi CTO, DSI, Lead Développeur, ... ) détient la quasi totalité des connaissances métiers et de l'application.

Même sans le vouloir, il sera dans une situation assez catastrophique de rétention d'informations car il lui sera plus rapide de corriger les bugs lui-même, la nuit ou le week-end, que de déléguer, car pour déléguer il faut du temps, et le premier développeur de la boite, avec toutes ses casquettes, du temps, il n'en a pas.

Cette situation n'est la faute de personne, elle est presque un passage obligé car rare son les entrepreneurs qui peuvent aligner de quoi avoir une dream team dès le départ. Vu comment les cabinets de recrutement IT tournent à plein régime, il serait irréaliste de croire que trouver des ingénieurs est chose aisée.

À un moment la technique sera submergée par des bugs incessants, des demandes de features toutes plus importantes les unes que les autres car sans elles, les gros comptes prêts à signer ne signeront pas, mais à cause des bugs à fixer, il n'y a pas de temps pour les features, même en bossant le week-end.

Ce qui nous donne une situation où les clients actuels sont de moins en moins satisfaits à cause des bugs, des account managers qui en peuvent plus de gérer les remontés client, des sales qui désespèrent en ne voyant pas arriver les features conditionnants la signature des contrats juteux. Bref, c'est un bordel sans nom, toute la boîte a la tête dans le guidon ce qui empêche totalement de prendre des initiatives avec du recul.

Vous voyez de quoi je parle ?

## Vite des devs pour aider !

Vous devez recruter des devs, plus de devs, quoi qu'il en coûte, il en va de la survie du projet, mais les nouveaux devs, durement recrutés, il faut les former, leur permettre de prendre le produit en main, de se l'approprier, mais ca n'arrivera pas, ou difficilement, car n'oubliez pas, le Dev / CTO / DSI n'a pas le temps de déléguer, alors former ...

Arrivé à ce point c'est du coup de poker. La solution serait de faire une refonte, il y a un ou deux dev super chauds dans l'équipe et qui annoncent des délais de livraisons super courts. Pourquoi ne pas tenter le coup après-tout ? Ok ils ne produiront pas de feature pendant toute la période de refonte, mais après l'application sera stable !!

Sauf que, la connaissance métier est logée dans la tête du CTO / DSI / ... le délai annoncé d'un mois passe à deux, puis à trois, puis ...

Parce que pour faire une refonte il faut déjà avoir une connaissance des fonctionnalités, des échanges de données, il faut une doc ...

## Quelques conseils

* Dès le départ, versionnez
* Pour votre API, ayez une doc Swagger. Pour de vrai ! Pas une liste de routes sans la moindre info sur les entités et les paramètres
* Toujours pour l’API, vous utilisez Postman ? Super ! Partagez vos collections, en plus de proposer une collection des endpoints vous avez de quoi mettre en place des tests automatisées avec Newman
* La UI doit être documentée, partez d’un fork d’un framework comme Bootstrap
* Le code auto documenté n'existe pas, ajouter des commentaires ne prend pas longtemps et les commentaires peuvent même permettre de générer la documentation Swagger 
* Documentez vos fonctionnalités ! Qu’est-ce qui se passe quand je fais telle action métier ?

Du MVP à l'application stable

images/pages/posts/et-si-je-foutais-cette-feature-a-la-poubelle/illustration.jpg


J’aime coder, et parce que j’aime coder, il peut m’arriver de me convaincre que telle ou telle fonctionnalité pourrait être super utile, simplement parce que la développer serait assez excitant. Mais n’est-ce pas en réalité une forme de pollution du projet ?

Et si je foutais cette feature la poubelle ?

images/pages/posts/faut-il-hair-les-recruteurs/illustration.jpg


Dans ce billet nous allons revenir sur l’aversion que peuvent avoir les développeurs envers les recruteurs et sur la nécessité de les voir comme des partenaires plutôt que comme des ennemies.

En tant que Freelance, faut-il haïr les recruteurs ?

images/pages/posts/le-singe-du-pourquoi/illustration.jpg


Lors de la présentation de certains cas de test, j’ai été étonné par l’absence de définition de l’intérêt des tests effectués. Dans la majorité des cas, les étapes du cas de tests sont suffisamment évidentes pour ne pas avoir besoin d’ajouter du contexte supplémentaire. Par exemple, si le test consiste à allumer une TV pour s’assurer que nous arrivons bien sur l’écran d’accueil, il n’est pas forcément nécessaire de détailler pourquoi il est important que la TV s’allume. Dans des cas plus particuliers comme le contrôle de la bonne exécution de trackings, il peut être utile de savoir à quoi servent les pixels tracking en question et quel est le risque en cas de défaillance. 

## Le théorème du singe

Le théorème du singe est une expérience imaginaire mettent en évidence la transmission de peurs collectives.

Dans une pièce, un groupe d'environ vingt chimpanzés se retrouve confiné avec une banane suspendue au plafond, accessible uniquement par une échelle. Cependant, chaque tentative d'un chimpanzé pour grimper sur l'échelle déclenche un système qui inonde la pièce d'eau froide.

Très vite, les chimpanzés assimilent l'escalade de l'échelle à un déclenchement de la douche froide, et choisissent donc de ne pas grimper. Même après que le système d'eau froide a été désactivé, les chimpanzés, marqués par leur expérience précédente, continuent à éviter l'échelle.

Un nouvel individu est introduit dans le groupe. Lorsqu'il essaye d'atteindre la banane en grimpant l'échelle, les autres chimpanzés le repoussent agressivement. Le même phénomène se reproduit quand un autre chimpanzé est introduit, y compris par le premier remplaçant.

L'expérimentation continue jusqu'à ce que tous les chimpanzés d'origine, ceux qui ont directement connu les douches froides, soient remplacés. Malgré cela, les singes persistent à ne pas grimper l'échelle, punissant tout individu qui tente l'expérience, même si aucun d'eux n'a personnellement vécu la douche froide et ne comprend réellement pourquoi l'escalade est interdite.

## Le conformisme à toute épreuve

Il pourrait sembler logique que les personnes nouvellement intégrées posent des questions sur les interdictions, par exemple celle de monter sur une échelle. Néanmoins, diverses expériences, dont celle menée par Asch, ont dévoilé notre surprenante tendance à adopter des comportements préétablis sans nécessairement les contester.

Il arrive souvent que nous n'osions pas interroger le "pourquoi" d'une pratique qui nous est présentée. Cela peut découler de plusieurs facteurs : la crainte d'être jugé ignorant, l'aspiration à être accepté par le groupe, ou tout simplement l'habitude d'adhérer aux normes en vigueur.

Par ailleurs, la psychologie sociale nous éclaire sur notre inclination à aligner nos attitudes et nos convictions sur celles des autres, un phénomène que l'on appelle conformisme. Cette propension peut s'avérer puissante, même si nous ne saisissons pas la raison fondamentale d'une règle ou d'une coutume.

À titre d'exemple, un nouveau membre d'une entreprise pourrait remarquer que personne n'utilise l'ascenseur le vendredi. Il pourrait décider de faire pareil, sans comprendre le pourquoi du comment, uniquement parce qu'il remarque que c'est le comportement adopté par le groupe. Il pourrait également hésiter à poser la question, par peur d'être perçu comme un perturbateur ou quelqu'un qui ne comprend pas les usages de l'entreprise.

L'expérience d'Asch démontre que le conformisme peut grandement influencer notre comportement, y compris lorsqu'il s'agit de jugements objectifs. Si tous les membres d'un groupe donnent une réponse manifestement erronée, l'individu peut se sentir obligé de se conformer, même s'il sait que la réponse du groupe n'est pas correcte.

## De l’importance de demander pourquoi

Même si la pression collective peut être écrasante, il est essentiel de s'interroger afin de comprendre les raisons sous-tendant une procédure, une méthodologie, une décision technique, ou un cas de test.

L'acte de questionner offre l'opportunité d'apprendre ce qui a conduit à l'état présent des choses. Il nous permet d’appréhender le pourquoi des situations, de transmettre ces connaissances à autrui, d'avoir une vision plus étendue, et potentiellement de contester la pertinence d'une décision technique, d'un processus ou d'un scénario de test.

Poser des questions, c'est aussi rompre avec une exécution simplement mécanique des tâches.

La prochaine étape consiste à transformer cette habitude interrogative en un outil précieux pour améliorer constamment nos pratiques. Chaque question peut conduire à des améliorations, à une meilleure compréhension des situations, et peut même aboutir à de nouvelles solutions ou méthodes. En effet, c'est en se posant des questions que nous pouvons véritablement innover et progresser. Donc, n'hésitez pas à interroger et à remettre en question - le potentiel d'apprentissage et de croissance est immense.

Et si les singes demandaient pourquoi ?


Souvent nous considérons des choses comme évidentes, tellement évidentes qu'il ne nous semble pas nécessaire de se poser la question de comment ça fonctionne.

Le problème, c'est que pafois, il est nécessaire de rentrer dans le détails et là, tu te sent un peu con.

C'est le cas par exemple des redirections HTTP, nosu asavons parfaitement ce qu'est une redirection 30x mais comment fonctionne-t-elles ? 









Comment fonctionnent les redirections web ?

images/pages/posts/premiere-perm-depuis-18-mois/andrei-devambez-la-charge-boulevard-montmartre-1902.jpg

18 mois sans vivre cette liberté. 18 mois sans pouvoir pleinement profiter de mon temps et ainsi aller à la découverte de nouvelles choses.

Je ne sors pas d’une peine de prison on, je n’ai pas été sous le coup d’une quelconque privation de liberté non plus. Je suis juste papa d’un enfant de 18 mois et aujourd’hui, c’est le premier depuis sa naissance où toutes les planètes sont alignées : 

- Je ne travaille pas
- Je suis à Paris
- Ismaël est gardé
- Farah est au travail

Alors effectivement, en soi, être sur Paris n’est pas une obligation pour profiter de la liberté, cependant, une des libertés qui me manque le plus c’est de pouvoir flâner en ville, de pouvoir m’arrêter dans des expos, et disons le franchement, coté expo, en province l’offre est assez restreinte. Ce n’est pas un reproche, il y a une logique à ça, mais bref, trêve de digressions.

Aujourd’hui je passais au Petit Palais pour visiter l’exposition dédiée à *André Devambez* que je ne connaissais absolument pas mais les affiches m’avaient donné envie de le découvrir.

## La découverte du reportage photo, sans photo

Les premières décennies du siècle passé me passionnent, comme beaucoup, j’aime rêver sur l’atmosphère que les rues parisiennes dégageaient, la folie artistique, technique, c’est une époque incroyable.

Parmi les différentes œuvres de Devambez, certaines ont la particularité d’être purement et simplement de la photo reportage.

![alt text](/images/pages/posts/premiere-perm-depuis-18-mois/reportage.png)

Dans les œuvres ci-dessus, nous pouvons voir des angles particulièrement étonnants, allant du point de vue de la fenêtre de l’artiste sous laquelle se produit une charge de police à la vue de dessus d’un ballet aérien.

Personnellement c’est la première fois que je tombe sur ce type de peinture et c’est un véritable plaisir de voir l’histoire sous cet angle particulier et si proche de ce qu nous sommes habitués à voir aujourd’hui. 

## La guerre comme fardeau commun

Une chose également remarquable durant cette exposition, ce sont les différentes peintures et eaux-fortes dépeignant la grande guerre.

Les scènes de vie de la guerre, des attaques, sont une claque qui nous rappelle encore une fois quel a été le sacrifice de nos anciens.

![alt text](/images/pages/posts/premiere-perm-depuis-18-mois/eaux-fortes.png)

Il y a certes un devoir le mémoire indiscutable à ce sujet, mais la mémoire ne peut se focaliser que sur le sacrifice. Il est également nécessaire de chercher à comprendre comment les peuples de cette époque voyaient l’idée de nation et de ce fait, l’idée de se sacrifier pour celle-ci. Il fallait y voir quelque chose de parfaitement transcendantal pour accepter ce sacrifice ultime. 

![alt text](/images/pages/posts/premiere-perm-depuis-18-mois/vive-la-france.png)

C’est également une piqûre de rappel sur le fait que toute la nation a participé à cette guerre. La mobilisation touchait tout le monde. Notre artiste a participé à ce sacrifice. En 1915 il se retrouva d’ailleurs hospitalisé, gravement blessé, après avoir été touché par des éclats d’obus.

Première perm’ depuis 18 mois

images/pages/posts/quand-les-developpeurs-se-mettent-au-tofu/preview.jpg


Il existe de nombreux plats à base végétale reprenant les appellations des plats / produits animaux.
Du lait de riz, du steak de tofu,  saucisses de seitan, fromage végétal …
Il en est de même pour le produit sans porc. Nous pouvons retrouver du bacon de dinde ou encore des lardons de poulet.

Ce n’est pas absurde, c’est nécessaire. Nous, humains, avons tendance à vouloir identifier de nouvelles choses par ce que nous connaissons déjà ou faire correspondre nos spécificités à notre environnement.

## Dans le développement, c’est la même.

Quand un développeur Java va commencer à faire du Javascript, il va avoir tendance à appliquer les principes qu’il utilise couramment en Java, c’est classique.
C’est certes un réflexe, mais ça pose plusieurs problèmes: 
* Vouloir appliquer des paradigmes provenant d’un autre langage a tendance à nous forcer à tordre le langage que nous utilisons maintenant 
* Vouloir appliquer les paradigmes d’un autre langage à celui que nous utilisons révèle souvent une absence de volonté d’apprendre les paradigmes du nouveau

Ce sont des problèmes majeurs parce que les utilisateurs d’un langage influent fortement sur le dit langage.

Ainsi, si une grande partie des gens qui se mettent à Go viennent du Java et que beaucoup d’entres-eux veulent faire du Java en Go, nous allons voir apparaitre un tat de projets Go avec des couches d’abstraction qui sont en décalage total avec la philosophie de Go.

De même, en cherchant à appliquer les paradigmes d’un autre langage avant-même de chercher à comprendre ceux du langage que nous commençons à utiliser, nous nous retrouvons forcés de faire des contorsion pour que ça colle.

Ce billet n’est au final pas sur Go mais sur le fait de pratiquer un nouveau langage. Être polyglotte peut apporter une grande richesse dans son quotidien de développeur, encore faut-il prendre le temps et la peine de s'intéresser aux principes fondamentaux du langage ainsi que ses idiomes.

Ça permet d’avoir plusieurs points de vue sur un même problème, de voir plusieurs implémentations d’un même principe.



Quand les développeurs se mettent au tofu

images/pages/posts/reconverstion-dans-le-numerique/illustration.jpeg

Se reconvertir dans le web, ok mais pour faire quoi ?


Saviez-vous qu’une loi contraignant les chaines de télévision à diffuser très exactement les mêmes publicités sur tout le territoire avait été récemment modifiée pour rendre possible ce que l’on appelle la Télévision Adressée, ou Segmentée ?

La TV Ségmentée, la télévision un device comme un autre ?

images/pages/posts/je-suis-un-dev-qui-blog-sur-wix-cest-grave-docteur/preview.webp


Généralement, nous avons tendance à considérer qu'un développeur doit publier son blog via une solution orientée dev. Une solution faite maison, un générateur de site type comme Hugo ou Next.

Aujourd'hui nous constatons que des solutions comme Medium offre plus de possibilités et de visibilité, d'ailleurs j’aurais parfaitement pu faire ce blog sur Medium, mais avec Farah nous cherchons à mieux connaitre les outils de création de site web sans connaissance technique.

Je suis un dev qui blog sur Wix, c'est grave docteur ?

Alors que des ouvriers travaillaient dans les salins, un bête différent entre ouvriers français et italiens dégénèrera jusqu’à donner lieux au plus important pogromes connu en France contemporaine. Suivant les sources, c’est entre 8 et 150 italiens auraient été tués, à coup de pierre, de couteau, de feux, tout a été bon pour chasser, blesser, tuer. Par la suite c’est une véritable polémique judiciaire qui s’en est suivie suite à l’acquittement de la totalité des meurtriers par le jury d’assises. 


[Bella Ciao - Baru](https://www.futuropolis.fr/9782754811699/bella-ciao-1.html)
[Au cœur de l’histoire - Le massacre des italiens d’Aigues-Mortes](https://youtu.be/lG7Z9nOL8L0?si=LOY7nLmZc6PvY9wu) 
[Le massacre des Italiens. Aigues-Mortes, 17 août 1893](https://www.histoire-immigration.fr/programmation/l-univercite/le-massacre-des-italiens-aigues-mortes-17-aout-1893) - Histoire de l’immigration (musée)

Les italiens furent chassés et tués en 1893 à Aigues-Mortes

D'après les travaux de Debashish Bhattacharya, ça serait en grande partie à l'aide de virus que certaines algues auraient obtenus les gènes leur permettant de rester sur notre belle planète.

[Epsilon, numéro 36](https://www.epsiloon.com/tous-les-numeros/n36/)

Si les algues sont sur terre, c'est en grande partie à l'aide de virus géants

Dans un soucis particulier du détails, il a été jusqu’à se faire prêter des morceau de cadavres pour le conserver dans son eye-liner afin de mieux maîtriser leur représentation. Pour cette œuvre il a également été rencontrer le charpentier du radeau (la « Machine ») qu’il intégra dans le tableau. 

Géricault avait jusqu’à se faire prêter des morceaux de cadavres pour réaliser le radeau de la méduse

Aujourd'hui j'ai appris qu'au 15ème siècle, le pouvoir pontifical organisait un monopole, celui de l'alun après la découverte de la mine de Tolfa et suite à des grandes difficultés d'approvisionnement du fait des conquêtes turc. L'alun était un matériau extrêmement important dans divers domaines comme l'industrie du textile, du tannage, de certains verres vénitiens ou encore dans la pharmacologie.

*Marchands et banquiers du Moyen Âge - Jacques Le Goff (page 22)*

Le pouvoir pontifical a organisé un monople de l'alun au 15ème siecle

C'est en 1726 que la police de Paris a rendus obligatoire de clouer un panneau avec le nom de la rue sur la première et dernière maison de chaque rue afin de pouvoir s'y retrouver. Ce n'est cependant qu'en 1844 que les plaques émaillées que nous connaissons ont fait leur apparition.

*Paris Méconnu - Jacques Garance et Maud Ratton (page 264)*

Il a fallu attendre 1728 pour s'y retrouver dans les rues de Paris

Sur les 37 ponts et passerelles que compte la capitale aujourd'hui, trois d'entre eux n'ont pas eu la chance de recevoir un nom.

Peut-être est-ce dû à l'usage des ponts anonymes ?
Quoi qu'il en soit, les deux ponts permettant au périphérique parisien de passer au-dessus la seine, ainsi que le pont du RER C au niveau de l'île aux cygnes, n'ont pas eu l'honneur d'être baptisés.



*Ponts de Paris: découverte & Histoire - Jean-Marc Larbodière (page 14)*

3 ponts parisiens n'ont pas eu la chance d'être nommés

L'échelle de Scoville mesure la piquance des piments en quantifiant leur concentration en capsaïcine, le composé chimique responsable de la sensation de chaleur. Développée en 1912 par Wilbur Scoville, elle utilise une méthode où la capsaïcine est extraite et diluée jusqu'à ce que la chaleur ne soit plus détectable par un panel de testeurs. La dilution nécessaire détermine le score en unités Scoville (SHU).

Aujourd'hui, on utilise souvent la chromatographie liquide à haute performance (HPLC) pour mesurer directement la concentration de capsaïcine, offrant des résultats plus précis. Par exemple, un poivron doux a 0 SHU, un Jalapeño entre 2 500 et 8 000 SHU, et un Carolina Reaper peut atteindre jusqu'à 2 200 000 SHU. L'échelle de Scoville est essentielle pour comparer et standardiser le niveau de piquant des piments et des produits alimentaires épicés.

Comment fonctionne l'échelle de Scoville

Aujourd'hui j'ai appris que les musiques diffusées sur Skyrock étaient accélérées à hauteur de 2.4% (pitch). Si certains évoquent le fait que ça rendre les titres plus "punchy", d'autres évoquent le fait d'avoir des titres plus court pour augmenter l'espace publicitaire disponible.