Thought Metamask is the standard application to discover the real web3,
there is a major security issue that could destroy all your funds. Ledger resolves this.
<hr>
Note: This is not an advertisement to Ledger, nor a paid article. You can replace Ledger by <a href="https://trezor.io/">Trezor</a>.
<h2>Steps of crypto discovery</h2>
The first step of discovering cryptocurrencies is to buy some on a centralized exchange like Binance or Kraken.
But you will understand the power of the blockchain only when you will have some tokens in a wallet like Metamask.
If you still didn’t do it, try it !
<h2>Dangers for your filesystem</h2>
If you have a good amount of money, then it’s time to have a hard wallet. Why ?
If an attacker has access to the filesystem of Metamask, then he will get your private keys and you will loose all your funds ☠️.
I often say that the web is the safest place, and that you don’t need an antivirus. If you don’t do anything stupid, you are probably ok.
Well, that’s not totally true. First you may be more stupid than me 😁 and I was once stupid enough to give my credit card number to a fishing web page.
If you are a coder or if you use a professional tool, a vicious plugin or an open source dependency can have an extended access to the filesystem. This happens sometimes when an open source developer gives its project to a nice contributor. This gentle contributor is the attacker. He will create an vicious update, and you will trust it.
It’s also possible for a chrome extension to <a href="https://stackoverflow.com/a/44948662/968988">read your filesystem</a>. Do you know all the permissions of your chrome extensions ?
For example permissions for my VPN extension are quite generous :
<img src="./images/vpn.png" alt="VPN permissions">
<h3>The right protection : Moving to Ledger</h3>
If your file system is exploited, private keys in Metamask will be stolen and your assets gone.
There are two major benefits of using Ledger :
<ul>
<li>It keeps your private key away from Internet</li>
<li>There is a very very low surface of attack, which is very important</li>
</ul>
Through the last few years, Ledger had <a href="https://donjon.ledger.com/lsb/">some minor security problems</a> only. Some would say that it’s so uncomfortable that it reduces attacks because you won’t use much of the DeFi capabilities. That’s not totally false.
<h3>When will you use Ledger ?</h3>
Keep Metamask as a purse for daily stuff, experiments, and Ledger account for your mid-long term savings. You don’t want to touch the Ledger too much because it needs some boring clicks on the device.
For example I use Metamask for my 400% APY farming on Elrond that I harvest almost daily. I farm on my Ledger account a stronger amount on 20% USDC/USDT that I can harvest quarterly. I have also put on Ledger my <a href="https://www.indexcoop.com/dpi.html">Index Coop ETFs</a> and <a href="https://app.stakedao.org/0x452c075125F04582771C0A420B80218894754991/strategies">StakeDAO</a> native tokens - there is only to wait.
<img src="./images/dpi.png" alt="DeFi Pulse Index">
<h3>Ledger with Metamask and DeFi</h3>
Metamask was not designed for DeFi, but for receiving and storing native tokens. Before interacting with smart contracts, you have to allow Blind Signing for each tokens you play with.
<img src="./images/blind-signing.png" alt="Blind signing">
This must be done again each time there is an update 😐.
Also there is a real annoying problem with other EVM, such as Polygon or Celo. You can’t see your assets if you have not linked your Ledger with Metamask
<img src="./images/connect-hardware-waller.png" alt="Connect hardware wallet">
Ledger will give you the same address for all EVM link chains, such as Ethereum, Polygon, Fantom, Celo, Avalanche... But as early 2022, you will only see tokens on Ethereum chain.
<img src="./images/ethereum-chain.png" alt="on ethereum chain">
That’s not good ! It’s on ethereum chain.
The documentation is really not good, and you can find on YouTube some tutorial <a href="https://youtu.be/TaFjuk1rQa0?t=148">sending matics</a> on Ethereum chain for 20$ transaction 😕
What you must do is connect your Ledger as an hardware wallet to a regular Metamask. This will give you another account on Metamask with your Ledger address. Then on Metamask, you can easily switch to Polygon and see your money on the Ledger account.
<img src="./images/connection.png" alt="connection">
<h3>Next step : Put your Ledger in a bank</h3>
If you have 20k$+ in your ledger, please give us all some security and put your Ledger in a bank. Some <a href="https://coconuts.co/hongkong/news/crypto-trader-kidnapped-beat-by-gang-demanding-hk30-million-ransom/">brutal kidnapping</a> have been reported here and there and we don’t want this to be common. Let them know there is not much to earn.
My personal rule is to have less than 5k$ in Metamask. If it goes up, I send it to the bank.
A bank chest cost around 100$ a year. It will be even less easy to use your Ledger, but for most of your long term asset, it should be ok.
With the magic of smart contracts with proxys, the ledger account could farm, and benefits can go to the Metamask account. This is still to be developed but it will surely come soon 😊

Ledger versus Metamask

