Upload the JSON output of the stats and visualize it

A thoughtful post about prioritizing new development in a project.

L’ar­­ticle parle de revue mais les deux points à rete­­nir pour moi c’est que l’hu­­main doit rester en maîtrise et toujours prou­­ver que le résul­­tat est le bon, sans juste faire confiance, et que le volume de code est un ennemi encore plus fort qu’a­­vant parce que l’IA est forte à géné­­rer beau­­coup de code.

(via https://n.survol.fr/n/lecture-ai-writes-code-faster-your-job-is-still-to-prove-it-works)

Why the author arrived at this situation?

• Have fun
• No competition
• I can do hard things
• Everyone has area of specialization
• learning comes by "being fucking around"
• these adives can be wrong due to the survivor biais

Places to start: the mozilla development network, Arch Wiki, Stackoverflow, and how I think when I think about programming

and a practice guide for computer as one image: https://jyn.dev/assets/it-is-only-computer.png

The website we needed

The website we needed

A good use of <picture>, sparingly creating a system to fetch the main content of the page, minification, image optimization of all formats,

The final product was lightning-fast even on the weakest data connections and most underpowered devices. Showing it off at trade shows, we found that competitive products were still displaying a loading spinner when our application was already loaded, rendered, and running.

Score: 29

You are the web developer equivalent of the quiet old man in the bar who lurks in the corner and only interjects when the main character reaches a moment of crisis. You've seen some shit, enough to know when to sit down and shut up. You are so far into nerd territory that you're now cool again.

I also discovered the blog post via ThePrimeagean.

A follow-up post is published on the blog of Turso https://turso.tech/blog/working-on-databases-from-prison

Because you, the developer is the liability. It ensures the code should work as expected, either by manual testing (and reproductible behavior), code review or automated tests.

AI can write code, but ensuring and proving it works is

The permission system should handle folders and files.

Strategies:

1. (naive) read-time permission queries
2. A simple table (RBAC role based access control).

-- RBAC: Pre-computed permissions
-- access_type: 'owner' (full control), 'shared' (read only), 'path_only' (visible but no access)
CREATE TABLE permissions (
  user_id INTEGER NOT NULL,
  resource_id INTEGER NOT NULL,
  access_type TEXT NOT NULL,
  PRIMARY KEY (user_id, resource_id),
  FOREIGN KEY (user_id) REFERENCES users(id),
  FOREIGN KEY (resource_id) REFERENCES resources(id)
);

3. Attribute-Based Access Control

This approach is very clear and composable. It works great for single-resource access checks: "can user X access resource Y?" It struggles when listing resources, as we would need to execute the policies for each resource and can't directly query the resources table with simple filters.

4. Zanzibar and ReBAC

Avec l'IA, l'ingénieur ne va plus dans un premier temps rechercher obligatoirement la solution, mais mettre en place le cadre, les outils, la surveillance, les docu­men­ta­tions, la chaîne de produc­tion et de livrai­son.
Dans un second temps, il va rester artisan. L’enjeu est de remon­ter partiel­le­ment la chaîne, se concen­trer sur ce qu’on veut produire, pourquoi, comment, et traduire le besoin.

La plupart des artisans purs vont alors se raréfier. "Il y a toujours des arti­sans potiers, céra­mistes et porce­lai­niers aujourd’­hui. Peu, mais il y en a. Ils répondent à des demandes diffé­rentes. Certains sont experts pour des demandes hors normes. D’autres, plus nombreux, visent des objec­tifs non utili­taires : le luxe, le tourisme, les cadeaux, les symboles, l’hé­ri­tage histo­rique, l’art."

Alors que deviendra l'artisanat logiciel?

Peut-être à des systèmes critiques où la confiance exige une main humaine. Peut-être à des créa­tions où l’in­ten­tion artis­tique prime sur l’ef­fi­ca­cité. Peut-être simple­ment au plai­sir de comprendre ce qu’on construit, ligne par ligne. Il y a un métier à trou­ver, ce ne sera pas tout à fait le même et il sera proba­ble­ment plus l’ex­cep­tion que la règle.

Coté développement, il y a toujours eu un énorme terrain de jeu hors professionnel avec l'open source.

Baseline in action is a collection of articles and demos showing you some of what's possible with features that are now Baseline.

3 rules to it:

• the fastest code is the code you don't run.
• the smaller the code, the less there is to go wrong.
• the less you run, the smaller the attack surface.

Rewrite to native is also an option: Atom got 10x faster with Zed.
COSMIC desktop looks like GNOME, works like GNOME SHell, but it's faster and smaller and more customisable because it's native Rust code.

The COSMIC desktop looks like GNOME, works like GNOME Shell, but it's smaller and faster and more customisable because it's native Rust code. GNOME Shell is Javascript running on an embedded copy of Mozilla's Javascript runtime.

Just like dotcoms wanted to dis-intermediate business, remove middlemen and distributors for faster sales, we could use disintermediation in our software. Fewer runtimes, better smarter compiled languages so we can trap more errors and have faster and safer compiled native code.

Dennis Ritchie and Ken Thompson knew this. That's why Research Unix evolved into Plan 9, which puts way more stuff through the filesystem to remove whole types of API. Everything's in a container all the time, the filesystem abstracts the network and the GUI and more. Under 10% of the syscalls of Linux, the kernel is 5MB of source, and yet it has much of Kubernetes in there. This is what we should be doing. This is what we need to do. Hack away at the code complexity. Don't add functionality, remove it. Simplify it. Enforce standards by putting them in the kernel and removing dozens of overlapping implementations. Make codebases that are smaller and readable by humans.

Gnome Shell is

One behind 37signals. They are currently doing great stuff with CSS.

We performed an empirical study to investigate whether the context of interruptions makes a difference. We found that context does not make a difference but surprisingly, people completed interrupted tasks in less time with no difference in quality. Our data suggests that people compensate for interruptions by working faster, but this comes at a price: experiencing more stress, higher frustration, time pressure and effort. Individual differences exist in the management of interruptions: personality measures of openness to experience and need for personal structure predict disruption costs of interruptions. We discuss implications for how system design can support interrupted work.