Grayger

Tom DeMarco, from his recent article in IEEE Software, says we should rethink the goal of a software project.

For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business.

Is software engineering, which weights controls over software projects, outdated? Really? The article is too short to strenghten his sensational arguments. However, software developement may become boring and dry as we focus more on a defined process or metrics.

A few days ago, I registered stackoverflow.com and found an interesting post: what are hidden features of Java?

The stuffs that I didn’t know before are

• Double brace initialization

	Map map=new HashMap<String,String>() {
		{
			put("key1","value1");
			put("key2","value2");
		}
	};

• Instance initializer

public class Initializer {
	static {
		System.out.println("static");
	}
	{
		System.out.println("instance");
	}
	public Initializer() {
		System.out.println("constructor");
	}
}

• Covariant return type

	abstract class Base {
		abstract List getList();
	}

	class Sub extends Base {
		@Override
		ArrayList getList() {
			return null;
		}
	}

Double brace initialization uses instance initializer because first brace is for declairing annomymous inner class and second brace is for instance initializer block.

“JavaScript The Good Parts” by Douglas Crockford is one of the most subjective books on JavaScript because it dares to divide JavaScript language specifications into good parts and bad parts.

Most of good parts are well-known, but not widely used. I can see they are fully and correctly used in JavaScript frameworks or toolkits but they are rarely or inappropriately used by page designers.

For me, sections on bad parts are much useful. I tell “===” from “==” but I have never used “===” just because I, as a Java programmer, am not familiar to it. The book helps use bad parts less rather than use good parts more.

I saw a presentation on Java VM optimization via InfoQ. Java is originally slow, but HotSpot compiler is getting smarter enough to free Java from the shame.

http://www.infoq.com/presentations/pampuch-vm-optimizations-language-designers