Setup as quick as possible your professional environment for learning web3 coding.
<hr>
This article will explain to regular developers how to setup a local environment for coding, testing and deploying
some Ethereum-like blockchains. I will give you some best practices and valuable web resources, so that you can start your
Web3 journey comfortably.
TL;DR; Watch this <a href="https://www.youtube.com/watch?v=62f757RVEvU">Truffle beginners</a> video
from EatTheBlocks.
<h2>Where to start</h2>
You can very quickly start using <a href="https://remix.ethereum.org">Remix IDE</a>. It's an online webtool. I have been able to deploy
<a href="https://bscscan.com/address/0x5eA1866F3b2c5EA4baBE9C5DB2F920CB9968560E">my first token (RBTA)</a>
with it. It's yet another shitcoin, but you can buy some to tip me 😊
To deploy the RBTA token, I used this tutorial <a href="https://www.youtube.com/watch?v=h4gQD7R1r94&#x26;t=298s">by Ivan on Tech</a>
<img src="./images/remix.png" alt="Remix Ide">
You can also learn solidity and web3js with <a href="https://cryptozombies.io/en">Cryptozombies</a>. It's quite deep by the way, but there is no
creativity as you must exactly type the correct line.
<img src="./images/cryptozombies.png" alt="Cryptozombies">
<h2>Use a local IDE</h2>
Remix is fun for one day, but you want your files with solid tooling. You will code some Solidity but also some
React or Vue for the web, and you probably want to keep your beloved tooling.
As I'm a Jetbrains fan, I added the Solidity plugin backed by Jetbrains. It brought some bugs, so I had to remove it then reinstall it. It's
quite unusual... but it happened
<h2>Use truffle</h2>
Truffle is a tooling framework. You have a set of preconfigured tools, but you don't
add their code.
Install it using <code>yard add truffle</code>. I would avoid installing it globally, so that you control exactly the version. In
that case you would type <code>node_modules/.bin/truffle</code> instead of just <code>truffle</code> - there are some tips for npm pros on the web.
You will be able to :
<ul>
<li>compile your code and create contracts : <code>truffle compile</code></li>
<li>make automated tests of your contracts : <code>truffle test</code></li>
<li>deploy the contracts :
<ul>
<li><code>truffle develop</code> will start the chain and open a console</li>
<li><code>truffle migrate --reset</code> will redeploy all contracts</li>
</ul>
</li>
</ul>
<a href="https://eattheblocks.com/">EatTheBlocks</a> team makes great contents on Solidity coding. Here is the one
for <a href="https://www.youtube.com/watch?v=62f757RVEvU">Truffle beginners</a>. This video is mandatory !
<h2>Use ganache</h2>
Ganache is a tool that allows you to run an ethereum blockchain with plenty of options. Truffle is using Ganache behind
the scene, but it's useful to be able to manage it yourself. We are coders, so we will use the CLI version 😁.
Install it with <code>yarn add ganache-cli</code>. Like with truffle, avoid installing it globally.
<ul>
<li><code>ganache-cli</code>: start a brand new blockchain</li>
<li><code>ganache-cli -db "./db-path" -m "bread car ... color"</code> : start a persisting blockchain with defined account</li>
</ul>
Here is the <a href="https://www.youtube.com/watch?v=AS2_uPSTk5E">EatTheBlocks Ganache video</a>.
<h2>Test and mocks</h2>
It's quite easy to test a Solidity contract. There is one major problem though. You often want to inject an
address - the oracle address in my case - and only the contract owner should do this. But while coding, you don't know the
owner address yet.
The idea is to make a mock contract. I code in a MockCodeFan.sol file that is the copy of the final <code>CodeFan.sol</code>, but
adding these lines at the end:
<pre><code class="language-solidity">contract MockCodeFan {

 // might be constant
 address private OWNER = 0xf17f52151EbEF6C7334FAD080c5704D77216b732;
 address private ORACLE = 0xf17f52151EbEF6C7334FAD080c5704D77216b732;
 
 function setOracle(address oracle) public{
 require(msg.sender == OWNER);
 ORACLE = oracle;
 }
 // ....
 /**
 * TESTABLE FUNCTIONS and events - Should be deleted in deployment
 */
 function setOwner(address owner) public{
 OWNER = owner;
 }

 event Debug(address _from, string domain);

}
</code></pre>
So in the test I can start with
<pre><code class="language-js">
 let [johndoe, nik, oracle ] = accounts;
 await contract.setOwner(nik);
 await contract.setOracle(oracle, {from: nik});

</code></pre>
<h2>Debug</h2>
Now that you have Solidity code, you want to understand what's going on before sending millions into the contract. But there
is no <code>console.log()</code> or debugger attachable in Solidity 🤷. You don't easily know what's
going on in the machine.
The technique is to create a Debug event and listen to it while testing.
<pre><code class="language-solidity"> event Debug(address _from, string domain);

 function addSite(address user, string calldata domain) external {
 emit Debug(user, domain);
 require(msg.sender == ORACLE);
 // ...
 }
</code></pre>
To simplify things, I used <a href="https://github.com/rkalis/truffle-assertions">truffle-assertions</a> library :
<pre><code class="language-js">const truffleAssert = require('truffle-assertions');
result = await contract.addSite(oracle, domainNames[0],
 {from: oracle});
// -> will display the event
truffleAssert.prettyPrintEmittedEvents(result); 
</code></pre>
<h2>Next step</h2>
I used Remix to deploy my first token, Truffle for my first real projects. And I will probably try <a href="https://hardhat.org/">Hardhat</a> soon.
The main reason is that you can use <code>console.log()</code> directly in the solidity code (wow 😁) and 0xGorilla created
<a href="https://github.com/defi-wonderland/smock">Smock</a>, a mock plugin for Hardhat. That proves Hardhat can be much more flexible than
Truffle. But as it gives a lot of options and plugins before starting, I would not start directly with it.
Here is the adoption table of major web3 companies
<img src="./images/tool-adoption.jpeg" alt="Web3 Tooling adoption">

Tooling for Solidity coders

