More questions and testing : Was: Trying to avoid digging through the archives

From: Karl Auerbach <karl_at_cavebear_dot_com>
Date: Sun Nov 30 2003 - 19:20:54 CST

On Sun, 30 Nov 2003, Alan Dechert wrote:

> Karl (digging through archives).

> > Can anyone point me to the description of how the choices are encoded into
> > "the big number" (36 digits?) that is made visible via the bar-code?

> Each button represents a digit in a 116-digit string of 0s and 1s, "0" for
> not selected an "1" for selected.

Thanks for the pointers.

Some points/questions occurred to me:

1. Is this 116-bit number only for this hypothetical election or is it a
built-in constant to the architecture of the whole system? If the former,
how does it generalize and is there anything in the bit pattern itself
that binds it to a particular set of contests?

2. We probably ought to be fairly precise in our terminology. For example
it was derailed for a moment when you used the word "digit" to refer to a
0/1 valued object. The reason that I think that terminology is important
is that eventually this software, or rather its descendants, will have to
pass under the watchful eye of some sort of certifying authority. We
ought to endevour to make the job of certifying code as painless as
possible by trying to go out of our way to be clear.

3. Which raises the issue of testing - I've started to look through the
code (mainly the Python code). It seems to me that we ought to adopt a
coding style in which there are lots of small functions will very
precisely defined jobs (e.g. generating the checksum, obscuring the
number, etc, generating barcode parameters apart from inserting them into
postscript, etc.) Much of this is already the case. But I would
encourage it to even a greater degree.

[I'd also encourage a greater use of parameters or per-class or
per-class-instance variables rather than global variables.] [And, if we
use Python's class mechanism, we ought to subclass from "object" rather
than create our own top level objects. We don't want to create too many
opportunitys for accidential and unintended side effects through global

The reason that I suggest small routines and avoidence of globals is that
with small routines we can make use of some of Python's unit testing
facilities to test each function in isolation. I have not used these
facilities much yet myself. However, one of our hurdles is to overcome
the FUD of poor quality that various companies are thowing at open source.

By-the-way, it appears that Python is slowly moving in the direction of
having only large integers instead of the current two-kind-of-integer
mechanism. This tripped me up when I first used Python 2.3 in some of my
own code - it gave me several "future" warnings about the fate of the
high-order bit on small integers when the Python world becomes big-int

4. We might want to consider using the GNU gettext API for python. This
allows for relatively easy localization. Again, this is something that I
have not used myself yet. But it looks pretty easy to use, at least in
the Python case.

By-the-way for the touch-screen part of the demo, what specific mechanisms
are going to be used to do the touch-screen stuff? (I saw that there is
some support for touch-screen in X, but I'm not familiar with it. In
addition, I've become a fan of wxPython/wxWindows but I'm not aware of how
it can deal with touch-screens.)


= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Sun Nov 30 23:17:12 2003

This archive was generated by hypermail 2.1.8 : Sun Nov 30 2003 - 23:17:13 CST