Antichesse (o ^ω^ o)
Oracle Enterprise est tellement confiante dans son produit phare Oracle Database, qu'elle a introduit des restrictions dans ses conditions d'utilisation interdisant la publication d'études et de benchmarks comparatifs de son outil...
Quand le professeur DeWitt avait réalisé un tel comparatif, Oracle l'avait alors attaqué en justice. Cette affaire est devenue tellement importante que ce type de restrictions s'appelle aujourd'hui une "DeWitt Clause".
A croire que l'entreprise n'a pas confiance en les capacités de son propre produit...
Avec ma moitié, nous devons refaire l'isolation de la toiture de notre nouvelle maison. Mais comme nous avons trop dépensé ces dernières années, nous sommes partis réaliser cette isolation nous-mêmes.
Pour choisir les bons matériaux plusieurs critères ont été retenus :
-
Le coefficient lambda qui doit être le plus petit possible.
- Il représente la quantité d'énergie qui a réussi a traverser l'isolant pour une section d'une même taille. Donc un lambda hyper bas indique que très peu de chaleur s'échappe.
-
La durée de déphasage qui doit être la plus grande possible.
- Cela représente la durée au-delà de laquelle l'isolant ne peut plus accumuler de la chaleur et donc va la laisser passer. Si votre région est un vrai cagnard en été, alors un déphasage de 8h fait que le soleil de 10h ne se fera pas sentir avant 18h dans votre maison. Alors qu'un déphasage de 4h fait que dès 14h il faudra allumer la climatisation...
-
Le niveau d'affaiblissement au bruit qui doit être le plus élevé possible.
- Attention, les chiffres ci-après sont une moyenne pondéré mais comme le bruit s'étend sur tout une gamme de fréquences audibles, il faut privilégier l'isolant qui correspond à cette fréquence. Par exemple, la laine de roche est super pour les bruits de conversation ou de voiture mais la laine de verre est meilleure pour les bruits d'impacts ou d'objets qui tombent.
=> Lire le PDF en lien.
Bref, avant cette petite étude, je pensais que la laine de verre sortait grande championne mais j'avais tort !
Voici un résumé
| Matériaux | Conductivité thermique lambda (- is better) |
Déphasage (+ is better) |
Atténuissement acoustique alpha pour 125 mm (+ is better) |
|---|---|---|---|
| Laine de Bois | 0,038 | 8 h | 0,60 |
| Laine de Roche | 0,035 | 6 h | 0,74 |
| Laine de Verre | 0,032 | 4 h | 0,29 |
| Plaque de Polyuréthane | 0,020 | 4 h | 0,04 |
Remarque
La laine de bois dans sa version ultra-vraiment-très-haut-de-gamme, c'est-à-dire mélangée avec du chanvre et du polystyrène, parvient à augmenter son coefficient alpha à 0,8 et baisser son coefficient lambda à 0,032 ce qui fait de lui l'un des meilleurs isolants (mais il semble sa durée de déphasage diminue sans que j'ai pu récupérer les chiffres exacts, donc ne pas prendre cette information comme argent comptant).
Par contre, la résistance au feu, à l'eau et aux nuisibles de la laine de bois est proche de l'infime. Mais pour isoler une toiture à partir d'un 3ème voir un 4ème étage près d'un aéroport, pourquoi pas.
Dernièrement je regardais les nouveautés en termes de frameworks CSS et globalement il y la liste suivante :
- Bootstrap
- Bulma
- Tailwind
- Foundation
- Skeleton
- Pure
- Tachyons
J'avais beaucoup d'espoir dans Tailwind qui adopte une approche par contraintes, dans le sens où il permet, sur chaque composant, d'appliquer des classes du type "à droite, vertical, graissé, etc" et c'est la combinaison de ces classes qui définira le rendu définitif du composant #SexySur20
A l'opposé, il y a Bulma où des composants déjà prêts existent et où les classes sont du type "burger-menu".
Sauf que je viens de m'apercevoir que Tailwind repose sur la mouvance JS bullshit dont la Comitstrip suivante matérialise parfaitement l'hérésie des fashions victims qui servissent dans l'industrie depuis un moment déjà :
Bref, il ne reste plus que Pure et Bulma comme frameworks CSS qui soient de vrais frameworks CSS paramétrables et simples. Certains me demanderont pourquoi j'insiste le fait d'avoir des CSS purs et durs et l'argument est simple : les SPA/PWA, j'en suis revenue !
Argumentons quand même. Selon moi, à moins que votre site implique au moins deux critères parmi les suivants (si ce n'est pas trois) :
- Du streaming de TRÈS gros fichiers (genre youtube)
- Des temps de surf qui se comptent en heureS (m'voyez le 'S') voire en jours
- Des actions ultra complexes (genre éditeur de photo en ligne)
- Le besoin de déporter des calculs côté clients si lourds qu'aucune infra sur terre ne tiendrait la charge si tout était centralisé côté serveur (ou alors à un coût équivalent à celui de ChatGPT)
- Le besoin de travailler en mode hors connexion
=> alors les SPA/PWA sont une mauvaise idée.
Du coup, la seule manière de pouvoir coder un design system qui fonctionne à la fois dans des MPA (ie. terme à la mode pour dire "pages générées côté serveur" comme Papy faisait avant en PHP) mais aussi dans des SPA/PWA, c'est d'avoir un framework CSS indépendant de tout JS et qui soit téléchargé en tant que fichier CSS et non JS.
Bref, je vais zoomer sur Pure histoire de voir ce qu'il est devenu - et peut-être Cardinal aussi - mais dans le fond, je pense garder Bulma d'autant que son développement aurait récemment repris :P
Le avant-après devrait permettre à la plupart de comprendre le problème de ces réformes.
P.S : si l'image ne s'affiche pas, remerciez Tweeter qui bloque les liens vers les images.
Rappel des définitions
PWA : Progressive Web App.
SPA : Single Page Application (voir ce post).
Introduction
Une PWA est fondamentalement une SPA à laquelle a été ajouté deux choses :
- Elle se comporte comme une application native sur les appareils (Mobile, Tablette et PC).
En d'autres termes, l'utilisateur trouvera sur son bureau une icône du site web développé à partir de la technologie PWA.
Elle peut travailler en mode déconnecté via ce que l'on appelle les Service Workers.
Fondamentalement qu'est-ce que ça change ?
Côté mobile, l’utilisateur installe la PWA de deux façons :
- Soit via un simple bookmark posé sur son bureau.
- Soit via un AppStore qui lui créera une icône sur son bureau.
Il a dont l'impression "d'installer une appli" et non plus de "surfer sur internet".
Si une panne de réseau survient, les Service Workers de la PWA vont prendre le relais et :
- Soit empiler les requêtes en fournissant les données précédentes.
- Soit en calculant les données requises (si possible).
Le Service Worker agit donc un peu comme un proxy, mais côté client, à qui le navigateur délègue l'accès au réseau.
Le gros avantage de la PWA sur les applications natives est qu'il n'est plus nécessaire de développé une version de GUI par plateforme mais tout via des technos web (Aurelia, Angular, Vue, etc).
Différence entre WebApp & SPA
Pour bien comprendre la différence, analysons le schéma placé en lien.
La partie supérieure montre bien qu'à chaque requête, toute la page est rechargée. C'est-à-dire que le navigateur va télécharger du HTML + du contenu (en supposant qu'il dispose déjà dans son cache de tous les CSS et JS dont il a besoin).
En-dessous se trouve la SPA, celle-ci va télécharger tout le HTML et le JS lors de la première requête uniquement. Ensuite, seule des données sont échangées entre le client et le serveur, généralement au format JSON (je précise minifié, ceci afin d'obtenir les meilleures performances possibles).
Quand utiliser quoi ?
- Lorsque vos utilisateurs surfent très peu sur votre site et qu'ils ont besoin d'accéder à du contenu rapidement, alors la WebApp est la solution à privilégier - le coût de chargement de la page étant réduit à l'ensemble des informations servant l'utilisateur).
- À l'inverse si vos utilisateurs sont connectés pendant dès heures sur votre site et qu'ils passent sans arrêt de page en page, alors la SPA est à privilégier - tout simplement parce que le coût de téléchargement de la première page (qui contient en réalité toutes les pages du site) est alors rentabilisé par le surf de longue durée.
Quelles technos pour des SPA ?
Les plus connues sont rangées par ordre décroissant d'importance sur le marché :
- Angular
- Vue JS
- React JS (+ redux)
- Ember JS
- Aurelia (qui est de loin ma préférée)
Un comparatif de performance entre différents serveur web expressifs du type Sparkjava (en java) et Sinatra (en Ruby). Pour rappel, un serveur web expression vous permet d'écrire ce genre de choses :
get("/mon/url", monAction);
post("/mon/url", monAction);
Avec "monAction" qui peut être au choix :
- une lambda
- une instance
- un pointeur sur fonction
En résumé, nous avons les résultats suivants sur un Retina Macbook Pro i7@2.7GHz and 16GB RAM :
-
Golang + bmizerany Pat + GOMAXPROCS(7):
51684 Requests/sec => 1550508 requests in 30s -
Sparkjava:
48631.24 Requests/sec => 1458768 requests in 30s
Average Latency 1.29ms -
Golang + bmizerany Pat:
42222 Requests/sec => 1266661 requests in 30s
Average Latency 1.52ms -
Golang + Gorilla Pat (using Gorillas Muxer)
37756 Requests/sec => 1132689 requests in 30s
Average Latency 1.71ms -
PyPy2.7 Python + Twisted:
12633 Requests/sec => 379001 requests in 30s -
Python + Flask:
11751 Requests/sec => 16393 requests in 30s
Average Latency 55.54ms -
Node + Express:
8962 Requests/sec => 268866 requests in 30s
Average Latency 7.14ms -
Python + Twisted:
3425 Requests/sec => 102781 requests in 30s
Un comparatif SAS vs SARL. Je me le garde sous le coude car il mesure laquelle des deux structures est la plus adaptée en fonction des rémunérations qui sont faites.
Un comparatif de la complexité des "niches fiscales" françaises versus le reste du monde.
NDR : plus la fiscalité d'un pays est complexe et plus ce pays est possédé par des dirigeants corrompus.
Benchmark de lib JS
Un comparatif qui démontre en quoi SVG c'est vraiment mieux que GIF. Dommage que le format ait autant peiné a être adopté.
Les publicités sur internet vous pourrissent la vie de plusieurs manières :
1) Elles vous importunent avec du contenu marketing.
2) Elles violent votre vie privée en déposant des cookie traceurs dans votre navigateur.
3) Elles rendent difficile la lecture des pages en ajoutant du contenu mouvant / coloré / etc.
4) Elles ralentissent votre surf de manière drastique.
Ici, un article qui mesure la vitesse de chargement d'une page web avec et sans pub. Imparable.
Un comparatif sur la popularité des frameworks PHP en 2015. Très bien pour savoir ce sur quoi se former.