JaroslavTulach: /* Got Your Game? */ - 2009-03-09 19:30:44

Got Your Game?

←Older revision Revision as of 19:30, 9 March 2009
Line 6: Line 6:
If you played game of this kind, please leave a note describing your experience.
If you played game of this kind, please leave a note describing your experience.
-
<comments/>
+
Just like the [[HPAPIFest09|HP guys]] that just finished their [[HPAPIFest09]].
== [[APIFest08|APIFest'08]] ==
== [[APIFest08|APIFest'08]] ==
{{:APIFest08:Report}}
{{:APIFest08:Report}}

JaroslavTulach: /* Got Your Game? */ - 2008-10-27 12:16:39

Got Your Game?

←Older revision Revision as of 12:16, 27 October 2008
Line 5: Line 5:
== Got Your Game? ==
== Got Your Game? ==
-
If you played game of this kind, please leave a note describing your experience:
+
If you played game of this kind, please leave a note describing your experience.
-
* [[APIFest08]]
+
-
 
+
<comments/>
<comments/>
 +
 +
== [[APIFest08|APIFest'08]] ==
 +
 +
{{:APIFest08:Report}}

JaroslavTulach at 17:10, 20 September 2008 - 2008-09-20 17:10:06

←Older revision Revision as of 17:10, 20 September 2008
Line 5: Line 5:
== Got Your Game? ==
== Got Your Game? ==
-
If you played game of this kind, please leave a note describing your experience.
+
If you played game of this kind, please leave a note describing your experience:
 +
* [[APIFest08]]
<comments/>
<comments/>

JaroslavTulach: /* Have You Ever Wondered...? */ - 2008-08-17 19:59:55

Have You Ever Wondered...?

←Older revision Revision as of 19:59, 17 August 2008
Line 1: Line 1:
-
== Have You Ever Wondered...? ==
+
== [[Have You Ever Wondered]]...? ==
After getting so far in the book you may ask: "OK, you told us how to write the APIs properly, but how am I supposed to transfer this knowledge to my peers?" The [[Using Games to Improve API Design Skills|chapter 17]] is here to teach you how to learn API Design by playing games. It is simple, entertaining and it really demonstrates the basic principles of backward compatibility and various types of API. Every time I participate in such ''API Fest'' I enjoy it very much.
After getting so far in the book you may ask: "OK, you told us how to write the APIs properly, but how am I supposed to transfer this knowledge to my peers?" The [[Using Games to Improve API Design Skills|chapter 17]] is here to teach you how to learn API Design by playing games. It is simple, entertaining and it really demonstrates the basic principles of backward compatibility and various types of API. Every time I participate in such ''API Fest'' I enjoy it very much.

JaroslavTulach at 20:27, 13 August 2008 - 2008-08-13 20:27:32

←Older revision Revision as of 20:27, 13 August 2008
Line 1: Line 1:
-
Learning by play.
+
== Have You Ever Wondered...? ==
 +
 
 +
After getting so far in the book you may ask: "OK, you told us how to write the APIs properly, but how am I supposed to transfer this knowledge to my peers?" The [[Using Games to Improve API Design Skills|chapter 17]] is here to teach you how to learn API Design by playing games. It is simple, entertaining and it really demonstrates the basic principles of backward compatibility and various types of API. Every time I participate in such ''API Fest'' I enjoy it very much.
 +
 
 +
== Got Your Game? ==
 +
 
 +
If you played game of this kind, please leave a note describing your experience.
 +
 
 +
<comments/>

Apidesign: Replacing page with 'Learning by play.' - 2008-06-14 06:32:42

Replacing page with 'Learning by play.'

←Older revision Revision as of 06:32, 14 June 2008
Line 1: Line 1:
-
'''Done: 619b3c11d015'''
+
Learning by play.
-
 
+
-
 
+
-
I think this section is wonderful in concept and well-done in execution.
+
-
 
+
-
I suggest adding some background about the developer participants: their experience, number of people, whether they worked in teams, etc. If there were few participants, it might even be useful to name your participants with pseudonyms instead of referring to "some participants", "other participants", "one very creative and interesting solution". Humanize them a bit.
+
-
 
+
-
("This was a nice and flexible solution" -> "Joe's solution was nice and flexible")
+
-
 
+
-
The names of some of the solutions, like day1/inputandsolution and subclassingsolution, seemed a little stilted to me. Slightly hard for me to wrap my head around. Don't know if there's any other way to refer to these things.
+
-
 
+
-
--[[User:Dmkoelle|Dmkoelle]] 02:30, 23 April 2008 (UTC)
+
-
 
+
-
I'm not sure this qualifies for a chapter in the book. Most parts of the book give advice (or go into lengthy discussions on why the reader should follow that advice). But this part describes a kind of workshop, an event that trains people to write better APIs. I would suggest turning it into an appendix.
+
-
 
+
-
--[[User:AndreiBadea|AndreiBadea]] 10:06, 23 April 2008 (UTC)
+
-
 
+
-
You have an static block in CircuitTest that has only a comment "Your code shall run without any permissions", but AFAIK this has no effect at runtime. I'd expect some usage of SecurityManager here instead, or a comment in the Javadoc instead of a static block.
+
-
 
+
-
'Tautology' is spelled as 'Taugology' in the link text for class Javadoc of CircuitTest.
+
-
 
+
-
Why does CircuitTest override setUp() and tearDown() to do nothing? Are you trying to avoid some behavior in the superclass' implementation?
+
-
 
+
-
It is nice that you warn us in certain places that it's our last chance to try these exercises on our own because you are going to reveal some details about it soon.
+
-
 
+
-
--[[User:TomWheeler|TomWheeler]] Wed Apr 23 20:38:48 CDT 2008
+

JaroslavTulach at 20:22, 25 April 2008 - 2008-04-25 20:22:48

←Older revision Revision as of 20:22, 25 April 2008
Line 1: Line 1:
 +
'''Done: 619b3c11d015'''
 +
 +
I think this section is wonderful in concept and well-done in execution.
I think this section is wonderful in concept and well-done in execution.

Tomwheeler at 02:38, 24 April 2008 - 2008-04-24 02:38:11

←Older revision Revision as of 02:38, 24 April 2008
Line 12: Line 12:
--[[User:AndreiBadea|AndreiBadea]] 10:06, 23 April 2008 (UTC)
--[[User:AndreiBadea|AndreiBadea]] 10:06, 23 April 2008 (UTC)
 +
 +
You have an static block in CircuitTest that has only a comment "Your code shall run without any permissions", but AFAIK this has no effect at runtime. I'd expect some usage of SecurityManager here instead, or a comment in the Javadoc instead of a static block.
 +
 +
'Tautology' is spelled as 'Taugology' in the link text for class Javadoc of CircuitTest.
 +
 +
Why does CircuitTest override setUp() and tearDown() to do nothing? Are you trying to avoid some behavior in the superclass' implementation?
 +
 +
It is nice that you warn us in certain places that it's our last chance to try these exercises on our own because you are going to reveal some details about it soon.
 +
 +
--[[User:TomWheeler|TomWheeler]] Wed Apr 23 20:38:48 CDT 2008

AndreiBadea at 10:06, 23 April 2008 - 2008-04-23 10:06:46

←Older revision Revision as of 10:06, 23 April 2008
Line 8: Line 8:
--[[User:Dmkoelle|Dmkoelle]] 02:30, 23 April 2008 (UTC)
--[[User:Dmkoelle|Dmkoelle]] 02:30, 23 April 2008 (UTC)
 +
 +
I'm not sure this qualifies for a chapter in the book. Most parts of the book give advice (or go into lengthy discussions on why the reader should follow that advice). But this part describes a kind of workshop, an event that trains people to write better APIs. I would suggest turning it into an appendix.
 +
 +
--[[User:AndreiBadea|AndreiBadea]] 10:06, 23 April 2008 (UTC)

Dmkoelle at 02:33, 23 April 2008 - 2008-04-23 02:33:38

←Older revision Revision as of 02:33, 23 April 2008
Line 1: Line 1:
-
I think this section is absolutely awesome, both in concept and execution.
+
I think this section is wonderful in concept and well-done in execution.
I suggest adding some background about the developer participants: their experience, number of people, whether they worked in teams, etc. If there were few participants, it might even be useful to name your participants with pseudonyms instead of referring to "some participants", "other participants", "one very creative and interesting solution". Humanize them a bit.
I suggest adding some background about the developer participants: their experience, number of people, whether they worked in teams, etc. If there were few participants, it might even be useful to name your participants with pseudonyms instead of referring to "some participants", "other participants", "one very creative and interesting solution". Humanize them a bit.
("This was a nice and flexible solution" -> "Joe's solution was nice and flexible")
("This was a nice and flexible solution" -> "Joe's solution was nice and flexible")
 +
 +
The names of some of the solutions, like day1/inputandsolution and subclassingsolution, seemed a little stilted to me. Slightly hard for me to wrap my head around. Don't know if there's any other way to refer to these things.
--[[User:Dmkoelle|Dmkoelle]] 02:30, 23 April 2008 (UTC)
--[[User:Dmkoelle|Dmkoelle]] 02:30, 23 April 2008 (UTC)