El Titi a écrit 3952 commentaires

Merci pour cette clarification … même si je crains que certains choix de design ne vous conduisent à un moment à négliger l'une des 2 cibles.

Voici donc quelques suggestions qui pourraient influencer votre architecture. Je ne suis pas assez technique pour être précis mais je comprends que cette nouvelle architecture vous permettra de scaler en multipliant les instances et même si vous vous défendez d'utiliser des microservices, vous n'êtes pas non plus dans une approche monolithique. Vous explorez une voie intermédiaire.

Il y a 2 aspects qui, me semble t'il, ne doivent pas être négligés:

Le premier réside en la possibilité de faire du crowdsourcing.
Je m'explique: Vous évoquez le fait de pouvoir partager un album photo pour la famille et donc de mettre en place des niveaux de permission. Il faut donc qu'ils soient implémentés au niveau de votre API mais je n'ai pas trouvé à quel service ça pouvait correspondre.
Pour ce cas d'usage, un seul repository sert référence mais imaginez qu'à présent on puisse proposer un service de tags partageables entre tous pour identifier papi et mamie. Imaginez que sur une instance mutualisée chez un hébergeur, sur laquelle on stocke ses bookmarks, on veuille bénéficier de tags auto dont la pertinence est liée au nombre de clients qui ont appliqué ce même tag. Il serait dommage que chaque appli doivent réimplémenter çà au travers de requêtes massives sur l'API de chaque instance utilisateur. Il serait préférable d'offrir ce genre de service de base. Votre architecture le permettra t'elle ?

L'autre aspect est la fédération. A l'image de XMPP, on pourrait imaginer de mettre en relation plusieurs noeuds cozy afin par exemple de croiser encore plus les données ou autre exemple de partager des items de ma todolist avec d'autres utilisateurs qui ne sont pas hébergés sur le même noeud. Pour vous représenter ceci, vous pouvez vous inspirer d'OSLC qui a spécifié une architecture de bus et un protocole même s'il vise le domaine de l'ALM.

Enfin 2 petites questions.
* Il est fait mention du service /realtime. Est-ce que ceci fait référence à une implémentation des Websockets ?
* pour cozy desktop, vous avez pensé à un framework en particulier ? Electron ?

Je vais m'éloigner du sujet de la dépêche qui pose l'architecture mais j'aimerais quand même réagir sur votre stratégie.

Lorsque je lis:

Par contre, la suite à donner l'est moins. Frank défendait une approche où la majorité des personnes ont leur serveur (un RPi chez eux, ou un serveur loué à OVH, Gandi, etc.). Et dans cette approche, il est préférable de juste regrouper cozy-home, cozy-proxy et cozy-datasystem à l'intérieur d'un seul processus et d'optimiser sa consommation mémoire. Les gains sont faibles mais c'est relativement facile à mettre en place (en tout cas, bien plus facile que recoder le backend dans un autre langage).

