Tag - demexp

Entries feed - Comments feed

Last entries

Tue 14 May 2013

High-level requirements for re-demexp

I recently spoke about the three main points to work on if one would start some re-engineering work on demexp. The first point was to start from some High-Level requirements. I have started to write those High-Level requirements. Let me know if you have comments or questions, either directly at dmentre@linux-france.org or through this post's comments.

Sat 04 May 2013

Re-engineering demexp

demexpA long long time ago, I worked on demexp, a specific software made to support the Democratic Experience, a direct democracy initiative. demexp is programmed in OCaml language. The software contains both a server and a client. The client user interface is programmed with Gtk+. I also tried to make a web interface, without much success. The whole software is made in literate programming style. After several years of development, I was bored and stopped working on it. The software project never had a lot of momentum. The Democratic Experience political project is still alive, without much activity as far as I know.

After those years, one (at least me ;-) ) could wonder what failed in the project and how it could be improved, from a software engineering point of view. I see three main points to work on if one wanted to re-engineer demexp.

1. Start from a well-defined high-level specification. When we started demexp, we did not know exactly what kind of software we wanted. We discovered a new territory. Nowadays, I think we could have a much clearer picture of the requirements. As for any software, starting from clear requirements is mandatory. :-) So we should start from a set of high-level requirements, from which derive some low-level requirements for the software.

2. Design a modular architecture. I made demexp as a big monolithic software. The server part contained the network interface, the question and response database, the security model, the delegation system, etc. The client was containing a User Interface as well as code to authenticate the user and access the server. I now think I should have started from a much modular architecture, with several small programs, each one of them focused on a part of the system. Having several programs would force me to have clear interfaces between them, thus imposing a cleaner architecture. And if the task of developing all those programs is too big, at least I could focus on a sub-part of them to have a system with less functionalities, but at least working.

3. Use formal methods to verify some properties. Using formal method is not strictly required, but, well, it interests me :-) and I think formal methods could bring benefits to such a software. For example to prove that some properties of the system, e.g. the security model is correctly designed and implemented.

Moreover, I see some additional points to review in the original demexp design:

  1. Drop the literate programming approach. It is too costly to maintain (it is heart-braking to remove some code, but its even more difficult to remove some documentation). Some well defined documentation for the tricky parts or the global overview of the system would be enough I think.
  2. Traceability. From high-level specification to low-level one, down to code and its tests or proofs. As for safety critical software, maintaining traceability would bring a cleaner view of the system and it would help code reviews (one can dream! ;-) ) and show the software meets its goals.
  3. Focus on smaller goals. The overall objectives of demexp were very ambitious and thus difficult to reach. One should probably start from less ambitious goals, but try to make useful software in small steps.

Regarding the use of OCaml language, is was probably part of the raison why we never gain much contributions. But OCaml is so nice to use! I would probably keep that part... or not. I currently some other interesting and somewhat confidential languages to look at. :)

Sat 11 Sep 2010

Literate programming: where we are and where we should aim at

Book and paper (CC-BY) Literate programming is an old idea: Donald Knuth invented it during the 70' to write TeX, the typesetting system.[1] The main idea of literate programming is to document a computer program while writing it by intertwining pieces of code and explanation. In other words, instead of writing a program, one writes a book that documents and contains the program. Then, two programs are used to extract the (i) the compilable code and (ii) the book ready to be printed.

The main philosophy behind literate programming is that:

  • One should document his/her program;
  • By putting program documentation very close to program text, we improve significantly the ability to update the documentation when the program is changed.

Where we are

Several literate programming systems now exist. Most of them are grand-child of the original Knuth's WEB system. They can be either generic, like noweb, or specifically tailored to a programming language like OCamlWeb for OCaml. The main idea of those tools is to write a LaTeX document and put pieces of code in it. For example, I have used noweb to write demexp, a special voting system for massive direct democracy. The OCaml code of demexp can be read like a book.

The main issue with those tools is that you need to write a LaTeX document. You cannot use your preferred (or mandatory) IDE to edit the code and it is rather cumbersome to use in a Windows environment.

That's why we have developed Lp4all. LP4all is a literate programming system where documentation is put within the language comments, using a special syntax close to a Wiki one. From those special comments one can generate web pages, like those for Lp4all itself.

However I'm not using Lp4all!

I'm not using it because, in my last document at work, I needed all the power of LaTeX:

  • Advance LaTeX packages to make special figures, add hyperlinks to the generated PDF document, ...
  • Use LaTeX ability to create special counters for dedicated cross-references;
  • Ability to pretty-print a relatively confidential programming language;
  • etc.

So, on one side, I need the flexibility of Lp4all, its ability to integrate within any IDE or development environment. On the other side, I need a complex documentation system, giving to me all the tools to fine tune my documents and produce quality documents. Moreover, Lp4all is limited to a single program while I need to generate various documents from a single source.

