Convention over Configuration - Revision history

JaroslavTulach at 08:26, 26 January 2010

2010-01-26T08:26:56Z

←Older revision		Revision as of 08:26, 26 January 2010
Line 1:		Line 1:
	Due to [[cluelessness]] being present in almost every user of our [[API]], it is better if they don't need to configure anything. It is good if the code [[API]] users create can be analysed automatically and default configuration deduced from it. Modern frameworks (that wish to be [[Good Technology\|cool and in]]) rely on this concept quite often as [[wikipedia::Convention_over_configuration\|wikipedia says]]. It is however fair to remind us that [[Java]] used [[Convention over Configuration]] sooner then it was invented: the [[JavaBean]] specification relies on it heavily.		Due to [[cluelessness]] being present in almost every user of our [[API]], it is better if they don't need to configure anything. It is good if the code [[API]] users create can be analysed automatically and default configuration deduced from it. Modern frameworks (that wish to be [[Good Technology\|cool and in]]) rely on this concept quite often as [[wikipedia::Convention_over_configuration\|wikipedia says]]. It is however fair to remind us that [[Java]] used [[Convention over Configuration]] sooner then it was invented: the [[JavaBean]] specification relies on it heavily.
		+
		+	An interesting observation about [[singleton]]s: If you follow the best practice of writing [[singleton]]s that support [[testability]] and extensibility, you end us with [[Injectable Singleton]]s which follow the credo of [[Convention over Configuration]]: The default is easy to use, if you don't like it, you can provide better implementation.

	[[Category:APIDesignPatterns]]		[[Category:APIDesignPatterns]]

JaroslavTulach at 12:03, 20 September 2009

2009-09-20T12:03:43Z

←Older revision		Revision as of 12:03, 20 September 2009
Line 1:		Line 1:
-	Due to [[cluelessness]] being present in almost every user of our [[API]], it is better if they don't need to configure anything. It is good if the code [[API]] users create can be ~~analyses~~ and default configuration deduced from it. Modern frameworks (that wish to be [[Good Technology\|cool and in]]) rely on this concept quite often as [[wikipedia::Convention_over_configuration\|wikipedia says]]. It is however fair to remind us that [[Java]] used [[Convention over Configuration]] sooner then it was invented: the [[JavaBean]] specification relies on it heavily.	+	Due to [[cluelessness]] being present in almost every user of our [[API]], it is better if they don't need to configure anything. It is good if the code [[API]] users create can be analysed automatically and default configuration deduced from it. Modern frameworks (that wish to be [[Good Technology\|cool and in]]) rely on this concept quite often as [[wikipedia::Convention_over_configuration\|wikipedia says]]. It is however fair to remind us that [[Java]] used [[Convention over Configuration]] sooner then it was invented: the [[JavaBean]] specification relies on it heavily.

	[[Category:APIDesignPatterns]]		[[Category:APIDesignPatterns]]

JaroslavTulach at 12:02, 20 September 2009

2009-09-20T12:02:12Z

←Older revision		Revision as of 12:02, 20 September 2009
Line 2:		Line 2:

	[[Category:APIDesignPatterns]]		[[Category:APIDesignPatterns]]
		+
		+	Anyone knows older use of [[Convention over Configuration]]?
		+
		+	<comments/>

JaroslavTulach at 12:00, 20 September 2009

2009-09-20T12:00:39Z

←Older revision		Revision as of 12:00, 20 September 2009
Line 1:		Line 1:
-	Due to [[cluelessness]] being present in almost every user of our [[API]], it is better if they don't need to configure anything. It is good if the code [[API]] users create can be analyses and default configuration deduced from it. Modern frameworks (that wish to be [[Good Technology\|cool and in]]) rely on this concept quite often as [[wikipedia::Convention_over_configuration\|wikipedia says]]. It is however fair to remind us that [[Java]] used [[Convention over Configuration]] sooner ~~than~~ it was invented: the [[JavaBean]] specification relies on it heavily.	+	Due to [[cluelessness]] being present in almost every user of our [[API]], it is better if they don't need to configure anything. It is good if the code [[API]] users create can be analyses and default configuration deduced from it. Modern frameworks (that wish to be [[Good Technology\|cool and in]]) rely on this concept quite often as [[wikipedia::Convention_over_configuration\|wikipedia says]]. It is however fair to remind us that [[Java]] used [[Convention over Configuration]] sooner then it was invented: the [[JavaBean]] specification relies on it heavily.

	[[Category:APIDesignPatterns]]		[[Category:APIDesignPatterns]]

JaroslavTulach: New page: Due to cluelessness being present in almost every user of our API, it is better if they don't need to configure anything. It is good if the code API users create can be analyse...

2009-09-20T12:00:16Z

New page: Due to cluelessness being present in almost every user of our API, it is better if they don't need to configure anything. It is good if the code API users create can be analyse...

New page

Due to [[cluelessness]] being present in almost every user of our [[API]], it is better if they don't need to configure anything. It is good if the code [[API]] users create can be analyses and default configuration deduced from it. Modern frameworks (that wish to be [[Good Technology|cool and in]]) rely on this concept quite often as [[wikipedia::Convention_over_configuration|wikipedia says]]. It is however fair to remind us that [[Java]] used [[Convention over Configuration]] sooner than it was invented: the [[JavaBean]] specification relies on it heavily.

[[Category:APIDesignPatterns]]