A method applied from Programming as Theory Building from Peter Naur to solve the problem about a behavior of neovim.

"abstraction" in mathematics means to use a higher-level concept that carries fewer assumptions but covers a broader superset of cases. complexity is removed for the sake of generalizability. "abstraction" in programming means to paper over the underlying workings of a system with shorthands or conveniences. complexity is added so you can pretend it isn't there. no matter how you dress it up, when you're using a computer, you are always somewhere in the jenga pagoda

master the fundamentals, understand how they're composed into abstractions, and you can pick almost anything up as you go.

So how to master them?

What is a kata: basic programming concepts as akin to martial arts kata. To be really good, you don't need to study any particular big thing. you need to practice and understand the small things, over and over, until they're second nature.

Frameworks and librairies are domains of specialists.

The rest is content about programming:

Kata one: variables, flow control, scope, functions; memory semantics stack and heap
Kata two: indirection and recursion; memory semantics structs, arrays, enums

Paradigms: imperative and oop
Disgression two: odds and ends. OS, IDEs, VCS, programming loop with feedback and responses,

Kata three: registers, jumps, calling convention

once you are are good at programming, you will have literally hundreds of ideas of things to do but lack the time to do more than two or three at once. so enjoy it while it lasts

Yes indeed

The end: further reading

the important thing to remember is that it's not enough to be valuable. you must be legibly valuable. this trips up people who are not used to cultivating an appearance.

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.

Enter the “rule of three” — the actually actionable, pragmatic principle that elegantly combines how you should be thinking about YAGNI, DRY and premature optimisation. The rule of three states that you should only refactor (or optimise) code once you’ve written the same code three times.

At the first time of writing the code, code that’s fast and optimized is great, but if it’s hard to read and reason about, it will slow us down in the long run. Here, I like to apply another principle: “Make it work, make it right, make it fast”

It works while iteration though. In some cases, you want to leverage engineering: make it right the first pass. It happens for API validation for example, or logging correctly in case of failure.

Gall's law: a complex system that works is invariably found to have evolved from a simple system that worked

Functions should be as idempotent as possible: all it really means is that a function always does the same thing when given the same arguments. Note idempotent functions are different from pure functions. pure functions are guaranteed to not have side effects.

Then there is this single responsibility principle. It avoid changes on the entire codebase. "A small trick to check for single responsibility is to describe what a function/module/class does in a single sentence. If you find yourself saying “and”, then it probably has multiple responsibilities and should be split up."

One efficient implementation is to operate on one level of abstraction. See a function implemented in three functions. I would still be critic on this one, because the tradeoff is not worth it from time to time.

These code principles are similar indeed. "All good code is alike; each bad code is bad in its own way."