Teamwork - Revision history

JaroslavTulach at 09:20, 12 August 2010

JaroslavTulach — Thu, 12 Aug 2010 09:20:00 GMT

←Older revision		Revision as of 09:20, 12 August 2010
Line 12:		Line 12:

	{{:API Patch}}		{{:API Patch}}
		+
		+
		+	== Parallel Project Integration ==
		+
		+	Preventing mistakes as early as possible is a prerequisition for effective work in team. Read how we used [[Mercurial]] to isolate each other from mistakes that we, the [[clueless]] programmers, do daily.

JaroslavTulach: /* Accepting Patches */

JaroslavTulach — Sun, 18 Apr 2010 08:02:58 GMT

Accepting Patches

←Older revision		Revision as of 08:02, 18 April 2010
Line 11:		Line 11:
	== Accepting Patches ==		== Accepting Patches ==

-	~~Encouraging community to seek for bugs in an [[~~API]] and provide patches to its behaviour is a best way to make the [[API]] really usable. On the other hand, one needs to be careful to not accept bad patches. The [[Teamwork\|chapter 16]] describes strategies to evaluate quality of submitted patches and separate the perils from dust. In addition to that here is a little trick, called [[CodeInjection\|code injection]], that can help balance the need for extensibility while lowering overall [[Cost of Ownership]].	+	{{:API Patch}}

JaroslavTulach: /* Accepting Patches */

JaroslavTulach — Sun, 11 Jan 2009 06:36:04 GMT

Accepting Patches

←Older revision		Revision as of 06:36, 11 January 2009
Line 11:		Line 11:
	== Accepting Patches ==		== Accepting Patches ==

-	Encouraging community to seek for bugs in an [[API]] and provide patches to its behaviour is a best way to make the [[API]] really usable. On the other hand, one needs to be careful to not accept bad patches. The [[Teamwork\|chapter 16]] describes strategies to evaluate quality of submitted patches and separate the perils from dust. In addition to that here is a little trick, called [[CodeInjection\|code injection]] that can help balance the need for extensibility while lowering overall [[Cost of Ownership]].	+	Encouraging community to seek for bugs in an [[API]] and provide patches to its behaviour is a best way to make the [[API]] really usable. On the other hand, one needs to be careful to not accept bad patches. The [[Teamwork\|chapter 16]] describes strategies to evaluate quality of submitted patches and separate the perils from dust. In addition to that here is a little trick, called [[CodeInjection\|code injection]], that can help balance the need for extensibility while lowering overall [[Cost of Ownership]].

JaroslavTulach: /* Accepting Patches */

JaroslavTulach — Sun, 11 Jan 2009 06:35:26 GMT

Accepting Patches

←Older revision		Revision as of 06:35, 11 January 2009
Line 11:		Line 11:
	== Accepting Patches ==		== Accepting Patches ==

-	Encouraging community to seek for bugs in an [[API]] and provide patches to its behaviour is a best way to make the [[API]] really usable. On the other hand, one needs to be careful to not accept bad patches. The [[Teamwork\|chapter]] describes strategies to evaluate quality of submitted patches and separate the perils from dust. In addition to that here is a little trick, called [[CodeInjection\|code injection]] that can help balance the need for extensibility while lowering overall [[Cost of Ownership]].	+	Encouraging community to seek for bugs in an [[API]] and provide patches to its behaviour is a best way to make the [[API]] really usable. On the other hand, one needs to be careful to not accept bad patches. The [[Teamwork\|chapter 16]] describes strategies to evaluate quality of submitted patches and separate the perils from dust. In addition to that here is a little trick, called [[CodeInjection\|code injection]] that can help balance the need for extensibility while lowering overall [[Cost of Ownership]].

JaroslavTulach: /* Accepting Patches */

JaroslavTulach — Sun, 11 Jan 2009 06:33:43 GMT

Accepting Patches

←Older revision		Revision as of 06:33, 11 January 2009
Line 11:		Line 11:
	== Accepting Patches ==		== Accepting Patches ==

-	Encouraging community to seek for bugs in an [[API]] and provide patches to its behaviour is a best way to make the [[API]] really usable. On the other hand, one needs to be careful to not accept bad patches. The [[Teamwork\|chapter]] describes strategies to evaluate quality of submitted patches and separate the perils from dust. In addition to that here is a little trick, called [[~~Code Injection~~]] that can help balance the need for extensibility while lowering overall [[Cost of Ownership]].	+	Encouraging community to seek for bugs in an [[API]] and provide patches to its behaviour is a best way to make the [[API]] really usable. On the other hand, one needs to be careful to not accept bad patches. The [[Teamwork\|chapter]] describes strategies to evaluate quality of submitted patches and separate the perils from dust. In addition to that here is a little trick, called [[CodeInjection\|code injection]] that can help balance the need for extensibility while lowering overall [[Cost of Ownership]].

JaroslavTulach at 06:33, 11 January 2009

JaroslavTulach — Sun, 11 Jan 2009 06:33:23 GMT

