How to Cure a Fanatic

21. July, 2008

Like many people, I’ve always been wondering how the Jews, barely escaped from being extinct, can behave like they do in Israel and Palestine today. It seems, some of them wonder as well. One of them is Amos Oz who has written a wonderful book about fanaticism: How to Cure a Fanatic.

If you don’t understand that I’m arguing against violence here, get the book and read it.

According to the book, a fanatic is a person who cares so much about you that he’d rather kill you than let you be miserable.

Oddly, this makes sense. Fanatics want to make the world a better place — at all cost. In the second chapter of the book, Oz tells a short story why this doesn’t work. He does that in a way that even a fanatic might understand (translated into English by me; all mistakes are mine).

A friend of Amos Oz, the Israeli romancer Sami Michael once made a long trip in a car. During the ride, the driver gave him the usual lecture how important it was for the Jews to kill all Arabs.

Instead of harassing this guy with “What a horrible man you are! Are you Nazi? A Fascist?”, Sami listened. He had decided to try a new approach and he asked the driver: “And who, in your opinion, should actually kill all the Arabs?”

The driver replied: “What are you talking about? We! The Israeli Jews! We have to! We have no choice, just look at what they do to us every day!”

“But who exactly should do the job in your opinion? The police or maybe the army or the fire brigade or a team of doctors? Who should do the work?”

The driver scratched his head: “I think it should be spread among us. Everyone should kill a few.”

Sami went along with the game. “O.K., I assume you will pick an apartment building in the capital of Haifa, you ring the doorbell or you knock on every door and you say: ‘Excuse me, dear Sir or Madam, are you an Arab by any chance?’ And if he or she should reply with ‘yes’, you will shoot them. Then, you just finished your block and want to go home, just then, you hear a baby cry somewhere on the third floor. Would you go back and shoot the baby? Yes or no?”

There was a moment of silence, then the driver said to Sami: “You know, you are a very cruel person.”

Now, if your feel anger or disgust, you didn’t understand the point of the story, so get the book and read it. For everyone else, think about it. You’ll be surprised how many levels of understanding this simple story has and how well it explains the reasons and the fundamental flaw of a fanatic.

Disclaimer: No humans and no animals were harmed, tortured or killed for this blog entry. Only my cat is now mad at me because I dared not to devote her my full attention while I wrote this.

Toying With Swing

21. July, 2008

I’ve been toying with Java Swing (the UI which comes with Java in case you’re wondering) a bit lately to determine which UI to use for my ePen project. I’ll post a longer article about my findings in the next few days but for now, just a few links I’ve collected:

From LegHumped:

Then, there is the JFC Swing FAQ and of course the Java Swing Trail by Sun.

I’ve been looking for a good source on editor components. Swing Hacks looked promising but it seems to only scratch the surface like the rest.

Docs? Ask The Sphinx

16. July, 2008

If you need to generate docs for your Python projects, try Sphinx.

There Are Two Kinds of People …

15. July, 2008

“… Those who separate people in two kinds and those who don’t.” But I digress.

Ever wondered about the wars in IT? VI vs. Emacs? KDE vs. Gnome? IntelliJ IDEA vs. Eclipse? PC vs. Mac? Why can’t people pull along the same string for once?

Well, because they can’t. Duh. We all have differences and we find these to make our life more rich or more simple. Can’t discuss with a guy who always agrees with you, can you? Or just image your better half to do as you do … you couldn’t even out your advantages and disadvantages! During work, we accept that people are different and we find that useful because it means that work can be spread and people can do what they’re good at (instead of where they suck).

Sometimes, this difference goes deep. Way deep. It’s so fundamental to our personality that we don’t even question this. That’s the fundamental schism which fuels the wars in IT. There are “vi” people and there are “emacs” people. Each member of both groups thinks the others are imbeciles who just won’t see the light, no matter how often they got beaten some brains into them.

The “vi” people wants to get things done and they don’t want the tools to get in the way. A tool should be like a hammer: Simple, to the point, easy to understand and use. If it comes with a manual, it’s not a tool, it’s a distraction.

The “emacs” people, on the other hand, like to have the most powerful tool they can find at their fingertips. They want to abstract, hide, build tool layer upon tool layer until the task at hand literally happens at the press of a button. If the tool can’t be customized, it’s not a tool, it’s a nuisance.

No matter how much you wish for it, these two kinds of people will never use the other ones tool. If they have to, they will be constantly irritated. Take IntelliJ IDEA, for example. I’m a “vi” guy and this IDE just freaks me out. It’s always doing something with my source that I never told it to do, always reformatting, always adding and removing whitespace, always getting in my way. I hate it.

