Skip to content
voting engine using ADA authentication and condorcet method
Java XSLT Python Shell Makefile Dockerfile
Branch: develop
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.

Universal preferential voting control server features:

  • Condorcet - Shulze method support
  • ballot managment
  • ADA login support (optional)
  • liquid democracy support
  • voks acredited support
  • voks weight support
  • secure system
  • flexibility confuguration

This is the voting engine core.

You can find it in the big picture of things here:

The design documentation is here:

For developers

!!! even the unit tests use hardware random generator (/dev/random). install the haveged package, otherwise tests will take ages!!!

Quality metrics gathered by sonar:

The issues we plan to do in the actual week are moved to "in this sprint", and ordered according to priority.

The ones we are working on are in "Working". Those should have the one working with it assigned.

If you are ready with the issue, move it to "Review". Issue the pull request to edemo/develop. You can ask for a reviewer. Have the issue # in the merge title/a commit title, so merging will move the issue to done.

In the sprint demo we

  • look at each issue in done and review, and archive those which are okay in the test system.

  • move around other issues randomly :)

When you code, please keep these in mind:

  • You are expected to implement the specification. No more, no less. You are not expected to be a telepath.

    • If a detail is not defined in the model, then feel free to make the decision e.g. we said you have to check the string for length, but did not specify minimum and maximum length.
    • If in doubt, feel free to ask. And feel free to discard suggestions. The only thing matters is the specification. Well, sometimes the specification WILL be wrong. The architect is also human. More or less.
    • Yes, you are actually helping the team by not trying to read minds. This way the architect will have faster and more direct feedback on the quality of his work. You help him to improve, and save a lot of time for your older self and teammates.
  • If coding to the specification breaks other tests, then amend them with possible renaming or delete them.

    • if the other test tests something unrelated (e.g. you implement validation, and the other test breaks the validation rules in the setup part), then the best way is to fix the setup.
    • if it is the same functionality than your test (e.g. the specification has actually changed, or the architect was sloppy and have given conflicting rules), then modify the assertions or delete the the test. At your discretion. The related rule of thumb: a test is useful if it enhances the test coverage. In some cases testing the exact same thing in the code tests totally unrelated aspects of the specification. Remember: test case names are sentences of the documentation. If none of the above stands, the test is just hindering us. If only the second stands, sometimes it is still better to delete the test.
    • the name of the test should reflect what the test actually tests. at all times. so if that is changed, then change the name
  • Make sure that you test the specification (if it is possible), and not some implementation detail of it. One of the most common problems with tests is that they pin down some implementation detail, and when that is changed, a lot of tests should be rewritten.

  • Keep tests as clean as production code. For example in the case above, it is much easier to rewrite one method setting up or asserting something for 42 tests than rewrite 42 tests individually.

If you use Eclipse, you need the following installed: m2e-wtp - JAX-RS configurator for WTP m2e-wtp - Maven integration for WTP

You can’t perform that action at this time.