InfoQReview - Revision history

JaroslavTulach: /* On Architects' Role */

2018-04-04T08:58:22Z

On Architects' Role

←Older revision		Revision as of 08:58, 4 April 2018
Line 113:		Line 113:
	bugs and design problems, to the extent that it is unfixable, requiring a complete rewrite.		bugs and design problems, to the extent that it is unfixable, requiring a complete rewrite.
	Coming to this point takes a very long time, with the evidence usually needing to grow over		Coming to this point takes a very long time, with the evidence usually needing to grow over
-	several releases. However, there is a point in the lifecycle of most software	+	several releases. However, there is a point in the [[lifecycle]] of most software
	projects where someone offers to perform a [[Big Bang]] change. Initially, the offer is declined		projects where someone offers to perform a [[Big Bang]] change. Initially, the offer is declined
	because everyone understands the rewrite will be painful and		because everyone understands the rewrite will be painful and

JaroslavTulach: /* On Architects' Role */

2012-10-23T07:47:07Z

On Architects' Role

←Older revision		Revision as of 07:47, 23 October 2012
Line 132:		Line 132:
	to bridge them, when necessary.		to bridge them, when necessary.

-	If we modularize our applications and treat each piece as a library with an	+	If we [[modularize]] our applications and treat each piece as a library with an
	API, we can minimize the need for stop-the-world [[Big Bang]] rewrites and		API, we can minimize the need for stop-the-world [[Big Bang]] rewrites and
	replace them with continuous distributed improvements. This is maybe slightly		replace them with continuous distributed improvements. This is maybe slightly

JaroslavTulach: /* On Favorite Book */

2011-06-05T10:59:16Z

On Favorite Book

←Older revision		Revision as of 10:59, 5 June 2011
Line 182:		Line 182:
	My book references Effective Java and the [[Gang of Four]]'s design pattern book. Those are a must read and indeed they are very well known already.		My book references Effective Java and the [[Gang of Four]]'s design pattern book. Those are a must read and indeed they are very well known already.

-	Beyond these, I also reference a perfect book by [[wikipedia::Petr_Vopenka\|Petr Vopěnka]] about the history of geometry: "The Key Stone of European Knowledge". It may sound boring at first, but it isn't and I fell in love with it. Many of [[TheAPIBook\|Practical API Design]]'s "philosophical" sections are based on ideas from that book. So, if you belong to the camp that finds those parts interesting, I'd recommend the book to your attention. There is just one problem... it hasn't been translated to English yet.	+	Beyond these, I also reference a perfect book by [[wikipedia::Petr_Vopenka\|Petr Vopěnka]] about the history of geometry: "[[The Key Stone of European Knowledge]]". It may sound boring at first, but it isn't and I fell in love with it. Many of [[TheAPIBook\|Practical API Design]]'s "philosophical" sections are based on ideas from that book. So, if you belong to the camp that finds those parts interesting, I'd recommend the book to your attention. There is just one problem... it hasn't been translated to English yet.

JaroslavTulach: /* On Architects' Role */

2010-10-28T17:40:27Z

On Architects' Role

JaroslavTulach: /* On Favorite Book */

2010-03-11T09:20:29Z

On Favorite Book

←Older revision		Revision as of 09:20, 11 March 2010
Line 182:		Line 182:
	My book references Effective Java and the [[Gang of Four]]'s design pattern book. Those are a must read and indeed they are very well known already.		My book references Effective Java and the [[Gang of Four]]'s design pattern book. Those are a must read and indeed they are very well known already.

-	Beyond these, I also reference a perfect book by Petr Vopěnka about the history of geometry: "The Key Stone of European Knowledge". It may sound boring at first, but it isn't and I fell in love with it. Many of Practical API Design's "philosophical" sections are based on ideas from that book. So, if you belong to the camp that finds those parts interesting, I'd recommend the book to your attention. There is just one problem... it hasn't been translated to English yet.	+	Beyond these, I also reference a perfect book by [[wikipedia::Petr_Vopenka\|Petr Vopěnka]] about the history of geometry: "The Key Stone of European Knowledge". It may sound boring at first, but it isn't and I fell in love with it. Many of [[TheAPIBook\|Practical API Design]]'s "philosophical" sections are based on ideas from that book. So, if you belong to the camp that finds those parts interesting, I'd recommend the book to your attention. There is just one problem... it hasn't been translated to English yet.
-		+
-	~~http://en.wikipedia.org/wiki/Petr_Vopenka~~	+

JaroslavTulach: /* On Favorite Book */

2010-03-11T09:19:37Z

On Favorite Book

