TDDPirate’s Ideas

Background Information

The Israeli Ministry of Interior is planning to computerize the process of elections in Israel, using electronic voting machines. They are planning to start by running a pilot in ten settlements during the upcoming Nov. 27, 2007 council elections.
Sources:

• Computerized Elections: a year from now (in Hebrew)
• Forget paper ballots: switching to computerized voting (in Hebrew)

This is a Bad Idea

The following reasons are given for the move to computerized elections:

1. Reduction and even elimination of rigging votes and multiple voting.
2. Election results availability few minutes after end of elections.
3. Budgetary savings.
4. Ability to vote from anywhere without special procedures.

Unfortunately, the first three reasons are either untrue or are insufficient justification for switching to computerized elections.

1. The worldwide experience with election machines is that they are not secure, not well-designed, violate anonymity of votes, and facilitate rigging of votes even more than paper based ballots.
   Sources:
   • http://www.votersunite.org/ - a Web site promoting fair and accurate elections.
   • Myth Breakers - Facts About Electronic Elections
   • The globalization of electronic election theft
   • Electronic Elections in Belgium: auditing the Digivote sourcecode
2. Election results are not available if the voting machines develop technical problems, as they did in several elections in the world. A more fundamental point is that the integrity of the election process is worth the wait until the next morning. Confronted by the choice between rigged elections with speedy results and clean elections with results available only after 10 hours or so, every sane citizen would choose the second alternative without thinking twice.
3. Any budgetary savings from using election machines are wiped by bad policies adopted by corrupt politicians, who got elected to office thanks to corrupt elections process. This is one place where one could be penny wise and Pound foolish (or one million wise and ten billion foolish).
4. The fourth goal of computerized elections can be accomplished by alternative means - for example, by using computers only to verify that a voter did not already vote elsewhere. Paper ballots can still be used for the actual votes.

See also:

• electronic voting and Democracy
• Paper Makes a Comeback as Electronic Elections Spur Opposition
• Voting category in Freedom to Tinker blog
• More California E-Voting Reports Released; More Bad News

It is to be noted that the talkbacks to the news items about the Israeli Ministry of Interior plans demonstrate that Israelis are clueful about the dangers of electronic elections.

What Can be Done About This?

• Find which voting machines will be used in the pilot and publicize audit results and cracking tips available from other countries where they were already used.
• Refuse to vote in the voting machines during the pilot.
• In the pilot, the results from the electronic voting machines will not have official use, so it may not be unlawful to actually crack into them. DISCLAIMER: IANAL. CONSULT WITH YOUR LAWYER BEFORE DOING ANYTHING ABOUT THIS SUGGESTION.

DON’T MAKE ME THINK! - A Common Sense Approach to Web Usability, Second Edition
© 2006 Steve Krug
Author: Steve Krug
Pages: 201
Publisher: New Riders
ISBN: 0-321-34475-8
The book introduces the principles of Web usability, and explains how to overcome political obstacles to actual implementation of usable Web sites. Being an introduction, the book is rather superficial. However, it has several footnote references and a section devoted to Recommended reading, which would benefit people, who want to learn more about Web usability.

In practical world, Web site design and implementation is fraught with politics, due to the large number of stakeholders in a typical organization. The book covers the political aspects as well, even though its title does not reflect this fact.

The book is very readable, and is rich with colorful illustrations. To fully benefit from the book, the reader should have browsed Web sites and to have participated in a Web site building project.

The book was designed to be readable in a single flight. I actually finished reading it in less than four hours, excluding pauses. In my opinion, it meets very well the needs of beginning Webmasters, and of busy executives in charge of Web site design projects.

The book starts with an introduction, which explains why the book is thin, and what was left out of it and why. Chapters 1-5 cover the guiding principles, which can be summarized as follows.

Krug’s Laws of Usability:

1. Don’t make me think!
2. It doesn’t matter how many times I have to click, as long as each click is a mindless, unambigous choice.
3. Get rid of half the words on each page, then get rid of half of what’s left.

Principles:

• Create a clear visual hierarchy.
• Design pages for scanning, not reading.
• Conventions are your friends.
• Users like mindless choices.

Facts of life:

• We don’t read pages. We scan them.
• We don’t make optimal choices. We satisfice.
• We don’t figure out how things work. We muddle through.
• Steve Krug’s wife: “If something is hard to use, I just don’t use it as much.”
• People won’t use your Web site if they can’t find their way around it.

Chapter 6 treats the subject of Web site navigation, covering search, breadcrumbs and tabs. It also introduces the “trunk test”.

Home pages have their special technical and political issues, so chapter 7 discusses home pages. An home page needs to answer the following questions:

1. What is this?
2. What do they have here?
3. What can I do here?
4. Why should I be here - and not somewhere else?
5. Where do I start?