Eclipse, on the other hand, comes with a rich tool set. I can have my source formatted any way I like, but it only does so when I tell it to. The default is to leave my artwork alone. Eclipse doesn’t try to be smarter than me. Eclipse gets my jobs done when I want them to be done and it doesn’t get in my way.

Don’t get my wrong. I’m not telling you why Eclipse is better for you than IntelliJ, I’m saying it’s better for me. I’m a “vi” guy.

Now, you may argue that I could probably hack IntelliJ into doing what I want. That’s my point exactly: If I have to turn IntelliJ into an Eclipse clone to be able to use it, why not use the tool which fits my hand to begin with? And let’s face it: No matter how customizable a tool is, after you’ve turned it into a clone, there will still be a lot of corner cases.

These come from the core of the design of these tools and that’s what makes them as fundamentally different as two humans and no argument in the world will change that.

So, next time someone comes up and says “This or that would be better”, answer: “It is better for you.. How about me?

Java Tricks: Fastest Way to Collecting Objects in a String

11. July, 2008

The fastest way to collect a list of objects in a String in Java:

StringBuilder buffer = new StringBuilder ();
String delim = "";
for (Object o: list)
    buffer.append (delim);
    delim = ", "; // Avoid if(); assignment is very fast!
    buffer.append (o);
buffer.toString ();

Are Bad Tests Worse Than No Tests At All?

9. July, 2008

In his article “Are Bad Tests Worse Than No Tests At All?“, olivstor writes:

Are the drawbacks to bad tests worse than having no coverage at all?

I think the answer is that in the short term, even bad tests are useful. Trying to squeeze a extra life out of them beyond that, however, pays diminishing returns.

Just like other software, your tests should be built for maintenance, but in a crunch, you can punch something in that works. It’s better to have bad tests than to have untested code.

Tests are like any other code: They can go bad.

In my career, I’ve found that it’s surprisingly hard to write good tests if you have no experience in doing so. People starting to write tests make them too complex, too long, let them have too many dependencies and they take too long to run.

If you’re in such a situation, you have to face the fact that you just programmed yourself in a corner and you must spent the effort to get out of there. Tests are no magic silver bullet. They are code and follow the usual rules of coding: When it hurts, something is broken and it won’t stop hurting unless you fix it.

So in this sense, I agree that bad tests are better than no tests because they tell you early that you need to fix something. That’s what their core purpose is.

Management might argue that you’re spending too much time on testing. I’ve never had a problem to sell myself to them. I usually figure that I spend 50% of my time (or more!) writing tests and 50% actual coding – and I’m still much faster than those who write code 80% of the time or more. What’s more: when my code goes into production, it’s is rock solid or at least easy to fix when something comes up. In 99% of the cases, the things I need to fix were those which I didn’t test.

This is a positive reinforcement loop which drives me to test more and more because it stops the hurting. If your tests cost more than they seem to return, you need to fix them until you get the same positive feeling when you think about them.


8. July, 2008

While doing some work with MQSeries, I got an error “MQJE001: Completion Code 2, Reason 2045” in MQQueueManager.accessQueue() which translates to “MQRC_OPTION_NOT_VALID_FOR_TYPE”. Hm. Hey, IBM, how about adding real error messages to your products instead of having people look up odd codes in tables?

Anyway, the error means that I’m trying to open a queue for output which doesn’t support this. For example, remote queues can be opened with the option MQC.MQOO_OUTPUT but not with MQOO_BROWSE or MQOO_INPUT_AS_Q_DEF. Other queues don’t allow to read from them, i.e. you have to get rid of MQC.MQOO_INPUT_AS_Q_DEF in the openOptions.

See this page for all possible combinations: MQOPEN – Open object

TurboGears 2.0 Is On Track

8. July, 2008

There are three things which hooked me to TurboGears:

  1. Every day stuff is simple, complex stuff is possible
  2. Automatic reload after code change (no need to restart)
  3. It’s in Python

What I didn’t like is that TG 2.0 has been so quiet for so long. I’m on the Planet Turbogears RSS feed and I wasn’t sure whether 2.0 was alive or dead or whatever.

Well, it seems to be more alive than I expected and hopefully, we’ll see a 2.0 soon. In “Doing the right thing should be easy” by Mark Ramm, you can find more details.

Starting Your Own OSS Project

8. July, 2008

If you’re planning to roll your own little OSS toy project, you should read the article “Party of one: Surviving the solo open source project” by Kirill Grouchnikov. Very good points on what to do and what to avoid and why.

Genes in Wikipedia

8. July, 2008

So if you ever wanted to know how that stuff works that you’re made of, scientists have started to put their knowledge about genes on Wikipedia. Beware, though, it’s heavy stuff.

It’s interesting to see how you can use an automated process to merge complex information from one system (the scientist’s databases) into another. Now, I’m waiting for the “translate this goo into language xyz” bot 🙂

%d bloggers like this: