Monday, October 09, 2006

Open and closed Source voting

In several countries voices are raised against the use of voting computers. The latest objection was raised by the CCC in germany. According to security analysis, voting machines are insecure, and allow for untracable manipulation of voting results and voter privacy. The software can be exchanged and votes could be manipulated without any traces. The systems used for voting in Germany are very similar to those in the Nederlands. Similar objects were raised before in this country. Andy Müller Maguhn wrote:
Die Bauartzulassung der Nedap-Wahlcomputer ist nach den nunmehr vorliegenden Forschungsresultaten hinfällig. Das Bundesinnenministerium muss daher die Zulassung entsprechend § 3 Absatz 3 der Bundeswahlgeräteverordnung widerrufen
It does not surprise that similar story are percepted in the USA, where some rumour around the company "Diebold Election Systems" raised, after a group of college students found some memos about the poor security of the system from developers of this company, which somehow sliped onto a public area of the companies website.

After the companies lawyers tried with the help of the "Digital Millennium Copyright Act" to force the university to remove these memos from the servers(yes they are copyrighted material...) the sutdents had to use peer to peer file shareing software to keep the memos online.
The NY Times wrote in an article:
The files circulating online include thousands of e-mail messages and memorandums dating to March 2003 from January 1999 that include discussions of bugs in Diebold‚s software and warnings that its computer network are poorly protected against hackers. Diebold has sold more than 33,000 machines, many of which have been used in elections.

Now a debate araised around the question wheter voting software should be open source or closed source, to assure maximum demoncracy. While I think that one should also keep in mind that the main problem of demoncracy is missing participation, I am convinced that an open source solution is the only appropriate way to ensure a secure voting process.
Clive Thompson wrote:

So now you're caught up. The reason I give this bloated preamble is to point to the real solution: Open-source software.

As the Diebold scandal illustrates, it's incredibly dangerous to let a private company develop proprietary voting software. If they "own" the code, they'll keep it a secret. That means we'll have to trust them that the software is secure. If they're lying to us -- or, more likely, if they're well-intentioned but just unable to realize how buggy their code is -- democracy is screwed.

Open source software could be manipulated by enemies of demoncracy, but that, at least would show up immediately, and it is an advantage of open source software, that the participants are not bound by any contracts or employers, and may talk freely about the problems of the software without the vendors commercially motived blur.

I therefore disagree with Barry Briggs, who answers to Clive Thompson:

I don't think it's perfect at all. Open-source rests on several cornerstones including programmer anonymity and zero accountability. What if we were to find out that a key contributor to our voting machine software was a member of Al-Qaeda?

In fact, the last people I'd trust to verify the correctness and trustworthiness of something as critical as voting machine software would be a loose group of international programmers who could care less about the integrity of our republic.

And who will be eager to write such software? Of course not the enemies of demoncracy, but those who realize the very value and importance of free elections. And it is really motivating to be part of the team that wrote the software, that drives a vital part of the election process.


Friday, October 06, 2006

Real Programmers :-)

Real Programmers Don't Use Pascal!


Java Locking

Here are some nice Articles about Double checked locking, the singleton pattern
and the friendly comepetition between people doing VM level locking (aka Synchronized) and Java locking (1.5 Reentrant locks)

Thursday, October 05, 2006


I like MDD, SCRUM and extreme Programming, so AMDD just seems so natural.

Monday, October 02, 2006

AntiPattern: AbstractionInversion

After trying to understand the AbstractionInversion antipattern, I wonder if this pattern is really a unique pattern and not actually more like a combination of other, more abstract AntiPatterns.

Is AbstractionInversion a special case of code duplication, where a dependend class not only duplicates effort, but also escapes its level in a stack of abstracness layers inside an application?

It seems to be common to most examples I have read so far, that AbstractionInversion occurs in conjunction with code/concept duplication in two dependent modules with diffrent levels of abstraction. To explain my thought I will rely on the ADA RendezVous example mentioned here.

If i.e. a mutex is implemented by using the RendezVous concept, a mutex concept is actually implemented by using something at least as complex as a mutex, and code is likely duplicated.
Furthermore the one-class-one responsibility rule seems violated in the above example, as the abstraction to the gory details of the model relate to the concepts used in order implement the level of abstraction used by a dependend class, that itselfs tries to escape its level of abstraction by using concepts with a much lower level of abstractness that would actually be appropriate for the position of the dependent class in the hierachy of abstractions.

Does AOP solve the problem?

Another observation in the ADA example is, that abstraction invsersion stems from some backdraws of object oriented desing, wich lacks efficient and clear modeling of cross cutting concerns(like Mutexes), and therefore confuses unexperienced developers, by creating the temptation to include certain aspects into strict hierachies of abstractions, aka class hierachies, even if this is not required by the application domain, but merely by technical issues.

Sunday, October 01, 2006

New Emoticons

Every owner of a german keyboard, will know these already, but might not have noticed them as first class emoticons painted so obviously on the keys ...




Sunday, September 24, 2006

Monday, September 18, 2006

The purpose of the MOCK

In response to a much nicer blog entry, that can be found here.

