API Designer - Revision history

JaroslavTulach at 11:03, 3 September 2012

JaroslavTulach — Mon, 03 Sep 2012 11:03:06 GMT

←Older revision		Revision as of 11:03, 3 September 2012
Line 1:		Line 1:
-	Why did I ~~decided~~ to be an [[API Designer]] with a strong emphasis on [[BackwardCompatibility]]?	+	Why did I decide to be an [[API Designer]] with a strong emphasis on [[BackwardCompatibility]]?

	[[User:JaroslavTulach\|I]]'ve been working on the [[NetBeans]] project since middle of nineties. One day, I guess in a year 1999, a product manager stopped by and started to shout at me:''"We need partners, we need people to code plugins for NetBeans. We need compatibility. Are we compatible or not?"'' I started to explain we are		[[User:JaroslavTulach\|I]]'ve been working on the [[NetBeans]] project since middle of nineties. One day, I guess in a year 1999, a product manager stopped by and started to shout at me:''"We need partners, we need people to code plugins for NetBeans. We need compatibility. Are we compatible or not?"'' I started to explain we are

JaroslavTulach at 07:44, 3 September 2012

JaroslavTulach — Mon, 03 Sep 2012 07:44:59 GMT

←Older revision		Revision as of 07:44, 3 September 2012
Line 15:		Line 15:


-	User comment: Compatibility is highly important, but not broking compatibility sometimes can be complex (code difficult to read or problem for finding an asked method; by example). When an API need to be broken, then a good solution is broking API while insuring good binary compatibility by using a small compatibility layer for implementing old API on new API(s).	+	User comment by Daniel Latrémolière: Compatibility is highly important, but not broking compatibility sometimes can be complex (code difficult to read or problem for finding an asked method; by example). When an API need to be broken, then a good solution is broking API while insuring good binary compatibility by using a small compatibility layer for implementing old API on new API(s).

	If the compatibility layer (no big idea in its code then no need of copyright) is released under an AS IS licence like BSD, the API user can use its code for refactoring easier its own code from old API to new API (with help of IDE). By example a non-modular API can be refactored in a non-modularized compatibility layer (for old users) calling two modularity-aware API (for new/updated users).		If the compatibility layer (no big idea in its code then no need of copyright) is released under an AS IS licence like BSD, the API user can use its code for refactoring easier its own code from old API to new API (with help of IDE). By example a non-modular API can be refactored in a non-modularized compatibility layer (for old users) calling two modularity-aware API (for new/updated users).

	[[User:JaroslavTulach\|My reply]]: Thanks for leaving your comment. Yes, keeping the old [[API]]s around may complicate [[good\|time to market]] as newcomers may have hard time to find the way to do things ''right''. Sometimes one wants to ''send old API to a blackhole'' - actually the Chapter 19, [[End Of Life Procedures]] of [[TheAPIBook]] contains description how one can keep [[BackwardCompatibility]] and still get rid of the old, deprectated [[API]]s.		[[User:JaroslavTulach\|My reply]]: Thanks for leaving your comment. Yes, keeping the old [[API]]s around may complicate [[good\|time to market]] as newcomers may have hard time to find the way to do things ''right''. Sometimes one wants to ''send old API to a blackhole'' - actually the Chapter 19, [[End Of Life Procedures]] of [[TheAPIBook]] contains description how one can keep [[BackwardCompatibility]] and still get rid of the old, deprectated [[API]]s.

JaroslavTulach at 18:51, 2 September 2012

JaroslavTulach — Sun, 02 Sep 2012 18:51:48 GMT

←Older revision		Revision as of 18:51, 2 September 2012
Line 19:		Line 19:
	If the compatibility layer (no big idea in its code then no need of copyright) is released under an AS IS licence like BSD, the API user can use its code for refactoring easier its own code from old API to new API (with help of IDE). By example a non-modular API can be refactored in a non-modularized compatibility layer (for old users) calling two modularity-aware API (for new/updated users).		If the compatibility layer (no big idea in its code then no need of copyright) is released under an AS IS licence like BSD, the API user can use its code for refactoring easier its own code from old API to new API (with help of IDE). By example a non-modular API can be refactored in a non-modularized compatibility layer (for old users) calling two modularity-aware API (for new/updated users).