←Older revision		Revision as of 09:19, 11 March 2010
Line 180:		Line 180:
	: ''recommendation for our readers?''		: ''recommendation for our readers?''

-	My book references Effective Java and the Gang of Four's design pattern book. Those are a must read and indeed they are very well known already.	+	My book references Effective Java and the [[Gang of Four]]'s design pattern book. Those are a must read and indeed they are very well known already.

	Beyond these, I also reference a perfect book by Petr Vopěnka about the history of geometry: "The Key Stone of European Knowledge". It may sound boring at first, but it isn't and I fell in love with it. Many of Practical API Design's "philosophical" sections are based on ideas from that book. So, if you belong to the camp that finds those parts interesting, I'd recommend the book to your attention. There is just one problem... it hasn't been translated to English yet.		Beyond these, I also reference a perfect book by Petr Vopěnka about the history of geometry: "The Key Stone of European Knowledge". It may sound boring at first, but it isn't and I fell in love with it. Many of Practical API Design's "philosophical" sections are based on ideas from that book. So, if you belong to the camp that finds those parts interesting, I'd recommend the book to your attention. There is just one problem... it hasn't been translated to English yet.

	http://en.wikipedia.org/wiki/Petr_Vopenka		http://en.wikipedia.org/wiki/Petr_Vopenka

JaroslavTulach at 15:28, 28 November 2009

2009-11-28T15:28:22Z

←Older revision		Revision as of 15:28, 28 November 2009
Line 146:		Line 146:
	: ''What do you think about the new ''		: ''What do you think about the new ''
	: ''features and APIs in the upcoming JDK Version 7 and the dropped features''		: ''features and APIs in the upcoming JDK Version 7 and the dropped features''
-	: ''like Closures? ''	+	: ''like [[Closures]]? ''

	The #1 thing that Java needs is a standard module system adopted by everyone.		The #1 thing that Java needs is a standard module system adopted by everyone.
Line 158:		Line 158:
	modularity in mind. This has got to be changed. There needs to be support for		modularity in mind. This has got to be changed. There needs to be support for
	modularity in the Java language itself. I'm even willing to wait a few		modularity in the Java language itself. I'm even willing to wait a few
-	years for closures, if I can get the modularity in Java right now.	+	years for [[closures]], if I can get the modularity in Java right now.

	== On Favorite Language Feature ==		== On Favorite Language Feature ==

JaroslavTulach: /* On Relationship with Agility */

2009-11-09T11:42:28Z

On Relationship with Agility

←Older revision		Revision as of 11:42, 9 November 2009
Line 56:		Line 56:
	the NetBeans team is following to review API changes before integration. This way we can prevent things to even think about regressing.		the NetBeans team is following to review API changes before integration. This way we can prevent things to even think about regressing.

-	== On Relationship with Agility ==	+	== On Relationship with [[Agile\|Agility]] ==

-	: ~~''How can~~ Agile ~~and lean ''~~	+	{{:Agile}}
-	~~: ''software development methodologies like SCRUM, XP and Kanban help a project''~~	+
-	~~: ''team involved in the design and development of API frameworks? ''~~	+
-		+
-	~~The question is whether agile methodologies help design and development of API~~	+
-	~~frameworks... or whether properly modularizing an application and splitting it~~	+
-	~~into many libraries with APIs simplifies the use of agile methodologies? Both~~	+
-	~~are probably true.~~	+
-		+
-	~~There are several sound rules in the world of API design. For example,~~	+
-	~~you need to be aware at the outset that the first version of your API~~	+
-	~~is not going to be perfect. Also, you need to envision who your users are. Two~~	+
-	~~other basic principles are that unit~~	+
-	~~test coverage is almost a must and that you should always design your API~~	+
-	~~in such a way that it is ready to be evolved further.~~	+
-		+
-	~~Many of these pieces of advice are close to being the governing rules of agile methodologies as well.~~	+
-	~~As such, I think that proper API design and agile methodologies can only~~	+
-	~~strengthen each other.~~	+

	== On API Reviews ==		== On API Reviews ==

90.178.159.79: /* On Favorite Book */

2009-02-19T08:22:38Z

On Favorite Book

←Older revision		Revision as of 08:22, 19 February 2009
Line 198:		Line 198:
	: ''recommendation for our readers?''		: ''recommendation for our readers?''

-	My book references Effective Java and Gang of Four's design pattern book. Those are a must read and indeed they are well known.	+	My book references Effective Java and the Gang of Four's design pattern book. Those are a must read and indeed they are very well known already.

