Using Games to Improve API Design Skills

From APIDesign

Done: 619b3c11d015

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.

--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.

--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.

--TomWheeler Wed Apr 23 20:38:48 CDT 2008