Where we should aim at

(or at least some ideas about it ;-)

One simple solution to above dilemma would be simply to add LaTeX capabilities within Lp4all. Some tools like ocamldoc (the OCaml equivalent to JavaDoc) is following this approach, with extensions to mark parts using the LaTeX syntax. This probably the most practical approach. After all, Wikipedia is using the LaTeX syntax for mathematical formula.

However I find that this approach is not satisfying.

First of all, LaTeX is a very weak system (a package can break another package) and is very complex to use when you want to extend the system. It would be much simpler if we could have a documentation system build upon a sane language.

Moreover, to really exploit the full potential of literate programming, one needs to produce and track dependencies between several documents. For example, if I modify the specification, I need to modify some parts of the code. Inversely, if I change my code I need to know which part of the "specification" have to be updated. This tracking between pieces of code/documentation goes to test, user documentation, code documentation, test review, Q&A documents, GUI design, mathematical scripts describing an algorithm, formal models to check the software, etc. And more importantly, if I modify a piece of this code/documentation, I need a list of all document parts I need to review and possibly update, a kind of make on steroids.

A third point is that one needs more graphical interfaces: it would be easier to graphically link a piece of code to a document paragraph describing it than create a LaTeX reference and reference it later in the document. Moreover, documents nowadays use graphics extensively and we need to link pieces of code/documentation and some graphics. For example, it would be interesting to link the drawing of an automaton with the set of functions in a code implementing this automaton. And when navigating through the software, it is crucial to be able to go from a given automaton state in the graphics to the code implementing it and vice versa.

And of course, one needs a system agnostic documentation software, running on many platforms and working with all possible kind of IDE and languages.

Overall, one needs an integrated documentation system that is able to encompass all the kind of artefacts that make a software and that can be used to maintain those artefacts along the whole life of the software, from design to maintenance. And this system should be flexible enough to not constrain you to a fixed development environment, letting you chose the tools that you prefer.

An interesting proposal in that regard is Scribble, a system for writing library documentation, users guides and tutorials. Scribble allows to write LaTeX like documents, JavaDoc like documents to document libraries or WEB-like literate programming documents. However Scribble is tightly linked to the Scheme language and thus lacks the important platform independence feature.

As you see, my proposed ideas are rather general and I am very far from being able to specify the documentation software I would like to have. I know for sure that the current documentation systems are not satisfying and I hope somebody will propose one day a better system, matching the needs we have to build better software. I would prefer not to have to implement it by myself. ;-)

Notes

[1] Knuth's literate programming system was called WEB, long before the Web was invented. :-)

Thu 01 Apr 2010

Pourquoi je quitte l'expérience démocratique