-	Beyond these I also reference a perfect book by Petr Vopěnka about history of geometry: "The Key Stone of European Knowledge". It may sound boring at first, but it ~~is not~~ and I fell in love with it. Many of Practical API Design's "philosophical" sections are based on ideas of that book. So if you belong to the camp that finds those parts interesting, I'd recommend the book to your attention. There is just one problem~~: It has not yet~~ been translated to English.	+	Beyond these, I also reference a perfect book by Petr Vopěnka about the history of geometry: "The Key Stone of European Knowledge". It may sound boring at first, but it isn't and I fell in love with it. Many of Practical API Design's "philosophical" sections are based on ideas from that book. So, if you belong to the camp that finds those parts interesting, I'd recommend the book to your attention. There is just one problem... it hasn't been translated to English yet.

	http://en.wikipedia.org/wiki/Petr_Vopenka		http://en.wikipedia.org/wiki/Petr_Vopenka

90.178.159.79: /* On Favorite Book */

2009-02-19T08:21:12Z

On Favorite Book

←Older revision		Revision as of 08:21, 19 February 2009
Line 200:		Line 200:
	My book references Effective Java and Gang of Four's design pattern book. Those are a must read and indeed they are well known.		My book references Effective Java and Gang of Four's design pattern book. Those are a must read and indeed they are well known.

-	Beyond these I also reference a perfect book by Petr Vopěnka about history of geometry: "The Key Stone of European Knowledge". It may sound boring at first, but it is not and I ~~felt~~ in love with it. Many of Practical API Design's "philosophical" sections are based on ideas of that book. So if you belong to the camp that finds those parts interesting, I'd recommend the book to your attention. There is just one problem: It has not yet been translated to English.	+	Beyond these I also reference a perfect book by Petr Vopěnka about history of geometry: "The Key Stone of European Knowledge". It may sound boring at first, but it is not and I fell in love with it. Many of Practical API Design's "philosophical" sections are based on ideas of that book. So if you belong to the camp that finds those parts interesting, I'd recommend the book to your attention. There is just one problem: It has not yet been translated to English.

	http://en.wikipedia.org/wiki/Petr_Vopenka		http://en.wikipedia.org/wiki/Petr_Vopenka

←Older revision		Revision as of 17:40, 28 October 2010
Line 109:		Line 109:
	needs. But I suspect nobody is really sure what that is. Except...		needs. But I suspect nobody is really sure what that is. Except...

-	...one of the problems in software development is associated with ~~"big bang"~~	+	...one of the problems in software development is associated with [[Big Bang]]
	changes, that is, situations where you find that your product has too many		changes, that is, situations where you find that your product has too many
	bugs and design problems, to the extent that it is unfixable, requiring a complete rewrite.		bugs and design problems, to the extent that it is unfixable, requiring a complete rewrite.
	Coming to this point takes a very long time, with the evidence usually needing to grow over		Coming to this point takes a very long time, with the evidence usually needing to grow over
	several releases. However, there is a point in the lifecycle of most software		several releases. However, there is a point in the lifecycle of most software
-	projects where someone offers to perform a ~~"bigbang"~~ change. Initially, the offer is declined	+	projects where someone offers to perform a [[Big Bang]] change. Initially, the offer is declined
	because everyone understands the rewrite will be painful and		because everyone understands the rewrite will be painful and
	costly. Yet, over the next releases, while the evidence mounts, the team		costly. Yet, over the next releases, while the evidence mounts, the team
Line 125:		Line 125:

	The Practical API Design book describes best practices to avoid the need for		The Practical API Design book describes best practices to avoid the need for
-	these ~~"big bang"~~ changes. First of all it explains what compatibility is and	+	these [[Big Bang]] changes. First of all it explains what compatibility is and
	advocates small, incremental, backwardly compatible changes, while always focusing on		advocates small, incremental, backwardly compatible changes, while always focusing on
-	future evolution. A mode of this kind does not need diruptive ~~"big bang"~~ changes at	+	future evolution. A mode of this kind does not need diruptive [[Big Bang]] changes at
	all. On the other hand, sometimes such large changes are necessary. That is why the book		all. On the other hand, sometimes such large changes are necessary. That is why the book
	discusses ways to provide alternative co-existent behaviors and explains how		discusses ways to provide alternative co-existent behaviors and explains how
Line 133:		Line 133:

	If we modularize our applications and treat each piece as a library with an		If we modularize our applications and treat each piece as a library with an
-	API, we can minimize the need for stop-the-world ~~"big bang"~~ rewrites and	+	API, we can minimize the need for stop-the-world [[Big Bang]] rewrites and
	replace them with continuous distributed improvements. This is maybe slightly		replace them with continuous distributed improvements. This is maybe slightly
	more expensive at first, but the long term cost of ownership is definitely		more expensive at first, but the long term cost of ownership is definitely