Les liens de la mer numérique
-
Une seule chose à la fois
-
L’andon. On arrête tout.
Si une personne est bloqué, on arrête tout tant qu'une solution n'est pas trouvé. Si besoin, on fait évoluer les standards. -
les standards
Alors si tu sais comment livrer du code de qualité, écris-le et explique-le. Un document qui guide notre façon de travailler et auquel on a nous-même contribué, c’est un outil simple et puissant pour accroître la qualité de ce qu’on fait.
roadmap.sh is a community effort to create roadmaps, guides and other educational content to help guide the developers in picking up the path and guide their learnings.
Our tools are the best, with features that impress
🎶
We build relationships, with developers we meet
And together, we make the product complete
Pour aller plus loin, le code en lui-même n’est peut-être pas si critique, mais ce que l’on a appris en le concevant et l’utilisant l’est bien davantage. C’est cette transmission qu’il est important de rendre possible au sein de l’équipe.
All in one resource that includes dozens of tools and utilities useful for web developers and programmers.
It seems well designed :)
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!
- Better appreciate the OSS work
- A better understanding of the underlying tools you use and the benefits with it
- Deepen the knowledge of the programming languages with state-of-the-art examples
- Learning workflows and communication with other devs
- Open to job opportunities
Utiliser des solutions plus faciles en premier:
- une API documentée
- une API utilisée par le service web en question
- 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.
- 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:
- Design a new schema change that can be applied without changing the application code that uses it.
- Ship that change to production, upgrading your database while keeping the old code working.
- Now ship new application code that uses the new schema.
- 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