demexp On m'a récemment contacté à propos de l'expérience démocratique. J'avais déjà annoncé que je quittais le projet mais j'ai fini par élaborer une réponse plus précise. Il me semble intéressant de la rendre publique, non pas pour étaler mes états d'âmes mais comme une réflexion a posteriori sur un engagement et sur un projet de logiciel Libre qui n'a pas marché (et accessoirement pour l'« histoire » du projet ;-).

Si on retourne en 2003, je venais surtout pour l'aspect informatique du projet. Faire un logiciel de débat et de vote électronique original, c'était intéressant et très motivant. Mais après plusieurs années de développement je n'ai toujours pas un logiciel utilisable et je me suis retrouvé tout seul à le faire (ou quasiment). La lassitude a fait le reste du travail. ;-)

Par ailleurs, certains choix technologiques ont limité le développement du projet (client lourd en Gtk+, pas d'interface web), même si cela était dû à des contraintes quand j'ai commencé (Ocsigen n'existait pas à l'époque). Pour d'autres choix comme utiliser le langage OCaml, ça a très certainement limité l'arrivée de nouveaux développeurs. Mais je n'en aurais pas fait autant dans des langages plus classiques comme PHP ou Python. D'ailleurs d'autres ont proposé des morceaux de logiciel, en repartant de zéro comme Jean-Marc Fauché ou Lyu Abe. Mais ces propositions ne m'ont jamais emballé.

Plus sur le fond, je m'interroge pas mal sur le sens du projet. La démocratie ne se limite pas au vote, le débat et la formation des citoyens sont tout aussi important. Après quelques années, j'ai eu l'impression qu'on se concentrait uniquement sur l'aspect vote et pas assez sur les autres aspects. Pour le dire autrement, c'était peut-être plus important de faire un serveur de listes de diffusion, un service web pour synthétiser les débats et puis finalement voter en Condorcet avec du papier et du crayon que de faire un logiciel de vote électronique. On avait dit qu'on ferait des « soirées Condorcet » dans un bar, pour mettre en œuvre de manière concrète et ludique les idées du projet : cela ne s'est jamais fait.

Pour le logiciel, je suis parti sans réellement de spécifications, quasiment par le codage. Ce n'est pas comme ça que l'on fait un bon logiciel. ;-) Évidemment, quand on a démarré, on ne savait pas trop où on allait. Maintenant je pense que j'aurais des idées plus claires.

Informatiquement parlant, l'amplitude du projet est très vaste. Cela va des bases de données aux interfaces graphiques en passant par la cryptographie ou le réseau. C'est très stimulant sur le plan intellectuel, on apprend pleins de choses mais on n'est pas forcément bon partout.

Sur un plan plus pratique et citoyen, le vote électronique est très polémique (voir par exemple ordinateurs-de-vote.org). Je suis moi même contre les machines de votes actuelles[1] ! Il est quasiment impossible de faire un logiciel de vote aussi transparent qu'une urne en plexiglas. La recherche dans le domaine des protocoles de vote avance mais il faudra encore probablement de nombreuses années avant d'avoir quelque chose d'utilisable. Et ce sera très vraisemblablement plus compliqué qu'un bulletin dans une urne.

Sur le plan plus humain, on a démarré à quatre sur le projet, puis à trois au cœur. J'ai trouvé sur le long terme que j'étais un peu seul à faire la gestion de tâches informatiques (mise à jour du serveur, répondre sur les listes, le développement, etc.), malgré le soutien de mes deux compères. Ils ont beau être les pères de l'idée, j'ai trouvé que leur implication n'y était plus.

Enfin et surtout, après plusieurs années, j'ai envie de m'attaquer à d'autres défis, dans des domaines totalement différent et cela ne se fera pas sans dégager du temps libre. J'ai donc arrếté mon implication dans des projets non « productifs ».

Voilà, c'est probablement trop long et un peu confus, mais c'est dur de résumer plusieurs années de projet en quelques mots.

Je considère toujours que la thématique du projet, la réflexion sur la démocratie et le rôle du politique, est cruciale. Peut-être juste que l'angle n'était pas le bon, je ne sais pas. Apparemment, d'autres on des idées similaires et très intéressantes.

Et l'expérience a été pour moi enrichissante. Je ne regrette rien ! :-)

Notes

[1] Vous avez dit schizophrène ? ;-)

Mon 13 Jul 2009

Mini news : micro-blogging et demexp

En premier lieu, désolé pour le manque de billets la semaine dernière, mais il est parfois nécessaire de faire une pause de temps en temps.

Première mini-news : micro-blogging

Logo Identi.ca J'ai cédé aux appels de Jean-Philippe, Thomas ou Fabien sur le micro-blogging en finissant par ouvrir un compte sur le service de micro-blogging libre identi.ca. Mon identifiant (très original) : dmentre. Pourquoi choisir identi.ca plutôt que Twitter ? Parce que identi.ca fonctionne sur une plate-forme libre avec le logiciel Laconica et que les billets sont publiés sous une licence libre (CC-BY-SA 3.0). Bon, à mon avis, c'est encore une source de perte de temps sans réel utilité, mais j'affirme de plus en plus mon côté geek. :-)

Deuxième mini-news : demexp et les RMLL

RMLL 2009 J'ai fait un saut au 10e Rencontres Mondiales du Logiciel Libre (les reumeuleuleu pour les intimes) à Nantes cette année et malgré le peu de temps que j'ai pu y passer, Fred a trouvé le moyen de me faire participer à un débat radiophonique sur le vote électronique. Et pourtant, ce n'est pas faute de dire que demexp m'intéresse de moins en moins ! :-) Si vous avez 50 minutes à perdre, n'hésitez pas à me donner votre avis. J'ai l'impression qu'on est super confus au début (forcément, aucune préparation !) mais qu'après ça s'arrange un peu. Enfin j'espère. ;-) Pour ceux qui suivent les aventures du vote électronique, pas grande originalité dans les propos. Sinon, les RMLL, c'est super sympa pour voir les potes exilés aux quatre coins de l'hexagone. :)

Le logiciel de vote epoll pour les élections au CNRS réalisé par le troisième intervenant, Olivier Thauvin (alias nanardon), est lui aussi disponible. Il a des spécifications plus classiques (par rapport à demexp ;-) mais il y a apparemment un gros effort pour garantir les bonnes propriétés du vote en respectant notamment les recommandations de la CNIL. Les présentations d'Olivier donnent une description plus complète d'epoll.

Troisième mini-news : nouvelle version du demexp de Jean-Marc Fauché

Jean-Marc a publié il y a plus de deux semaines une nouvelle version de son demexp développé en Python avec web2py. Elle est enfin accessible en ligne à l'URL http://bentobako.org:8000/Demexp. Cette version apporte un système de délégation d'un vote.