Tags

Passwords

November 20th, 2007

Joe Walker had some ideas on how you may manage your passwords. I am not really covinced:

The idea of using a password core and a mangle procedure with the site name is dangerous. You assume that this PWD is compromized, thus the attacker might get behind your mangle style and can guess other site’s passwords.

The counter for password versions defies even the reason for frequent password changes: You want to know at least approximately when the passwort had been stolen.

IMHO a pretty stupid idea, because to have meaningful data from a theft, the expire period must be rather short. This in turns requires the user to change that often that they will use the simplest password possible.

My advice: No I won’t even tell you how I think passwords should be created - Be paranoid!

Expression idiom for Java

November 17th, 2007

Scala has spoiled me, accepting that an if-else doesn’t yield an expression gets harder and harder for me. As my day job is still Java based, I looked for some replacement for

class Foo {
    val baz = Map(1->2, 2->3)
}

First step is to javaize it:

class Foo {
    val bar = {
        val map = new java.util.HashMap()
        map put(1,2);
        map put(2,3);
        map
    }
}

And now in Java this can be translated to:

public class Foo {

	final Map<Integer,Integer> bar = new Object(){
		Map<Integer,Integer> map() {
			Map<Integer,Integer> map = new HashMap<Integer,Integer>();
			map.put(1,2);
			map.put(2,3);
			return Collections.unmodifiableMap(map);
		}}.map();
}

Why the anonymous class? I could wrap it into a method, but this method must be private, otherwise bad things can happen when the class gets extended (never call non-finals from a constructor). In the anonymous class it is clear that this code serves only this single purpose and is not meant to be used elsewhere; nobody would lightheartly widen the visiblity of this code.

The thing new for some might be that I can call map() on Object. It works on an anonymous calls definition, not elsewhere. Thus you can store away your initializer, if access from a reference it degenerates back to an ordinary object, things that don’t work are:

final Object initializer = new Object() {
  String name() { return "MU";}
}
final String name = initializer.name(); //method doesn't exist

and

final String name = new Object() {
  Object me() { return this;}
  String name() { return "MU";}
}.me()
  .name(); // me returns a simple Object, no name() method

Besides the Java clutter, if you can establish it as an idiom it is still fairly readable and expresses well your intent - it is just the syntax imposed by the language which makes it different from the from bit of code. It also helps eliminating non-final variables from a method as you can construct a value completely before exposing it. Of course there is a runtime penalty for the extra Object to be created and collected. The limitations can play for your advantage: The method (why singular?:-) you declared can’t be called elsewhere (unless you use reflection), a “private” method you can call!

Anyway, one question remains: Why did the “return this” idiom heavily used in C++ (at least in my days) out of fashion? In Java you find it in StringBu(ild|ff)er, but rarely elsewhere. Some attempts to create DSLs in Java used it, but besides it seems to be bad style - anyone know some good reason for that? Doing so would allow to write

final Map<Integer,Integer> bar = new HashMap<Integer,Integer>()
    .put(1,2)
    .put(2,3);

Reflection

If you read so far, here the reflection leak:

Object o = new Object(){
    Map<Integer,Integer> map() {
        Map<Integer,Integer> map = new HashMap<Integer,Integer>();
        map.put(1,2);
        map.put(2,3);
        return Collections.unmodifiableMap(map);
    }};
Method mapFn = o.getClass().getDeclaredMethod("map");
final Map map= (Map) mapFn.invoke(o);

Even more interesting - by this you can pass hidden methods (why plural?:-) through your system - I can imagine even a good use for that: This allows hooks into the defining object so that you can tell where it comes from - worst OO style, but for some intricate manipulation within an API perhaps worth a consideration - or simply an unobstrusive way to to debug with a decorated instance.

Auf der anderen Seite (TR/D 2007)

November 16th, 2007

Migrationsroadmovie

Handlung

Ayten muss sich aus der Türkei absetzen und sucht in Bremen Ihre Mutter, während Nejat sie zugleich in Iatambul sucht. Beide finden woanders etwas was sich nicht erwartet haben.

