What's surprising is that Brad Frost shared this in 2011.

The key points are:

• They are a plethora of devices
• The power of the web is in its ubiquity. The web's superpower is its ability to go to more places than any proprietary solution.
• There is no future proof, but it can be future-friendly
• Content like water: it's fluid
• the mobile web browser is unique because it has native mobile conventions
• Mobile-first and responsive design please
• Native Vs Web are built differently. They both have they strength.
• structured content first
• design for diversity: does hte user have a touch-enabled device? Navigation with mouse and keyboard, D-pad, touch device, ...
• take advatange of the CSS cascade
• progressive enhancement Javascript
• separate sites aren't scalable (m.site.com, tv.site.com)

ApacheBench (ab) pour lancer un nombre de requêtes: ab -n 5000 -c 100 http://tested.example.org/. Le logiciel donne les p50, p66, ... p95, p98, p99 et p100.

Siege : siege -c 100 -r 50 http://tested.example.org/
donne:

Transactions:               5000 hits
Availability:             100.00 %
Elapsed time:               5.09 secs
Response time:              0.07 secs
Transaction rate:         982.32 trans/sec
Concurrency:               66.82
Successful transactions:        5000
Failed transactions:               0
Longest transaction:            3.05
Shortest transaction:           0.00

JMeter en Java nécessite un test plan.

Cassowary en go, mais ils n'affichent pas les erreurs.

k6 de Grafana

Gatling plus complet, mais il faut écrire du code pour chaque tests.

Locust est aussi plus complet avec une UI, mais le programme devient rapidement limité par le CPU.

Conclusion: il n'y a pas un logiciel idéal, autant en essayer plusieurs.

Try CSS selectors as fast as possible

data:text/html can embed things directly in the URL actually.

Rust allows precision and provide intent with the code.

Tangled is no good alternative based on their UI choices

Un ERP open source. Le projet est disponible à https://github.com/glpi-project/glpi

Leur roadmap est intéressante: https://www.glpi-project.org/fr/roadmap/

Oui la publicité à un impact important sur le numérique.

C’est pas que je me la pète individuellement, mais que je constate que la plupart des décisions sociétalement prises se sont révélées être les mauvaises. Et que ça a toujours été plutôt les 2-3 personnes bien isolées et moquées dans leurs coins qui auraient dû être écoutées…

J'ai aussi cette impression sur la gouvernance de la France. Le nucléaire en 2015,

Le champ ressemble fortement au HTTP.

The bandwith (with linear data) is more efficient than RAM.

Part 1 showed that computers are getting wider, not faster, and that PCIe bandwidth is outpacing DRAM bandwidth.
Part 2 showed that streaming from disk can beat streaming from the page cache.
Part 2.5 showed that with the right hardware and software, streaming from disk can beat a buffer in DRAM. So far I've shown how a sequential read from NVMe is fast, which is a cool trick but not controversial enough.

Big O notation assumes every step costs the same. They don't. The notation defines the shape of the performance curve but not it's slope or magnitude.

Big O notation can't see some limits such as AVL search drops from 4.0M/S to 2.3M/s between 512K and 1M nodes

Better than AVL tree:

• an adaptive Radix tree: walks the bits of the key instead of comparing
• A B+tree: (fat nodes with many keys each, so far fewer levels
• NextArray: extensible array using a specific amount of RAM for pagination such as 1 KiB in RAM

I didn't have use cases for this, but it's interesting to see how massive text data are processed. The goal was to build a tool FineWeb with high quality data.

Used to build https://practicaltypography.com/index.html

Pour les fonts, je viens d'apprendre qu'il est possible de forcer l'utilisation de la police en local via le src: local("Verdana")".

Le site doit fonctionner sans JS; utiliser le CSS au lieu du JS quand c'est possible; diminuer le poids des images en servant des images plus petite en taille pour le mobile;

1. A DevOps team is not devOps anymore
2. The minimal needs to make the app working is not devOps

The term in companies is often misused or overused.

The author recommends to follow five core components:

1. Extendable with open-source tooling. Teams and workloads are different and will have different golden paths
2. Anti-Lock-In as the platform should be able to walk away from a bad build-or-buy decision
3. Security, compliance, and guardrails must be built in.
4. Powerful building blocks to increase engineering velocity.
5. Enable experimentation to be able to try things out
6. Ephemeral environments for applications and infrastructure.
7. Configurable alerting and monitoring

Keep public functions for public use. Internal use of public functions should be avoided because they are not meant for these cases. "By proactively making the shared implementation private, the tension is defused. "

Rationale: the goal of a public API is to provide an interface that works best at the call site. If parts of public API are re-used to implement the rest of the API, then there’s a tension between making the interface convenient for the outside user and making it convenient to use from within abstraction itself.