Genre là pour Feedbin, faut 3 ou 4 processus différents qui tournent (Redis, Sidekiq, nginx, ruby, ....), avec une installation à rallonge, où tu dois définir 28 (j'ai compté) variables d'environnement, qui checkout la moitié des gems ruby dans ton home..
Tu viens de découvrir qu'il existe un fossé entre les objectifs des projets destiné à l'hébergement personnel et les services hébergés.
Pour l'un on veut des dépendances minimales, une installation simple et un footprint minimal en s'en tamponnant des perfs. Pour l'autre on cherche une architecture robuste pour assurer la résilience du service, qui sera capable d'encaisser la charge et qui dispose de briques évolutive pour répondre rapidement aux différentes évolutions fonctionnelles ou non-fonctionnelles (basiquement tu scales petit à petit tout ses composants qui deviennent des goulots d'étranglement).
Ces contraintes et objectifs sont très important à comprendre quand on évalue des produits ou des technos ainsi que quand on créer un produit. Et je pense que c'est un problème courant quand on lit les conneries sur telle ou telle technos alors que le mec n'a visiblement pas su cerner le contexte dans lequel elle avait un intêret.
C'est la tout le problème pour les produits libre destinés aux particuliers et voulant jouer sur les deux tableaux. Il faut souvent une partie cloud/hébergement pour se financer et ainsi pouvoir arriver à un niveau de développement qui permet de faire des produits qui évoluent vites et sont bien polishés (une bonne UI/UX ca coûte une blinde, ca demande pas mal de technique et c'est donc très rare). Mais si tu pars avec ce modèle en tête alors tu as un produit inadapté à l'auto-hébergement du geek qui veut faire tourner ses 300 services dans 32Mo de RAM sur un ARM. On ne peut pas tout avoir et il faut faire des choix.
[^] # Re: Encore un truc que tu dois héberger sur un Quad Core
Posté par ckyl . En réponse à la dépêche Libération de Feedbin, lecteur de flux RSS/ATOM. Évalué à 8.
Tu viens de découvrir qu'il existe un fossé entre les objectifs des projets destiné à l'hébergement personnel et les services hébergés.
Pour l'un on veut des dépendances minimales, une installation simple et un footprint minimal en s'en tamponnant des perfs. Pour l'autre on cherche une architecture robuste pour assurer la résilience du service, qui sera capable d'encaisser la charge et qui dispose de briques évolutive pour répondre rapidement aux différentes évolutions fonctionnelles ou non-fonctionnelles (basiquement tu scales petit à petit tout ses composants qui deviennent des goulots d'étranglement).
Ces contraintes et objectifs sont très important à comprendre quand on évalue des produits ou des technos ainsi que quand on créer un produit. Et je pense que c'est un problème courant quand on lit les conneries sur telle ou telle technos alors que le mec n'a visiblement pas su cerner le contexte dans lequel elle avait un intêret.
C'est la tout le problème pour les produits libre destinés aux particuliers et voulant jouer sur les deux tableaux. Il faut souvent une partie cloud/hébergement pour se financer et ainsi pouvoir arriver à un niveau de développement qui permet de faire des produits qui évoluent vites et sont bien polishés (une bonne UI/UX ca coûte une blinde, ca demande pas mal de technique et c'est donc très rare). Mais si tu pars avec ce modèle en tête alors tu as un produit inadapté à l'auto-hébergement du geek qui veut faire tourner ses 300 services dans 32Mo de RAM sur un ARM. On ne peut pas tout avoir et il faut faire des choix.