Archive for February, 2010

The psychology of voting and choice (on Stackoverflow and in general)

February 24, 2010

Voting is at the center of (a programming Q&A site), and at the center of democracy (at least such are the claims). How and why do people vote? Today I have a fresh example:

There was this easy question on the |= operator in Java, and I was the first to provide an answer. That lead to a few initial upvotes, so at one point I had 7 and another answer had 2. Then the question author accepted the second-rated answer. An hour later the votes where 9 to 6. So:

  • while my answer was on the top (by virtue of being the first), I got voted up to a big margin
  • when the other answer got on the top (by virtue of being accepted), people started voting it up instead

It’s not who posted the answer (this time) – i.e. who the community trusts more. It is not a matter of quality – both answers give the same information because the question is really simple. It is the simple fact that one answer is the first to be seen.

(And these are intelligent people – they use the Internets and most of them are programmers)


Appeal to API designers

February 18, 2010

If a developer has used the Java security APIs he already knows what’s ahead. That’s not the only example, alas, but I’ll be using it to illustrate my point.

These APIs provide their configurable properties through singleton maps. Security.setProperty("ocsp.enable", "true"); for example

The documentation of these properties is not always in the most visible place, and instead of seeing them while using the API, you have to go though dozens of google results before (if lucky) get to them. And you don’t always know what exactly you are looking for.

Another very serious concern is thread-safety. For example if two threads want to check a revocation via ocsp, they have to set the ocsp.responderURL property in some cases. The “validate(..)” method is not thread-safe, so you should make a synchronization on the validation yourself. A synchronization (and hence potential blocking and waiting) that could have been avoided.

Some at least semi-valid reasons for such type-unsafe, thread-unsafe, Map design could be:

  • setting the properties from the command line – a simple transformer from command-line to default values in the classes suggested above would be trivial
  • allowing additional custom properties by different providers – they can have public Map getProviderProperties(), or even public Object ... with the casting to the custom provider class.

But since many properties are used by only one class (or just a couple), this can be made far more usable. The two potential steps for improvement are:

  • again singleton, but with getter and setter for each property
  • an object containing the properties relevant to the current context CertPathValidator.setValidatorProperties(..) (it already has a setter for PKIXParameters, which is a good start, but it does not include everything)

So the appeal to API designers is – don’t make properties configurable via static Maps.

Using multiple ELResolvers with CompositeELResolver in JSF

February 5, 2010

Imagine the case where you have a JSF application that’s already using some custom ELResolver, but you want to get all the benefits of spring and want to have the SpringBeanFacesELResolver. Well, it’s rather simple:

public class MyCompositeELResolver extends javax.el.CompositeELResolver 

    public class MyCompositeELREsolver() {
         add(new YourCustomELResolver());
         add(new SpringBeanFacesELResolver());

Note that the resolvers are ‘consulted’ in the order they are added.

Now just define your newly created composite resolver as in faces-config.xml.