À l'inverse, si la majorité des utilisateurs n'ont pas les compétences pour gérer leur serveur, ils vont se tourner vers des offres d'hébergement de cozy tierces. Ça peut-être l'offre beta de Cozy Cloud, bientôt celles de partenaires comme Gandi (avec qui nous avons remporté le Concours d'Innovation Numérique sur cette thématique), et plus tard, potentiellement ce que des grands groupes comme la MAIF pourront offrir à leurs clients. Dans ce cas là, il est possible d'aller beaucoup plus loin dans la réduction de la consommation de ressources (et donc faire baisser le prix d'une instance Cozy) en mutualisant les briques. Au lieu d'avoir un processus par utilisateur, on peut servir plusieurs utilisateurs avec ce même processus.

… je m'interroge quelques peu

Si on s'en tient à cet extrait, votre vision à terme n'est absolument pas l'auto-hébergement.
Vous souhaitez développer des partenariats et j'en conclus qu'il sera de plus en plus complexe de s'installer une infra pour son propre besoin sans être obligé d'en passer par un prestataire. Et vos choix architecturaux vont dans ce sens.
Je peux me tromper cependant.
Je comprend que chacun doive trouver des moyens de subsistance et je ne critique pas vos choix.

Mais il serait bien de les clarifier. Notamment sur votre page d'accueil on voit "Run your cloud at home"
Ca ne ma parait pas approprié.

Encore une fois je comprends votre position mais le minimum est d'être honnête avec vos potentiels "partenaires" (j'entends ceux qui vont rentrer dans l'aventure du LL).

Quoiqu'il en soit, me concernant je ne participerai pas si cette vision est confirmée.

D'ailleurs nous n'avons pas eu de nouvelles de Franck qui souhaitait s'exprimer.
Qu'il sache (s'il traîne par ici) en tout cas que je soutiens sa vision et que s'il souhaite relancer le projet en forkant dans cette direction, il trouvera certainement des soutiens.

Tout le monde comate encore ou quoi ?

Allez une petite interview du géniteur pour se mettre en bouche:
http://www.zdnet.fr/actualites/linus-torvalds-celebre-les-25-ans-de-linux-39841134.htm

Les liseuses c'est comme systemd, … c'est l'Avenir.

http://linuxfr.org/users/gnumdk/journaux/microsoft-powershell-libere#comment-1669525

Ou plutôt la plier avec un angle à 30 degré pour qu'elle dépasse.
Pour le reste son argumentaire est percutant.

Apparemment, il existait déjà une solution libre pour connecter des kanbans à Gitlab:
http://kanban.leanlabs.io/

Syndrome NIH ?

Pour être honnête les alternatives à Trello sont encore un peu … instables.
Et niveau fonctionnalité ce n'est pas très abouti, encore que Trello a beaucoup de limitations en lui-même pour du GTD:

Par exemple:
* les labels ne peuvent pas être partagés entre plusieurs boards (le transfert de listes les copient et on doit les gérer par tableaux)
* Lorsqu'on veut transformer un item de checklist en carte, on perd le lien avec la carte parente (pas top pour les projets GTD)
…

L'alternative la plus aboutie que j'ai essayé, c'est Restya:
http://restya.com/board/
Projet dynamique, interface moderne, … mais on se retrouve assez vite avec des petits bugs qui irritent et même s'ils prétendent
que les Websockets sont plus lentes que long polling, leur interface est beaucoup moins réactive que celle de Trello.
A noter que tu peux tester dans une sandbox.

Pour les alternatives liées à des issues Tracker, n'oubliez pas Tuleap. https://www.tuleap.org/
L'équipe est française et très sympa. On en a déjà parlé ici
Leur nouveau Kanban est pas mal est va remplacer progressivement toutes les vues où l'ancien était utilisé (rudimentaire)

houps doublon à supprimer SVP si un modo passe par là

ipython, c'est dépassé.

La nouvelle tuerie c'est xon.sh.
Cf; presentation au pycon
https://www.youtube.com/watch?v=uaje5I22kgE

Ca veut dire quoi "dénue" ? Habillée ?

Tomber des nues en revanche …

Tu parles de cette saloperie ?
https://www.google.fr/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#safe=active&q=incredimail+crapware

Je viens d'apprendre son vrai nom.
Bravo !

Je fais mon premier après avoir pris un ponne poufféé

Mon tout est un tzélebreu auteur anglais

Ach Ja, le PrinTemps Sur Le DanUbe, alors.
Trôle,, Très Trôle.

Mon premier est un mot familier pour designer à la fois mon moyen de locomotion roulant et mes émanations nauséabondes
Mon second désigne ce que l'on pense des autres lorsque qu'on les dénigre
Mon troisième coule dans nos veines
Mon quatrième est l'endroit où se retrouve nombre de mes seconds en ce moment et s'il en avait, il serait mon père
Mon cinquième vient après un
Mon sixième accueille les réfugiés à Calais
Mon septième est une commune de Meurthe et Moselle dont le nom correspond au début d'une autre du sud ouest où l'on voit la ville en rose.
Je me balade par mon huitième et par vaux
Mon neuvième est ce que fait mon second, lorsqu'il est à mon quatrième ou pour les malcomprenants, ce que mon devient monappendice après la veuve poignée
Mon dixième est comme mon second
Mon onzième est le verbe avoir conjugué à la première personne du singulier de l'indicatif présent

Mon tout résume l'ambiance ici en cette période estivale.

Surtout qu'il est conseillé de tester sur le dernier modèle (en fait idéalement sur plusieurs modèles, nouveaux et plus vieux; mais si on n'a peu de moyen ou de développeur, il vaut mieux se concentrer sur le dernier que sur des anciens pour questions de pérennité évidentes).

