Skip to main content

Posts

Showing posts from October, 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...

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) Double Checked Locking 1 Double Checked Locking 2 Why is ReentrantLock faster than synchronized ?

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 re...