269 private links
- I still don't know very much.
- The hardest part of software is building the right thing.
- The best software engineers think like designers.
- The best code is no code, or code you don't have to maintain.
- Software is a means to an end.
- Sometimes you have to stop sharpening the saw, and just start cutting shit.
- If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system.
- Every system eventually sicks, get over it.
- Nobody asks "why" enough.
- We should be far more focused on avoiding 0.1x programmers than finding 10x programmers.
- One of the biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be.
- People don’t really want innovation.
- Your data is the most important part of your system.
- Look for technological sharks.
- Don't mistake humility for ignorance.
- Software engineers should write regularly.
- Keep your processes as lean as possible.
- Software engineers, like all humans, need to feel ownership.
- Interviews are almost worthless for telling how good of a team member someone will be.
- Always strive to build a smaller system.
A blog post as response to it ?
- ... true at some point
- IDK
- TRUE. I see it between Typescript and Javascript. If you know how TS works, then
- I don't have enough experience about this to know if it is right to me
- Except with regulations
- True, but the API seems to be easier and more powerful over time. You can do now things that are more powerful than before.
- pairing +1
- YES
- Maybe. I am currently satisfied with the new cli tools (fd, exa, bat, nvim ...)
- Maybe
- They can be improved
- True as the companies does not want to get involved. But how to blame if your products are going to be more expensive than others.
- True. We need regulations. The GDPR in Europe or the accessibility laws in the US lead the way.
A little project with a quasi daily positive impact. True Myth export 3 types: Maybe, Result and Unit.
- I bet he's thinking about other women
- log4j log4j log4j log4j log4j log4j log4j log4j log4j log4j log4j log4j
Un retour d'expérience sur le développement d'un jeu, 1 an et demi après.
Voici le retour:
Microservices vs. Monolithe n'est pas la question: dans tous les cas, votre soucis le plus immédiat est d’isoler les composants chacun derrière des interfaces publiques clairement définies. Avoir un binaire par tâche ou plusieurs dépend en réalité du nombre de personnes et d'équipes qui travaillent sur le projet.
À voir le projet gRPC afin de faire communiquer les différentes interfaces. Pourquoi gRPC ? Pour générer automatiquement le code d'un service lorsque celui-ci se content d'exposer des méthodes CRUD sur une simple entité dans une base de données SQL.
Qui finalement s'est révélé moins pratique à la longue lorsque les requêtes se sont complexifiées.
Contrairement au dicton qu'il ne faut pas réinventer la roue, certaines valent mieux être réinventée. Ici:
- l'ORM gorm par une bibliothèque plus bas niveau: sqlx
- testify remplacé par rien
Finalement, ce n'est pas une réinvention, mais un débarras de surcouche en complexité.
Le mantra d'E.W. Djikstra:
Are you quite sure that all those bells and whistles, all those wonderful facilities of your so called powerful programming languages, belong to the solution set rather than the problem set?
la maîtrise du problème est beaucoup plus importante que la solution qu’on lui apporte
Concernant les tests: l'auteur recommande le TDD pour développer ce qui est utile uniquement.
Enfin il s'agit surtout de maîtriser le problème afin de parvenir à une excellente solution.
Guidelines:
- make small changes in each PR
- precommit hooks
- pair programming
Guidelines:
- don't make it personal
- don't fall in love with your code
- reviewer is not alwyas right
- Do make sure the why
- Do make your own comments
The first rule of thumb:
If you’re stuck for over an hour, seek help.
with
When you seek advice, first write down everything you’ve tried.
that as 3 benefits:
- act as a rubber duck debugging
- evidence that there is some kind of structured thought process that has been carried out, and what it was
- saving time explaining the context to someone else
If this is not useful enough, the author recommends to use his formula.
Why this post ?
The software industry is filled with a chaotic mess of a developer experience. Everything and anything can break.
🤣😭
If you figure out something fun, and integration that otherwise wasted an hour or two. Find ways to document it. On StackOverflow or on your blog or what have you. Just do that. Many developers including your future self will thank you for that.
So does this implies writing question and posting your own answer ?
About data structures, immutable and mutable data, programming model, public interface, distributed system, always having a limit for everything and trust your gut.
Je veux être fier de mon travail. Je veux fournir des choses qui fonctionnent, qui sont stables. Pour faire ça, il faut que l’on comprenne ce que nous faisons, à l’entrée et à la sortie, et ça ne peut pas se faire dans un système fourre-tout avec autant de surcouches.
👍 pour tout ce qui est énoncé dans ce billet de blog
- De quoi parle-t-on ?
l’architecture micro frontend c’est faire d’une application web front-end un ensemble d’applications indépendantes (cycle de vie, complexité, technologie) cohabitant et communiquant sur le même site.
-
Concrètement, pourquoi faire ?
-
front + front = front ?
Technologies pour les construire:- Web Components
- Node.js / Express / EJS
- Framework Single SPA
-
Comment les applications communiquent entre elles ?
- Attributes et properties
- DOM / Custom Events
- Solution de state management
- sessionStorage / localStorage / cookies
-
Quelle stratégie de tests utiliser ?
-
Ai-je vraiment besoin des micro frontends ?
Hey, on m'a assigné des bugs à corriger sur ton dernier projet, mais j'ai l'impression qu'il n'y a pas de documentation ?
Hein ?
Bien sûr qu'il y a de la doc. Il y a des infos dans des readme, et des éléments sur le Jira. Ou alors c'est dans le Trello. En plus, on a mis des infos sur des Google Docs dans un dossier partagé, regarde si t'as les droits. Même si c'est pas à jour c'est utile. Et, au pire, il y a plein de commentaires contextuels dans le code...
Bref, c'est bien ce que je disais... y a pas de doc
in-house expertise is needed at some point.
Advices for open source projects:
- don't make promises
- don't try to compete on anything
- just describe what it does now and have fun with it
An not ending mess as we know it. This may improve in the future though...
Tout peut s'écrire sous forme de fonction quoi !
with examples
With software development, though, mistakes are free! If we make a mistake, we can tab back to our editor, change the code, and try again. We even have helpful error messages that can (sometimes) point us in the right direction. This is an incredible luxury, and not one that we take advantage of enough.
I should the "learn in public" philosophy as it could fit what I want to do :)