Monthly Archives: June 2009

Book review: A question of torture

After receiving request to revive my book reviews, I’ve decided to blog about books I read again.

If a known terrorist in police custody knew the whereabouts of a ticking bomb about to explode in a large city, would the use of torture be acceptable? Would it be helpful? I stumbled across Alfred McCoy through fora.tv. The program impressed me so much that I decided to pick up his book A Question of Torture.

A Question of Torture

In the book, McCoy examines the history of coercive techniques from the fifties until the present. He makes the case that the so-called “few bad apples” in Abu Ghraib in fact were using techniques directly from the CIA’s playbook on torture. These techniques focus on sensory deprivation (such as hooding and prolonged isolation), self-inflicted pain (such as prolonged standing and other “stress positions”), humiliation (such as forced nudity), and sensory disorientation (such as loud music and sleep deprivation) and they do constitute torture.

Some of the questions raised and answered in this frightening book:

  • How does torture and coercive methods compare to noncoercive methods when it comes to getting useful information? This is in a sense the difference between the effectivenesss of CIA and FBI in “the war on terror”.
  • What long term effects does torture have on its victims?
  • What is the effect on those who commit torture?
  • What is the strategic effect of employing torture as a weapon in a war, such as the use of torture and summary executions by the CIA in Vietnam and France in Algers? McCoy unstated claim is that in a sense, the CIA’s Phoenix-program cost the US the Vietnam war.
  • Can the use of torture ever be effectively limited to avoid torturing innocent civilians?

The book offers a resounding indictment of torture on practical, but more importantly, on moral grounds.

The academic style of the book makes it a bit hard to read. At times, it feels like a collage of quotations. On the other hand, this means that it contains well-documented, important and disturbing claims. In the end, this made it into a very quick read.

Posted in Books, English, Non-technical | 1 Comment

From computer determinism to real world indeterminism

I thought it was about time I wrote about topics where I’m an amateur. This time: Experimental philosophy.

As a computer programmer, I often entertain myself with writing computer programs. Last Easter I stayed up a few nights playing with an insignificant, but entertaining program. During a discussion with my philosopher uncle, I discovered that this program might provide some insight as to why determinism is, if not dead, then at least lame.

A Game of Blokus (by Andy_Tinkham)
A Game of Blokus (by Andy_Tinkham)

(more…)

Posted in English, Non-technical | 5 Comments

Unit testing tricks: Look ma, no setters!

Here’s a neat trick if you want set an object in a specific state in a unit test, but you don’t want to violate encapsulation:

    @Test
    public void withdrawShouldReduceBalance() {
        Account account = new Account() {{
            super.balance = 100;
        }};
        account.withdraw(10);
        assertEquals(90, account.getBalance());
    }
 
    @Test(expected=IllegalStateException.class)
    public void overdraftShouldThrow() {
        Account account = new Account() {{
            super.balance = 5;
        }};
        account.withdraw(10);
    }

This seemingly magic code lets me have a protected (but sadly not private) field Account#balance. I can set this field in each individual test method.

It looks very magic, so it deserves a brief explanation:

  1. The first set of curlies create an anonymous subclass of Account. That is: new Account() {}.
  2. The second set of curlies creates an initializer block, that is: a block of code that is added to the constructor.
  3. So in effect: Each test method creates a subclass of Account and modifies the account field in the constructor. This is why Account#balance must be protected instead of private.

This trick (and it is a trick) lets me set up the object under test to any state I want, without needing a special constructor and without breaking encapsulation by adding a setter. However, I’m required to make the fields I want to initialize protected. Additionally, each test method creates one or more new classes. This could potentially affect performance and/or memory use during compilation and/or running of tests. I’ve only used the trick at a small scale, so I don’t know if I’ll run into these issues in the future.

So, what do you think: How big of a “WTF” is this code?

Posted in English, Java | 18 Comments

Guidelines for eGovernment Projects

The Agency for Public Management and eGovernment in Norway is currently developing guidelines for IT-projects within the Norwegian governmental sector. The Norwegian Computing Association hosted a presentation and discussion about this work yesterday. I was privileged enough to summarize the comments from one of the three discussion groups at the meeting. For the enjoyment of the internet, I hereby provide a few ideas on eGovernment projects.

(more…)

Posted in Communities, English, Software Development | 7 Comments