|
12345678910111213141516171819202122232425262728 |
- # Smolstack
-
- > [en] The “smol” net is the “small” net. It’s small because it is build for friends and friends of friends. It doesn’t have to scale to millions of people because those millions should build their own local small nets.
- >
- > <cite>*[CommunityWiki: Smol Net](https://communitywiki.org/wiki/SmolNet)* ([cache](/david/cache/2021/cd910565715dbc18d4b31ad60546a4a3/))</cite>
-
- On me demandait [récemment](/david/2021/03/23/) si je me considérais comme étant un développeur *fullstack*. Avec le recul, cette question m’a permis d’affiner ce que j’entends par ce terme et pourquoi je ne veux pas l’être. Je me suis aussi [replongé](/david/blog/2017/web-developer/) dans mes [archives](/david/blog/2016/inclusive-developer/) car le sujet n’est pas nouveau mais j’ai besoin de le revisiter régulièrement.
-
- Ce que l’on entend traditionnellement par le terme *fullstack* me semble aller de l’orchestration de containers (incluant sécurité, disponibilité, redondance, etc.) à l’interface utilisateur·ice et à son expérience que l’on espère la plus pertinente possible (incluant l’accessibilité, les performances, etc.) en passant par le *backend* et le *frontend* qui apportent leur lot de connaissances à maîtriser et maintenir à jour. Mais ce n’est pas tant le périmètre en lui-même que l’appétence que l’on peut avoir pour l’ensemble de ce spectre qui est une attente qui *m*’est irréaliste.
-
- Je vais maintenant essayer de définir ce que j’entends par *smolstack*, c’est brouillon et je vais probablement avoir besoin de plusieurs itérations :
-
- * vérifier la pertinence des fonctionnalités avec des tests utilisateur·ices ;
- * réduire les dépendances au maximum et être guidé par le besoin plus que par la tendance actuelle ;
- * prendre le temps de faire le ménage à tous les niveaux : nouvelles attentes, évolution de dépendance, retrait de fonctionnalités, etc. ;
- * faire en sorte que les données soient accessibles au plus grand nombre (je vais avoir besoin de préciser ce point) ;
- * privilégier le statique tant que c’est possible, il n’y a rien qui soit plus performant et polyvalent ;
- * arbitrer la [complexité](/david/blog/2017/bugs-complexite/) vis-à-vis de l’impact que cela va avoir sur les utilisateur·ices mais aussi la maintenance, la fiabilité et la légèreté du produit ;
- * documenter les choix techniques ainsi que les joies/échecs associés (journal d’équipe ?) ;
- * envisager l’essaimage plutôt que le passage à l’échelle.
-
- Je vais m’arrêter là pour ce soir, je n’ai pas l’ambition d’en faire un manifeste, ni la prétention d’en faire un terme consacré. Je le vois plus comme une ébauche [inspirante et vivante](/david/2021/03/26/). C’est incomplet à dessein. Et ce sera obsolète dès demain.
-
- *Keep smoling!* 😀
-
- > [en] That last bit is a bit of a concern as ageism is already strong enough in web development for 30 to be considered old. ==The last thing I want is to be labelled a conservative old fogey in an industry dominated by novelty-seeking.== Mostly because it really isn’t accurate. I really *do* enjoy some of the new developments in the field. So much so that I constantly have to fight the urge to start building projects using the latest bit of shiny.
- >
- > <cite>*[Which type of novelty-seeking web developer are you?](https://www.baldurbjarnason.com/2021/which-kind-of-web-developer-are-you/)* ([cache](/david/cache/2021/809290eb60d9bda55b427919091533f0/))</cite>
|