The conscientious Web designer will find in chapter 7 also a list of the top five plausible excuses for not spelling out the big picture on the home page, along with arguments, which refute those excuses.

The next two chapters, chapters 8-9, deal with the politics of designing for usability and present usability testing as a way to reduce the impact of “religious arguments”. Chapter 9 provides also a list of the top five plausible excuses for not testing Web sites, along with their refutations.

Chapter 10 deals with the benefits to an organization from improved usability of its Web site. Chapter 11 covers accessibility. Chapter 12 deals with the politics of bad design decisions and how to overcome them.

The following points pertaining to politics are covered by the above chapters:

1. Home page design is fraught with politics, because there are several stakeholders.
2. Usability testing is presented as antidote to religious arguments in the Web design team.
3. People are afraid that better accessibility degrades the experience of non-disabled users.
4. Bosses want to ask too much personal data.
5. Bosses want to add “sizzle” to the Web site.

The author’s Web site is at http://www.sensible.com/.
The first edition of the book had three chapters about usability testing, which were condensed into a single chapter in the second edition. The original text of those chapters can be found in http://www.sensible.com/secondedition/.

The book was reviewed also in Amazon Web site: http://www.amazon.com/Dont-Make-Me-Think-Usability/dp/0789723107

The following are reviews of the first edition of the book:

• http://informationr.net/ir/reviews/revs032.html - reviews the first edition of the book along with some other books.
• http://www.mathguide.com/services/Design/Laws.html

The following is an interview with the book author: Meet the MasterMinds: Common Sense Web Design with Steve Krug.

When you maintain a Web site, it is a good practice to hold in your PC a mirror of the Web site’s contents. When you want to modify the contents, you edit the files in your PC and then synchronize the Web site’s contents with the copy in your PC.

To actually synchronize the files, you have several possibilities:

• Individually FTP modified files to the Web site. Manually delete from the Web site files, which you deleted in your PC.
• Create a tar ball of the modified files, FTP it to the Web site, and then untar them remotely. Then manually delete any files which you deleted in your PC. You need also to make sure you missed no modified file in the tarball.
• If the Web hosting services provides a rsync server, you can use rsync to synchronize.
• If you can set up a rsync server on your PC, you can invoke rsync on the remote Web host, if you have shell access to it. In this case, you need also to poke a hole in your PC’s firewall.
• Use the sitecopy command, the topic of this blog post.
• There are also other commands with substantially the same functionality as sitecopy.

Homepage for the sitecopy project: http://www.lyra.org/sitecopy/
Should I use sitecopy? http://www.lyra.org/sitecopy/why.html
Freshmeat project information: http://freshmeat.net/projects/sitecopy/

To use sitecopy under Linux, you need to create the file .sitecopyrc in your home directory. The following works for me (replace words with ‘you’ by names relevant to your situation):