←Older revision		Revision as of 06:33, 11 January 2009
Line 8:		Line 8:

	--[[User:JaroslavTulach\|JaroslavTulach]] 16:05, 17 July 2008 (UTC)		--[[User:JaroslavTulach\|JaroslavTulach]] 16:05, 17 July 2008 (UTC)
		+
		+	== Accepting Patches ==
		+
		+	Encouraging community to seek for bugs in an [[API]] and provide patches to its behaviour is a best way to make the [[API]] really usable. On the other hand, one needs to be careful to not accept bad patches. The [[Teamwork\|chapter]] describes strategies to evaluate quality of submitted patches and separate the perils from dust. In addition to that here is a little trick, called [[Code Injection]] that can help balance the need for extensibility while lowering overall [[Cost of Ownership]].

JaroslavTulach at 19:58, 17 August 2008

JaroslavTulach — Sun, 17 Aug 2008 19:58:43 GMT

←Older revision		Revision as of 19:58, 17 August 2008
Line 1:		Line 1:
-	Most people seem to be able to keep design consistency when they work alone, however software projects of today and of the future are designed by teams. Keeping consistency in such environment is much harder. ~~There are many~~ aspects ~~that~~ need to be verified and checked, ~~however the initial~~ and ~~most important one seems to be~~ the [[APIReview]] process.	+	== [[Have You Ever Wondered]]...? ==
		+
		+	There is a common wisdom among programmers saying that ''design cannot be done by committee''. However how can we design bigger and bigger systems without designing in teams? Does not that hurt consistency? Yes, partially. Most people seem to be able to keep design consistency when they work alone, however software projects of today and of the future are designed by teams. Keeping consistency in such environment is much harder, but it is possible. [[Teamwork\|Chapter 16]] describes what aspects need to be verified and checked, and introduces the [[APIReview]] process which is capable of doing so.

	== Convincing Developers to Document Their API ==		== Convincing Developers to Document Their API ==

JaroslavTulach at 16:05, 17 July 2008

JaroslavTulach — Thu, 17 Jul 2008 16:05:19 GMT

←Older revision		Revision as of 16:05, 17 July 2008
Line 1:		Line 1:
	Most people seem to be able to keep design consistency when they work alone, however software projects of today and of the future are designed by teams. Keeping consistency in such environment is much harder. There are many aspects that need to be verified and checked, however the initial and most important one seems to be the [[APIReview]] process.		Most people seem to be able to keep design consistency when they work alone, however software projects of today and of the future are designed by teams. Keeping consistency in such environment is much harder. There are many aspects that need to be verified and checked, however the initial and most important one seems to be the [[APIReview]] process.
		+
		+	== Convincing Developers to Document Their API ==
		+
		+	The [[Teamwork]] chapter also contains section called ''Convincing Developers to Document Their API''. One note there nit picks on [[GeertjanWielenga]] for being afraid to modify [[wikipedia::Javadoc\|Javadoc]]. After many weeks of convincing him, I am happy to report success! As [[GeertjanWielenga\|Geertjan]] just disclosed on [http://blogs.sun.com/geertjan/entry/my_1st_contribution_to_netbeans his blog], he finally changed javadoc to point to one of his tutorials. Perfect! [[GeertjanWielenga\|Geertjan]] confesses that the final reason that forced him to fulfil his promise lies in the fact that I used a tape recorder and recorded him swearing to do it. Maybe, this may be the final decision contributor, but not the most important one! The most important moment happened a month ago when, by an accident, I disclosed to [[GeertjanWielenga\|Geertjan]] that [[wikipedia::Javadoc\|Javadoc]] is just an [[wikipedia::HTML\|HTML]] text. Before that [[GeertjanWielenga\|Geertjan]] probably thought that the [[wikipedia::Javadoc\|Javadoc]] is something complicated and was afraid of it. When Geerjan realized that it is just another version of HTML, his fear started to disappear. That was the ''breakpoint''. Then it took just one month and one pub visit to remove it completely. [[GeertjanWielenga\|Geertjan]], I am glad, you managed to make such a significant step on your road to be API guru!
		+
		+	--[[User:JaroslavTulach\|JaroslavTulach]] 16:05, 17 July 2008 (UTC)

JaroslavTulach at 07:42, 15 July 2008

JaroslavTulach — Tue, 15 Jul 2008 07:42:52 GMT

←Older revision		Revision as of 07:42, 15 July 2008
Line 1:		Line 1:
-	Most people seem to be able to keep design consistency when they work alone, however software projects of today and of the future are designed by teams. Keeping consistency in such environment is much harder...	+	Most people seem to be able to keep design consistency when they work alone, however software projects of today and of the future are designed by teams. Keeping consistency in such environment is much harder. There are many aspects that need to be verified and checked, however the initial and most important one seems to be the [[APIReview]] process.

Apidesign: New page: Most people seem to be able to keep design consistency when they work alone, however software projects of today and of the future are designed by teams. Keeping consistency in such environ...

Apidesign — Sat, 14 Jun 2008 06:26:56 GMT

New page: Most people seem to be able to keep design consistency when they work alone, however software projects of today and of the future are designed by teams. Keeping consistency in such environ...

New page

Most people seem to be able to keep design consistency when they work alone, however software projects of today and of the future are designed by teams. Keeping consistency in such environment is much harder...