Warum sollte man den Film sehen

Schwer zu sagen bei Roadmovies, man betrachtet halt gern die Charaktere, davon gibt es reichlich und sie habe auch etwas gemeinsames/trennendes, was es interessant macht dem Spiel zuzusehen. Gut angelegte Handlung, wie sie sich nur im Migrantenmillieu abspielen kann.

Was nervt

Die Dialoge sind manchmal etwas hölzern, von Schauspielern wie Hannah Schygulla erwartet man da doch, dass sie die Schwächen des Drehbuchs am Set korrigieren.

American Gangster (US 2007)

November 15th, 2007

Dokumentarspiel von Ridley Scott über eine reale Person.

Handlung

Frank Lucas, Ziehsohn einer New Yorker Unterweltgröße startet nach dessen Tod seine eigene Karriere.

Warum sollte man den Film sehen

Nach Blackhawk Down hat Ridley Scott mal wieder einen dokumentarischen Film gemacht. Der Realismus is manchmal schwer zu ertragen, er zeigt aber deutlich die Ambivalenz ziehen Gangstern mit Ehrenkodex und skrupellosen korrupten Polizisten, Filmisch ein großer Film, Denzel Washington einmal als Bösewicht (ist man sich da so sicher?).

Was nervt

Nichts, einfach nur perfekt.

Multiton

November 15th, 2007

What is a Multiton? It is a multiple Singleton. Below I have a Multion for some random primes of a given length, but it might as well be some config data you read from a named DB connection, etc.

Some say that the Multiton is an antipattern (shrug), but it is widely used, here my high performance implementation. It uses a IODH variant - note that the classic IODH cannot work for Multitons as the holder there - even if the Wikipedia article mentions this. The IODH relies on the fact that the (singleton) instance is bound to the class that holds it. As a class can bei initialized only a single time, this works for a Singleton, but not for a Multiton.

The following code is designed for a quite expensive creation where the instances are queried very frequently.

public class Multiton {

	private interface MHolder {
		Multiton m();
	}
	private static final ConcurrentHashMap instances
		= new ConcurrentHashMap();

	public BigInteger primeForLength;

	public Multiton(int key) {
		primeForLength=BigInteger.probablePrime(key, new Random());
	}

	public static final Multiton get(final int key) {
		MHolder m = instances.get(key); // most of the time we should have it already, no locking
		if (m==null){
			m = new MHolder(){
				/**
				 * might be contended if same instance is requested during computation
				 */
				public synchronized Multiton m(){
					final Multiton m = new Multiton(key);
					MHolder mh = new MHolder(){
						@Override
						public Multiton m() {
							return m;
						}
					};
					// replace with simple holder after value is computed
					instances.put(key, mh);
					return m;
				}
			};
			MHolder mh = instances.putIfAbsent(key, m);
			if (mh!=null) m=mh; // race occurred
		}

		return m.m(); // now the expensive creation is outside the synchronized block
	}

}

The key for performance in parallel system lies in the reduction of contended locking. Here we have two locking points:

  • putIfAbsent - only locks a segment, thus most parallel creation will not be affected
  • synchronized Multiton m()

The later is the interesting one: As the creation is slow m() might be called in parallel, here we have our IODH pattern. Instead of relying on the synchronization of the classloader we sync the object. To avoid unnecessary synchonization the holder gets replaced by a non-synchronized one which returns that same value.

Cassandra’s Dream (US/UK 2007)

November 11th, 2007

Parabel auf die griechische Legende

Handlung

Ian und Terry sollen für ihren Onkel als Gegenleistung für seine Hilfe einen Mord begehen. Gier gegen Moral.

Warum sollte man den Film sehen

Ewan McGregor und Colin Farrel sind in Hochform.

Was nervt

Nichts, aber auch nichts was irgendwie das Interesse aufrecht erhalten könnte. Die Handlung plätschert vor sich hin und irgendwie ist man nicht gespannt wie es genau ausgeht - ungefähr wird es zu schnell klar - sondern das es endlich aus ist.