Oserais-je suggérer ceci?
(pour le non natif s'entend)

Pour le moment, il n'y a rien a redire sur la stratégie vis à vis du LL.

L'avenir nous dira ce qu'il en est. Des boîtes qui pratiquent l'open source washing, il y en a plus d'une.
Avec Tristan Nitot et toi dans le navire, on peut espérer que le projet ne s'égarera sur le chemin.

Que sera sera …

Tu as raison, c'est pour ça que Java prend enfin le virage de la programmation réactive avec RxJava car il se fait poutrer par du Node à tire larigot.
C'est pour ça que vert.x essaie péniblement de décoller et qu'Oracle va se recentrer sur les microservices (cf. mon post un peu plus bas)

Je pense qu'il faut l'utiliser pour être convaincu de s'en passer lorsqu'on en a la possibilité.

C'est pourquoi aussi, ce qui fait la richesse de l'écosystème java, c'est avant tout sa JVM qui permet de composer avec différents langage selon ses besoins.
Quel bonheur de pouvoir écrire ses TUs avec du Groovy et du Spock ( https://github.com/spockframework/spock ) tout en garantissant la qualité de ton code de prod au lieu de se taper des infâmes combinaison de JUnit, Mockito, AssertJ JUnitParams & Co
Quel bonheur de builder et deployer son produit avec du gradle plutôt que d'en passer par du XML et du Java.
Quel bonheur d'écrire du code de glue dans un langage dynamique tout en appelant directement des classes implémentées en Java
Quel bonheur de prototyper en Clojure …

C'est pour ça que le vilain troll lancé par le posteur du journal est mort-né et qu'il faut l'élever avec amour pour qu'il prenne un tant soit peu son envol.

Il n'y a que .NET qui puisse offrir la même chose à l'heure actuelle et l'ouverture qui se met en place est à mon sens une menace opportunité bien plus réelle de détrôner Java que les soubresauts d'Oracle.

Quels arguments !

Parce qu'un troll en vaut un autre.

La programmation par contrat est aussi un avantage du point de vue génie logiciel, l'inférence de type,
les test unitaires, …
Je vois aussi assez bien les inconvénients du typage statique.

Bref beaucoup de gratuité dans ces affirmations.

Le typage statique est un avantage ?

http://www.nextinpact.com/news/100588-oracle-veut-rassurer-developpement-java-ee-8-continue.htm

Il semble surtout qu'Oracle ait compris que l'avenir n'était plus au monolithe mais aux micro-services.

https://www.scm-manager.org/

Tu le lances, tu déclares tes dépôts et c'est parti !

Accessoirement tu installes ça sur un serveur Tomcat le connecte à un annuaire (Crowd pour nous) e ça tient la charge easy pour administrer des dépôts d'une entreprise.
Testé et approuvé dans une DSI de 500 personnes avec plus de 1000 dépôts dont certains d'une taille de 4Go.

Enjoy !!!

Ca, c'est de la mise bière !

Wow, c'est du lourd là.
Et pourquoi pas la théorie du grand complot ?