There are actually several distinct "tests" that make up usual unit tests, among them two that really do stand out:
  • one kind of testing to test method flows,
  • one to test some sort of computation.

Mock objects are for the purpose of testing method flows. A method flow is a series of message transmissions to dependent objects.

The control flow logic inside the method(the ifs and whiles) will alter the flow
  • in repsonse to the parameters of the method call parameters passed by calling the method under test,
  • depending on the state of the object that contains the method under test and
  • the return values of the external method calls(aka responses to the messages sent).
There should be one test method for every branch of an if statement, and usuale some sort of mock control objects in the mock framework will handle loop checking.

BTW: I partly use message transmission instead of method invocation to include other kinds of "not really method invocations" like "exceptions".

The author of the afore mentioned post is quite right with his observation, that his test resembles the method under test quite closely, except, of course, for the control flow code(loops, conditionals). And that is absolutely desired, as he is testing mainly the "method flow" - there is not much computation necessary in JDBC code like this anyway.

It is tempting to raise the objection that a change in the order of messages sent to another object inside the method under test will result in a failing test, but it is easy to perceive the fact that the order of messages send to ONE object SHOULD be relevant. If it is not, well then there is no point in changing the method under test, isn't there?

Even if the method under test send variuos messages to various distinct objects, the order will be relevant at some level of abstraction. Therefore mock-checking of the order of method invocations can be(and must be) adjusted, at least if multiple distinct objects are addressed by the method under test.

And nothing else is it, that the author proposes, although, a little more complicated, than necessary when using easymock, for what I know.

Friday, September 15, 2006

Free Programming Books

I stumbled over some not so common class of free programming books:

Although these books are not the most recent spiffy Ajax/Java books, the are worth reading:

  1. A nice book about Mozilla programming
  2. Some Free Smalltalk books(yes smalltalk ain't dead yet)

Thursday, September 14, 2006

Maven Changelog plugin

I tried to use the maven changelog plugin, as described here
but maven complained that it could not find the plugin!

That was due to the fact this plugin is not yet stable, this wasnt mentioned anywhere I looked.

To enable the plugin you must first add the apache maven snapshot repository, read this site to find out how.

Wednesday, September 13, 2006


I just realized some nice Articles in the English and German wikipedia about anti patterns. I was well aware of the existence of software engineering related anti patterns, but I read about two other categories of anti patterns, well explained in the afore mentioned articles:
  • organizational&project management anti-patterns
  • and Meta-(anti)-Patterns

I found it both enlightening and shocking to learn about these patterns. Nevertheless the most funniest were IMHO:
  1. Programmer Experience Clumping
  2. Fear of success
  3. Management by numbers
  4. Single head of knowledge


Tuesday, September 12, 2006

Maven Source-Formatting/-Metrics

I needed to add source code formatting and some code metrics to my maven based project. These are the places on the web where I found help.

I wanted to get the Jalopy plugin to format my source code, and promptly failed to get the snaptshots from the mojo projects without the help of this resource,
this resources helped me to get the codehaus mojo snapshot plugins:
What to put in settings.xml

after that I could simply run:

mvn -Pcodehaus jalopy:format

As I was bothered by the command line cluttering by -Pcodehaus, I actived the profile by adding <activeByDefault/> into the activation tag in the profile definiton for the "codehaus" profile.
Now ....

mvn jalopy:format

... and voila! Jalopy formatted my sources.

See also: maven Jalopy plugin

Very helpful for the "other" reports was an interesting java world article...

I also wanted JDepend to check my project, to I added Jdepend.

my first migration of a legacy project to maven 2

I had to do migrate a legacy webstart swing application to the maven build process. The app was build into several(signed) jars from a single source directory(containing a mix of java files, property files and html help files). The app was deployed with webstart.

Sometimes the pom file reference and settings file reference were helpful...

Important is the introduction to maven lifecycles.
Interresting is the fact, that maven uses plexus container for IoC, reading the comparison, I figured I should try using plexus in another project...

These are the steps that needed to be done to migrate the project:

1. Install 3rd party jars into the local repository
- I checked in this repository

2. use the maven2 jar plugin to create a manifest wich points out the main class:
Maven2 Jar plugin

3. use the jar plugin to sign the jar
- use the maven keytool plugin to create the keystore automatically after reading this page.
- add the jar plugin sign goal

4. use the assembly plugin to creat a a zip file with my (bad practice) manually created jnlp file.
- read the assemply plugin introduction

this pages describes howto use the maven-antrun-plugin.

5. create the appropriate ant build file

Maven 2 3rd Party Jars

Maven: Installing 3rd Party JARs
This page states that one should install a file into the local repository; But another option I found more useful in a team development environment is to deploy 3rd party jars to a maven repository in the companies network via ssh/scp.

If multiple developers work on the project it is advisable to have a linux box somewhere with an ssh server installed and apache running. Just configure this
server in your settings.xml and define the deployment to use that server.

All 3rd party jars, the project website/reports and the project itself can then be deployd to that server with this:

mvn deploy:deploy-file -DgroupId= -DartifactId= -Dversion= -Dpackaging= -Dfile= -DrepositoryId= -Durl=

Taken fromhere.

I truely love maven ;-)