La Blockchain n'est pas qu'un Ponzi. Cet article explique la provenance de l'argent qui abbreuve la DeFi.
<hr>
Cet article propose de l'information, pas des conseils financiers. N'investissez que de la fun money : ce que vous pouvez perdre sans soucis !
<h1>Le Yield Farming des cryptocurrencies : d'où vient l'argent magique de la DeFi ?</h1>
Le Yield farming - que l'on peut traduire comme agriculture de rendement - est un processus permettant de générer plus d'actifs
en partant d'un portefeuille initial. Ce processus peut utiliser des stratégies très agressives ou plutôt passives.
Pourquoi le nommer Yield farming ? Dans mon potager, je peux combiner des plantes, faire une rotation des cultures,
repiquer une plante... ou juste jeter des graines.
Le yield farming propose la même logique, produisant ainsi plus ou moins de revenus. Certaines stratégies sont conçues
pour augmenter l'espérance de gain, d'autres pour réduire la complexité ou minimiser les risques.
Vous avez tout le champs en expansion de la DeFi (Decentralized Finance), qui propose beaucoup d'outils
gratuits pour extraire le maximum de valeur à court ou moyen terme.
Cet article n'est pas un tutoriel qui vous montre comment gagner à tous les coups, ni un dictionaire technique.
Je vais plutôt montrer que la crypto n'est pas qu'un Ponzi, en appuyant sur la provenance de l'argent.
Pourquoi certaines personnes vous donneraient de l'argent sans vraiment travailler ?
(Pour cette version française, je garderai après définition l'ensemble du verbiage anglais, puisque c'est ainsi qu'il vous
sera présenté si vous creusez plus loin dans la DeFi)
<h3>Staking pour la sécurité</h3>
En détenant 32 ethers et un bon ordinateur, nous pouvons sécuriser le réseau Ethereum 2.0 et en gagner des revenus.
Entre 5% par an (0.05x32 = 1.6 eth) s'il y a beaucoup de validateurs faisant déjà le même travail que vous,
et jusqu'à 20% si ces validateurs venaient à manquer. Le revenu actuel est de 7%, et il ne faut pas espérer gagner beaucoup plus.
Il est par contre possible - mais pas certain ! - que la conversion en dollar de l'ethereum gagné augmente pendant cette année.
Il est également possible de sécuriser d'autre blockchains ayant un consensus de type Proof of Stake, tel que Fantom, Solana,
Avalanche, Terra, etc. Chacune aura un rendement différent et des exigences de materiel et configuration différentes.
Accrochez-vous pour avoir <a href="https://docs.solana.com/running-validator/validator-reqs">une machine Solana</a> !
Staker est le fait de détenir vos ethers ou d'autres tokens, que vous lockez dans un Smart contract pour qu'ils puissent
jouer leur rôle défini dans le code de ce smart contract.
Techniquement, vous transmettez vos tokens à l'adresse de ce smart contract et espérez que le code soit suffisamment bien
écrit pour pouvoir récupérer ces tokens quand vous le décidez.
<img src="./images/staking-eth.png" alt="Staking ethers">
Dans le staking d'Ethereum 2.0, la raison pour laquelle vous gagnez de l'argent est simple. Le réseau a besoin d'un ordinateur bien configuré pour créer une chaîne sécurisée pour tous.
Les utilisateurs de la blockchain payent des frais de transaction et des ethers sont créés à chaque nouveau bloc, créant ainsi une légère inflation. Si vous parvenez à sécuriser le réseau, vous gagnez votre part.
Sinon, par exemple en étant déconnecté ou en rangeant les blocs dans le désordre, vous perdez une partie de votre mise.
<h3>Participation à une Liquidity Pool</h3>
En finance traditionnelle, la liquidité représente la monnaie immédiatement disponible pour être échangée contre un
bien, un service, une autre monnaie... Elles sont extrêmement importantes : la crise des subprimes s'est transformée en
crise de liquidités qui a achevé Lehman Brothers en 2008 - événement fondateur du mythe de Bitcoin.
Les banquiers centraux se battent actuellement à qui créera le plus de liquidités.
Dans la DeFi, vous gagnez des revenus en partageant vos liquidités. Avec un token <code>$A</code> et un token <code>$B</code>, vous créez un
token nommé <code>LP A/B</code> (LP pour Liquidity Pool) et fournissez une Farm avec ce LP Token.
Vous pourrez voir les mots Pool, Vault ou Farm - chaque plateforme a son vocabulaire et ses subtilités.
<img src="./images/swap-bsc.png" alt="Fournir des liquidités sur la BSC">
Fournir des liquidités pour LP BNB/Cake dans une Farm PancakeSwap
Vous pourrez maintenant récolter (harvest) dans cette ferme. Soit lors du retrait des LP Tokens, soit en cliquant sur un bouton Harvest.
Cela peut être automatisé dans des auto-compound farms, telles que Autofarm.
Cela crée cependant un risque d'une couche de confiance ou de bug supplémentaire.
Il y a ceux qui cliquent, et ceux qui codent. La blockchain est ouverte, est vous pouvez appeler vous-même le web3 avec votre code,
récupérant ainsi les tokens <code>$A</code> et <code>$B</code>. Des plateformes no-code permettront sûrement bientôt de contrôler plus finement
les opérations sans code.
La plateforme centralisée leader Binance reproduit le partage de liquidité en off-chain. Le coeur du système d'échange
de Binance n'est pas bâti sur la blockchain. Ce serait trop lent et trop coûteux. Mais puisque Binance a aussi besoin de liquidités
pour faire fonctionner ses marchés, les liquidités de leur propres utilisateurs sont les bienvenues.
Contrairement à votre banque, Binance va rémunérer les liquidités de ses usagers.
<img src="./images/matic-usdt.png" alt="Liquidités sur Binance">
Dans l'exemple ci-dessus, le stacker gagne de l'argent provenant des utilisateurs de Binance faisant la conversion (swap)
des <code>$MATIC</code> en <code>$USDT</code>, ou de l'<code>$USDT</code> vers <code>$MATIC</code>. Ces utilisateurs peuvent lui payer 0.2% des frais de transaction, plus 0.1% de frais vers la plateforme.
Ces chiffres ne sont pas du tout standards d'une plateforme à l'autre, mais il est important de noter que
les liquidity providers vont au final souvent gagner plus que la plateforme.
Dans un Decentralized EXchanges (DEX) sur la blockchain comme Uniswap, les utilisateurs vont en plus payer
des frais de transaction au stackers ETH 2.0.
La seconde partie des revenus sont les récompenses, ou rewards. Elles sont de 4.11% dans l'exemple précédent et au final
elles peuvent dépasser les gains des frais de swap. Voici un exemple du couple <code>AAVE/ETH</code> sur Binance :
<img src="./images/swap-fees.png" alt="Sawp fees">
Ces rewards sont souvent payées en token du protocole. Vous êtes récompensés en <code>$SUSHI</code> sur SushiSwap, en <code>$CAKE</code> sur PancakeSwap...
Cela semble ne pas coûter cher aux propriétaire du protocole, pourtant cela crée une très forte inflation et une fois la hype disparue,
des millions de tokens sans utilité évidente sont distribués.
Les développeurs et investisseurs sont rétribués par ces tokens, et c'est donc dans leur intérêt qu'un marché trouve une utilisation à ce token, et que ce token garde une valeur.
Un moyen habituel de satisfaire tout le monde est de distribuer des fees aux propriétaires des tokens.
Si vous swappez du <code>$DAI</code> en <code>$ETH</code> sur SushiSwap, vous payez 0.2% de fees aux liquidity providers de <code>LP DAI/ETH</code> et 0.1% aux stackers de <code>$SUSHI</code>.
Vous pouvez donc d'un côté gagner des fees en stackant <code>LP DAI/ETH</code> tout en ayant tous les jours des <code>$SUSHI</code> en reward, que vous pourrez stacker pour obtenir plus de fees.
Et tout le monde y trouve son compte... À condition qu'il y ait le moindre intérêt pour l'utilisateur en bout de chaîne à transformer du <code>$DAI</code> en <code>$ETH</code> !
Il est possible, et c'est un peu le but du jeu, de trouver de meilleures opportunités dans le spectre de la DeFi. Sur le réseau Polygon de SushiSwap, j'ai
un rendement de 35% annuel pour un <code>LP USDC/ETH</code> qui sont probablement deux des trois tokens les plus sûrs avec le <code>$DAI</code> (not an advice !).
<img src="./images/sushi-swap.png" alt="Meilleur rendement sur SushiSwap">
La blockchain est une base de donnée ouverte en temps réel. Et donc en fonction des fees et des rewards proposés à un instant t,
des quantités ÉNORMES d'actifs peuvent être déplacés d'un protocole à un autre pour gagner quelques pourcents de plus.
Ce n'est pas non plus le succès à tous les coups : un concept complexe d'Impermanent Loss vient gâcher la fête. En fournissant vos liquidités, vous donnez vos <code>$USDC</code> contre des ethers au moment où les gens veulent moins d'ethers - donc le prix de vos ethers diminue.
Vous êtes toujours du mauvais côté du marché !
Il faut donc entrer au juste prix, espérer du traffic et des oscillations, rester sur un moyen terme.
<h3>Farms aux rendements énormes : l'exemple des Exchanges</h3>
Il arrive que des farms aient des rendements gigantesques. La très légitime blockchain <a href="https://coinmarketcap.com/currencies/elrond-egld/">Elrond</a> propose à travers de
son nouvel exchange <a href="https://maiar.exchange/">Maiar</a> des rendements annuels supérieurs à 2000% (APR), et même bien plus en composant tous les jours les gains (APY).
Dans cet exemple, Elrond a apporté plus d'un milliard de dollars aux utilisateurs de Maiar EXchange (MEX).
Le problème est que cette valeur est déclarée en tokens <code>$MEX</code>, Elrond n'a pas mis un seul vrai dollar sur la table.
Chaque heure, 2493$ investi rapporte 11$ en intérêt, jour et nuit, week-ends inclus. Après un an, le total gagné en <code>$MEX</code>
serait supérieur à un million de dollars - ce n'est pas un conseil, lisez plus bas !
<img src="./images/egld-mex.png" alt="Elrond et EGLD-MEX">
Malheureusement - ou plutôt, logiquement - plus nombreux sont les <code>$MEX</code> délivrés, plus faible est leur valeur.
Et la valeur des <code>LP EGLD-MEX</code> stackés peut décroître bien plus vite que les gains récupérés en <code>$MEX</code>.
La mise initiale d'un milliard de dollar en <code>$MEX</code> pourrait valoir une cacahuète un an plus tard. Ce pattern s'est déjà
vu avec Goose Finance, PolyWhale (token <code>$KRILL</code>) et bien d'autres.
<img src="./images/shit-coins.png" alt="Shitcoins">
S'il n'y a aucun utilisateur pour swapper des actifs sur la plateforme, ces tokens n'ont aucune valeur. Cependant quelques
échanges survivent très bien, tels UniSwap (13 Md $ sur Ethereum), SushiSwap, PancakeSwap, Quickswap (100 M$ sur Polygon)...
Ceux qui ont récupéré les tokens récupèrent également les fees journalières.
Après avoir distribué gratuitement la majeure partie des tokens de Maiar Exchange, Elrond peut revendre une partie des <code>$MEX</code> qui
lui reste avec un profit. Et surtout dans ce cas, Elrond s'offre une communauté richement incitée à démarrer l'écosystème autour de sa blockchain.
<h3>Prêter et emprunter</h3>
Emprunter dans le monde de la crypto n'a pas grand chose à voir avec un emprunt dans le monde réel. Honnêtement je n'en vois pas trop l'intérêt.
Dans le monde réel, une banque va prêter de l'argent parce qu'ils pensent que vous gagnerez bien plus d'argent.
Si vous partez avec l'argent prêté, la banque a confiance sur le fait que les policiers vous rendront la vie impossible.
La DeFi est un monde sans confiance - trustless. Ce n'est pas que les protocoles ne vous font pas confiance, c'est qu'il n'ont
aucun besoin de vous faire confiance pour faire fonctionner le système.
La raison est que pour emprunter un million de dollars, vous devez déposer, où plutôt stacker, deux millions.
Si vous n'arrivez pas à rembourser, le protocole puisera 1.1 million dans votre staking.
À quoi cela peut-il servir alors si vous avez déjà l'argent ? Vous pouvez avoir un effet de levier. Si vous avez deux
millions de dollars en ether, vous pouvez les mettre de côté tout en empruntant un million pour faire d'autre choses.
Le bénéfice n'est en fait toujours pas évident...
Dans certaines juridictions, réelles ou futures, vous pouvez préférer garder vos tokens pour des raisons fiscales et
par une telle pirouette avoir de nouveaux tokens sans payer la taxe sur la plus-value acquise.
C'est une vue de l'esprit, et je ferai prochainement un article pour expliquer qui détient réellement un actif dans la crypto.
Il y a également un gain de trading immédiat si l'on regarde ce cas sur l'application leader Aave :
<img src="./images/aave.png" alt="Prêter et emprunter sur la blockchain">
Supposons que j'ai 8k$ en <code>$USDT</code>, avec l'ether évalué à 4k$. Je dépose 8k$ en <code>$USDT</code> et gagne (16.12+4.6) = 20.7 % de gain par an (1656 $).
16.1% proviennent des frais payés par les emprunteurs d'<code>$USDT</code>, 4.6% de rewards offerts par le protocole Aave.
Je peux aussitôt emprunter 1 ether. Si je suis vicieux je peux donc les swapper en <code>$USDT</code> et déposer encore ces <code>$USDT</code>
pour des gains supplémentaires.
Cependant je dois repayer 1 ether avec 2.03 % de frais, tout en récupérant 1.19% en reward😱. Par le jeu des rewards, si
je prête ce que je viens d'emprunter, je suis largement positif. Nous avons pu justifié auparavant l'intérêt des rewards,
et cela met aussi en lumière la valeur de la blockchain. Il y a si peu d'intermédiaires que le coût du système est très faible.
En bon développeur, j'ai évidemment voulu créer une boucle infinie, mais le système de collatéral ne le permet pas.
Plus embêtant, si le prix d'ether monte rapidement, j'aurai une somme plus grande à rembourser avant d'être débordé et donc liquidé.
Si je suis un robot ou un smart contract, c'est ok, je peux réagir instantanément si le code l'a prévu.
En fait la plupart des transactions d'Aave sont exécutées par des smart contracts détenus par d'autres protocoles.
Bien que je ne sois pas personnellement motivé pour prêter/emprunter, le fait que les robots soient les principaux clients
montre qu'il y a un intérêt pour un tel service.
Évidemment le market cap d'un protocole ne peut pas se mesurer de la même façon qu'une capitalisation boursière.
On peut tout de même noter que Aave est évalué à 5Md$ en étant largement leader sur ce domaine.
Comparativement, Bank of America vaut 385Md$ et la Société Générale environ 30Md$.
<h3>Initial Farm Offering</h3>
L'Initial Farm Offering, ou IFO, est une façon pour les fondateurs d'une compagnie de vendre rapidement et publiquement
leurs parts. C'est comme une introduction en bourse (IPO) sous stéroides, à un stade très précoce.
Le processus exact de l'IFO va dépendre de chaque plateforme.
Supposons que les fondateurs d'ACME Inc. mettent leur tokens <code>$ACME</code> dans une farm, et que les utilisateurs y investissent des ethers.
A la fin de l'IFO, le prix initial du token <code>$ACME</code> sera déterminé par le nombre d'ethers déposés. Les fondateurs récupèrent les ethers,
pour s'enrichir mais aussi continuer le développement et le marketing. Les utilisateurs récupèrent des tokens contre ces ethers.
Certains le vendront immédiatement, d'autres prévoient une valeur future plus grande, et les enthousiastes espéreront
une vrai utilité à ce token si les développements arrivent à terme.
Le but des fondateurs est aussi de répandre le token à un public plus large que les investisseurs de startups.
Plus bruyante est l'IFO, plus nombreux seront ceux qui verront une utilité au token et pourront déterminer son prix.
Prenons l'exemple de l'<a href="https://pancakeswap.finance/ifo">IFO actuelle du club de football FC Porto</a>, sur PancakeSwap.
<img src="./images/ifo.png" alt="IFO PancakeSwap">
C'est une autre mécanique : 250,000 token <code>$PORTO</code> seront vendus au prix fixe de 2$ pour un total de 500k$.
Un demi-milliard est déjà levé par la foule,
donc tout ce monde n'aura pas le nombre de tokens désirés. Certains d'entre eux essayeront d'en acquérir sur le second marché,
peut-être pour plus que 2$.
Pour une personne normale, il est virtuellement impossible d'investir dans le prochain batch de startup du Y Combinator,
la crème des startups incubées. Vous pouvez assez facilement investir dans d'autres start-up via un club mais le ticket d'entrée est
en général autour de 10k$.
Avec le farming, et plus encore l'IFO, n'importe qui avec Internet peut investir très tôt dans une startup blockchain pour quelques dollars.
<h3>Composition et conclusion</h3>
Nous avons décrit ici des moyens de gagner de l'argent virtuel. Cela requiert des connaissances techniques et il y a beaucoup
de façons de perdre de l'argent : mauvais choix, arnaque, bug dans un smart contract ou simplement perte des clés.
Vous pouvez aussi être cupide (c'est ici une vertu !) et essayer de gagner un peu plus, en empruntant autant que possible,
prenant les rewards, puis les déposant dans un Liquidity Pool. Rembourser le prêt, prendre les profits, recommencer.
Automatiser, puis écrire un smart contract pour le faire.
Ou plus simplement staker sur <a href="https://yearn.finance/#/vaults">Yearn Finance</a> qui a déjà codé pour vous des systèmes similaires.
Quoiqu'il en soit, demandez-vous toujours : quel est l'intérêt du token ? Pourquoi des personnes m'en donneraient plus ?

Provenance des rendements du Yield Farming dans la blockchain

This site just migrated from Gatsby to NextJS. If every coder today leans toward NextJs versus Gatsby, now I don't feel this so obvious.
<hr>
<h2>Gatsby and its plugins</h2>
I want to write more premium content on this site, so I was motivated to upgrade a few items,
when appeared at my first <code>gatsby develop</code> :
<img src="./images/gatsby-plugin-bug.png" alt="Bug du plugin gatsby">
...last bug I wanted to see. Not on my code, but a bug about a plugin and the wrong version of
one of its dependencies.
<h2>Gatsby versus NextJS ?</h2>
The site you are reading now just migrated from Gatsby toward NextJS.
Those two technologies embrace the JAM stack and are static sites generators, which allow
to display very fastly web pages with a maximum of security. Wordpress killers.
But does it allow fast improvements ?
<h2>DX: Developer Experience</h2>
This capability of improving fastly and nicely an application is named Developer Experience. Now
that developers are more valuated than users, it has its importance.
DX relies on development speed, but even more on the pleasure of coding. This is impacted by many
factors that won't be described there, but you can understand that pleasure is important for
such a not monetized web site.
And, in terms of pleasure, Gatsby and and GraphQL are terrible. My opinion, and opinions of many.
Every type of page is affected by a huge, unpleasant, partly copy/pasted GraphQL query.
<img src="./images/graph-ql-blog.png" alt="graphql query">
That is not very readable, and moreover the tooling is far from excellent.
Even worst, you must add many plugins, where each plugin wrap a lib adapted to Gatsby structure and GraphQL
queries. The bug I had above appeared on one of this plugin, not updated quickly enough. Classic and predictable.
<h2>Programming language</h2>
Both Gatsby and NextJS use React JS, but only one command line argument quickly adds Typescript to NextJS.
Typescript is now a must for most developers.
You can still use typescript with Gatsby. I used an <a href="https://github.com/antoinerousseau/gatsby-starter-antoine/">unofficial starter kit</a>
proposed by <a href="https://antoine.rousseau.im">Antoine Rousseau</a> for Gatsby.
<h2>CSS Framework</h2>
NextJS proposes by default CSS Modules. Nothing is proposed by Gatsby, which is not that bad.
Both work well with Sass.
I used very easily Styled Components with Gatsby, and it would be that easy also with NextJS.
CSS Modules didn't bring me more, it's a question of taste and coder experience.
<h2>Deployment ease</h2>
Vercel, which is an Heroku competitor, is the NextJS editor and proposes in its documentation
a path to deploy in a few steps the website on Vercel servers.
The JAM stack also contains api capabilities. Your website is not read-only, and can create actions.
Vercel proposes an api from React JS front to Vercel servers.
However pricing from Vercel is not obvious to catch. Also I don't think it's always a good idea to be tied
to an editor. If the code gets slowly locked, I would have more awareness on quitting NextJS being outside
Vercel cocoon. I needed around 20 hours to move from Gatsby to NextJS, so I may reverse it quickly as long
as I don't call too much proprietary Vercel apis.
<h3>Strange build for NextJS</h3>
It took 10 seconds to my new edge computer to build NextJS website, and 16 seconds with Gatsby. As this
site is very small, those are not representative figures.
I expected both technologies to create basic html. It happens that structures were different. Here is the one generated by Gatsby.
<img src="./images/structure-gatsby.png" alt="Generation Gatsby">
A browser going to <code>/page/2/</code> will load <code>/page/2/index.html</code> file with a basic server.
Generation is significantly different with NextJS:
<img src="./images/structure-next.png" alt="Generation NextJS">
So after the command <code>next build &#x26;&#x26; next export</code>, I deployed the site with a local server (<code>php -S localhost:8888</code>), and going directly
to the second page (<code>/page/2</code>), we have an awful 404 error. I should call <code>/page/2.html</code> which is not a sexy url.
If I first go to the homepage, then on the second page, it will work as the React application will display content loaded from
some Json.
<img src="./images/404.png" alt="404 sur NextJS">
Thought I followed the documentation with nothing fancy, it may be a configuration problem, but it's worrying if it's not the case.
Nevertheless, like my old Gatsby site, I used Netlify who deployed everything without any problem,
nor any 404 error page.
<h2>Site publication</h2>
The change of DNS was done quickly. The roadmap is written and next items are:
<ul>
<li>The page to present the trainings</li>
<li>SEO: some headers and the sitemap</li>
<li>An API to record the emails of a newsletter</li>
</ul>
The point of the sitemap is interesting for the comparison between Gatsby versus NextJS. It is about transforming all the pages
and articles to generate an XML. Using Gatsby, you would have to start from some sort of plugin or graphQL query.
With NextJS, I already have access to a <code>Post</code> type object array representing the pages that will need to be mapped to XML.
It's not done, but I have a clear idea of where to start.
In conclusion, Gatsby is missing an official version with typescript and without GraphQL to compete.
Since the migration, the site is just as fast, the updates are more regular, the articles more frequents,
which was the desired goal.

Why I made the migration from Gatsby toward NextJS

Le bug de trop de Gatsby et ses plugins, un mois plus tard, je migre ce site en NextJS... Si aujourd'hui chaque codeur semble préférer NextJs à Gatsby, le choix n'est
rétrospectivement pas si évident.
<hr>
<h2>Gatsby et ses plugins</h2>
Je veux maintenant écrire bien plus de contenu à haute valeur sur ce site,
et j'étais donc décidé à améliorer deux-trois éléments, quand apparu à mon premier <code>gatsby develop</code> :
<img src="./images/gatsby-plugin-bug.png" alt="Bug du plugin gatsby">
...le bug de trop. Non pas sur mon code, mais un bug qui parle de plugin
et de mauvaise version de l'une de ses dépendances.
<h2>Gatsby ou NextJS ?</h2>
Le site que vous lisez actuellement vient de migrer de Gatsby vers NextJS.
Ces deux technologies embrassant la JAM Stack sont des Static site generators, ce qui permet
d'afficher très rapidement des pages web, avec un maximum de sécurité. L'opposé de Wordpress.
Mais est-ce que cela permet de coder rapidement ?
<h2>DX: Experience de développement</h2>
Cette capacité à faire progresser rapidement et sympathiquement une application a son petit anglicisme
barbare : la Developer Experience, aka DX. Maintenant que les développeurs sont plus précieux
que les utilisateurs, la DX a son importance.
La DX joue sur la rapidité de développement, mais aussi sur le
plaisir à coder, ce qui est en fait essentiel pour un projet non monétisé comme celui-là.
Et pour moi comme beaucoup d'autre, Gatsby et GraphQL sont catastrophiques. Chaque type de page
se retrouve affublée d'une requête GraphQL plus ou moins longue et qui se ressemblent.
<img src="./images/graph-ql-blog.png" alt="graphql query">
Non seulement, c'est peu lisible, mais en plus l'outillage associé n'est pas excellent.
De plus il faut enchaîner plugins sur plugins. Et donc l'utilisation d'une bibliothèque adaptée à Gatsby et
,problème parfois superposé, requêtable en GraphQL. Le problème qui m'est survenu était qu'un de ces plugin n'était pas mis
à jour assez vite. Classique et prévisible.
<h2>Langage de programmation</h2>
Les deux technologies utilisent React JS, mais il suffit d'un argument simple pour initialiser NextJS avec Typescript.
Avec un peu d'habitude, Typescript est un must pour la plupart des dévelopeurs.
Typescript est toutefois utilisable avec Gatsby. J'ai utilisé
un <a href="https://github.com/antoinerousseau/gatsby-starter-antoine/">starter kit non officiel</a> proposé
par <a href="https://antoine.rousseau.im">Antoine Rousseau</a> pour Gatsby.
<h2>Framework CSS</h2>
NextJS propose les CSS Modules par défaut. Rien n'est proposé par Gatsby, ce qui n'est pas plus mal.
Les deux frameworks fonctionnent bien avec Sass.
J'avais utilisé facilement les Styled Components avec Gatsby, et ce serait aussi simple à mettre en place avec NextJS.
En comparaison, les CSS Modules ne m'ont rien apporté, c'est vraiment une question de goût et d'expérience.
<h2>Simplicité de déploiement</h2>
Vercel, que l'on peut classer comme un concurrent de Heroku, est l'éditeur de NextJS.
La documentation propose donc logiquement de déployer en quelques instants
le site sur les serveurs de Vercel.
Mais d'une part le pricing de Vercel n'est pas clair, d'autre part je pense qu'il n'est pas bon de trop se nouer avec un éditeur.
Si le code se verouille doucement, je serai plus alerte pour sortir de Next JS en étant hors du cocon de Vercel.
<h3>Build étrange pour Next JS</h3>
Il me faut 10 secondes pour builder NextJS, où Gatsby prend 16 secondes. Ce n'est pas représentatif vu la petite taille du site.
En théorie, ces deux build doivent créer un site avec du html basique. Or les structures sont différentes. Voici celle générée par
Gatsby
<img src="./images/structure-gatsby.png" alt="Génération Gatsby">
Pour Gatsby, il faut se rendre sur <code>/page/2/</code> pour qu'un serveur très standard va charger le fichier <code>/page/2/index.html</code>
La génération est différente pour Next JS :
<img src="./images/structure-next.png" alt="Génération NextJS">
Si bien qu'après avoir fait la commande <code>next build &#x26;&#x26; next export</code>, j'ai deployé le site avec un serveur local
(<code>php -S localhost:8888</code>), et
si l'on se rend immédiatement à la seconde page <code>/page/2</code>, nous avons un affreux 404. Il faudrait charger
<code>/page/2.html</code>, ce qui n'est pas une url sexy.
Si je passe par le homepage, puis navigue vers la 2e page,
je n'ai pas de problème car l'application affiche le contenu issu d'un Json chargé via Ajax.
<img src="./images/404.png" alt="404 sur NextJS">
Peut-être un problème de configuration, mais c'est inquiétant si ce n'est pas le cas.
Le déploiement sous Netlify se fait pourtant sans soucis et le probleme de 404 n'est pas rencontré.
<h2>Publication du site</h2>
Le changement des DNS s'est fait rapidement. La roadmap est écrite et les prochains objectifs sont :
<ul>
<li>La page pour presenter les formations</li>
<li>SEO : quelques headers et le sitemap</li>
<li>Une api pour enregister les emails d'une newsletter</li>
</ul>
Le point du sitemap est intéressant pour la comparaison entre Gatsby ou NextJS. Il s'agit de transformer l'ensemble des pages
et articles pour générer un XML. En utilisant Gatsby, il faudrait partir de je ne sais quel plugin ou requête graphQL.
Avec NextJS j'ai déjà accès un tableau d'objet de type <code>Post</code> représentant les pages qu'il faudra mapper vers du XML.
Ce n'est pas fait, mais j'ai une vision claire de par où commencer.
En conclusion, il manque à Gatsby de proposer une version officielle avec typescript et sans graphQl pour rivaliser.
Depuis la migration, le site est tout aussi rapide, les mises à jour sont plus régulières, les articles plus fréquents,
ce qui était bien le but recherché.

Pourquoi j'ai migré de Gatsby vers NextJS

How to complete an observable when the other completes ?
<hr>
<h2>When to use RxJs ?</h2>
I'm working on real time data these days, and now I'm getting pretty good with RxJS.
I have ranted many years against RxJS because it was packed with Angular, and
I don't see the point of using an Observable for a rest request, when a Promise is
perfect for that.
Moreover, RxJs api was moving fast, causing displeasure when you don't follow that much this
project.
When dealing with real time data, it's another story. RxJs nails it, and its
integration with Typescript is perfect.
<h2>Completing an observable</h2>
There are many operators included with RxJs, and over the time, they removed some to limit
the api surface, which is good. It's very easy to make your own operator,
so if your code often use a certain combination of operators with recurrent logic,
don't hesitate to factorize your code with your customized operator.
In my project, I often need to terminate an <code>Observable</code> when another finish. They
both finish at the same time. I first supposed that this is common and therefore an
operator already exists, but <code>takeUntil(other$)</code> terminates your observable
when the <code>other$</code> starts.
It's also easy to complete a <code>Subject</code>, with <code>subject.completes()</code>, but I prefer to
work with observables.
<h2>My customized operator</h2>
I want my <code>stream$</code> to complete with <code>other$</code> stream. I wish to use it like this:
<pre><code class="language-typescript">stream$.pipe(completeWith(other$))
</code></pre>
My <code>completesWith</code> function uses 4 lines of code:
<pre><code class="language-typescript">export const completesWith = (other$: Observable&#x3C;any>) => (o: Observable&#x3C;number>) => {
 const terminator$ = new Subject()
 other$.subscribe().add(() => {
 terminator$.next('terminate')
 })
 return o.pipe(takeUntil(terminator$))
}
</code></pre>
When other$ completes, a terminator$ Subject will emit any value, and using
takeUntil, it will then complete our observable.
<h2>Replace Subject by an Observable</h2>
As I said before, I prefer to avoid Subjects. The way Subjects store listeners could provoke
memory leaks. Functional style has much more guarantees.
<pre><code class="language-typescript">export const completesWith = (end$: Observable&#x3C;any>) => (o: Observable&#x3C;number>) => {
 const terminator$ = new Observable(subscriber => {
 end$.subscribe().add(() => {
 // Will officially start the observable
 subscriber.next('FUNCTIONAL terminate')
 })
 })

 return o.pipe(takeUntil(terminator$))
}
</code></pre>
This is more an exercise than a reality, as my project is full of Subjects, but they are always private object,
with very limited power. I just use them because it's convenient, more readable. Thought a bit dangerous...
If you can't replace your <code>Subject</code> by an <code>Observable</code>, probably harm is already done. Your Subject
may be linked to other objects, with complexity that puts your memory at risk.

Completing a RxJs Observable with another

Turn on and off your old electric heater with code. You can save money and lower CO2 with
a bit of Javascript.
<hr>
<h1>Easy automation with Sonoff and Javascript</h1>
<h2>Sonoff</h2>
<a href="https://amzn.to/39a54eI">Sonoff</a> is a company that builds smart and cheap components (5$ - 40$), compatible with IFTTT softwares. Some competitors of Sonoff are first <a href="https://amzn.to/38YKjm4">Shelly</a>, but also <a href="https://amzn.to/3nnwva2">Horsky</a>, Kankun.... But in terms of Javascript, I only found something similar with <a href="https://www.npmjs.com/package/homebridge-smartplug">Kankun</a>, but was published 3 years ago. So don't count on it.
This blogpost will present <a href="https://github.com/skydiver/ewelink-api">Skydiver's ewelink npm module</a> that worked great immediately.
Because I work on the heater, I bought the <a href="https://amzn.to/3bcx97P">TH-16</a> version : with a 16 Amperes capacity with temperature sensor for 15$. Be careful to use the <a href="https://amzn.to/38ihMc2">Sonoff TH Sensor-AM2301</a>, other sensors are not working as well.
<img src="./images/sonoff.png" alt="Sonoff basic">
<h2>eWeLink, IFTTT, Alexa...</h2>
Now it's dirty. Though your mileage may vary, it's not working the right way for me. No way to put Alexa or similar at home.
The ewelink app (android or iOS) is needed and allows the Internet to find your device. You create an account on eWeLink, and they will register your device. Then you have a few options to set the switch on and off. But there are a lot of limitations. Either it's controlled by a min/max temperature, either by time triggers. Given a time, it will force <code>on</code> or <code>off</code>. It's not bad but not enough, with a poor UX.
My android phone and iPad have both eWeLink installed.
<img src="images/sonoff-both-temperatures.jpeg" alt="Both Sonoff tempratures differs">
Well, you understand why I don't want to lean on the app .... Hopefully the results I get from the code are more consistent.
IFTTT means IF This Then That. It's not an open protocol, but more a private Saas tool much like Zapier. There is an <a href="https://platform.ifttt.com/docs/api_reference">Http API</a> that allows us to control the devices. It's quite hard to follow, especially on how to access the device with your rights.
<h2>The code and the setup</h2>
The goal is to power on Lili's room, based on some constraints. If temperature is below 18 AND if
it's the right moment of the right day, then turn it on. If not turn it off.
I just installed ewelink-api and dotenv packages, the latter to avoid hard coded passwords. There is some closed code about how to parse the ewelink responses.
<pre><code class="language-javascript">require('dotenv').config()
const ewelink = require('ewelink-api')

const devices = {
 lili: process.env.LILI
}

const connection = new ewelink({
 email: process.env.EMAIL,
 password: process.env.PASSWORD,
 region: process.env.REGION // eu, us ....
})

let intervalId;
connection.getDevices().then(()=> intervalId = setInterval(work, 15*60*1000))

async function work() {
 try {
 const {temperature, power} = await liliStatus()

 if (temperature &#x3C; 18 &#x26;&#x26; !power &#x26;&#x26; timeAndDayToPowerOn()) {
 console.log({temperature, power},"Powering lili on");
 await connection.setDevicePowerState(devices.lili, 'on')
 }else{
 if(power){
 console.log({temperature, power},"Powering lili off");
 await connection.setDevicePowerState(devices.lili, 'off')
 }else{
 console.log({temperature, power},"Nothing to do");
 }
 }
 } catch (e) {
 console.error(e)
 }
}

</code></pre>
That's almost all the logic needed. More details are on <a href="https://gist.github.com/nicolas-zozol/1f06ec0822c32b5e4ce30ffaba09947a">this gist</a>, that will probably improve this code.
<h2>So far so good.</h2>
The device is far from the wi-fi box, but it's still working.
<img src="./images/run-logs.png" alt="up and running">
Next step are to deploy this on <a href="https://www.clever-cloud.com/en/">Clever Cloud</a> or similar. Maybe remove the loop from the setInterval function and run a <a href="https://cloud.google.com/functions">GCP Function</a> (aka lambda) with a <a href="https://cloud.google.com/scheduler">cron</a>.
Fun fact: if you keep <code>setInterval</code> in your cloud Function, you may thousands of dollars in stacked running lambdas.
The instructions are not stored on the device itself. It waits for external inputs to trigger <code>on /off</code>. I should save money, but the problem is that heat will depend on weather and now also on
clouds.

Easy automation with Sonoff and Javascript

Quel langage pour progresser dans sa carrière ?

Styled component is a technology that scales css. It's great, but there are some
traps. Here is what I wished I knew the most when starting Styled Components.
<hr>
<h2>Goals and Difficulties</h2>
Styled Component is a library coded by the impressive Max Stoiber and now
maintained by many others, proof of success and durability.
There are two main goals in my point of vue.
<ul>
<li>Scale by avoiding hell of BEM, like using class name such as <code>search-box__btn search -box__btn_max_visible</code></li>
<li>Protect your component from the cascading pattern of CSS. Yes. Break the C of CSS</li>
</ul>
Like you may expect, this second goal may bring some pain, or at least surprises when, like me
, your are too naive.
<h3>Quick example</h3>
Let starts with an example <a href="https://styled-components.com/docs/basics#extending">from the doc</a>:
<pre><code class="language-jsx">const Button = styled.button`
 color: palevioletred;
`;

const TomatoButton = styled(Button)`
 color: tomato;
`;
</code></pre>
That works and gives two nice buttons. But using:
<pre><code class="language-jsx">const MyButton = ()=>&#x3C;button>Click Me&#x3C;/button>

const MyTomatoButton = styled(MyButton)`
 color: tomato;
`;
</code></pre>
I'm naive and I have a button. I want to style it, so I write <code>styled(button)</code>.
But my new button won't have any tomato color 😞
<h3>Read the manual</h3>
First, be smarter than me and don't miss this most important line <a href="https://styled-components.com/docs/basics#styling-any-component">from the manual</a>:
<blockquote>
The styled method works perfectly on all of your own or any third-party component, as
long as they attach the passed className prop to a DOM element.
</blockquote>
<pre><code class="language-jsx">const Link = ({ className, children }) => (
 &#x3C;a className={className}>
 {children}
 &#x3C;/a>
);
</code></pre>
Why ? Because later the examples given across the web, including Styled Component
documentation gives examples where it looks easy to modify a component, when
this second goal is exactly to avoid any modification of a component.
<h2>Applying classes</h2>
The problem is that styled(Comp) is effective only if Comp is already a styled component.
To achieve this, you must add the <code>className</code> to MyButton
<pre><code class="language-jsx">const MyStyledButton = ({className})=>&#x3C;button className={className}>Click Me&#x3C;/button>

const MyTomatoButton = styled(MyStyledButton)`
 color: tomato;
`;
</code></pre>
Now StyleComponent will create some classes and apply them to your component, making it a styled
component.
<img src="./images/styled-classname.png" alt="ClassName applied to styled component">
No className, no style. When using <code>styled.div</code>, then StyledComponent has
already applied the <code>className</code> trick.
This is wanted behaviour. You are not supposed to transform a component except
if the component creator has explicitly said you can ! It's the
<a href="https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle">open/close principal</a>
applied to styling.
<h2>Advanced usage</h2>
<h3>Restyle</h3>
Once a component is styled, you can re-style it.
<pre><code class="language-jsx">const AttachingComp = ({className})=>&#x3C;div className={className}>I am a &#x3C;strong>attaching&#x3C;/strong> component&#x3C;/div>

const GreenAttachingComp= styled(AttachingComp)`
 color:green;
 strong{
 text-decoration:underline
 }
`

const Child = styled(GreenAttachingComp)`
 margin: 20px 20px;
 color: red;
`

</code></pre>
<img src="./images/restyle.png" alt="Restyling from another component">
<h3>Nesting components</h3>
The same closed by default behaviour is applied to nesting components. If you
have not applied <code>className</code> to a React element, nesting rules are ...not applied.
<pre><code class="language-jsx">
const BasicComp = () => &#x3C;div>I am a &#x3C;strong>basic &#x3C;/strong>component&#x3C;/div>;

const AttachedComp = ({ className }) => (
 &#x3C;div className={className}>
 I am an &#x3C;strong>attached&#x3C;/strong> component
 &#x3C;/div>
);

const StyledBasicComp = styled(BasicComp)``;
const StyledAttachedComp = styled(AttachedComp)``;


const DemoNesting = ({className})=>{
 return (
 &#x3C;div className={className}>
 &#x3C;StyledBasicComp/>
 &#x3C;StyledAttachedComp/>
 &#x3C;/div>
)}


export const StyledDemoNesting = styled(DemoNesting)`
// general css rules. Will be applied to all nodes below
font-size:12px;
strong{
 color:red;
}


// component rule on basic component. Won't be effective
${StyledBasicComp}{
 color:yellow;
}

// component rule on className attached component. Rule is effective
${StyledAttachedComp}{
 color:green;
 font-size:24px;
}
`
</code></pre>
You can test it in this <a href="https://stackblitz.com/edit/styled-components-robusta?file=nesting.js">Stackblitz</a>
<h2>When should I attach className ?</h2>
Most often, you should not. Because it's designed this way. If you have a few rules, you should
prefer standard css or sass.
If you have a bigger application, then attaching <code>className</code> could increase interferences.
If you want to present a component in different way, you will rather use a <a href="https://styled-components.com/docs/advanced#theming">theme</a>
or <a href="https://styled-components.com/docs/basics#passed-props">passed props</a> if it's through your application state:
Attaching <code>className</code> is really meant for the case where you create a third party library, and you
design a point of extension. You create some open explicitly for the style. Attaching the
<code>className</code> will avoid some hacks are they are described here <a href="https://github.com/styled-components/styled-components/issues/2076">in this issue</a>
I kind of attach <code>className</code> for creating my own library. I design some Theme Component, such as
<code>TCard</code>, then I modify the spacing at different point of this Gatsby website, or reuse it for similar
websites.
For the moment, it's just a test, and it looks good. But it took me way too much time to really
understand how and why attach <code>className</code>. Maybe this article will help you 😊

Applying correctly className with Styled components

GMail was a revolution in 2004. Is Google too big now ?
<hr>
<h1>Leaving Gmail</h1>
<h2>Why ?</h2>
Thousands of blog post have their opinion, here is mine.
Giving your data to Google was acceptable some time ago. It's not anymore. First because Google has changed, being so big. Second, and mostly important,
because if you think Google is still acceptable, it may not be tomorrow. Be prepared.
Today and tomorrow, an email address will represent your identity. Own it.
<h2>Registrar</h2>
First is to choose a registrar for your domain, like the excellent [http://www.gandi.net].
Choose a domain name, such as <code>yourname.co.uk</code> if it's available and if you are britain.
If you are linked to the city and have 45€/y, choosing <code>yourname.paris</code> is a sexy option. But <code>yourname.me</code> is the most regular way and quite cheaper.
Then create a Fastmail (or ProtonMail or whatever that is not hotmail) account. The first real problem is that you must change the DNS settings
, so that when a mail arrive to <code>yourname.me</code>, your registrar can send it back to fastmail.
You can't buy directly a domain with Fastmail. But if you are no more agree with Fastmail, it will extremely simple to move and keep the same identity.
I'm an advanced user, so I preferred to use the advanced option and use MX records for Fastmail, keeping other records for me, especially for the associated website.
<img src="./images/dns-fastmail.png" alt="DNS Record in Fastmail">
DNS records are very hard to understand, but fortunately, the MX records that handle email redirection are not the worst.
The main problem is that you must wait hours before knowing if the dns record is good or not. And <code>hours</code> is not precise enough.
The other problem is that I had to create email box on Gandi, then the MX would redirect to Fastmail. And emails are limited to two. It's not Gandi's Job.
So the standard way is better. Let say to Gandi that the serveur name is not on Gandi's IP but Fastmail IP.
<img src="./images/dns-servers.png" alt="DNS Servers in Gandi">
<h2>Import emails</h2>
Then you must import all of your mail from Gmail. The main difficulty is to turn off Gmail security after these messages:
https://www.fastmail.com/help/account/gmailimport.html
<blockquote>
Critical security alert : A suspicious app was blocked from accessing your account
</blockquote>
You must temporarily accept <a href="https://myaccount.google.com/lesssecureapps">Less secured Apps</a> in your Google account
And don't forget to put security back after import. You should still keep your Google account safe.
<h2>Ooops</h2>
It looks like Gmail and Fastmail have not the same relationship with the read word. I had more than 4000 supposed
unread messages. It's very easy to deal with that, but needs a bit of courage. Just archive them.
<img src="./images/archive.png" alt="">