Les quatres manières de lire:

• indexation
• skimming
• analyse
• sémiologique

Concernant le code:

• Ne pas attribuer à la malveillance ce que la bêtise peut expliquer ;
• Ne pas attribuer à la stupidité ce qui est expliqué par le manque d'attention ;
• Ne pas attribuer au manque d'attention ce qui peut être expliqué par un contexte non dit ;
• Ne pas attribuer à un contexte non dit ce que le système autour de la personne peut expliquer ;

Beyond the basics, how did you know if you were doing a good job?

I didn’t. I’m not sure how I would.

When the feedback paths are missing, success is measured through peer opinion, i.e. the practitioners that have a good reputation among their peers are considered skilled, regardless of what their real world impact is.

major.minor.patch works well but not for applications.

1. Simplicity is essential
2. Solve problems instead of creating them
3. We are not smarter than others, others are usually not smarter
4. Do everything yourself
5. Strive for robustness
6. Do not think you can make computing "secure"
7. Use input devices when they make the most sense
8. Avoid all ornaments
9. Tools are just tools
10. Be humble
11. Don't work for free if you do not enjoy it
12. Do not listen to others

About high and low-programming languages

I go often for the state based version, based on component states.

Nearly all the state is handled in the view component.

Are we web yet? Well yes but with extra work. A lot of work.

The author provides its experience.

All the things I love about Django, could we have those for a Rust web framework so that we can reap the benefits of Rust without having to go needlessly slowly?

An attempt: https://git.sr.ht/~ntietz/newt

Never mind that you can also harvest code from any of your shelved projects. I mean why rewrite the Fisher–Yates shuffle algorithm if you have it already in a shelved game? Code for switching the monitor depth (on those early Macs) I moved from game to game… Polygon-point collision code, a sine lookup-table for quick trig functions, a dot-product routine, cross-product routines…

was the whole exercise of my guerilla programming technique a wash? Maybe. But it always served me well

There were times too when a coworker might have said, “You should have used a Bloom Filter” and I was able to come back with, “Yeah, already tried that but the typical data we are seeing is so small that the performance gains were negligible and added unnecessary complexity to the code base so I tossed it.” Boom!

A.B.I Always Be Iterating.

Software is a way to get something done.

The followers of the Code It Yourself Manifesto believe in these things:

• We implement it according to our own goals.
• We make mistakes and learn from them.
• We learn how our tools we depend on need to work.
• We gain a deep understanding of our problem domain.

About writing their own RSS script:

I learned new things and got satisfaction out of seeing them run correctly. I get nothing like that out of comparing apps and services.

the biggest advantage echoes what Dr. Drang says: Programming is often more fun than the alternative uses of my time.

Three reasons why time spent programming is well spent and joyful:

1. Learning: for example the EmojiHomepage to learn VueJS; Altercamp Live to learn "Phoenix LiveView" and practice OTP knowledge.
2. Control: the software does exactly what you want + from the self-built programs come the IKEA Effect
3. Creativity: creating anything is a desire and practicing it always leads to joyful experiences. That includes anything - complex systems, simple scripts, an article posted online, a wooden box.

The Hacker news discussion about this post has many testimony: side effects of programming without clear goal first. https://news.ycombinator.com/item?id=24564835

Every problem at every company I’ve ever worked at eventually boils down to “please dear god can we just hire people who know how to write HTML and CSS.”

This UX is awful? That UI looks old? Accessibility busted? Performance bad? Design team can’t ship stuff? Customers annoyed by tons of bugs? Everything takes too long to build? No time for small usability improvements?

Hire. HTML. And. CSS. People.

How to cache? It depends of the context: push vs pull and owned vs user.

Push means that the asset is pushed to a central server and then distributed.
Pull means the asset is referenced and the central server has to “pull” the content.
Owned means it’s owned by the central server.
User means it’s user-submitted content.

Push + owned

Make everything push + owned content if possible. "It turns out, however, that you can make a shit ton of other stuff push + owned if you try a little harder. "

How does the client check if they're expired?
Use “stale while re-validate”. Ur welc’

In summary:

• store asset
• use stale-while-re-validate access patterns
• should work offline

Push + User & Pull + Owned

Handle these with hash URLs. Hash the URL and treat it immutably.
Push + User: Forum comment -> hash URL
Pull + Owned: "in-content" assets. That’s where it’s user generated content, but not owned by the server.

Summary:

• Load asset
• Use infinite TTL + hashed URLs
• Should not re-fetch across page/app reloads

Pull + User

That’s where it’s user generated content, but not owned by the server. Posting gifs into the chat is a prime example; linking a blog post and generating a media upload for that is another.

Guess what: this pattern fits for highly dynamic user-generated content, which means it’s the content users link to each other in-platform.

Stable URL, short TTL. YES, SHORT TTL. [...] Debounce + throttle? Sure. Micro-TTL? Yes. Cache? Never.

The axioms of programming

• small teams
• difference between theory and practice
• metrics
• greenfield projects
• employee turnover
• "If anyone is remote, everyone is remote."
• "Given long enough, all tech discussions turn into discussions about K8s."
• two hard problems: People are the hardest problem in Computer Science; Convincing people that people are the hardest problem in Computer Science.

Générer dynamiquement des champs de formulaire totalement débile qu’on cache ensuite avec toutes les astuces de la terre pour ne pas les afficher aux utilisateurs. Mais pas aux bots.
Le champ est rempli à la soumission du formulaire ? Ah ben dégage le bot hein ☺️

Crev is a scalable, social, distributed Code Review and recommendation system that we desperately need for establishing trust in Open Source code.

Getting started: https://web.crev.dev/rust-reviews/your_personal_reviews/

The project is not maintained anymore though.

The Open Source ideology is misused by companies: its ideology concerns production (similarly to FLOSS). You contribute to the software back.

Copyleft can force an absolute minimal “contribution” back to your project, but it can’t force a good-faith one. This makes it an inadequate tool towards building something with the kinds of values that many developers care about.

But I do think I’ve properly identified the problem: many developers conceive of software freedom as something larger than purely a license that kinds in on redistribution. This is the new frontier for those who are thinking about furthering the goals of the free software and open source movements. Our old tools are inadequate, and I’m not sure that the needed replacements work, or even exist.

The downside of AI for programming:

• Erosion of Core Programming Skills
• Over-Reliance on Auto-Generated Code
• Lack of Ownership and Responsibility
• Reduced Learning Opportunities
• Narrowed Creative Thinking
• Dependency on Proprietary Tools
• false sense of expertise