Pollen 2, préparation...
Hello, En vue de refaire Pollen from scratch, j'ai fait un peu le ménage dans les tickets. Les tickets des version >= 2 en tous été placés sur une version fictive (http://chorem.org/versions/99), on pourra rebalayer ces tickets quand on va ré-écrire la version 2.0. Sur la version 2.0 (http://chorem.org/versions/30), on a désormais que 3 tickets : - persistence http://chorem.org/issues/885 (topia) - REST API http://chorem.org/issues/886 (webmotion (pollen/api)) - UI http://chorem.org/issues/887 (html/javascript - webmotion (pollen/ui)) Sur chaque ticket y'a un pad pour qu'on puisse rédiger le document qui va servir pour la réalisation. Ainsi on aura la documentation (technique) déjà faite. Je compte faire une première passe sur l'api REST et le modèle de persistence, la semaine prochaine c'est la base... Pour les UI, il faut entamer une reflexion, avec peut-être de l'aide extérieure (ergonomes, école de design,...); la technologie de réalisation n'est pas très importante (l'api REST va nous permettre de nous affranchir de ça). Donc on pourrait imaginer du pure html-javascript, html 5, ... que sais-je. Avis aux amateurs, tony.
Hello, Pour décrire un peut les archi possibles coté WebMotion, tu peux faire de 2 façons différentes. La première façon consiste à avoir seulement un API JSON (de préférence), ce qu'il implique de faire ta gestion de page tout en javascript. Pour t'aider, tu as quelques frameworks JavaScript du style (backbone, angularjs, sammyjs, ...). La deuxième façon consiste à créer à la fois une API JSON et une couche web pour la gestion des pages en mutalisant dans une couche service les appels BD. L'avantage de la solution 1, c'est que tu aura une single page, et donc ton application sera plus sympa. Mais la solution 2 est plus facile à mettre en oeuvre. Ma folie me porterait sur la première solution. Julien Le Fri, 22 Feb 2013 11:28:26 +0100, Tony Chemit <chemit@codelutin.com> a écrit :
Hello,
En vue de refaire Pollen from scratch, j'ai fait un peu le ménage dans les tickets.
Les tickets des version >= 2 en tous été placés sur une version fictive (http://chorem.org/versions/99), on pourra rebalayer ces tickets quand on va ré-écrire la version 2.0.
Sur la version 2.0 (http://chorem.org/versions/30), on a désormais que 3 tickets :
- persistence http://chorem.org/issues/885 (topia) - REST API http://chorem.org/issues/886 (webmotion (pollen/api)) - UI http://chorem.org/issues/887 (html/javascript - webmotion (pollen/ui))
Sur chaque ticket y'a un pad pour qu'on puisse rédiger le document qui va servir pour la réalisation. Ainsi on aura la documentation (technique) déjà faite.
Je compte faire une première passe sur l'api REST et le modèle de persistence, la semaine prochaine c'est la base...
Pour les UI, il faut entamer une reflexion, avec peut-être de l'aide extérieure (ergonomes, école de design,...); la technologie de réalisation n'est pas très importante (l'api REST va nous permettre de nous affranchir de ça).
Donc on pourrait imaginer du pure html-javascript, html 5, ... que sais-je.
Avis aux amateurs,
tony. _______________________________________________ Pollen-devel mailing list Pollen-devel@list.chorem.org http://list.chorem.org/cgi-bin/mailman/listinfo/pollen-devel
Salut ! Le 2013-02-22 11:28, Tony Chemit a écrit :
Hello,
En vue de refaire Pollen from scratch, j'ai fait un peu le ménage dans les tickets.
Les tickets des version >= 2 en tous été placés sur une version fictive (http://chorem.org/versions/99), on pourra rebalayer ces tickets quand on va ré-écrire la version 2.0.
Sur la version 2.0 (http://chorem.org/versions/30), on a désormais que 3 tickets :
- persistence http://chorem.org/issues/885 (topia)
Je me demandais si la persistance NOSQL orientée document (MongoDB? Couchbase?) pourrait pas coller au modèle "vote" ? Je sais qu'on ne baigne pas dans ce paradigme, mais la souplesse et la "facilité" vu lors de conférence (JUG 2013 & Devoxx 2011), me laissent croire que ça peut coller...
- REST API http://chorem.org/issues/886 (webmotion (pollen/api)) - UI http://chorem.org/issues/887 (html/javascript - webmotion (pollen/ui))
Sur chaque ticket y'a un pad pour qu'on puisse rédiger le document qui va servir pour la réalisation. Ainsi on aura la documentation (technique) déjà faite.
Je compte faire une première passe sur l'api REST et le modèle de persistence, la semaine prochaine c'est la base...
Part-on dans l'idée de rester iso-fonctionnel, ou peut-on envisager d'y aller par etape, genre commencer à créer des sondages simples (oui/non et un total pour chaque choix) ? puis ensuite rajouter la complexité (Condorcet, pondération...)
Pour les UI, il faut entamer une reflexion, avec peut-être de l'aide extérieure (ergonomes, école de design,...); la technologie de réalisation n'est pas très importante (l'api REST va nous permettre de nous affranchir de ça).
Donc on pourrait imaginer du pure html-javascript, html 5, ... que sais-je.
Avis aux amateurs,
tony.
-- Yannick Martel
On Fri, 01 Mar 2013 15:14:57 +0100 Yannick Martel <martel@codelutin.com> wrote:
Salut ! ...
- persistence http://chorem.org/issues/885 (topia)
Je me demandais si la persistance NOSQL orientée document (MongoDB? Couchbase?) pourrait pas coller au modèle "vote" ? Je sais qu'on ne baigne pas dans ce paradigme, mais la souplesse et la "facilité" vu lors de conférence (JUG 2013 & Devoxx 2011), me laissent croire que ça peut coller...
Si on part dans le NoSQL, j'aurais peut-être dit plutôt une base orienté graph car il y a forcément des liens entres Votants/Votes/Choix/Sondages. Mais est-ce vraiment nécessaire de mettre beaucoup de nouvelle techno dans un projet qu'on souhaite voir aboutir ? Si on fait déjà une api pure Rest avec UI en HTML/JS. Je pense qu'on aura assez de nouvelle chose qui nous ferrons perdre du temps. Mais on peut toujours faire une petite réunion sur la persistance et une fois qu'on sait ce dont on a besoin voir celle qui nous permet de le mettre en oeuvre le plus facilement possible (le stockage ne sera pas un problème, mais la restitution pour le/les dépouillements doit-être le plus simple possible) ...
Part-on dans l'idée de rester iso-fonctionnel, ou peut-on envisager d'y aller par etape, genre commencer à créer des sondages simples (oui/non et un total pour chaque choix) ? puis ensuite rajouter la complexité (Condorcet, pondération...)
Je pense que le but est de même faire plus. Mais pas forcément en une seule étape. Il vaut mieux faire une base qui fonctionne et ajouter les autres choses après. Donc pendant quelques temps il y aura surement pollenOld et pollenNew en fonctionnement l'un a coté de l'autre. Pour ce qui est de dépouillement, peut-etre n'est-ce pas nécessaire, mais je verrais bien un module complètement indépendant de la persistance et de l'UI qui permette de faire le dépouillement. Ce module pourrait alors être réexploiter par d'autres pour du dépouillement, car il n'y a pas de librairie (il me semble) qui existe avec tout ce qui est déjà codé. Si je ne me trompe pas c'est déjà un peu le cas. Donc avoir un dépouillement ou N ne doit demander que d'écrire et faire un peu plus de tests (différence entre 1 et N) -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
On Tue, 9 Apr 2013 18:17:56 +0200 Benjamin POUSSIN <poussin@codelutin.com> wrote:
On Fri, 01 Mar 2013 15:14:57 +0100 Yannick Martel <martel@codelutin.com> wrote:
Salut ! ...
- persistence http://chorem.org/issues/885 (topia)
Je me demandais si la persistance NOSQL orientée document (MongoDB? Couchbase?) pourrait pas coller au modèle "vote" ? Je sais qu'on ne baigne pas dans ce paradigme, mais la souplesse et la "facilité" vu lors de conférence (JUG 2013 & Devoxx 2011), me laissent croire que ça peut coller...
Si on part dans le NoSQL, j'aurais peut-être dit plutôt une base orienté graph car il y a forcément des liens entres Votants/Votes/Choix/Sondages. Mais est-ce vraiment nécessaire de mettre beaucoup de nouvelle techno dans un projet qu'on souhaite voir aboutir ?
Si on fait déjà une api pure Rest avec UI en HTML/JS. Je pense qu'on aura assez de nouvelle chose qui nous ferrons perdre du temps. +1
Mais on peut toujours faire une petite réunion sur la persistance et une fois qu'on sait ce dont on a besoin voir celle qui nous permet de le mettre en oeuvre le plus facilement possible (le stockage ne sera pas un problème, mais la restitution pour le/les dépouillements doit-être le plus simple possible)
Je ne me souviens plus si je me suis déjà exprimé sur le sujet, mais je ne trouve vraiment aucun argument pour faire du NoSQL sur Pollen, c'est un peu comme si on venait me dire, pourquoi ne pas refaire Pollen en Python :(. donc +1 (pour ne rien changer) perso çe ne me parrait pas nécessaire, on a déjà pas beaucoup de temps à y consacrer, autant se focaliser sur les choses plus importante, à savoir les services et les ui. La seule chose importante pour moi c'est vraiment ça : service + UI.
...
Part-on dans l'idée de rester iso-fonctionnel, ou peut-on envisager d'y aller par etape, genre commencer à créer des sondages simples (oui/non et un total pour chaque choix) ? puis ensuite rajouter la complexité (Condorcet, pondération...)
Je pense que le but est de même faire plus. Mais pas forcément en une seule étape. Il vaut mieux faire une base qui fonctionne et ajouter les autres choses après.
Donc pendant quelques temps il y aura surement pollenOld et pollenNew en fonctionnement l'un a coté de l'autre.
Oui mais surtout il faudrait éviter de reproduire les erreurs du passé en repartant d'un existant qu'on modifie au fur et à mesure car on arrivera toujours aux limites des erreurs de conceptions originales, je pense ici vraiment au problème de la sécurité qui est la plus grosse limite actuelle pour continuer dans la même voie.
Pour ce qui est de dépouillement, peut-etre n'est-ce pas nécessaire, mais je verrais bien un module complètement indépendant de la persistance et de l'UI qui permette de faire le dépouillement. Ce module pourrait alors être réexploiter par d'autres pour du dépouillement, car il n'y a pas de librairie (il me semble) qui existe avec tout ce qui est déjà codé.
oui c'est déjà le cas, en quelque sorte, on a bien un module avec une API de dépouillement et chaque type de dépouillement a son module se basant sur cette API.
Si je ne me trompe pas c'est déjà un peu le cas. Donc avoir un dépouillement ou N ne doit demander que d'écrire et faire un peu plus de tests (différence entre 1 et N)
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
participants (4)
-
Benjamin POUSSIN -
Julien Ruchaud -
Tony Chemit -
Yannick Martel