-	[User:JaroslavTulach\|My reply]]: Thanks for leaving your comment. Yes, keeping the old [[API]]s around may complicate [[good\|time to market]] as newcomers may have hard time to find the way to do things ''right''. Sometimes one wants to ''send old API to a blackhole'' - actually the Chapter 19, [[End Of Life Procedures]] of [[TheAPIBook]] contains description how one can keep [[BackwardCompatibility]] and still get rid of the old, deprectated [[API]]s.	+	[[User:JaroslavTulach\|My reply]]: Thanks for leaving your comment. Yes, keeping the old [[API]]s around may complicate [[good\|time to market]] as newcomers may have hard time to find the way to do things ''right''. Sometimes one wants to ''send old API to a blackhole'' - actually the Chapter 19, [[End Of Life Procedures]] of [[TheAPIBook]] contains description how one can keep [[BackwardCompatibility]] and still get rid of the old, deprectated [[API]]s.

JaroslavTulach at 18:51, 2 September 2012

JaroslavTulach — Sun, 02 Sep 2012 18:51:28 GMT

←Older revision		Revision as of 18:51, 2 September 2012
Line 18:		Line 18:

	If the compatibility layer (no big idea in its code then no need of copyright) is released under an AS IS licence like BSD, the API user can use its code for refactoring easier its own code from old API to new API (with help of IDE). By example a non-modular API can be refactored in a non-modularized compatibility layer (for old users) calling two modularity-aware API (for new/updated users).		If the compatibility layer (no big idea in its code then no need of copyright) is released under an AS IS licence like BSD, the API user can use its code for refactoring easier its own code from old API to new API (with help of IDE). By example a non-modular API can be refactored in a non-modularized compatibility layer (for old users) calling two modularity-aware API (for new/updated users).
		+
		+	[User:JaroslavTulach\|My reply]]: Thanks for leaving your comment. Yes, keeping the old [[API]]s around may complicate [[good\|time to market]] as newcomers may have hard time to find the way to do things ''right''. Sometimes one wants to ''send old API to a blackhole'' - actually the Chapter 19, [[End Of Life Procedures]] of [[TheAPIBook]] contains description how one can keep [[BackwardCompatibility]] and still get rid of the old, deprectated [[API]]s.

86.66.199.227: [Daniel Latrémolière] Delete my comment as you like

86.66.199.227 — Thu, 30 Aug 2012 18:26:37 GMT

[Daniel Latrémolière] Delete my comment as you like

←Older revision		Revision as of 18:26, 30 August 2012
Line 13:		Line 13:

	Don't be afraid to [[Talkback\|ask us]] to prepare an [[APIFest]] game for you! Find out why [[BackwardCompatibility]] matters!		Don't be afraid to [[Talkback\|ask us]] to prepare an [[APIFest]] game for you! Find out why [[BackwardCompatibility]] matters!
		+
		+
		+	User comment: Compatibility is highly important, but not broking compatibility sometimes can be complex (code difficult to read or problem for finding an asked method; by example). When an API need to be broken, then a good solution is broking API while insuring good binary compatibility by using a small compatibility layer for implementing old API on new API(s).
		+
		+	If the compatibility layer (no big idea in its code then no need of copyright) is released under an AS IS licence like BSD, the API user can use its code for refactoring easier its own code from old API to new API (with help of IDE). By example a non-modular API can be refactored in a non-modularized compatibility layer (for old users) calling two modularity-aware API (for new/updated users).

JaroslavTulach at 10:54, 30 August 2012

JaroslavTulach — Thu, 30 Aug 2012 10:54:43 GMT

←Older revision		Revision as of 10:54, 30 August 2012
Line 8:		Line 8:
	Up until that moment we treated [[BackwardCompatibility]] from a practical point of view. We were ready to sacrifice it when we had a vague feeling it does not matter to keep it. However that one moment changed everything.		Up until that moment we treated [[BackwardCompatibility]] from a practical point of view. We were ready to sacrifice it when we had a vague feeling it does not matter to keep it. However that one moment changed everything.