site yoursitename
  server yourwebdomain.com
  username yourremoteusername
  # password ________________ # sitecopy will prompt you for your password
  local /home/yourlocalusername/websites/yourwebsite  # Your Web site's mirror
  remote /        # FTP home directory for your Web site
  ftp usecwd      # FTP will upload files only to the current working directory
  permissions all # Set permissions of files after uploading
  permissions dir # Set permissions of directories after uploading
  safe   # Block uploading of files, which were updated on the Web host.
  exclude *~  # Exclude backup versions of files modified by you
  exclude /.bash* # Do not delete dot bash files in the Web host.
  exclude /.svn   # or /CVS if you use CVS rather than subversion.
  exclude /*/.svn
  exclude /*/*/.svn
  exclude /*/*/*/.svn
  exclude /*/*/*/*/.svn
  exclude /*/*/*/*/*/.svn
  exclude /*/*/*/*/*/*/.svn
  exclude /*/*/*/*/*/*/*/.svn
  exclude /*/*/*/*/*/*/*/*/.svn
  exclude /*/*/*/*/*/*/*/*/*/.svn
  exclude /*/*/*/*/*/*/*/*/*/*/.svn
  exclude /*/*/*/*/*/*/*/*/*/*/*/.svn
  exclude /*/*/*/*/*/*/*/*/*/*/*/*/.svn
  exclude /*/*/*/*/*/*/*/*/*/*/*/*/*/.svn
  exclude /*/*/*/*/*/*/*/*/*/*/*/*/*/*/.svn
  exclude /*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/.svn

(The above illustrates also a problem which I had in systematically excluding directories by name.)

To actually run sitecopy, create a shell script file with the following command:

sitecopy -u --debug=ftp,files,socket --logfile=/home/yourlocalusername/sitecopy.log yoursitename

The logfile will be few MB long for a Web site with few hundreds of files, but if you encounter any problems, the logfile will help you diagnose the problems.

I found that sometimes I need to run

sitecopy --catchup yoursitename

before uploading some files, because the safe option seems to be overzealous at times.

It was publicized that Microsoft sold 40 million licenses of its Windows Vista OS. The question is if this is for real or not?

For real:

• Microsoft’s revenues during Q1 2007 were reported to be much higher than in previous quarters.

But more than 10% of those revenues are deferred income from the Software Assurance program, which is being recognized now.

Reasons to doubt whether those numbers mean much:

• The already publicized reason - it is not known whether those licenses represent PCs and laptops already sold to the public, or still in warehouses.
• How many developers received licenses as part of their MSDN subscriptions?
• How many licenses were disbursed at no extra cost to those, who paid for Software Assurance during the last few years?

And I still do not mention the question how many people tried Windows Vista and then switched back to Windows XP. In those cases, Microsoft already got the money for the Vista license, and the customer got several more gigabytes, with which to fill his bookshelf.

I am subscribed to the GPLv3 Information mailing list. About two weeks ago, the new draft of GPLv3 was announced. I reviewed it and had four comments.

I tried to submit the comments via the provided E-mail address. The system requires you to associate your comment with a fragment from the GPLv3 draft. I associated my comments with fragments as requested.

All four E-mail messages bounced back to me - the fragments were not found in the draft.

I sent a bug report (gnu.org #333022). I was told that I found a bug in the comments handling system, and that now the bug has been fixed. I was asked to resubmit my comments. I resubmitted all four comments.

I got messages about delayed local delivery of my E-mail messages, but no confirmations of receipt of my comments arrived.

Another bug report was sent (gnu.org #333429). Again, apology for the problem with the E-mail system. The problem was fixed, and I was asked to resubmit my comments, which I did today.

This time, confirmation messages arrived after less than 5 minutes (Comment #2930, Comment #2931, Comment #2932, Comment #2933). The status of the above comments can be tracked by surfing to the appropriate link. For example, Comment #2930 can be tracked by browsing http://gplv3.fsf.org/comments/rt/readsay.html?id=2930.

I feel proud of myself. Not only did I make some comments, but I also cleared the way for other people to contribute to this very important review of the GPLv3.

Basically, this is a true story. However, some of the details were made different from what happened in reality.

Once upon a time, in a nonprofit organization, which will remain nameless, a volunteer sysadmin set up a PC to serve as the nonprofit’s public server, serving few Web sites, managing mailing lists and some other services.

The guy was clever and configured the OS (Linux) on the PC in a nonstandard but highly secure way.

Few years later, other volunteers took over the PC. They preferred not to bother to learn how the system is configured and how to administer it. They preferred instead to reconfigure the PC to a more conventional and familiar configuration.

End of story.

The arguments, which erupted due to the above preference, led me to ponder the general question: when and why do software professionals prefer to reinvent the wheel?

On one hand, operating systems and computer languages are not, as a rule, reinvented all the time. Most people are content to learn an existing environment, become expert in it and stick to it. Only very few venture forth and write a new OS or a development framework for a new programming language.

On the other hand, when confronted by legacy software or existing installation, several people prefer to discard any existing work and start from afresh.

What differentiates among those two extremes? I tried to build a list of the relevant variables:

1. How well is the framework designed for extensibility or for building upon it?
2. Quality and thoroughness of documentation - especially instructions how to make changes to the system.
3. Amount of wisdom invested in the basic system design, which is worthy of learning due to its own sake.

In the case of the above story, the first two variables seem to explain the reluctance of the other volunteers to use the first volunteer’s system.

It is well known that it is impossible to use currently available tools to test for ability to program computers.

In their paper The camel has two humps (working title), Dehnadi and Bornat claim to finally have a test, which can predict one’s ability to program. Basically, their test assesses the candidate’s ability to manipulate symbols according to rules without looking for a meaning in those symbols.

A note to self:
According to the above paper, the following are the major semantic hurdles, which trip up novice imperative programmers:

1. Assignment and sequence.
2. Recursion/Iteration.
3. Concurrency.

Novice declarative programmers have to leap the following semantic hurdle:

• Argument substitution.

In addition to the above semantic hurdles, I know of one additional major semantic hurdle:

• The concept of a pointer.

I wonder whether there are additional semantic hurdles, listed in some obscure (or not so obscure) paper published somewhere in the world - or even unrecognized so far.

This creates a problem when one wants to discuss the state of worshipping in the context of Perl.
bless is a reserved word in Perl, and it has a specific technical meaning.

Roget’s Thesaurus came to my rescue. It offered me three alternative words: hallow, consecrate, sanctify.

Now we can start hallowing whatever is holy and sacred in the magnificent language Perl.

You haven’t made an impact on the world before you caused a Debian release to be named after Snufkin.

My Days as a Barber

If your boss or client insists upon using the MS-Windows XP platform for running the application, show them the above article.