About software supply chain attacks and FOSS software:

There is a small problem here. We are not suppliers. We do not have a business relationship with all these organisations. We are volunteers, writing code and putting it online under these Licences. And yes, we put it online for people to use them. But we do not get anything from it.

[With the MIT licence, maintainers] do not have a business relationship with all these organisations. [Maintainers] are volunteers, writing code and putting it online under these Licences. And yes, [Maintainers] put it online for people to use them. But [Maintainers] do not get anything from it.

To get a supplier, you need to give people what they need to live and they have to agree to these terms.

Consistency is the deciding factor in long-term success

Totally agree.

We can all stay consistent when we're in a great mood and feeling motivated. What really makes the difference is finding a way to stay consistent when we feel like shit and would rather stay in bed.

A key difference is how to react when it is hard or you don't want to do it anymore.

When we fall to the Sunk Cost Fallacy, we are most likely to continue an endeavour if we have already invested in it, minimising downsides and new information in the process.

It happens due to three reasons:

• the commitment bias: we stick to a previous decision despite new evidence showing it isn’t the best course of action
• the loss aversion bias: avoid being in a losing situation since losses feel much worse than gains.
• the endowment effect: we tend to attribute more value to something we own or make than something we buy.

Solution?

Instead of estimating how long it will take to code a feature, you could estimate the maximum amount you’re willing to spend on this feature

Tooling for DX have skyrocketed these last years.

Point is it is still hard to develop these tools: what if there is a standard? "What if your users could start writing lint rules immediately?".

As an example of Tree-sitter, what if such a compiler could include every build framework such as salsa, turbo [opinionated thought], VSCode, etc...

All of these tools are what I’d call meta-tools. They allow programming language implementors to increase their productivity in a comparable manner to how developer tools increase the productivity of regular developers.

How?

• Meta-tools must offer such a compelling suite of features that it becomes difficult to refuse.
• The experience of using a meta-tool should also be first-class.
• Meta-tools must fundamentally be extensible: being able to implement theirself 1% needed.

What keeps Rust from being an Inria PhD student’s thesis that nobody uses is its focus on tooling, good compiler diagnostics, and ecosystem

• raise the bar: maybe it’s better code generation for scaffolding projects. Maybe it’s extremely quick deployment based on incremental compilation. Maybe it’s seamless interop with other languages.

Because without reproduction, it takes so much time!

Open Source Software is served "as-is"

So provide a repro or don't open an issue.

Tools that developers can need

Well written :)

I thought the same till some times ago, but now I disagree.

if you're commenting to explain the how and the what, then yes, you're doing it wrong.

If you are commenting the why, it makes sense and it could save hours of rediscovering what was obvious only while writing it.

👍

In bulk and there is a lot!

1. Better appreciate the OSS work
2. A better understanding of the underlying tools you use and the benefits with it
3. Deepen the knowledge of the programming languages with state-of-the-art examples
4. Learning workflows and communication with other devs
5. Open to job opportunities

Utiliser des solutions plus faciles en premier:

1. une API documentée
2. une API utilisée par le service web en question
3. Flux RSS, websockets
   • Les flux RSS ont tendance à être très utiles pour tout ce qui ressemble de près ou de loin à un blog.
4. Parser le HTML

J'avais toujours utilisé le 1 ou le 4 :u

Vous venez de trouver une API sur un site internet et souhaitez l’utiliser dans du code, tout a l’air similaire mais quand vous exécutez votre requête vous obtenez une erreur.

Dans 90 % du temps, c'est un problème de User-Agent.

Pour éviter de surcharger un site:

Google Cache est un outil de Google qui garde une version en cache d’un site web, pour l’utiliser il suffit de remplacer par le lien que vous souhaitez scraper, vous n’ interagissez pas directement avec le site, mais bien avec Google cache.
https://webcache.googleusercontent.com/search?ie=UTF-8&q=cache:

Tout est question d'investissement

Good practices !
✅ on my personal projects

• Documentation in the same repo as the code ✅
• Mechanisms for creating test data
• Rock solid database migrations
• Templates for new projects and components
• Automated code formatting ✅
• Tested, automated process for new development environments ✅
• Automated preview environments ✅

As a result, to avoid downtime you need to design every schema change with this in mind. The process needs to be:

1. Design a new schema change that can be applied without changing the application code that uses it.
2. Ship that change to production, upgrading your database while keeping the old code working.
3. Now ship new application code that uses the new schema.
4. Ship a new schema change that cleans up any remaining work—dropping columns that are no longer used, for example.

Integrate a code sandbox with live edit functions directly in pages. I am totally for it ! :D

Here is a guide

Things to consider :

• alternative descriptions
• character sets and language codes
• documentation
• invisible content
• ask for Voluntary Product Accessibility Template (VPAT) and use it
• CLI tools are also concerned with accessibility

Sous traiter son travail de dev, y dépenser 1/5 de son salaire et

Au cours des dernières années il avait reçu d'excellentes remarques. Son code était propre, bien écrit, et soumis en temps opportun. Trimestre après trimestre, son examen de performance l'avait élu meilleur développeur de l'entreprise.

LOL

Clean code is not only concise code, but more importantly, it is readable. A rule of thumb when writing code, is to write code as if comments didn’t exist. The code should be self-explanatory.

• booleans should always have a prefix like "is", "has", or "was"

and other JS tips

Ce blog illustre chaque billet avec des images d'un thème donné.

Le dernier publié Comment affronter un entretien technique des enfers ? utilise les images du dictateur de Corée du Nord. Ces illustrations fonctionnent bien et renforcent le storytelling.

Comment devenir riche en vendant des JPGs utilise des images du loup de wall street.

4 raisons de se lancer dans une relation de mentorat a des illustrations des films Rocky