-	Since then I decided to treat compatibility seriously and keep 100% [[BackwardCompatibility]]. As I studied computer science at [[MatFyz\|mathematics and physics faculty]], I decided to apply as mathematical approach as I was able ~~and~~ find ways to really keep absolute compatibility. To transfer that knowledge to my colleagues I invented an [[APIFest]] game (described in [[Chapter 17]] of [[TheAPIBook]]). Playing ~~that came~~ really seems to ~~master~~ the 100% backward compatibility skills. It is a bit academic approach, in real world one is usually OK with "99%" compatibility, but by taking things to extreme, the [[APIFest]] nicely shows the point.	+	Since then I decided to treat compatibility seriously and keep 100% [[BackwardCompatibility]]. As I studied computer science at [[MatFyz\|mathematics and physics faculty]], I decided to apply as mathematical approach as I was able to find ways to really keep absolute compatibility. No excuses, no cheating, just 100% [[BackwardCompatibility]]. I guess [[NetBeans]] platform [[API]] compatibility history is a [[good]] proof showing we gained some knowledge in this respect.
		+
		+	To transfer that knowledge to my colleagues I invented an [[APIFest]] game (described in [[Chapter 17]] of [[TheAPIBook]]). Playing such game really seems to improve the 100% backward compatibility skills. It comes with a bit academic approach, in real world one is usually OK with "99%" compatibility, but by taking things to extreme, the [[APIFest]] nicely shows the point.

	Don't be afraid to [[Talkback\|ask us]] to prepare an [[APIFest]] game for you! Find out why [[BackwardCompatibility]] matters!		Don't be afraid to [[Talkback\|ask us]] to prepare an [[APIFest]] game for you! Find out why [[BackwardCompatibility]] matters!

JaroslavTulach at 08:16, 30 August 2012

JaroslavTulach — Thu, 30 Aug 2012 08:16:23 GMT

←Older revision		Revision as of 08:16, 30 August 2012
Line 10:		Line 10:
	Since then I decided to treat compatibility seriously and keep 100% [[BackwardCompatibility]]. As I studied computer science at [[MatFyz\|mathematics and physics faculty]], I decided to apply as mathematical approach as I was able and find ways to really keep absolute compatibility. To transfer that knowledge to my colleagues I invented an [[APIFest]] game (described in [[Chapter 17]] of [[TheAPIBook]]). Playing that came really seems to master the 100% backward compatibility skills. It is a bit academic approach, in real world one is usually OK with "99%" compatibility, but by taking things to extreme, the [[APIFest]] nicely shows the point.		Since then I decided to treat compatibility seriously and keep 100% [[BackwardCompatibility]]. As I studied computer science at [[MatFyz\|mathematics and physics faculty]], I decided to apply as mathematical approach as I was able and find ways to really keep absolute compatibility. To transfer that knowledge to my colleagues I invented an [[APIFest]] game (described in [[Chapter 17]] of [[TheAPIBook]]). Playing that came really seems to master the 100% backward compatibility skills. It is a bit academic approach, in real world one is usually OK with "99%" compatibility, but by taking things to extreme, the [[APIFest]] nicely shows the point.

-	Don't be afraid to [[Talkback\|ask us]] to prepare an [[APIFest]] game for you! Find out why [[BackwardCompatibility]] matters?	+	Don't be afraid to [[Talkback\|ask us]] to prepare an [[APIFest]] game for you! Find out why [[BackwardCompatibility]] matters!

JaroslavTulach at 08:16, 30 August 2012

JaroslavTulach — Thu, 30 Aug 2012 08:16:14 GMT

←Older revision		Revision as of 08:16, 30 August 2012
Line 10:		Line 10:
	Since then I decided to treat compatibility seriously and keep 100% [[BackwardCompatibility]]. As I studied computer science at [[MatFyz\|mathematics and physics faculty]], I decided to apply as mathematical approach as I was able and find ways to really keep absolute compatibility. To transfer that knowledge to my colleagues I invented an [[APIFest]] game (described in [[Chapter 17]] of [[TheAPIBook]]). Playing that came really seems to master the 100% backward compatibility skills. It is a bit academic approach, in real world one is usually OK with "99%" compatibility, but by taking things to extreme, the [[APIFest]] nicely shows the point.		Since then I decided to treat compatibility seriously and keep 100% [[BackwardCompatibility]]. As I studied computer science at [[MatFyz\|mathematics and physics faculty]], I decided to apply as mathematical approach as I was able and find ways to really keep absolute compatibility. To transfer that knowledge to my colleagues I invented an [[APIFest]] game (described in [[Chapter 17]] of [[TheAPIBook]]). Playing that came really seems to master the 100% backward compatibility skills. It is a bit academic approach, in real world one is usually OK with "99%" compatibility, but by taking things to extreme, the [[APIFest]] nicely shows the point.

