Be sure to know enough of the language you are arguing against

By Confusion on maandag 22 juni 2009 17:31 - Comments (3)
Categories: Python, Software engineering, Views: 3.828

A flamewar ensues, where people try to show that their solution in their favorite language is better. Well, that didn't really happen, but it makes for a more dramatic ending.

[1] I don't claim he's serious. In fact, I think he just ends his post on a tongue-in-cheek, semi-hopeful note.
[2] Singling out the least interesting part of the blog post as the title of his submission, IMHO
[3] Which explains the title of this post: if you don't have at least that much understanding of a language that you know whether a certain solution is possible or not, than you probably shouldn't be commenting on it.
[4] Act 4 has many variations, but usually people produce a different solution in the original language that approaches the solution in the alternative language.

Installing DB2 Express C on linux

By Confusion on zaterdag 20 juni 2009 15:43 - Comments (2)
Category: Software engineering, Views: 6.725

For anyone else trying to install DB2 Express C, the free community edition of IBM's DB2, on his linux system and running into problems:
  • You need to source sqllib/db2profile in every shell where you are going to run commands from sqllib/bin:
    confusion@ulm:~$ . sqllib/db2profile
  • Running the db2val validation program multiple times in a row can yield different results. For instance, on the first attempt, it told me it couldn't find the sqllib/logs directory. However, that one was already present (perhaps created by db2val?) and when I ran the validation program again, it noticed that.
  • If db2val fails to start your instance with
    SQL1220N The database manager shared memory set cannot be allocated.
    then you probably need to increase the maximum amount of shared memory the kernel may allocate:
    sysctl -w kernel.shmmax=268435456

    The default is 32M and this increases it to 256M, which turned out to be enough. For 64-bit systems, they advise pushing it to 1GB.

    Edit: As moto-moi points out in the comments, this is a temporary change that will disappear with a reboot. To make it permanent, follow his instructions.
  • If running
    confusion@ulm:~$ sqllib/adm/db2start
    SQL10007N Message "-1390" could not be retrieved. Reason code: "3".
    then you probably forgot the first step I described here.
  • If you try to make a connection from your favorite programming language and you receive
    then you probably did a non-root install. Unfortunately, DB2 doesn't have any DB-level users: all user management, including authentication, is delegated to the OS. On a *nix system, the routine checking the password usually requires root privileges. The problem is that the file sqllib/security/db2ckpw needs to be owned by root and needs to have its setuid bit set:
    chown root db2ckpw
    chmod u+s db2ckpw

    I first found the file sqllib/security32/db2ckpw, but that doesn't seem to be used on linux. Might be the Windows version? Afterwards, perform a
    db2 force applications all

    The first command breaks all connections, otherwise the db2stop probably won't work.
  • Keep an eye on sqllib/db2dump/db2diag.log: that's where interesting logging about DB2's functioning ends up. The db2diag command can be used to extract information from that file and can be used to tail it, if you haven't done so already.
  • A warning I encountered in the db2diag log was
    The user per process file descriptor limit of 1024 is less than the maxfilop setting of 30720
    This can be solved by issuing
    ulimit -n 32768

    However, that usually won't work, as the default limits prevent you from going above 1024. To overcome that limit, add the following line to /etc/security/limits.conf
    your_db2_user hard nofile 32768

    After that, you need to open a new shell (for that user) (if you are running an X environment: restart X) and the new shell will have it maximum number of file descriptors set to 32768 after you issue the ulimit command. Now all you need to do is restart DB2.

A simple Java puzzler

By Confusion on donderdag 18 juni 2009 14:59 - Comments (17)
Categories: Java, Software engineering, Views: 3.905

        final long YEAR_IN_MS = 1000 * 60 * 60 * 24 * 365;

What will be printed?

Undecipherable product descriptions

By Confusion on vrijdag 12 juni 2009 17:57 - Comments (4)
Categories: Java, Software engineering, Views: 3.375

Today I had to merge a Flex frontend into a Java project. Inside the Flex project, in a 'lib' directory, I found something called 'cairngorm.swc'. Having no experience with development in Flex, I had no clue what this file was. The person responsible was not available at the moment, so I did the only natural thing: Google it. That turned up Adobe's homepage for Cairngorm. The first section, which your eye falls onto when you view the page, is titled 'Overview' and reads:
Cairngorm is the lightweight micro-architecture for Rich Internet Applications built in Flex or AIR. A collaboration of recognized design patterns, Cairngorm exemplifies and encourages best-practices for RIA development advocated by Adobe Consulting, encourages best-practice leverage of the underlying Flex framework, while making it easier for medium to large teams of software engineers deliver medium to large scale, mission-critical Rich Internet Applications.
Ehmmm, yeah, right. Thanks for making me feel stupid. Now I still don't know whether it's a library that I need to include to get the application to run, a standalone Flex viewer/debugger or a collection of examples. By clicking "More information" and reading further, I didn't actually get more information. Only after a PgDn I finally encountered
The Cairngorm microarchitecture is intended as a framework for Enterprise RIA developers.
ah, framework. That's a word I know. So it's a library.

I have this kind of experience more often than I like to: I read an introduction to something and afterwards I still have no idea what the thing is. Is it just me or do you also feel introductions should start with the simple facts and purpose and maybe expand towards an all-encompassing vision of the developers towards the end, rather than starting out that way and leaving you at a plane of abstraction that causes you to miss the actual simplicity of the thing?

Nasty Java HashMap race condition

By Confusion on dinsdag 9 juni 2009 22:03 - Comments (13)
Categories: Java, Software engineering, Views: 15.104

After reading this I think I need to check some applications I wrote in the past.

The piece is excellent and details matter, but I'll attempt a summary anyway:
if you use a regular HashMap in a multithreaded environment, it seems the worst that can happen is that you incur some additional cache misses due to race conditions. In a lot of situations that is perfectly acceptable and since wrapping the HashMap with Collections.synchronizedMap() incurs quite a performance penalty (and at that point, that was basically the choice), you are tempted to just leave the HashMap in. Don't. The 'put' operation may trigger a resize and redistribution of the internal data structure of the HashMap that can thoroughly hose it is concurrently accessed during the restructing , to the extent that your program goes into an infinite loop.

These days, there isn't any performance reason to decide in favor of the regular HashMap: the java.util.concurrent.ConcurrentHashMap has excellent performance, even in singlethreaded applications. However, I think I've made the mistake of using a regular HashMap somewhere in the past. However, the application has never malfunctioned (as far as I know), so it may well be that the chances of this bug occurring are so small that they are negligible for all practical purposes. Nevertheless, unless you want to do the math, replacing it by a ConcurrentHashMap is a safe bet.