-	Don't be afraid to [[Talkback\|ask us]] to prepare an [[APIFest]] game for you!	+	Don't be afraid to [[Talkback\|ask us]] to prepare an [[APIFest]] game for you! Find out why [[BackwardCompatibility]] matters?

JaroslavTulach at 08:15, 30 August 2012

JaroslavTulach — Thu, 30 Aug 2012 08:15:50 GMT

←Older revision		Revision as of 08:15, 30 August 2012
Line 8:		Line 8:
	Up until that moment we treated [[BackwardCompatibility]] from a practical point of view. We were ready to sacrifice it when we had a vague feeling it does not matter to keep it. However that one moment changed everything.		Up until that moment we treated [[BackwardCompatibility]] from a practical point of view. We were ready to sacrifice it when we had a vague feeling it does not matter to keep it. However that one moment changed everything.

-	Since then I decided to treat compatibility seriously and keep 100% [[BackwardCompatibility]]. As I studied computer science at [[MatFyz\|mathematics and physics faculty]], I decided to apply as mathematical approach as I was able and find ways to really keep absolute compatibility. To transfer that knowledge to my colleagues I invented an [APIFest]] game (described in [[Chapter 17]] of [[TheAPIBook]]). Playing that came really seems to master the 100% backward compatibility skills. It is a bit academic approach, in real world one is usually OK with "99%" compatibility, but by taking things to extreme, the [[APIFest]] nicely shows the point.	+	Since then I decided to treat compatibility seriously and keep 100% [[BackwardCompatibility]]. As I studied computer science at [[MatFyz\|mathematics and physics faculty]], I decided to apply as mathematical approach as I was able and find ways to really keep absolute compatibility. To transfer that knowledge to my colleagues I invented an [[APIFest]] game (described in [[Chapter 17]] of [[TheAPIBook]]). Playing that came really seems to master the 100% backward compatibility skills. It is a bit academic approach, in real world one is usually OK with "99%" compatibility, but by taking things to extreme, the [[APIFest]] nicely shows the point.

	Don't be afraid to [[Talkback\|ask us]] to prepare an [[APIFest]] game for you!		Don't be afraid to [[Talkback\|ask us]] to prepare an [[APIFest]] game for you!

JaroslavTulach: New page: Why did I decided to be an API Designer with a strong emphasis on BackwardCompatibility? I've been working on the NetBeans project since middle of nine...

JaroslavTulach — Thu, 30 Aug 2012 08:14:27 GMT

New page: Why did I decided to be an API Designer with a strong emphasis on BackwardCompatibility? I've been working on the NetBeans project since middle of nine...

New page

Why did I decided to be an [[API Designer]] with a strong emphasis on [[BackwardCompatibility]]?

[[User:JaroslavTulach|I]]'ve been working on the [[NetBeans]] project since middle of nineties. One day, I guess in a year 1999, a product manager stopped by and started to shout at me:''"We need partners, we need people to code plugins for NetBeans. We need compatibility. Are we compatible or not?"'' I started to explain we are
compatible - just a few methods and classes were renamed, deleted, but nobody
was supposed to use them anyway. The shouting however got even worse: ''"That is
not compatible! We need full backward compatibility! Keep it!"''

Up until that moment we treated [[BackwardCompatibility]] from a practical point of view. We were ready to sacrifice it when we had a vague feeling it does not matter to keep it. However that one moment changed everything.

Since then I decided to treat compatibility seriously and keep 100% [[BackwardCompatibility]]. As I studied computer science at [[MatFyz|mathematics and physics faculty]], I decided to apply as mathematical approach as I was able and find ways to really keep absolute compatibility. To transfer that knowledge to my colleagues I invented an [APIFest]] game (described in [[Chapter 17]] of [[TheAPIBook]]). Playing that came really seems to master the 100% backward compatibility skills. It is a bit academic approach, in real world one is usually OK with "99%" compatibility, but by taking things to extreme, the [[APIFest]] nicely shows the point.

Don't be afraid to [[Talkback|ask us]] to prepare an [[APIFest]] game for you!